Why backups are a target
Ransomware is malicious software that encrypts or locks data and demands payment for its return. For many organizations, the strongest defense is the ability to restore from a clean backup instead of paying. Attackers know this, so many attacks try to find and damage backups first, often quietly, before revealing the main attack.
Typical tactics include deleting backup files and snapshots, encrypting backup storage along with everything else, tampering with backup software settings or schedules, and stealing the data too, so there is pressure to pay even if backups survive. The details differ between incidents, and no single measure stops all of them. The aim is to make it harder for an attacker to reach every copy.
The core idea: separation
If a backup is reachable from the same network, with the same accounts, as the systems being attacked, then whoever controls those systems may control the backup too. A drive permanently attached to a server, or a network share that every computer can write to, is often exposed in exactly this way. Protection comes from adding separation:
- Separation of location. Keep at least one copy away from the main network, in a different place or a separate service.
- Separation of access. Use accounts for backup administration that are not the everyday administrator accounts and that are not used to sign in to normal workstations.
- Separation of time. Keep multiple older versions, so that if damaged data is backed up for several days before anyone notices, a good version still exists.
Isolation in practice
Several general approaches help, at different costs:
Offline or disconnected copies. Media that is physically disconnected most of the time, such as rotated drives stored elsewhere, cannot be encrypted by malware that is not connected to it. The trade-off is manual effort, and the need to make sure the media is genuinely disconnected when it should be.
Immutable or write-once storage. Some storage systems and services can prevent backups from being changed or deleted for a set period, even by administrators. This reduces the damage if an administrative account is compromised. Check carefully how any such feature is configured, because settings, retention periods and who can alter them matter a great deal.
Separate credentials and strong sign-in. Protect backup systems with unique credentials and multi-factor authentication. Apply least privilege so that backup accounts can do only what they need. The same goes for any service accounts used by backup jobs, which are often overlooked and over-permissioned.
Network segmentation. Place backup systems on a separate part of the network with restricted access, so that an infected workstation cannot reach them directly. Basic firewall rules and a secure network design support this.
Cloud copies with care. Cloud storage provides a copy away from your premises, but synchronized folders are not backups: if a file is encrypted locally, the encrypted version may sync up and overwrite the good one. Versioning and recovery features can help, and under the principle of shared responsibility you remain responsible for configuring access and protecting accounts.
The 3-2-1 rule gives a useful base, and many people extend it by making sure that at least one copy is offline or immutable.
Protect the data inside backups
Backups contain complete copies of sensitive information, so a stolen backup can be as damaging as a stolen database. Data encryption of backup media and transfers limits that exposure, provided the keys are kept safe and recoverable by trusted staff. Remember that a lost key can make your own backup unreadable.
Reduce the chance of infection
Backups are the last line, not the first. General good practice still applies: prompt patch management, reducing exposed services, limiting administrative rights, filtering email, and security awareness so staff can recognize social engineering attempts. Understanding the different malware types helps teams recognize what they are facing. None of this guarantees safety, but it lowers the likelihood that you will ever need to rely on backups.
Watch for warning signs
Monitor backup jobs for unusual behavior: sudden changes in backup size, failed or missing runs, deleted backup sets, new administrator accounts, or settings being altered. Early detection can limit the loss. Good system monitoring and alerts that go to more than one person help.
Test restores and plan for recovery
A restore test confirms that backups are usable, and it should include restoring onto clean systems, since restoring onto infected machines can bring the problem back. Practice will also show how long recovery takes, which is vital in a real event. Restoring is only part of the response; a documented incident response approach, including incident containment before restoration, helps avoid making things worse. These steps belong within a wider disaster recovery plan.
Be realistic
No setup is immune. A well-resourced attacker may still find a way through, and every extra layer adds some cost and effort. The practical goal is to ensure that a single compromised account or a single infected network cannot erase every copy you have, and that you have rehearsed how to recover. If you are unsure about your setup, consider an independent review by a qualified professional.