A Backup Plan That Survives Fire, Theft and Ransomware
A backup is only useful if it survives the incident that destroys the original data.
That sounds obvious.
Yet many businesses still rely on:
a USB drive beside the server
a NAS in the same office
OneDrive synchronisation
snapshots controlled by the same administrator account
cloud backups nobody has ever restored
Those arrangements may help with accidental deletion.
They may not survive:
fire
theft
or:
ransomware
A proper backup strategy must assume something much worse than one failed hard drive.
It should assume that:
the building may be inaccessible
local equipment may be destroyed
administrator credentials may be compromised
connected storage may be encrypted
cloud backups may be targeted
the latest backup may itself contain corrupted data
The question is therefore not:
“Do we have backups?”
It is:
“Could we restore the business if the original systems and the obvious backups disappeared at the same time?”
Why Ordinary Backups Fail
Backup failures are often design failures rather than software failures.
Examples include:
server and backup stored in the same building
USB backup permanently connected
production administrator also controls backups
cloud synchronisation mistaken for independent backup
retention too short to recover from a delayed attack
backup repositories writable from compromised systems
nobody monitoring failures
nobody testing restores
recovery documentation stored only on the failed network
The NCSC specifically warns that cloud and on-premises backup data is not automatically resistant to ransomware simply because it is called a backup.
A green:
Backup successful
message is useful.
It is not proof that the business can recover.
Start With the 3-2-1 Principle
A useful starting point remains the 3-2-1 backup model:
3 copies of important data
across:
2 forms or locations of storage
with:
1 copy off-site
The principle is simple:
one incident should not be able to destroy every copy.
For modern ransomware protection, I would strengthen that with another requirement:
At least one recovery copy must be isolated, offline or protected against destructive modification.
The NCSC describes offline backups as copies that are not continuously accessible from the live environment so that an incident cannot affect all backups simultaneously.
Don't Get Too Hung Up on “3-2-1-1-0”
You will sometimes see:
3-2-1-1-0
where:
3 = copies
2 = storage types
1 = off-site
1 = offline/immutable
0 = unverified errors
It is a useful mnemonic.
But the numbers are less important than the design.
A business with four backup copies that can all be deleted using the same compromised administrator account is not well protected.
A business with fewer copies but strong separation, immutability, monitoring and tested restoration may be much more resilient.
Focus on failure independence, not just counting copies.
First Decide What Actually Needs Protecting
Before choosing a backup product, identify the systems the business cannot operate without.
That might include:
Microsoft 365
Exchange/email
OneDrive
SharePoint
file servers
databases
accounting systems
customer records
virtual machines
line-of-business software
websites
network configuration
firewall configuration
encryption keys
password-vault recovery information
recovery documentation
The NCSC recommends keeping an independent copy of important organisational data rather than relying solely on the resilience and recovery features built into an online service.
That matters particularly with cloud services.
Cloud does not automatically mean independently backed up.
Synchronisation Is Not the Same as Backup
Suppose somebody deletes an important file.
OneDrive synchronises the deletion.
The file disappears everywhere.
Version history or recycle-bin functionality may save you.
But synchronisation itself has done exactly what it was designed to do:
keep every copy synchronised.
The same applies to malicious encryption.
A ransomware-encrypted file may synchronise perfectly into the cloud.
That does not mean OneDrive, SharePoint or another cloud platform provides no recovery capability.
It means sync and independent backup solve different problems.
Decide How Much Data You Can Lose
Every important system should have a Recovery Point Objective — RPO.
That answers:
How much recent data could we afford to lose?
For example:
Finance system:
15 minutes
Shared documents:
4 hours
Archived files:
24 hours
Those numbers determine how frequently recovery points need to be created.
A once-a-night backup cannot meet a 15-minute RPO.
Decide How Long You Can Be Offline
You also need a Recovery Time Objective — RTO.
That answers:
How long can this service remain unavailable?
Examples:
Telephone system:
1 hour
Customer database:
2 hours
Archive server:
24 hours
The fact that a system is backed up does not tell you whether it can be restored quickly enough.
A 12 TB server stored in the cloud may be technically recoverable but still take far too long to download if nobody planned for disaster recovery.
Protecting Backups From Fire
A fire can affect:
server
NAS
USB drives
networking
power
local backup appliance
all at once.
The backup therefore needs geographical separation.
At least one useful recovery copy should be stored:
in another physical location
in a remote data centre
in an appropriately secured cloud backup service
Do not treat:
“It's in another room”
as an off-site backup.
A serious fire, flood, sprinkler activation or building-access restriction can affect the entire premises.
Keep Recovery Information Off-Site Too
This is often overlooked.
Suppose the building is inaccessible.
Where are:
backup credentials?
MFA recovery methods?
encryption keys?
supplier numbers?
firewall information?
restore procedure?
cyber-insurance contacts?
If the answer is:
“on the server”
you have another single point of failure.
Maintain securely protected recovery information that authorised staff can access even when the normal IT environment is unavailable.
Protecting Backups From Theft
A burglar may take:
laptops
desktops
server
NAS
external backup disks
in one incident.
So theft protection needs both:
physical separation
and:
encryption.
Backup copies containing business information should be encrypted appropriately.
But the encryption keys also need protection.
An encrypted backup whose only decryption key existed on the stolen server is not a useful recovery system.
Protecting Backups From Ransomware
Ransomware changes the threat model because the attacker may deliberately target the backup environment.
The NCSC's ransomware-resistant backup guidance recommends that backups be isolatable, resilient against destructive actions and capable of restoring earlier versions even when later backups become corrupted.
Attackers may attempt to:
encrypt backup repositories
delete snapshots
reduce retention
remove cloud recovery points
steal backup administrator credentials
disable backup jobs
compromise virtualisation hosts
This is why:
“We back up to a NAS every night”
is not enough if every compromised administrator can also delete the NAS backups.
Use Immutable Recovery Copies
An immutable backup cannot normally be changed or deleted during its protected retention period.
That can make it much harder for ransomware operators to destroy recovery data after obtaining administrator access.
Useful protections may include:
object-lock/immutability
write-once retention
delayed deletion
protected recovery vaults
separately controlled backup accounts
The important point is:
An attacker should not be able to delete every recovery point instantly using the same credentials used to manage the production environment.
Separate Backup Administration
This is one of the strongest improvements many SMEs can make.
Do not automatically use the same privileged account for:
Microsoft 365
servers
and:
backup administration.
The NCSC specifically recommends restricting access to backup systems and isolating their management interfaces as far as practical.
Use:
separate privileged identities
MFA
least privilege
restricted management access
A compromised ordinary administrator account should not automatically grant the attacker the ability to destroy the recovery platform.
Retention Needs to Be Long Enough
Suppose ransomware enters the network on Monday.
Nobody notices until three weeks later.
If your backup platform retains only:
7 days
of history, every surviving recovery point may already contain:
encrypted data
malicious configuration
attacker persistence
The NCSC explicitly recommends retaining earlier backups so organisations can restore from a known-clean point even when newer copies are corrupted.
Retention should therefore consider:
How long could an incident remain undetected?
not merely:
How many backups can we afford to store?
Offline Backups Still Have a Place
Offline backup does not necessarily mean somebody has to manually carry tapes home every evening.
But at least one recovery path should be inaccessible to a compromised production environment.
That might involve:
physically disconnected media
isolated backup infrastructure
immutable cloud storage
controlled vaulting
The NCSC's guidance on offline backups specifically recommends ensuring that not all backup copies are connected to live systems simultaneously.
Don't Forget Microsoft 365
A business may have moved:
documents
SharePoint
Teams files
to Microsoft 365 and assume:
“Microsoft backs it up.”
Microsoft provides extensive platform resilience and recovery capabilities.
But the business still needs to understand its own requirements around:
deletion
retention
malicious administrator actions
ransomware
long-term historical versions
independent recovery
The NCSC recommends independent backup for business-critical cloud data where the built-in service mechanisms do not meet the organisation's recovery requirement.
Test Restores, Not Just Backup Jobs
This is probably the most important operational requirement.
The NCSC explicitly recommends testing backups regularly and knowing how to restore data before a real disaster occurs.
Test things such as:
one deleted file
complete folder
mailbox
SharePoint data
database
virtual machine
entire server
application recovery
Then record:
Did it restore successfully?
How long did it take?
Were permissions preserved?
Could another technician repeat the process?
A backup nobody has restored is still partly an assumption.
Test Disaster Recovery as Well
File restoration and disaster recovery are different.
Restoring:
one Word document
does not prove you can recover:
the entire business after the server room burns down.
Periodically test a larger scenario.
For example:
> The main office is unavailable. The production server is destroyed. Administrator credentials may be compromised. How do we restore the critical services from another location?
You quickly discover dependencies such as:
internet connectivity
DNS
firewall configuration
encryption keys
licences
application installers
vendor support
authentication
Those dependencies belong in the recovery plan.
Restore Into a Clean Environment After Ransomware
Do not immediately reconnect recovered data to systems that may still contain the attacker.
The NCSC recommends verifying that the backup is clean and restoring only to devices or environments you are confident are free from malware.
A ransomware recovery may therefore involve:
1. Contain the attack.
2. Investigate the initial compromise.
3. Secure privileged accounts.
4. Rebuild clean infrastructure.
5. Validate the backup.
6. Restore into the clean environment.
7. Monitor closely afterwards.
Simply restoring yesterday's files onto a still-compromised server can allow the attacker to encrypt them again.
Monitor the Backup Platform
Backup systems should alert somebody when:
job fails
repository is inaccessible
retention changes
backup administrator changes
large numbers of copies are deleted
immutability is altered
backup infrastructure goes offline
The NCSC's ransomware-resistant principles specifically recommend alerts for significant changes and privileged actions affecting backups.
The most useless backup alert is the one nobody monitors.
How Often Should You Test?
There is no one frequency for every business.
A sensible schedule might involve:
frequent automated verification
plus:
regular sample file restores
plus:
periodic full workload/disaster-recovery tests.
Critical systems deserve more frequent testing than low-value archives.
The testing frequency should reflect:
business importance
complexity
rate of change
regulatory requirement
What About USB Drives?
USB drives can form one part of a backup strategy.
They should not normally be the entire strategy.
A permanently attached USB drive can be:
encrypted by ransomware
deleted accidentally
stolen
damaged in the same fire
If using removable media, rotate it appropriately and keep at least one copy disconnected and physically secure.
Also encrypt it where it contains sensitive business information.
What About a NAS?
A NAS can provide excellent local backup performance.
But a NAS in the same building remains vulnerable to:
fire
theft
flood
ransomware
administrator compromise
Use it as one layer.
Not the only layer.
A Practical SME Backup Architecture
For many SMEs, I would aim for something conceptually like:
Production
Live business systems.
Fast local recovery
Local backup appliance/NAS where appropriate.
Useful for quick restores.
Off-site recovery
Encrypted backup stored outside the premises.
Ransomware-resistant copy
Immutable or isolated recovery points with suitable retention.
Independent cloud-data protection
Where required for Microsoft 365 or other SaaS platforms.
Tested recovery
Scheduled restore tests and documented disaster-recovery procedures.
The exact technology depends on the organisation.
The principles do not.
The Backup Questions Every Business Should Answer
Before saying:
“Our backups are sorted.”
you should be able to answer:
1. What exactly is backed up?
2. Which systems are excluded?
3. How often are recovery points created?
4. How long are they kept?
5. Is one useful copy off-site?
6. Can ransomware reach every copy?
7. Can one administrator delete everything?
8. Are backups encrypted?
9. Where are the encryption keys?
10. Who receives failure alerts?
11. When was the last restore test?
12. How long would recovery take?
13. How much data could we lose?
14. What gets restored first?
15. Could we recover if the office itself was inaccessible?
If several answers are:
“I'm not sure”
then the backup strategy needs attention.
The Simplest Resilience Test
Ask:
Fire destroys the office
Can we recover?
Thieves take every local computer and storage device
Can we recover?
Ransomware compromises administrator accounts and deletes everything it can reach
Can we recover?
If the answer is:
Yes, because at least one independently protected and tested recovery path survives each event
then you have something approaching a proper backup strategy.
How Hamilton Group Can Help
Hamilton Group can help businesses design backup systems around actual recovery, not simply successful backup-job notifications.
We can assist with:
business backup
Microsoft 365 backup
server and virtual-machine backup
cloud backup
immutable backups
ransomware-resistant backups
off-site backup
retention planning
restore testing
disaster recovery
business continuity
The real objective is not:
“Our backups ran last night.”
It is:
“If the building, servers or administrator accounts were compromised tomorrow, we could still restore the business.”
Visit hgmssp.com or call 0330 043 0069 to discuss backup and disaster recovery.