Immutable backup: a copy nobody can delete
Ransomware goes looking for the backup first. If your backup can be reached with the same credentials as the systems it protects, it is not a backup, it is a second target.
An immutable backup is a copy that cannot be changed or deleted for a set retention period, not even by an administrator. Veeam supports this through hardened repositories and object storage with lock, and it is the single most effective defence against a backup being encrypted along with everything else.
The practical rule is 3-2-1-1-0: three copies, on two types of media, one off site, one immutable or offline, and zero errors in the last verified restore test.
The number that matters is not how often you back up but how long it takes to get back. Agree the recovery time in advance, then prove it once a year with a real restore.
Why immutability changed the calculation
For years the standard advice was three copies, two media, one off site. That is still right, but it assumes the thing you are recovering from is a fire or a failed disk. Modern ransomware is patient: it gets in, waits, watches which account runs the backup job, and deletes or encrypts the repository before it touches anything visible.
Immutability removes that option. Once a restore point is written it cannot be modified or deleted until its retention expires, regardless of who asks. An attacker with full domain administrator rights still cannot remove yesterday.
The 3-2-1-1-0 rule in practice
| Digit | Means | In practice |
|---|---|---|
| 3 | Three copies of the data | The production copy plus two backups |
| 2 | On two different types of media | Local appliance plus object storage, for example |
| 1 | One copy off site | A second location or a cloud target, not the same server room |
| 1 | One copy immutable or offline | Hardened repository, object lock, or genuinely disconnected media |
| 0 | Zero errors in the last restore test | A verified restore, not a successful job log |
The last digit is where most organisations quietly fail. A green backup job means the copy was written. It does not mean the copy can be turned back into a working system.
RTO and RPO, without the jargon
Two numbers drive every design decision, and both are business decisions rather than technical ones.
- Recovery point objective. How much work you are willing to lose. If you back up nightly, the answer is up to a day. For a till system or a warehouse management system, a day is usually unacceptable and the answer has to be minutes.
- Recovery time objective. How long you can be down. This is the number people underestimate, because restoring two terabytes over a connection sized for office use takes a lot longer than copying it locally.
We put both in writing before we design anything, and we design to meet them rather than to fill a disk. That is what data and business continuity covers.
What we build it with
- Veeam for backup and replication across virtual, physical and cloud workloads, with hardened repositories for the immutable copy. It is our default because it covers VMware, Hyper-V, Microsoft 365 and physical servers from one console.
- Synology for site-level network storage and as a local restore target, which is what makes a fast recovery possible without pulling everything back over the internet.
- Datto where a very fast local restore matters more than archive depth, typically in smaller sites that cannot tolerate a long outage.
- Schneider Electric for UPS and rack power. A controlled shutdown prevents the corruption that turns a power cut into a restore.
- Azure or AWS object storage with lock enabled for the off-site immutable copy.
Microsoft 365 is not backed up for you
This one still surprises people. Microsoft guarantees the availability of the service, not the recoverability of your content after a retention window passes. Deleted mailboxes, purged SharePoint sites and a Teams channel someone cleaned up are recoverable for a limited period and then they are gone.
If your organisation runs on Microsoft 365, back it up separately. It is inexpensive relative to the exposure, and it is the single most common gap we find when we take over an environment.
The restore test is the whole point
A backup you have never restored is a hypothesis. Once a year we restore a real system from a real restore point, in a sandbox, and record how long it took. That number goes into the report, and if it does not match the agreed recovery time we change the design rather than the promise.
The test also catches the boring failures: the application that needs a licence key nobody kept, the server that will not boot without a domain controller that was restored second, the database that comes back but without the scheduled tasks. None of those show up in a backup log.
What you should see every month
Backup success rate per system, the age of the oldest and newest restore point, capacity used against capacity available, and any job that failed twice in a row. Anything less than that and you are being asked to trust a green tick.
That reporting is part of service governance, so it arrives on a rhythm rather than when somebody asks.
Questions we get about this
What comes up in every continuity conversation.
What is an immutable backup?
A backup copy that cannot be modified or deleted until its retention period expires, not even by someone with administrator rights. It is created using a hardened repository or object storage with a lock, and it is what stops ransomware from encrypting your recovery option along with your production systems.
Is Microsoft 365 backed up by Microsoft?
Not in the way most people assume. Microsoft protects the availability of the platform and offers limited retention for deleted items, but once that window passes the content is gone. A separate backup of Microsoft 365 is a standard part of any continuity design we build.
How often should we test a restore?
At least once a year for a full system restore, and continuously for automated verification where the tooling supports it. The annual test is what turns an assumption into a number you can put in front of a board or an auditor.
What does a backup design cost?
It scales with data volume and with how fast you need to be back. The recovery time is the expensive variable, not the storage: getting back in an hour costs considerably more than getting back in a day. We price both so you can decide which systems justify which.
Where this lands in our work
Where continuity connects.
Want this looked at for your own sites?
Half an hour on a call is usually enough to tell you whether we are the right party for it, and we will say so if we are not.