Eleven Nines Is Not a Promise: What Your Cloud Backup Actually Guarantees

Every cloud storage company selling to photographers leads with the same number. Eleven nines. 99.999999999% durability. Backblaze puts it in human terms: store a million files for ten million years and you would expect to lose one.

It is a real number, honestly calculated, and it describes something true about the hardware. It is also, for a working wedding photographer, close to irrelevant. The archive that disappears does not disappear because eleven nines failed. It disappears because a card expired.

This post is about the gap between the number on the marketing page and the sentences in the contract. Both are public. Almost nobody in this industry reads the second one.

The number is a design target, and the provider says so

Start with the exact wording. Amazon does not say S3 achieves eleven nines. It says S3 is "designed to exceed 99.999999999% (11 nines) data durability", and that phrasing repeats across the S3 storage classes page without variation. Backblaze uses the same construction: data is stored to infrastructure designed for eleven nines.

Designed for is not the same as committed to, and we know these companies understand the difference because they draw it themselves, in public, on the neighbouring metric. On the same AWS page, S3 Standard carries two availability figures: designed for 99.99%, and an Availability SLA of 99.9%. Two numbers, explicitly labelled, one an engineering target and one a contractual promise.

This is not a gotcha and it is not sharp practice. Durability is genuinely hard to write an SLA around, because you cannot verify it inside a billing period. Backblaze says as much in its own explainer on durability versus availability: providers "should both publish and guarantee" availability with compensation terms, and durability is discussed entirely separately from that machinery. The same article ends where an honest one has to end: "no number of nines can absolutely protect your data. Human error or acts of nature can always intercede."

So the industry is being straight with us. The problem is that photographers read eleven nines as a guarantee against loss, when it is a statement about disk arrays. It answers a question almost nobody was going to lose sleep over, and stays silent on the one that actually empties accounts.

What actually deletes an archive, on a published schedule

Here is the part worth printing out. Backblaze publishes its non-payment procedure as a three-phase timetable, and it is specific.

• Phase 1, grace period. Thirty days from the failed charge. Everything still works. An email goes out within the first 48 hours, then every five days.
• Phase 2, no service. Two weeks. Uploads stop. API calls return 403 "account_trouble".
• Phase 3, deletion of account data. In Backblaze's own words, the data in the account "may deleted data at any moment at this time".

Add it up. Forty-four days from a card being declined to an archive that may be removed without further warning. That is the real number a photographer should have in their head, and it is roughly six weeks, not ten million years.

Now consider how a declined card actually happens to a wedding photographer. The business card expires and the replacement goes into the wallet but not into the seven services it was paying for. The bank reissues after a fraud flag. A sole trader closes one account and opens another between seasons. None of these feel like a data loss event. All of them start the clock.

The archive can also die of not being touched

Payment is not the only administrative failure mode. Google's inactive account policy states that an account unused for two years may be deleted along with its data, and that this reaches Drive and Photos content. Google set 1 December 2023 as the earliest date an account could be removed under the rule, and it applies to personal accounts rather than those issued through work or school.

Read that against what an archive is for. An archive is storage you deliberately do not touch, which is also why how long you actually have to keep it is a question worth answering before you decide what to pay for. A wedding delivered in 2024 and never revisited is the normal case, not the neglected one. A policy that treats two years of silence as abandonment is aimed at dormant free accounts, but the behaviour it punishes is exactly the behaviour a good archive exhibits.

None of this makes Google or Backblaze the wrong choice. Both publish their rules clearly, which is more than can be said for a hard drive in a drawer, where corruption stays silent until the archive is read back. The point is narrower: the terms that govern your archive are administrative, they are written down, and they operate on timescales you can miss while shooting a season.

Why a second cloud copy often is not a second copy

The standard answer to all of this is redundancy, and it is the right instinct applied to the wrong axis. We covered in the 3-2-1 rule and where wedding-day risk actually sits that copies only help when they fail independently. The same logic decides whether your cloud redundancy is real.

Two buckets at two different providers, on two different continents, running on hardware from two different manufacturers, are still a single point of failure if they are paid with the same card and recovered to the same email address. Hardware independence is what the eleven nines describes and what the marketing sells. Administrative independence is what the 44-day timetable tests, and it is the one nobody diagrams.

What to do with an afternoon

This is unglamorous and it takes about an hour, once.

• Write down every service holding client work, and which card pays for it. Most photographers cannot do this from memory, which is itself the finding.
• Check the expiry date on that card against your busiest month. A card expiring in September is a card expiring while you are least able to notice.
• Make sure billing alerts go somewhere you read. A dedicated address that receives nothing else is better than the inbox that receives everything else.
• Put a calendar reminder to sign in to the archive once a year. It defeats inactivity policies and confirms the login still works, which is worth knowing before you need it.
• For the copy that matters most, prefer a provider you pay annually. One renewal a year is one failure opportunity a year.

Everything on that list is administrative. That is the point. The engineering has already been done for you to eleven decimal places, and it is not where your risk lives.

The honest summary

Cloud durability figures are trustworthy, carefully derived, and describe a failure mode that redundant storage has largely solved. They are also excluded from the only document that carries a remedy. A photographer reading eleven nines as insurance has misread a spec sheet as a contract.

The failure modes with contractual force behind them are mundane: non-payment, inactivity, and account closure. They are published, they are measured in weeks rather than geological time, and they are entirely preventable with a calendar reminder and a card that is not about to expire.

If you want the companion piece on the other end of the chain, what the memory card manufacturer actually promises when a card fails reads the warranty in the box with the same eye. The pattern repeats: the safety nets are real, they are just narrower than the marketing implies, and the narrowing is always written down.