Immutable on Arrival: Default Bucket Retention on Z1 Storage

23 July 2026 Cloud Storage

Default bucket retention: every object locked automatically on arrival

The strongest backup protection is the kind nobody has to remember to apply. With a default retention rule on a Z1 Storage bucket, every object written to it is automatically locked the moment it arrives — no lock headers in your backup tool, no client-side configuration, no human in the loop. Point Veeam, Duplicati, Duplicacy, MSP360 or any S3-compatible tool at the bucket, and every restore point is immutable on arrival.

How it works

A default retention rule lives on the bucket itself. When any object is PUT without explicit lock headers, the bucket applies its default — a mode (governance or compliance) and a period (say, 30 days) — automatically. Verified against s3.z1storage.com: defaults apply to every new object, are configurable and removable via PutObjectLockConfiguration, and behave exactly as on AWS.

Setting it up

  1. Create a bucket with Object Lock enabled — Advanced Settings → Object lock → Enabled at creation time (it cannot be added later; versioning comes on automatically).

  2. Set the default retention rule, either in your client portal's bucket settings or via the API:

    $ aws s3api put-object-lock-configuration --bucket vault \
    --object-lock-configuration '{
      "ObjectLockEnabled": "Enabled",
      "Rule": { "DefaultRetention": { "Mode": "GOVERNANCE", "Days": 30 } }
    }' --endpoint-url https://s3.z1storage.com

  3. Point your backup tool at the bucket. That's it — nothing to change in the tool itself. Each new backup object is locked for 30 days from the moment it lands.

Choosing mode and period

  • Governance — protected against ordinary deletion, but operators with bypass rights keep an escape hatch. The right default for most operational backups.
  • Compliance — true WORM; nobody, including the account owner, can remove a locked version early. Choose deliberately: a mis-sized compliance rule cannot be shortened, and you will store every locked version until it expires.
  • Period — long enough to cover how long a breach might go unnoticed; short enough that storage costs stay sane. 14–30 days suits most recent-backup protection; regulated data may justify more.

The one setting people forget: lifecycle

A lock-enabled bucket keeps object versions until retention expires — and with versioning on, old versions accumulate. Configure a lifecycle policy alongside your default retention so expired versions are cleaned up and storage doesn't grow without bound. One caution from our testing, in the other direction: do not enable versioning-plus-lock on a bucket used by backup tooling without a retention rule and then apply aggressive lifecycle policies — lifecycle deletions can remove objects that a backup archive chain still depends on. Default retention plus a matching lifecycle window is the safe pairing.

Verify it took

$ aws s3 cp test.txt s3://vault/ --endpoint-url https://s3.z1storage.com
$ aws s3api get-object-retention --bucket vault --key test.txt \
    --endpoint-url https://s3.z1storage.com
{ "Retention": { "Mode": "GOVERNANCE", "RetainUntilDate": "..." } }

Then try to delete the version — and enjoy the AccessDenied. For the full picture of what locked versions will and won't allow, see Object Lock on Z1: independently verified.

Immutability used to require careful per-job configuration. On Z1 Storage it is one rule on one bucket — sign up, first 10GB free, and make your backups immutable by default.

Tags:
Share