BEFORE YOU BEGIN
Check before you begin
The locally evidenced path is the RustFS native repository and EraBackup catalog workflow. General source backup of every S3 endpoint/bucket, bucket versions, delete markers, metadata, Object Lock/WORM and cross-region copying were not verified. Selecting a RustFS catalog source is not arbitrary S3 bucket crawling.
Live verification limit: Firefox lab control could not reliably read page content; no NAS/S3 policy or restore screen was captured in this inspection. Steps are based on local Storage Policy templates and RustFS engine documentation. Another workflow’s screenshot was not substituted; no policy, bucket, mount, backup or restore was created. The installed release and end-to-end data acceptance require separate validation.
- Source/destination storage identity, release and data scope
- Access, TLS, service identity and capacity
- Full/incremental chain, catalog and retention
- Isolated acceptance destination, hashes and metadata checks
011. Find the correct catalog and recovery point
Match the storage job in Backup List to source storage, policy and date. Record Full and any Incremental identities; storageJobs and the repository chain must identify the same point. A VM Object Restore menu is not the same workflow as Storage Policy or general S3 bucket recovery.
Expected resultThe relevant scope and acceptance evidence are recorded.
022. Check chain and repository access
The requested date’s Full base and required incremental data must be accessible. Verify credentials, TLS, tenant/prefix, repository pool and capacity. Listing an object does not prove readable contents or an intact chain. Do not rely on the latest catalog row when lifecycle/GC may have removed objects.
Expected resultThe relevant scope and acceptance evidence are recorded.
033. Establish effects on existing destination data
Recovering files from an S3 repository and writing objects/versions back into a bucket are different operations. The inspected Storage Policy restore form uses only Original Location and pos=orjinal. A generic endpoint/bucket/key/version target form was not verified. Do not assume preservation of keys/metadata/ACL or restore to another bucket; validate destination effects with the technical team.
Expected resultThe relevant scope and acceptance evidence are recorded.
044. Compare selection and the final summary
Compare policy, source storage, fullbackupset_id/incbackupset_id, selected content and destination effects in one acceptance plan. Do not copy example --restore-full-id and --restore-inc-id numbers from the engine document into a real environment. Do not start restore through an alternative command before UI and engine destination behavior are validated in the same release.
Expected resultThe relevant scope and acceptance evidence are recorded.
055. Monitor an approved small test
Execute final Restore only in a test with validated destination effects and scope. Monitor queue, task, engine result and repository/datamover logs together. On partial failure or interruption, do not blindly rerun against the same destination; establish what was written first. No restore was submitted while preparing this guide.
Expected resultThe relevant scope and acceptance evidence are recorded.
066. Independently verify contents and access
Compare extracted paths, counts, sizes and SHA-256 values with recorded samples. If S3 bucket-source recovery is required, assess version IDs, delete markers, Content-Type, user metadata, tags, ACL and encryption as separate technical scope; these features were not verified in this inspection.
Expected resultThe relevant scope and acceptance evidence are recorded.
077. Record acceptance and retention planning
Record backup identities, installed releases, source/destination, data/hash results, duration and errors. Complete access acceptance with the application owner. Repository retention, bucket lifecycle/Object Lock and NAS snapshot retention are different mechanisms. Do not delete chains or catalogs before acceptance; this inspection performed no deletion/GC.
Expected resultThe relevant scope and acceptance evidence are recorded.
COMMON QUESTIONS
Does S3 compatibility guarantee all recovery features?
No. Endpoint, release, source type, metadata, versioning, retention and destination behavior require separate validation. Repository acceptance is not general bucket-source backup acceptance.