If nobody knows, that’s the answer. Call if something is wrong now, or book a free IT review. No pressure, no jargon.
Immutable backups: why ransomware goes after your backups first
If attackers can delete your backups, they can name their price.
Modern ransomware looks for backups before it locks your files. An immutable backup is a copy that can’t be changed or deleted for a set time. Ours are locked for 30 days. Here’s what that means, how we set it up, and what it can’t do.
What is an immutable backup?
Immutable means unchangeable. An immutable backup is written once, then locked for a set lock period. During that time it can’t be edited, encrypted or deleted through normal means, including by the backup software itself. When the lock period ends, the copy ages out on schedule. Our lock period is 30 days.
Why it matters
Backups are the reason you don’t have to pay. Attackers know that too.
If you own the business
- Pay or rebuild is a terrible choice. A locked copy gives you a third option: restore.
- Insurers ask about backups. Commonly: are they tested, is there an offsite copy, can they be deleted? Read your policy and answer honestly.
- Client and patient data stay recoverable, even if someone gets admin access to your network.
If you run the office
- You won’t be the one who “forgot the backup”. Backups run on schedule, and we watch them.
- A deleted folder isn’t a crisis. We can bring it back from a point in time before the mistake.
- You can answer the insurer form with a plain list from us of what’s in place.
How immutability works
The lock lives in the storage, not in a setting someone can untick on a bad day.
Write once, then lock
Each backup is written, then stamped with a date before which it can’t be changed or removed. Storage that supports this is often called WORM (write once, read many).
Two common ways to do it
Object storage with a lock feature (often called object lock), or a hardened backup server whose files are flagged unchangeable at the operating system level. Veeam supports both, through a hardened repository or object lock in compliance mode. On a Synology NAS, the same idea is called immutable snapshots.
Who can unlock it early? No one.
We use a compliance-style lock, the strictest kind. Until the 30 days are up, no one can change or delete a locked copy: not your staff, not an attacker with a stolen admin password, not an administrator and not Benson Hunt. When the 30 days end, the lock lifts on its own.
Where immutability fits in 3-2-1
3-2-1 is the long-standing rule: three copies of your data, on two kinds of storage, with one copy offsite. Immutability adds a copy that can’t be tampered with. Some people call the full idea 3-2-1-1-0: one copy offline or immutable, and zero errors when restores are tested.
- Copy 1: your live data on the server or in the cloud.
- Copy 2: a local backup for fast restores. When we restore a failed server from local storage with Hyper-V and Veeam, it has taken less than 2 hours.
- Copy 3: an encrypted copy in offsite cold storage in Vancouver, BC, so a fire, flood or theft at the office doesn’t take every copy.
- The lock: immutable copies kept for 30 days.
How we set it up
- Veeam for servers and for Microsoft 365. For Google Workspace, Synology Active Backup for Google Workspace backs up Gmail, Drive, shared drives, contacts and calendars to a Synology NAS on site. Veeam then copies that backup offsite, encrypted, with the same 30 day lock.
- A 30 day compliance-style lock on immutable copies. No one can shorten it or remove it early, us included.
- Encrypted offsite cold storage in Vancouver, BC. Your offsite copy stays in Canada.
- Separate credentials. Backup storage has its own sign in, never shared with the everyday office network, so one stolen admin account doesn’t open everything.
- Spot checks on multiple copies, and a yearly disaster recovery test. We restore, then check that the software opens and the files are there.
- We ask two questions first: how long can you be down, and how much work could you redo? Those answers decide how often we back up.
What immutable backups can’t do
- Stop an attack. They get you back after one. Prevention is the job of the firewall, filtering, multi-factor sign in, monitoring and training.
- Protect data that was never backed up. A laptop full of files that never reached the server or the cloud isn’t covered.
- Undo stolen data. If files were copied out before they were locked, a backup brings them back for you, but it doesn’t take them back from the attacker.
- Keep a copy longer than the lock. After 30 days, copies age out on schedule.
Common mistakes we see
- A USB drive left plugged in. Ransomware encrypts it with everything else.
- Backups that sign in with the same admin account as the office network.
- A lock period shorter than the time attackers often sit unnoticed, so every clean copy has already aged out.
- Never testing a restore. A backup that has never been restored is only a hope.
- Counting on the Microsoft 365 or Google recycle bin. Those windows are short. After they empty, data can be gone for good.
- Calling RAID or a Hyper-V checkpoint a backup. Neither is. Why RAID is not a backup
Immutable backup questions
Can anyone delete an immutable backup?
No. During the 30 day lock, no one can change or delete a locked copy: not your staff, not an attacker, not an administrator and not Benson Hunt. The lock is on the backup copies themselves for the whole 30 days, and it lifts on its own when they end. It doesn’t clean a copy that was already infected when it was made, which is why we test restores.
Is immutable the same as offsite?
No. Offsite protects against fire, flood and theft at the office. Immutable protects against tampering and deletion. We do both: an encrypted offsite copy in Vancouver, BC, and copies locked for 30 days.
Why 30 days?
It gives a long window to find a clean copy if something goes wrong unnoticed, while keeping storage costs sensible. If your industry or insurer needs longer retention, ask us.
Do you back up Microsoft 365 and Google Workspace?
Yes. See Microsoft 365 and Google Workspace for how.
How do we know a restore will work?
We test. Spot checks on multiple copies, and a yearly disaster recovery test where we restore and check that the software opens and the files are there.
