Encryption addresses confidentiality; WORM addresses modification/deletion protection for a defined scope and period. A policy checkbox is not end-to-end engine acceptance; validate the installed release and repository support.
Screenshots were captured from the actual lab interface on 16 October 2026. The interface is in English; explanations follow your selected language. Resource names, dates and settings are examples; use values for your own environment.
Visual note: the earlier real VM Advanced Settings screen is reused. Encryption and Worm Protection fields are visible; an unsaved lab draft is not operational acceptance. No settings, keys or protection periods were changed, and no backup/restore or deletion test was run while preparing this guide.
Installed release, engine and repository identity
Access, key and recovery owners
Isolated test data and acceptance plan
Catalog evidence and restore verification
01
1. Define the protection scope
Define which backups, manifests and data chunks must be protected and until when. Backup retention, archive and replication periods are not the same assurance. A retention policy alone is not immutability acceptance.
Expected result
Protected data and the end time are defined.
02
2. Check backend and release compatibility
The RustFS native WORM contract is not a claim of completed production support. The deployed build requires EraBackup compatibility tests, bucket versioning and readable Object Lock configuration. An S3-compatible label does not guarantee identical behavior across providers.
Expected result
Repository support is matched to evidence.
03
3. Validate the Worm Protection option
The real VM Advanced Settings screen includes Worm Protection; the form submits a worm boolean. A checkbox alone does not establish Object Lock or retention on all chunks. Confirm support and consequences before enabling protection.
Real VM Policy Advanced Settings screen with Encryption and Worm Protection options. This is an earlier unsaved lab draft, not evidence of encrypted data or backend immutability acceptance. Enlarge ↗
Expected result
The policy request is separated from backend enforcement.
04
4. Plan periods, permissions and capacity
Verify expiry, clock accuracy, required capacity and service-account permissions. If Governance/Compliance or legal hold options exist, review the backend contract; this guide does not claim EraBackup UI support for all of them. Do not experiment with irreversible periods/modes in production.
Expected result
The operational effect of the protection period is documented.
05
5. Plan enforcement acceptance with an isolated object
The RustFS contract requires a retained test object to reject early overwrite/delete. Use only explicitly isolated test data and an approved test plan; never attempt deletion of a real recovery point. Use error codes and backend evidence to distinguish protection enforcement from unrelated request failures.
Expected result
Acceptance criteria for early overwrite/delete rejection are established.
06
6. Match manifest and chunk evidence
The contract requires backup manifests and every referenced new chunk to receive the requested retention metadata, with evidence stored in the catalog. Validate shared chunks and retention/GC separately. One protected object does not establish protection of the entire chain; do not claim WORM: active with missing evidence.
Expected result
Chain coverage is matched to catalog evidence.
07
7. Validate restore and post-expiry operations
Plan restore to an isolated target and data acceptance during protection. Expiry does not mean immediate automatic deletion; chain references, policy and GC conditions still apply. WORM does not replace another copy, access control, encryption or disaster-recovery testing.
Expected result
Protection and recovery acceptance are documented together.
COMMON QUESTIONS
Does selecting Worm Protection make every backup immutable?
No. Engine/backend support, versioning/Object Lock, actual enforcement, manifest/chunk retention and catalog evidence must be verified together. Open acceptance gates in the RustFS design are not a completed production guarantee.