Durable is not backed up: the five ways cloud storage actually loses data

Every object store advertises durability: 99.999999999% at Amazon S3, and similar elsewhere. It is a true number and it answers one question — will a stored byte still be there tomorrow, absent anyone touching it. It does not answer the question that matters, which is whether the byte will still be there after everyone who can touch it has had a year to do so.

1. 1.A delete. A person, a script, a lifecycle rule with the wrong prefix. Replicated perfectly to every region.
2. 2.An overwrite. The export that ran with the wrong input, the sync that went the wrong way. The old bytes are gone the moment the new ones land, unless versioning kept them.
3. 3.A lost credential. Anyone with the key can empty the bucket, and a compromised CI runner is a person with the key.
4. 4.An account event. Billing lapses, a root account is lost, an organisation is restructured; the bucket is intact and unreachable.
5. 5.A migration that half-finished. The script that moved the archive stopped at 60% on a Sunday and nobody noticed until the old server was wiped.

None of these is a durability event. All of them are ordinary.

A separate copy, in a separate place, refreshed on a schedule, that you have restored from at least once. Separate account or separate provider covers the credential and the account event. A schedule covers the delete and the overwrite, as long as the copy never deletes and keeps versions. A restore you have practised covers the half-finished migration, because you know what "finished" looks like.

This is also why BucketPilot's backup jobs never delete at the destination, why every job has a Restore button rather than a separate product, and why the analytics page keeps a board of which buckets are covered and how fresh the copy is. The number on the brochure is fine. It is just answering a different question.