Infrastructure · Backups
How to Configure S3 Backups: Versioning, Lifecycle, Encryption, and Object Lock
Configuring S3 backups properly means going well beyond copying files to a bucket. You create a bucket with versioning enabled to protect against accidental deletion and overwrites, turn on default server-side encryption, and block all public access from the start. You then write lifecycle policies that automatically transition aging backups into cheaper tiers — Standard to Standard-IA to Glacier — and expire old versions so your bill stays predictable. For ransomware protection you enable Object Lock in Compliance mode, which makes backups immutable so that no one, not even the account root user, can delete them before their retention expires. You organise objects under date-based prefixes, drive the backups with a tool like restic or rclone, and — the step most people skip — test restores regularly, because immutability alone doesn’t tell you which recovery point is actually clean.
Key takeaways
- Copying files isn’t a strategy. Real S3 backups need versioning, lifecycle, encryption, and tested restores.
- Lifecycle policies control cost. Age data into Glacier and expire old versions, or your bill compounds.
- Object Lock stops ransomware. Compliance mode makes backups immutable even to the root user.
- Immutable isn’t the same as clean. An attack before backup leaves encrypted versions locked too — test restores.
- Tools do the heavy lifting. restic adds dedup and encryption; rclone moves data; AWS Backup centralises.
Amazon S3 is the default destination for backups thanks to its durability, but simply copying files there is not a backup strategy. A real one accounts for retention, cost, replication, and — above all — recovery. This guide walks through configuring S3 backups that actually protect you: an encrypted versioned bucket, lifecycle policies that manage cost automatically, Object Lock for ransomware resistance, and the testing discipline that turns a pile of objects into a system you can rely on. The same patterns work on S3-compatible storage like Wasabi, Backblaze B2, or self-hosted MinIO.
Why isn’t copying files to S3 enough?
The temptation is to treat S3 as a remote folder — sync your files there and consider yourself backed up. S3’s durability of eleven nines makes that feel safe, but durability only means S3 won’t lose the bytes you store; it says nothing about whether you can recover the right data when you need it. A real backup strategy adds four things on top of raw storage: retention rules so you keep what you need and prune what you don’t, replication so a regional failure doesn’t wipe you out, cost optimisation so the bill stays sane, and recovery testing so you know restores actually work.
The gap between “files in S3” and “a backup system” is exactly where disasters hide. Without versioning, an overwrite or accidental delete destroys your only copy. Without lifecycle rules, every version piles up at full price until the bill becomes the emergency. Without immutability, ransomware that reaches your credentials can encrypt or delete the backups along with the production data. And without tested restores, you discover your backups were incomplete at the worst possible moment. Configuring S3 backups well is really about closing each of these gaps deliberately, which is the broader theme of our backup strategy guide.
Creating the bucket: versioning and encryption
The foundation is a properly configured bucket, and three settings go on at creation. First, enable versioning, which keeps every version of an object rather than overwriting in place — this is your protection against both accidental deletion and the silent corruption of an overwrite, since the previous good version is always recoverable. Second, enable default server-side encryption so every object is encrypted at rest; AES-256 managed by S3 is the simple choice, while SSE-KMS gives you key control at slightly higher cost, where enabling a bucket key reduces the per-request KMS charges. Third, block all public access — a backup bucket should never be reachable from the internet, and this setting prevents the misconfiguration that leaks data.
These are quick to apply but easy to forget, and the order matters: versioning especially should be on from day one, because it only protects objects written after it’s enabled. The one caveat to flag early is that versioning without a corresponding lifecycle rule to expire old versions will quietly compound your storage bill, since every overwrite leaves the old version behind at full price. That makes the lifecycle policy not optional but the necessary companion to versioning, which is the next step.
Lifecycle policies and storage tiers
Lifecycle policies are what turn S3 from an ever-growing cost into a managed one, by automatically moving data into cheaper tiers as it ages and expiring it when it’s no longer needed. The principle is to keep recent backups in fast, warm storage and let older ones sink into progressively colder, cheaper tiers, matching each tier to how urgently you’d ever need that data back. The table lays out the main classes.
| Class | Use for | Retrieval |
|---|---|---|
| Standard | Recent, hot backups | Immediate |
| Standard-IA | Infrequent access | Immediate |
| Glacier Instant | Quarterly access | Milliseconds |
| Glacier Flexible | Yearly access | 1–12 hours |
| Deep Archive | Compliance, rarely touched | 12–48 hours |
A typical lifecycle policy, applied as JSON, transitions objects under a daily prefix to Standard-IA after 30 days and to Glacier after 90, expires noncurrent versions after a year, and aborts incomplete multipart uploads after a week so they don’t accumulate as invisible cost. The strong recommendation is to write lifecycle rules rather than uploading directly to the cold tiers, unless data is clearly cold from day one — Deep Archive is roughly 73 percent cheaper than Glacier for storage but takes far longer to retrieve, so you match the tier to your recovery time objective. One practical gotcha: objects need to be at least 128KB for Glacier classes to be economical, so bundle small files before archiving to avoid per-object overhead.
The lifecycle of a backup over time
It helps to picture how a single backup ages through the tiers, because the lifecycle policy is really a schedule that this one object follows over its lifetime. The timeline shows a daily backup moving from hot storage to progressively colder, cheaper tiers and finally expiring.
What this picture makes clear is that the policy operates continuously and invisibly once written: you don’t touch individual objects, you describe the schedule once and S3 enforces it for everything matching the prefix. The cost savings compound precisely because the transitions are automatic — data that would otherwise sit at full Standard price for years instead drifts into tiers costing a fraction as much, exactly in proportion to how unlikely you are to need it. The discipline is to start conservative with the timings, since a transition or expiry that fires too early is far harder to undo than one that fires a little late.
How do you structure prefixes?
The way you name and organise objects in the bucket has an outsized effect on how manageable your backups are, because lifecycle rules and retrieval both operate on prefixes. A consistent, date-based prefix structure — something like db/YYYY/MM/DD/database-name/, logs/YYYY/MM/DD/service-name/, and compliance/YYYY/department/ — lets you scope lifecycle rules to specific categories of data and makes retrieval deterministic, since you always know where a given backup lives.
This pays off in two concrete ways. First, you can apply different retention to different data: your database backups might age into Glacier after 90 days while compliance records stay in Deep Archive for seven years, and clean prefixes let one lifecycle configuration express both without ambiguity. Second, when you need to restore, a predictable path means you can find and pull exactly the objects you need rather than hunting through a flat namespace. Tagging prefixes clearly — daily versus monthly, by application or sensitivity — also reduces the risk that a careless lifecycle rule deletes something you still needed, which is the most common self-inflicted backup wound.
Object Lock and immutable backups
Object Lock is the feature that makes S3 backups genuinely ransomware-resistant, and it’s the strongest protection in the whole setup. It implements write-once-read-many (WORM) storage, preventing objects from being deleted or overwritten for a defined retention period, and it comes in two modes. Governance mode protects against accidental deletion while letting privileged users with a specific IAM permission override the lock when genuinely needed. Compliance mode is the maximum: no user at all — not even the AWS account root user — can delete or overwrite a locked object version, or even shorten its retention, until the period expires.
That root-proof immutability is what defeats ransomware: an attacker who compromises your credentials still cannot encrypt or delete a Compliance-locked backup, so you always retain a clean, restorable copy, giving you an effectively air-gapped recovery option. It also satisfies strict regulatory regimes like SEC Rule 17a-4 and FINRA that mandate immutable storage. Two practical notes: Object Lock must be enabled when the bucket is created, not retrofitted, and locked objects can still transition storage classes via lifecycle — so you can archive them to Deep Archive — but a lifecycle rule cannot delete them before their lock expires. This immutability is the backbone of serious disaster recovery.
How do you handle disaster recovery?
A backup in a single region protects you from most failures, but not from losing that region itself, which is where cross-region replication comes in. By configuring replication, S3 automatically copies objects to a bucket in a different region, so a regional outage — or a problem confined to one location — leaves you with an intact second copy elsewhere to restore from. Combined with versioning and Object Lock, this gives you the geographic separation that a serious disaster recovery posture requires, rounding out the classic principle of keeping copies in more than one place.
There’s an important and frequently missed catch, though: lifecycle policy actions don’t replicate. If you’ve written a rule that ages objects into Glacier in your source bucket, that rule does not automatically exist in the destination bucket — you must recreate the same lifecycle configuration there separately, or your replica will sit at full Standard price indefinitely while you assume it’s being managed like the source. The same goes for any Object Lock and encryption settings, which need to be established on the destination too. In larger setups, separating backups into distinct vaults or buckets by application or sensitivity tier also makes access control and cost tracking cleaner, and tightly scoped IAM permissions throughout ensure that a single compromised credential can’t reach across and wipe your recovery points.
Driving backups with restic, rclone, or AWS Backup
You need a tool to actually move data into this bucket, and three approaches dominate, each suiting different needs. The terminal shows the common ones.
# Option A: restic — dedup + client-side encryption export RESTIC_REPOSITORY=“s3:s3.amazonaws.com/company-backups/restic” restic backup /var/www/app /etc —exclude=“*.log” —tag automated restic forget —keep-daily 7 —keep-weekly 4 —keep-monthly 12 —prune restic check —read-data-subset=10% # verify integrity weekly # Option B: rclone — fast S3-API courier $ rclone copy /var/archives/ s3:company-backups/daily/ \ —transfers 8 —checkers 16 —fast-list —s3-storage-class STANDARD_IA # Option C: AWS Backup — centralized policy engine (EC2/RDS/S3/DynamoDB) # continuous PITR (35d) or periodic snapshots, retention up to 99yr
Each tool has a niche. Restic adds deduplication and client-side encryption on top of S3, with a clean retention model — keep so many daily, weekly, and monthly snapshots, then prune — and a check command to verify repository integrity. Rclone is the efficient courier for moving files and whole directory trees, with parallel transfers and the ability to set a storage class at upload; just remember it speaks only the S3 API, so it can’t read an object that’s already in Glacier without restoring it first. AWS Backup is the centralised, managed option that backs up many AWS services to one policy engine, offering continuous point-in-time recovery within the last 35 days or periodic snapshots retained for years. For cross-region disaster recovery you can add replication, but note that lifecycle policies don’t replicate — you must recreate the same rules in the destination bucket separately.
Why must you test your restores?
The single most overlooked step, and the one that separates real protection from false confidence, is testing that you can actually restore. The uncomfortable truth surfaced by ransomware specifically is that immutability is not the same as usability: Object Lock stops an attacker from deleting your backups, but if they encrypted your data before your backup job ran, those encrypted versions are now preserved immutably right alongside your clean ones. Immutability tells you the backup survived; it does not tell you which recovery point is actually clean and restorable.
The discipline that closes this gap is regular, realistic restore testing — ideally quarterly, on a fresh machine, with fresh eyes — so that recovering is a rehearsed routine rather than a panicked improvisation. You document the real retrieval times you observe, because the brochure numbers for Glacier and Deep Archive are best cases and your actual restore of a large archive may take far longer. You verify the restored data is complete and correct, not just that the files came back. And you scope your IAM permissions tightly throughout, so that even a compromised credential can’t wipe your recovery points in the first place. A backup you’ve never restored is a hypothesis, not a safety net — and for the production systems behind these backups, our dedicated servers in Toronto give you a controllable foundation, while the restore test is what proves the whole chain works.