Backups against ransomware: prepare before it happens
A preventive look at backup discipline, offline copies, and recovery testing - while there is still time to do it calmly.
Malware that encrypts files and demands a ransom has existed for a few years. For now it is rare - isolated incidents discussed in professional circles as an oddity. But the attack mechanic is simple, and wider distribution of these tools is only a matter of time.
I am writing this now, while the situation has not yet become widespread. Because preparing for something like this needs to happen in a calm state - not in a panic, when the server is already encrypted.
Why a normal backup does not save you
Most companies run backups. But the question is not whether backups are running - it is whether they will survive an attack. Even before the ransomware question, many backup schemes were already broken by virtualisation.
If backup files sit on a network drive connected to the same infrastructure, ransomware will reach them. If backups run daily and are kept for a few days, but the attack is discovered a week later, there may be no usable copies left. If the recovery procedure has never been tested in practice, discovering that it does not work at the moment of an incident is the worst possible time for that discovery.
A backup is not a file on a disk. It is the ability to restore operations within an acceptable time. Those are different things.
What an offline copy is and why it matters
An offline copy is a backup that is physically or logically separated from the main infrastructure and is not reachable over the network during normal operations.
Options:
- an external medium (tape, drive) that is physically disconnected after writing;
- a copy in cloud storage with separate credentials that are not linked to the main infrastructure;
- a time-delayed backup - an "air gap" in time where the last copy has not yet been overwritten.
The goal is the same in all cases: if the main infrastructure is compromised, there must be a copy the attack has not reached.
Testing recovery
A backup without a test is a belief, not a protection. A common situation: a company had been running backups for years, and when they attempted a restore they found the files were corrupted, the format was outdated, or the procedure took three times longer than expected.
A minimum sensible practice:
- run a test restore of at least part of the data to an isolated environment once a quarter;
- record how long a full recovery of critical systems actually takes;
- verify not just that files were copied, but that the restored systems actually function.
This is dull work. That is exactly why it is almost never done until something breaks.
What needs to be documented
During an incident, the people who know what to do may be unreachable. The recovery procedure must exist as a document, not only in the system administrator's head.
Minimum contents:
- where backup copies physically live and how to access them;
- the order in which systems are restored (what comes first, what comes after);
- who decides to declare an incident and initiate the procedure;
- who calls whom and in what order.
The document must be accessible without access to the main infrastructure - printed out, kept in a safe, or stored somewhere separate.
A quick readiness audit
Four questions worth asking right now:
- Where are backup copies of critical data stored - and are they reachable from the main network?
- When was the last time anyone verified that a working system could actually be restored from backup?
- How long would recovery take if the main storage were completely unavailable?
- Is there a written procedure that someone unfamiliar with these systems could follow?
If any one of these questions has no answer, that is the right place to start.