1 Overview
Cloud backup is often described as off-site protection, and in one sense that is true: the data leaves your building and lands in a provider's data center. But off-site and isolated are not the same thing. If your cloud backup account is reachable from the same network, uses the same identity provider, and depends on the same credentials as your production systems, then a single compromised administrator account or a single destructive script can reach both your live data and your backups. That is the gap an air gap closes.
An air gap means there is a deliberate break between the systems that hold your production data and the systems that hold your backup copies. The break can be physical, such as removable media that is disconnected after each backup, or logical, such as a separate cloud account with immutable storage and no network path from production. The goal is the same in both cases: an attacker or an accident that destroys production data should not be able to travel the same path to the backups.
This article explains what cloud backup does and does not protect against, how to choose a strategy that fits your recovery objectives, how the 3-2-1 rule works in practice, why restore testing matters more than backup success messages, and how off-site storage and encryption fit together. It is written for teams that already back up to the cloud and want to close the remaining gap.
2 What you are actually protecting against
Backup planning starts with a clear list of threats, because different threats call for different controls. The most common categories are hardware failure, accidental deletion, software bugs, ransomware, insider misuse, and site-level disasters such as fire, flood, or extended power loss. Hardware failure and accidental deletion are usually recoverable from any recent copy. Ransomware and insider misuse are different: they involve an active adversary who may look for and try to destroy your backups before demanding payment or covering their tracks.
Cloud backup alone addresses some of these threats well. If a disk fails or a user deletes the wrong folder, a cloud copy in a separate region is a strong safety net. But if the attacker has the same credentials that your backup jobs use, or if the backup account trusts the production identity provider, then the cloud copy is not isolated. Many destructive incidents begin with stolen credentials, and the first thing a careful attacker does is enumerate backup systems and delete or encrypt the copies they can reach.
That is why the threat model matters more than the storage location. A backup that is off-site but reachable is still vulnerable to the same credential theft, the same misconfiguration, and the same destructive command. An air gap changes the attacker's problem: instead of deleting every copy through one console, they must find and defeat a separate system that is not normally connected to production. That extra step is the point.
3 Choosing a backup strategy
A workable strategy begins with two numbers: your recovery point objective, which is how much data you can afford to lose, and your recovery time objective, which is how long you can afford to be down. These numbers drive how often you back up, what you back up, and how quickly you must be able to restore. A system that changes constantly and supports revenue needs a tighter recovery point objective than an archive that changes once a week. Write the numbers down and treat them as requirements, not aspirations.
Next, decide what data belongs in scope. That usually includes user files, application data, databases, configuration files, and the system images or build recipes needed to recreate servers. Configuration and identity data are easy to overlook, yet restoring a server without its configuration often takes longer than restoring the data itself. A complete strategy also accounts for dependencies: if an application needs a database, a message queue, and a set of secrets, all of those must be recoverable together and in the right order.
Finally, choose the storage tiers and copy schedule that match your objectives. Frequent incremental copies to fast storage support short recovery points, while periodic full copies to slower, cheaper storage support long retention. The strategy should also define who can delete backups, how deletion is approved, and how long deleted data remains recoverable. Those controls are what turn a backup plan into a defensible recovery capability rather than a hopeful one.
4 The 3-2-1 rule in practice
The 3-2-1 rule says keep at least three copies of your data, on two different media or storage types, with one copy off-site. In a cloud-first environment, a practical reading is: production data, a local or fast backup copy for quick restores, and a separate off-site copy in a different region or provider. The two media requirement is satisfied when the copies do not share a single failure domain, such as one copy on local disk and one in object storage.
The rule becomes much stronger when you add an air gap to the off-site copy. That can mean a separate cloud account with immutable, write-once storage and no trust relationship to production, or it can mean removable media that is physically disconnected between backup runs. The key property is that the backup copy cannot be altered or deleted by credentials that exist in the production environment. Immutability and account separation are the controls that make this practical at cloud scale.
In practice, many teams run a tiered schedule. They take frequent local snapshots for fast recovery, replicate a copy to a separate cloud account for off-site protection, and periodically write a full copy to isolated or removable media for the strongest air gap. Retention should be long enough to cover the time it takes to notice a problem; slow-moving corruption or a quiet intruder may not be discovered for weeks. Test that each tier can actually be restored, not just written.
5 Restore is the real test
A backup job that reports success proves only that data was written. It does not prove that the data can be read, that the application can start from it, or that the restore will finish inside your recovery time objective. The only meaningful test is a restore, performed on a schedule, into an environment that is separate from production. Treat restore testing as a recurring operational task with an owner, a checklist, and a record of results.
A useful test goes beyond copying files back. Restore a database and confirm it passes consistency checks. Rebuild a server from its image and confirm the application starts and serves traffic. Restore a set of files and confirm permissions, ownership, and timestamps are correct. Measure how long each step takes and compare it with your recovery time objective. If the measured time is longer than the objective, the plan needs to change before an incident forces the issue.
Testing also validates your documentation and your people. Someone should be able to follow the runbook without the original author present. Credentials, encryption keys, and network access must all be available when they are needed, which is often the hardest part during a real incident. Keep a small, current set of test restores running continuously so that drift in configuration, retention, or access does not go unnoticed until the worst possible moment.
6 Offsite and encryption
Off-site storage protects against events that destroy an entire location, and encryption protects the copies while they are at rest and in transit. Both are necessary, and both are easy to get wrong. Encrypt backup data before it leaves the source system, keep the keys in a location that is separate from the backup data, and make sure the keys themselves are backed up and recoverable. A backup you cannot decrypt is not a backup.
Key management deserves the same care as the data. If the encryption key lives only in the production environment, then a disaster that destroys production may also destroy your ability to read the off-site copy. Store keys in a separate system, restrict who can retrieve them, and document the recovery procedure for the keys themselves. Rotate keys on a schedule, but keep old keys long enough to read retained backups, and test decryption as part of your restore exercises.
Off-site and air-gapped are complementary, not interchangeable. Off-site answers the question of where the copy lives; an air gap answers the question of who can reach it. The strongest configuration places an encrypted copy in a separate account or region that production credentials cannot modify or delete, and keeps a further isolated copy on media that is disconnected between runs. Together, encryption, off-site placement, and isolation turn a cloud backup into a genuine last line of defense.
7 Frequently asked questions
Is cloud backup automatically off-site? The data is stored away from your primary location, so it is off-site in the geographic sense. But if the backup account is reachable from production with the same credentials or identity provider, it is not isolated. Off-site placement and an air gap solve different problems, and mature plans use both.
Do I still need local backups if everything is in the cloud? Local or fast copies usually make restores quicker and cheaper for routine recoveries, while the off-site copy covers larger disasters. The 3-2-1 rule expects multiple copies on different media, so a local copy plus an isolated off-site copy is a common and sensible arrangement.
How often should I test restores? Frequently enough that the test is routine rather than exceptional. Many teams test a small restore weekly, a full application restore monthly or quarterly, and a complete recovery exercise at least once a year. The schedule should match how quickly your data and configuration change.
What about encryption keys? Keep them separate from the backup data, back them up, restrict access, and test that you can decrypt an old copy. Losing keys is functionally the same as losing the data.
How long should I keep copies? Long enough to cover the time it takes to detect a problem, plus any legal or regulatory requirement. Retention is a business decision, and it should be written down and tested rather than left to defaults.