This article is based on a piece originally published on RedSharkNews.com. The observations below expand on the original editorial with additional technical context for DevOps and infrastructure practitioners.
Cloud Storage and the Backup Misconception
Cloud storage has become so ubiquitous and so reliable that a dangerous assumption has crept into how teams think about data protection: that storing data in the cloud is backing it up. It is not. Understanding the difference between storage redundancy and a genuine backup strategy is one of the most important disciplines in operational engineering.
What Cloud Storage Actually Provides
At its core, cloud storage is still hard disks in a rack somewhere — typically many racks in purpose-built, physically nondescript data centres distributed around the world. What makes cloud storage impressive is the reliability engineering layered on top of that hardware:
- Hardware redundancy: Data is spread across multiple physical drives using techniques such as erasure coding or replication, so a single drive failure causes no data loss.
- Multi-site replication: Many providers allow or automatically arrange for data to be stored in more than one geographic region simultaneously, providing strong resistance to localised disasters — fires, floods, power outages.
- High availability: The operational burden of keeping storage online shifts from the user to the provider, along with their staffing, monitoring, and hardware replacement cycles.
This is genuinely valuable. For most workloads, cloud object storage or block storage is far more reliable than a single on-premises server. But reliability against hardware failure and geographic disasters is not the same thing as protection against data loss caused by human error, software bugs, or account-level events.
Cloud Storage Is to Backup What RAID Is to Backup
The analogy that best frames this problem is RAID. A RAID array protects against individual disk failures; it does not protect you from accidentally deleting a critical directory, from ransomware encrypting your data, or from a bug that silently corrupts files over weeks. RAID is not backup — a principle the storage industry has repeated for decades.
Cloud storage occupies the same category. Multi-site cloud replication protects against hardware failure and data-centre-level disasters. It does not protect against:
- Accidental deletion — a mistyped command, a runaway script, or a UI mistake replicates instantly to all redundant copies.
- Account compromise or closure — a lost password, a billing lapse, or a provider-side account termination can make data inaccessible at the system level, regardless of how many redundant copies exist within that system.
- Logical corruption — if corrupt data is written, all replicas store the corrupt version.
- Ransomware — encrypted files sync faithfully to every replica and every region.
- Provider-side errors — though rare, cloud providers have suffered data loss incidents. A provider’s internal backup is designed to recover the provider’s infrastructure, not necessarily to give individual users point-in-time recovery on demand.
The Single Point of Failure Hidden in Plain Sight
No matter how many physical locations hold your data, everything passes through one logical control plane: the cloud account, the API credentials, and the provider’s access management system. Lose access at that level — through a credential incident, an inadvertently closed account, or a provider dispute — and all the geographic redundancy in the world does not help you retrieve your data.
This is a single point of failure at the access layer, not the storage layer. Genuine backup strategy requires a copy of your data that is reachable through a different mechanism, ideally controlled by a different set of credentials and, ideally, stored with a different provider or on a different media type.
What Cloud Providers Actually Back Up — And for Whom
Most major cloud providers do maintain their own backup and snapshot infrastructure. However, that infrastructure exists primarily to recover the provider’s platform, not to provide users with self-service point-in-time recovery. If a data centre suffers a catastrophic event, the provider’s backup may restore service — but possibly to a state from hours or days earlier, and on the provider’s schedule, not yours.
Some providers offer user-facing backup features — versioning, soft-delete windows, cross-region replication, or snapshot schedules — either as default behaviour or as paid add-ons. These features genuinely do improve your protection posture and are worth enabling. But before treating them as your backup strategy, ask specific questions:
- How far back does versioning or snapshot history go?
- Is that retention period guaranteed in the SLA, or is it best-effort?
- How quickly can a large restore be completed, and at what cost?
- Does accidental deletion of the bucket or container also delete the version history?
- Is there an additional fee to retrieve backup data?
If the answers to those questions are satisfactory and documented in your service agreement, cloud versioning or snapshots can legitimately function as one layer of backup. The key phrase is one layer.
The 3-2-1 Rule Still Applies in the Cloud Era
The long-established 3-2-1 backup rule remains the most practical starting point for any data protection policy:
- 3 copies of your data
- 2 different storage media or platforms
- 1 copy stored off-site (or off-account)
Applying this in a cloud-native context might look like: primary data in one cloud provider’s object storage, automated snapshots or exports to a second cloud provider or to on-premises storage, and a periodic cold copy to tape or to an air-gapped system for long-term retention. The exact combination depends on your recovery time objectives (RTO) and recovery point objectives (RPO), your budget, and your compliance requirements.
Practical Recommendations for Engineering Teams
- Enable versioning and soft-delete on every storage bucket or blob container from day one. These are cheap and provide a safety net for the most common data loss scenarios.
- Automate cross-account or cross-provider exports for any data that would be genuinely catastrophic to lose. Do not rely on manual processes.
- Test restores regularly. A backup you have never restored is a backup you cannot trust. Schedule restore drills and document the results.
- Treat cloud account credentials as critical infrastructure. Use MFA, audit access logs, and have a documented process for credential rotation and account recovery.
- Read the SLA carefully before choosing a cloud storage tier. Understand the durability guarantees, the support response times for data loss incidents, and what — if any — compensation is offered if the provider fails to meet those guarantees.
- Document your RPO and RTO before designing your backup architecture, not after. Your backup strategy should be derived from those targets.
Summary
Cloud storage is one of the most reliable ways to store data at scale. Its redundancy, geographic distribution, and operational guarantees are genuinely impressive compared with most on-premises alternatives. But reliability is not the same as recoverability. A single logical system — however redundant its physical infrastructure — remains a single system. Accidental deletion, account-level failures, logical corruption, and ransomware all bypass physical redundancy entirely.
RAID is not backup. Cloud storage is not backup. Keeping data in both a RAID array and cloud storage adds one layer of protection, but a proper backup strategy requires independent copies, independently accessible, tested and verified on a regular schedule. The old adage has not changed; the technology around it has.