Scheduling, methods, retention chains and physical deletion/immutability are separate concerns. A generic VM screen does not establish identical behavior for Storage Policy or database engines; validate the installed scheduler/backend separately.
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/action limit: real VM Policy Advanced Settings/Schedules screens from the earlier authorized inspection are reused unchanged. Displayed days/times/durations are lab examples, not evidence of every platform’s runtime behavior. No policy, Start Now, schedule/retention changes or cleanup/GC/deletion were performed.
Platform/method and policy identity
Calendar, time zone and Full/incremental chain
Repository reservations and retention capacity
Isolated restore and measured acceptance point
01
1. Define retention requirements with the data owner
Record historical recovery needs, operational windows, change rates and organizational retention requirements. This guide does not set legal/compliance durations; use authorized organizational policy. RPO, restore-point age and retention duration are different measures.
Expected result
Policy scope and the relevant acceptance result are recorded.
02
2. Separate Backup, Archive and Replication fields
Compare Backup Retention Time and any Archive Retention Time/Replication Retention Time in Advanced Settings against the installed release/method. Options may come from periods records in days/weeks/months/years; validate units and interpretation. Visible fields do not establish accepted archive/replication data paths for every platform.
Earlier real Advanced Settings screen: Backup Retention Time and policy options. This image is not cleanup/GC, WORM or all-engine retention acceptance. Enlarge ↗
Expected result
Policy scope and the relevant acceptance result are recorded.
03
3. Plan Full bases and dependent chains together
Preserve required bases for incremental/differential/WAL/binlog/oplog pieces. Existing Full-set incrementals may remain pinned to the old repository after a policy storage change; catalog repository_id is authoritative. Never manually delete Full objects/chunks solely by age. Validate chain dependencies and retention/GC acceptance for the engine.
Expected result
Policy scope and the relevant acceptance result are recorded.
04
4. Account for Last cycle protection
The inspected VM Advanced Settings screen describes Last cycle protection as retaining an additional cycle until the new cycle completes. It needs extra capacity; calculate overlap, reservations and new-Full duration. The checkbox description is not a universal guarantee of working chain-safe cleanup; validate it in an approved test.
Expected result
Policy scope and the relevant acceptance result are recorded.
05
5. Validate capacity and backend limits
Compare available/min_free/reserved/reservable values with Full-cycle size and incremental growth. Repository retention, bucket lifecycle, NAS snapshots and Object Lock/WORM are different mechanisms. RustFS documentation lists open production gates for retention/GC, faults, scale and TLS/WORM; selecting a duration does not guarantee immutability.
Expected result
Policy scope and the relevant acceptance result are recorded.
06
6. Plan retention changes and deletion effects
Record current catalogs, last-good points and referenced repositories. Validate retrospective effects of shorter retention and cleanup timing in the installed release; do not assume immediate space reclamation. Disabling a pool blocks uploads, not data; do not unmount/remove a pool with restore references. This inspection changed no retention, lifecycle or GC.
Expected result
Policy scope and the relevant acceptance result are recorded.
07
7. Accept the oldest required point through restore
In an approved small test inspect new cycles, protected older cycles and required references. Validate the oldest required and latest points through isolated restore of data/hashes/applications. Compare cleanup logs and capacity together; a disappearing catalog row does not prove safe physical deletion or reclaimed space.
Expected result
Policy scope and the relevant acceptance result are recorded.
COMMON QUESTIONS
Does a schedule or retention field guarantee data protection?
No. Validate actual execution, chain access, capacity and isolated data recovery separately. Retention duration does not guarantee WORM or immutability.