1 Overview
Cloud backup has become the default answer to data protection for many organizations. It is convenient, it scales without buying tape or disk arrays, and it moves copies away from the systems they protect. But a cloud backup is still a copy that lives under the control of an account, a set of credentials, and a retention policy. If any of those are compromised, misconfigured, or simply deleted by mistake, the backup can disappear exactly when it is needed most.
An immutable copy changes that equation. Immutability means the backup data cannot be altered or deleted for a defined period, even by an administrator with full credentials. It is sometimes implemented through object lock, write-once-read-many storage, or append-only repositories. The point is not the technology label but the guarantee: once a restore point is written, it stays written until its retention window expires.
This article explains why a cloud backup alone is an incomplete strategy, what threats an immutable copy actually addresses, how to choose retention and restore targets, and how to test the whole chain. The goal is a practical, evergreen approach that survives ransomware, insider mistakes, and account compromise without turning into an expensive archive of everything forever.
2 What you are actually protecting against
The most common assumption is that cloud backup exists mainly for hardware failure. That is only part of the picture. Modern data loss is more often logical than physical: a ransomware operator encrypts production and then deletes or encrypts the backups, a scripted cleanup job removes the wrong retention set, a compromised administrator account issues a delete against the backup repository, or a misconfigured lifecycle rule expires objects earlier than intended.
These events share a property that ordinary cloud backup does not solve. If the backup system trusts the same identity, network path, or management plane as production, an attacker or a mistake can reach the backups too. Immutability inserts a hard boundary. Deletion requests are rejected by the storage layer for the retention period, so even valid credentials cannot erase the protected copies. That gives you a recovery point that predates the incident.
It is worth being precise about what immutability does not do. It does not prevent data corruption before the backup is written, it does not replace malware detection, and it does not remove the need for tested restore procedures. It also does not help if the immutable copy is the only copy and the retention window is shorter than the time it takes to discover the incident. Immutability is one control in a layered strategy, not a complete answer.
3 Choosing a backup strategy
A workable strategy starts with classifying data by how much loss and downtime the business can tolerate. That produces two numbers: the recovery point objective, which sets how much data you can afford to lose, and the recovery time objective, which sets how quickly service must return. These numbers drive backup frequency, retention, and the type of copy you keep.
From there, decide what gets backed up and at what granularity. Some systems are best protected as full images so they can be rebuilt quickly. Others are better as application-consistent database backups or file-level copies. A mix is normal. What matters is that every protected system has a defined owner, a schedule, a retention rule, and a documented restore procedure.
Then separate the copies by trust boundary. The primary cloud backup can remain convenient and fast for everyday restores. The immutable copy should live where production credentials cannot delete it, ideally in a different account or provider with its own access controls. Retention should be long enough to cover the realistic detection window for ransomware and the time needed to investigate before restoring. Finally, build the strategy so that restoring does not depend on the same systems that failed. A backup you cannot reach during an incident is not a backup.
4 The 3-2-1 rule in practice
The classic 3-2-1 rule says keep three copies of data, on two different media or storage types, with one copy offsite. In cloud-centric environments the rule still applies, but the interpretation shifts. Three copies might mean production data, a primary cloud backup, and an immutable secondary copy. Two media might mean block or file storage plus object storage. Offsite might mean a different region or a different provider.
The critical addition for modern threats is that at least one copy must be immutable and isolated. Without that, the three copies can all be deleted through the same compromised account. Isolation means separate credentials, separate management consoles where possible, and no trust relationship that lets production identities delete backup data. Some teams describe this as a logical air gap.
In practice, a common pattern is a fast primary backup for routine restores and an immutable copy written on a schedule that matches your recovery point objective. The immutable copy can be less frequent if the business can tolerate losing a few hours, but it should be frequent enough that the gap is acceptable. Document which copy is used for which scenario, because during an incident nobody wants to discover that the only surviving copy is a monthly archive when the business needs yesterday.
5 Restore is the real test
A backup that has never been restored is a hypothesis, not a recovery capability. The only way to know whether your strategy works is to restore data on a schedule and measure the result against your recovery time objective. Start small with single files and directories, then move to full virtual machines, databases, and finally a broader environment rebuild.
Stress testing should include the awkward cases. Restore from the immutable copy, not just the primary. Restore into an isolated environment so you do not overwrite production. Test with the credentials and runbooks that would actually be used during an incident, and confirm that the people on call know where those runbooks live. Time each step, including the time to locate the right restore point, provision target storage, and validate application consistency.
Record what you learn. If a restore takes longer than expected, either the recovery time objective is wrong or the process needs work. If the immutable copy cannot be restored because of a configuration error, that is a finding worth fixing before a real event. Repeat the exercise at least quarterly and after any major change to infrastructure, backup software, or retention policy. Restore testing is also the best way to catch silent corruption, because a backup that reads back cleanly but produces a broken application is worse than no backup at all.
6 Offsite and encryption
Offsite protection exists so that a single incident, region outage, or account compromise cannot take every copy at once. In cloud terms, offsite usually means a different region, a different account, or a different provider. The strongest arrangements combine all three where feasible, because account-level compromise is one of the most common ways backup data is lost. The immutable copy should be the one that is hardest to reach and hardest to delete.
Encryption is essential at every stage. Encrypt data in transit and at rest, and manage keys separately from the backup data itself. If the encryption keys live in the same account as the backups, an attacker who takes the account may also take the keys. Consider a separate key management boundary, and document how keys are recovered if the primary key store is unavailable. Losing keys is functionally the same as losing data.
Also think about who can decrypt. Restrict key usage to the smallest set of roles that need it, and log every access. Immutability protects the ciphertext from deletion, but it does not stop an attacker who obtains the keys from reading the data. Combine immutable storage, separate key custody, least-privilege access, and monitoring so that suspicious access is detected early. Together these controls make the immutable copy genuinely useful rather than merely present.
7 Frequently asked questions
Is cloud backup useless then? No. Cloud backup is fast, scalable, and convenient for everyday recovery. The argument is that it should not be the only copy, because a single account or credential compromise can remove it. Add an immutable copy and the strategy becomes resilient to the threats that most often cause major data loss.
How long should immutable copies be retained? Long enough to cover the time between an incident occurring and being detected, plus investigation and recovery. Many organizations use at least 30 to 90 days for immutable retention, with longer windows where regulations or contracts require it. Longer retention increases cost, so align it with your actual recovery point objective and legal obligations.
Does immutability replace testing? No. Immutability protects copies from deletion or alteration, but it says nothing about whether those copies are complete or restorable. You still need scheduled restore tests, including restores from the immutable copy, and you still need to verify application consistency.
What about cost? Immutable storage often carries minimum retention commitments and slightly higher per-gigabyte pricing than standard object storage. Treat it as insurance: a modest fraction of primary backup spend that buys protection against the scenario where every other copy is gone. Review the cost against the downtime and data loss it prevents, and adjust retention as your risk profile changes.