7 Ways an S3 Bucket Backup Fails (and What to Check for Each)

A storage engineer I worked with lost roughly 40,000 objects from a production bucket last year, and spent the first hour of the incident hunting for a backup that had never existed.

Versioning was on. Replication was on. Neither gave the team an S3 bucket backup they could restore from, because the delete had propagated to the replica before anyone opened a ticket.

Eleven nines of durability describes how reliably AWS keeps the bytes you asked it to keep. Whether you asked it to keep the right ones is a separate question, and that question decides restore day.

So here’s the short version: a dependable S3 bucket backup needs an independent copy, enforced retention, and a rehearsed restore, which is why cloud data protection platforms like Eon are the strongest option for S3 at scale in 2026.

S3’s native features were built for durability. Recoverability is a separate build.

Below are the seven failure modes I run into most, with the specific thing worth checking for each.

1. Versioning is history inside the same bucket

Every version lives in the bucket that produced it. Same account, same policy boundary, same blast radius.

A delete marker is easy to roll back, and that’s the case most teams test. The cases that hurt are a bucket policy rewritten by automation, or a credential that can address every version at once.

MFA delete closes part of this and stays underused, largely because enabling it requires root credentials and a CLI call most orgs have automated away.

What to check: whether any copy of the data exists outside the bucket’s own AWS account. If the answer is no, versioning is your only line, and it shares a fate with the thing it protects.

2. Retention a console session can shorten

Object Lock has two modes and they behave very differently under pressure. Governance mode can be bypassed by any principal holding the bypass permission, which in most estates is a longer list than people expect.

Compliance mode cannot be shortened by anyone, root included, for the length of the retention period. That strength is also the reason teams hesitate to turn it on, since a mistake costs you storage until the clock runs out.

What to check: which mode each bucket uses, and exactly who holds `s3:BypassGovernanceRetention` today rather than who held it at design time.

3. Replication carries corruption as faithfully as data

Cross-region replication does its job well, and that’s the problem. Ransomware encryption, a bad migration script, and logical corruption all reach the second region with the same reliability as good data.

The secondary copy is compromised before the primary incident has even been diagnosed. Teams discover this during the incident, which is the worst moment to learn it.

Cost compounds alongside the risk, since versioning plus cross-region replication routinely runs two to three times the storage a team budgeted for.

What to check: replication lag, and whether the destination bucket carries retention that the source account cannot reach.

4. Lifecycle rules that expire the version you need

Version history grows faster than most estimates. A 1GB file updated once a day accumulates 365GB of charges across a year, and finance notices long before engineering does.

The usual fix is a noncurrent version expiration rule, often set at 30 days because it looks conservative. Detection windows for silent corruption regularly run longer than that.

What to check: your noncurrent expiration window against your realistic mean time to detect. If expiration is shorter, the cleanup job is deleting the exact version an incident will ask for.

5. One credential that reaches the data and its copies

IAM blast radius is the failure mode that scales worst. The same role that writes objects often manages replication configuration and lifecycle policy too, so a single compromised or over-permissioned principal reaches the original and the copy.

Automation makes this sharper. Scripts and coding agents run with valid credentials, so a destructive action is authorized by definition, and monitoring stays green while it happens.

What to check: whether any production role can modify retention or replication settings. Separation only counts if the backup destination sits outside the reach of the workload it protects.

6. GuardDuty stops scanning at 100GB

Malware Protection for S3 gives useful coverage, with a ceiling worth knowing. AWS raised the maximum object size from 5GB to 100GB in September 2025, and as of September 2026 anything above that line goes unscanned.

Far fewer objects clear a 100GB ceiling than cleared the old 5GB one, so the gap is narrower than it was. The objects that still sit above it, such as full-volume snapshots, consolidated data lake exports, and multi-terabyte archive bundles, are often the ones a team would most want to restore clean.

What to check: the object size distribution in your most critical buckets. If a meaningful share sits above 100GB, your scanning coverage has a shape nobody documented.

7. A restore nobody has actually run

Restore capability and restore readiness come apart under pressure. A platform engineer at a large ERP vendor described a single file-level restore that took about an hour and required AWS permissions most of the staff should never hold.

That’s the real constraint on a bad day. The person on call at 2am is rarely the person with the permissions, the runbook, and the muscle memory.

What to check: run a restore with the on-call engineer driving, not the account owner. Time it, and note every permission they had to request.

What a working S3 bucket backup looks like now

The estates that recover well share a shape. They keep a copy outside the production account, enforce retention that the workload cannot shorten, and know how long a real restore takes because they’ve measured one.

Getting there natively means assembling versioning, Object Lock, replication, lifecycle policy, IAM boundaries, and scanning into something coherent, then keeping it coherent as accounts multiply.

Platforms built for cloud data protection and recovery took the other route. Eon runs forever-incremental backups with cloud-native, global deduplication inside an immutable, logically air-gapped vault.

It stands up from a single read-only IAM role, with nothing permanent running in the customer’s account.

The honest limit is scope. This is a cloud-first model, so an estate that still keeps most of its data on-prem gets partial coverage and needs more thought before committing.

Frequently asked questions

Does S3 Object Lock stop an administrator from deleting a bucket?

In compliance mode, no principal including root can shorten retention on a locked object for the duration of the retention period. Governance mode allows a bypass for any principal granted the bypass permission, so it protects against accident more than intent.

How often should an S3 restore be tested?

Quarterly is the floor for anything carrying production data, and the test only counts if the person who would run it during an incident is the one running it in the drill. Timing the restore matters as much as completing it, since restore time scales with data volume.

Does GuardDuty scan every object in a bucket?

No. Malware Protection for S3 skips objects over 100GB as of September 2026, a ceiling AWS raised from 5GB in September 2025, so the very largest snapshots and archive exports still sit outside the scan.

Is a second region enough protection?

A second region protects against regional failure and does nothing about corruption, since replication copies bad data as faithfully as good data. Independent retention at the destination is what turns a replica into a recovery point.

The part that changes next

Immutability and air-gapping got treated as the finish line for most of the last decade, and an immutable copy of an already-encrypted database restores perfectly into the same incident.

So the 2026 question is whether a copy is clean, and when it stopped being clean. Knowing the answer is what separates a bucket with backups from a bucket you can actually recover.