Imagine a script accidentally overwrites an important object with an empty file. The storage service accepts the write and replicates it successfully. Every physical copy survives. The application still loses access to the original data unless an earlier version or backup can be recovered.
Durability protects against loss of stored data within a defined failure model. Availability concerns whether an application can access the service. Backups provide a way to recover a useful earlier state. A storage product's long string of nines does not cover all three.
What eleven nines actually describe
Amazon S3's data-protection documentation describes redundant storage, integrity checks and repair of lost redundancy. S3 Standard and several other storage classes distribute objects across at least three availability zones. S3 One Zone-IA stores redundant copies within one zone.
AWS describes S3 Standard as designed for 99.999999999% annual object durability and 99.99% annual object availability. These are separate design targets for that storage class. Durability is not an uptime percentage and neither design target is equivalent to an unconditional guarantee for every individual object.
For intuition, applying eleven-nines annual durability to 10 billion objects would correspond to an expected 0.1 object losses per year under a simple uniform per-object probability model. That is an illustration of the number's scale, not a prediction for a particular dataset. Correlated failures, service boundaries and user actions cannot be inferred from that arithmetic.
A durable object can be inaccessible
The stored bytes might be intact while a network outage, invalid credential or broken application prevents a read. Availability measures a different property from whether the object survives.
Azure Storage redundancy illustrates another complication. Geo-redundant storage (GRS) and geo-zone-redundant storage (GZRS) replicate data asynchronously to a secondary region. Their ordinary secondary copies are not available for routine direct reads before failover; the read-access variants offer a different access model. Writes still depend on the primary until the appropriate failover arrangement changes that role.
Because replication is asynchronous, a regional failure can leave recent writes missing from the secondary. A second copy does not guarantee immediate read/write access or zero data loss. Check the service's actual recovery and replication behavior.
Replication can copy a mistake
A replica follows the accepted state of the storage service. If an authorized process deletes an object or replaces it with corrupted data, the replication arrangement may reproduce that change. Hardware redundancy cannot distinguish a valid application write from a business mistake.
A backup needs to preserve a recoverable state. For a database export, storing a file successfully is not enough: the export must be complete, consistent and usable for restoration. An integrity checksum can confirm that the stored bytes have not changed, but it cannot establish that the original export contained the right records.
The time before a mistake is discovered matters too. If an object was corrupted three weeks ago, a seven-day recovery window may be insufficient even if every backup taken during those seven days is intact.
Versioning, soft delete and retention
Google Cloud Storage Object Versioning retains noncurrent object generations after replacement or deletion. It explicitly does not protect against deletion of the entire bucket. Google's documentation recommends considering soft delete, which can operate alongside versioning.
These controls serve different purposes. Versioning preserves older generations. Soft delete provides recovery for covered deleted resources within the configured window. Retention policies and locks can prevent specified deletion or replacement operations for a defined period. See Google's protection and recovery overview for the exact behavior.
The cost can grow quietly. If a 10 GB object is replaced daily and every previous generation is retained for 30 days, historical versions alone could occupy around 300 GB, assuming one full replacement per day and no other optimization. Lifecycle rules should reflect how long the organization needs those versions, not simply minimize storage charges.
Can you restore after an account compromise?
A recovery copy under the same destructive permissions as production may be vulnerable to the same compromised administrator. Separate accounts or administrative boundaries, restricted deletion rights and appropriate retention controls can reduce that exposure.
Encrypted backups also depend on access to decryption keys. A recovery exercise should establish that the organization can obtain the necessary credentials and keys when its normal systems are unavailable.
Test more than the download of an object: restore representative application data into an isolated environment, verify its consistency and measure how long the process takes. Include the storage, retrieval and transfer costs described in our cloud egress article. The meaningful backup result is a usable restored service, not just a successful object upload.