BEFORE YOU BEGIN
Check before you begin
In this guide NAS is a filesystem source mounted by an administrator. Validate NFS/SMB access, service identity and mount scope for the installed release; do not assume vendor snapshot, NDMP or whole-volume recovery support.
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
Recheck NAS export/share and mount identity. The inspected storage restore form offers only Original Location and its handler sends pos=orjinal. Do not assume a different folder or new NAS destination has been selected. Stop before final Restore until overwrite/collision behavior is validated; agree an isolated-destination procedure 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 destination file count, paths, sizes and SHA-256 values with the sample list. Test opening files as the expected user/service identity. Separately accept NAS ACL/owner, UID/GID, timestamps and special metadata; a successful task does not guarantee them.
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.