S3 versioning is not a backup: protecting buckets with Object Lock

Friday, 5:40 pm. A clean-up job is meant to delete old exports, but the prefix variable is empty, and aws s3 rm s3://shop-media/$PREFIX --recursive becomes a command for the whole bucket. 180,000 product images are gone. Versioning is on; two hours later everything is back. They were lucky: the recovery meant removing 180,000 delete markers – with the very delete right an attacker holding that key would have had.

S3 versioning is a bucket setting that keeps an object’s previous state as an older version in the same bucket whenever it is overwritten or deleted. A backup, by contrast, is a copy that lives somewhere else, is kept for a fixed time and cannot be removed by the thing it protects against.

What S3 versioning protects – and what it does not

Versioning catches the common mistakes: an overwrite keeps the old state as a version, a simple delete only sets a delete marker. It survives nothing beyond that:

• A deleted bucket. A bucket can only be deleted once it is empty – but whoever may delete versions can empty it. After that, every version is gone.
• A compromised key. Most application keys may delete. A DeleteObject with a version ID removes an old state for good – a script does thousands in minutes.
• A lifecycle rule gone wrong. A rule with NoncurrentDays set to 1, meant to save money, clears every old version a day after it was overwritten.
• The loss of a region or project. The versions share the original’s region, project and billing.

Is replication a backup?

Replication copies new objects into a second bucket, often in another region. That helps in a regional outage, but it carries over whatever is written: if ransomware encrypts your files, the encrypted versions arrive in the destination on time. At AWS, delete markers travel only if configured – not by default in the current rule format. Deleting a specific version is deliberately never replicated, to guard against malicious deletes.

Replication also has no restore point – “Tuesday night’s state” for the whole bucket – and the destination usually sits in the same account, with the same administrators. Replication makes data available; a backup makes it recoverable.

What a real bucket backup needs

• Another location. A Scaleway project just for backups, in a different region from the originals – nl-ams for buckets in fr-par.
• A key that cannot delete. The nightly job writes with a key that can read and write but not delete.
• Object Lock with a retention period. Every version written is locked until a date; deleting and overwriting it are refused.
• Restore points. Per run, a list of which version of each object belongs to that state.
• Tested restores and alerts. A backup only counts once a restore has worked; a missed run has to get noticed.

Governance or compliance: which Object Lock mode?

Object Lock follows the WORM model (write once, read many) and requires versioning. It has two modes:

• Governance: Without a special permission, nobody can delete or overwrite a locked version; authorised users can lift the lock – at AWS with s3:BypassGovernanceRetention and an explicit header.
• Compliance: Nobody deletes or overwrites a locked version before the period ends, not even the owner or an administrator. The mode cannot be changed and the period cannot be shortened.

Governance is the sensible start: it stops mistakes and stolen keys and leaves an emergency exit, say when a deletion obligation must reach the backups too. Choose compliance when a rule demands copies nobody can remove. At Scaleway, Object Lock cannot be switched off once enabled.

How do I set up a bucket backup with Object Lock?

Against Scaleway’s S3 endpoint with the AWS CLI, the core is:

1. Create a project for backups and the bucket with Object Lock: aws s3api create-bucket --bucket media-backup --object-lock-enabled-for-bucket.
2. Set a default retention: put-object-lock-configuration with "Mode": "GOVERNANCE", "Days": 30. At Scaleway this currently needs the CLI or another S3 tool, not the console.
3. A lifecycle rule that expires old versions after the same period – otherwise storage grows without limit.
4. Create a backup key: an IAM application with the permission sets ObjectStorageObjectsRead, ObjectStorageObjectsWrite and ObjectStorageBucketsRead in the backup project – without ObjectStorageObjectsDelete and without ObjectStorageBucketsDelete.
5. Copy only what changed each night and write a manifest per run: object key → version ID.
6. Alert when a bucket has had no successful backup for 36 hours.
7. Once a month, read a sample back from the latest manifest; compare size and checksum.

Steps 1 to 4 take an hour; 5 to 7 are the real project: a job that runs reliably and proves its copies are readable.

How Clusterward handles S3 backups

Clusterward manages your applications’ buckets under Object Storage, where you set up the backup target once: provider, region (no default – you decide), bucket name, lock mode and retention: 7 to 365 days, by default 30 in governance mode. Clusterward creates the bucket with Object Lock and versioning, reads the settings back, mints its own backup key without a delete right and writes a test object with it. If the target shares a region or project with any of your buckets, the card says so.

Each night, every bucket with backups on gets a run that copies only changes and ends with a restore point. Restores go only into a new bucket – the running one is never touched – or out as a single file via a link valid for five minutes. Once a month a restore test reads a sample back and compares size and checksum. Notifications report a failed run, a bucket without a good backup for 36 hours and a failed test. Details are on S3 backups, the ISO 27001 audit side under Compliance & ISO 27001. After a tenant is offboarded, its restore points stay until their lock runs out, on top of the archive from Back up before you drop.

Conclusion

Versioning is a good first layer against slips, but it is not a backup: it lives in the same bucket, in the same project, behind the same key. A backup needs another location, a key without a delete right, Object Lock with a fixed period, restore points and tests that prove it works. Replication adds to that but replaces none of it.

Want your buckets properly backed up? Tell us where your data lives today and who holds which key. We’ll show you how a backup with Object Lock fits in. Ask a question →

Sources and further reading

• Scaleway docs: How to use object lock
• Scaleway docs: S3 and IAM permissions
• AWS docs: S3 Object Lock
• AWS docs: What does Amazon S3 replicate?
• AWS docs: S3 Versioning