Reader and distinct contribution
Follow-up to #597 and the September 14 Timelock article's proposed extension: A Delete Succeeded. Did the Backup Survive?
The offline Timelock model tests a synthetic mutation policy. This proposal would test a disposable versioned store's administrative retention boundary and whether the original bytes remain recoverable. Its contribution is a version-aware evidence manifest, with deliberate controls, rather than another broad backup-settings guide. The nearest existing Proxmox/HA posts discuss backup layers and availability; #597 explicitly does not execute this product exercise.
Verified primary source
Amazon S3 Object Lock documentation, read September 11, 2026: governance bypass requires the appropriate permission and request header; compliance restrictions include the account root user, with account deletion separately documented as an exception. Protection applies to a version; a simple delete can create a delete marker while the protected version remains. Published documentation is the current evidence, not an observation of a performed cloud experiment.
The Timelock paper, OSDI July 2026, supplies motivation for separating host/admin authority from enforcement. Do not describe this product exercise as a Timelock Drive replication.
Proposed experiment
Use only newly generated synthetic bytes in a dedicated disposable versioned store. Before execution, specify provider/version, retention modes and durations, expected results, least-privilege identities, request limit, maximum stored bytes, estimated charges, stopping rules and eventual cleanup. An initial target is at most 10 small objects and 30 explicit requests; adapt only with a recorded reason and authorized budget. Avoid any existing backup bucket, real recovery data or root-account credentials.
Record a manifest containing object/version identifier, expected original-byte hash, mode, retained-until time, request timestamp, logical actor/permissions, operation, expected result, actual status and recovered-byte hash. Keep credentials out of artifacts; retain failed requests and unexpected outcomes.
Compare:
- Governance mode without bypass permission/header, then an explicitly authorized bypass control.
- Compliance mode under least-privilege test identities: early version deletion and retention shortening should fail according to documented policy. Root/account-deletion exceptions remain documentation-only; never test account deletion.
- A simple delete marker versus a permanent version-specific delete; list versions and retrieve the original version explicitly.
- Recovery of the original bytes while protected, then successful version deletion after expiry as a positive control. Do not shorten compliance retention merely to make cleanup convenient.
A successful simple delete alone neither falsifies retention nor demonstrates loss. An unexpectedly successful early version deletion, permitted policy shortening, or inability to retrieve the expected retained bytes requires investigation; do not hide it behind an aggregate pass count. A local emulator, if used, supports claims only about that emulator and cannot establish AWS behavior.
Acceptance and authority
This issue records a proposal. Creating it does not authorize live cloud calls, paid resources, changes to account permissions, or deletion of existing data. Complete independent design work first; obtain any authorization missing from the active session before those operations.
Reader and distinct contribution
Follow-up to #597 and the September 14 Timelock article's proposed extension: A Delete Succeeded. Did the Backup Survive?
The offline Timelock model tests a synthetic mutation policy. This proposal would test a disposable versioned store's administrative retention boundary and whether the original bytes remain recoverable. Its contribution is a version-aware evidence manifest, with deliberate controls, rather than another broad backup-settings guide. The nearest existing Proxmox/HA posts discuss backup layers and availability; #597 explicitly does not execute this product exercise.
Verified primary source
Amazon S3 Object Lock documentation, read September 11, 2026: governance bypass requires the appropriate permission and request header; compliance restrictions include the account root user, with account deletion separately documented as an exception. Protection applies to a version; a simple delete can create a delete marker while the protected version remains. Published documentation is the current evidence, not an observation of a performed cloud experiment.
The Timelock paper, OSDI July 2026, supplies motivation for separating host/admin authority from enforcement. Do not describe this product exercise as a Timelock Drive replication.
Proposed experiment
Use only newly generated synthetic bytes in a dedicated disposable versioned store. Before execution, specify provider/version, retention modes and durations, expected results, least-privilege identities, request limit, maximum stored bytes, estimated charges, stopping rules and eventual cleanup. An initial target is at most 10 small objects and 30 explicit requests; adapt only with a recorded reason and authorized budget. Avoid any existing backup bucket, real recovery data or root-account credentials.
Record a manifest containing object/version identifier, expected original-byte hash, mode, retained-until time, request timestamp, logical actor/permissions, operation, expected result, actual status and recovered-byte hash. Keep credentials out of artifacts; retain failed requests and unexpected outcomes.
Compare:
A successful simple delete alone neither falsifies retention nor demonstrates loss. An unexpectedly successful early version deletion, permitted policy shortening, or inability to retrieve the expected retained bytes requires investigation; do not hide it behind an aggregate pass count. A local emulator, if used, supports claims only about that emulator and cannot establish AWS behavior.
Acceptance and authority
This issue records a proposal. Creating it does not authorize live cloud calls, paid resources, changes to account permissions, or deletion of existing data. Complete independent design work first; obtain any authorization missing from the active session before those operations.