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. Define the source role and data scope
First choose the objective: protect files into a RustFS repository, extract existing EraBackup RustFS catalog content, or protect an independent S3 bucket source. General support for the last case was not verified here; do not reuse the procedure without endpoint/release-specific technical acceptance.
Expected resultThe relevant scope and acceptance evidence are recorded.
022. Verify access and the actual destination
With the repository administrator, validate RustFS endpoint, bucket/tenant prefix, CA/TLS, quota and authorized service identity. The local design uses the S3 API rather than s3fs/NFS/SMB/FUSE mounting. Access keys belong to repository pool configuration; keep them out of policy names and screenshots.
Expected resultThe relevant scope and acceptance evidence are recorded.
033. Select the Storage Policy source and destination
Review Policy & Storage under Home → Policies → Storage Policy → Create Storage Backup Policy. Compare Policy Name, Source storage and Backup destination identities. Source and destination cannot be the same. The inspected template blocks RustFS-to-RustFS policy copy as unsupported; do not hide this limitation by selecting a different destination.
Expected resultThe relevant scope and acceptance evidence are recorded.
044. Explicitly select paths in Source Content
For a mounted source → RustFS destination, select test paths from the Source Content tree. A RustFS source selection shows existing repository catalog content; do not assume it lists every S3 bucket version. Record catalog/policy/backup identity together with the selected path.
Expected resultThe relevant scope and acceptance evidence are recorded.
055. Plan preflight, scheduling and capacity
Validate the engine/scheduler release. The local engine document checks mounts, selected paths, storage and repository access using --validate-policy. The documented scheduler selects Full without a base and Incremental with an active catalog; do not generalize to every release. Validate weekly/monthly day behavior against the installed UI/release. Do not start a second concurrent job for the same policy.
Expected resultThe relevant scope and acceptance evidence are recorded.
066. Accept Full and incremental catalog results
In an approved small test, compare task results, storageJobs catalog records and repository output. A notification or exit_code=0 alone is not content acceptance. Record Full and dependent incremental identities and check access to the entire required chain. Do not treat the 18 September RustFS development acceptance as production acceptance of the current installation.
Expected resultThe relevant scope and acceptance evidence are recorded.
077. Complete restore and metadata testing
Use the separate S3 restore guide to extract test files from the repository and verify hashes and application access. Retention/GC, interruption/retry, scale and WORM production gates remain open in the local design. Do not assume bucket versioning or Object Lock has been configured.
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.