Backups usually come to mind when they are already needed: a server won’t start after an emergency power cut, an employee deleted a folder, ransomware locked the files. That is exactly when it turns out the copy is outdated, sits on the same storage, or nobody has ever restored from it.
Here is how to build backup around the 3-2-1 rule, what its modern version 3-2-1-1-0 adds, and how to make sure the copies will actually work.
The 3-2-1 rule: what it means
The rule is described, among others, in the US-CERT paper “Data Backup Options” (US-CERT is now part of CISA):
- 3 copies of important data: the original and two backups.
- 2 different media types — so that one cause of failure cannot destroy every copy. For example, disk storage in the server room plus a tape library or cloud object storage.
- 1 copy off-site — at another site or in the cloud, so that a fire, a flood or losing access to the premises does not take the backups too.
Each element covers its own risk: two copies instead of one — a media failure; different media — a problem with one storage type; an off-site copy — losing the site itself.
3-2-1-1-0: the rule with ransomware in mind
Modern attacks go after backups too. According to the review by Ukraine’s National Cybersecurity Coordination Center, the attack on Ukrzaliznytsia (Ukrainian Railways) in March 2025 destroyed the virtualisation and backup systems at both the primary and the backup site, and one ransomware group deleted shadow copies before encrypting, to prevent recovery.
That is why two more digits are added to the classic rule. In Veeam’s best practices:
- +1 copy offline, air-gapped or immutable — one that cannot be changed or deleted from the main network.
- 0 errors. The recoverability of every copy is verified automatically.
The #StopRansomware Guide by the US agencies CISA, NSA and FBI likewise recommends keeping offline, encrypted backups of critical data and testing them regularly.
What to back up
- Servers and virtual machines — whole, so you can bring a system back quickly, not just files.
- Databases (Microsoft SQL Server, Oracle, MySQL) — consistent copies made by the database itself or by an application-aware agent; a file copy of a running database may not restore.
- Active Directory — without it, accounts and access will not work after a disaster.
- File shares and SharePoint.
- Configurations of network equipment and firewalls — rebuilding them from memory takes a long time.
- Cloud services, including Microsoft 365. In the shared responsibility model described by Microsoft, the customer is responsible for data whatever the service type.
What is not a backup:
- A snapshot on the same storage: it is lost together with the storage.
- Replication and RAID: they protect against hardware failure, but copy deletions and encryption just as fast.
- Syncing to a cloud drive: a deleted or encrypted file is synced too.
How often to back up and how long to keep copies
- Frequency follows the RPO — the acceptable data loss. If a system can lose no more than an hour of work, it needs a backup or replica at least every hour. How to set RPO and RTO for each system is covered in “Blackouts: how to keep business IT running”.
- The restore method follows the RTO — the acceptable downtime. Restoring a large virtual machine from tape and running it straight from backup storage take very different times, and you need to know which in advance.
- Retention. Keep daily, weekly and monthly copies. Attackers can sit in a network long before encrypting it, so you need a restore point from before they got in. For some data, retention periods are set by law — check them with your lawyer.
How to protect the backups themselves
- Separate accounts for the backup system, not tied to the main domain, and multi-factor authentication on the console. Veeam calls the backup server the number one target in the infrastructure and recommends tightly restricting access to it.
- Immutable storage (for example, object storage with change locking) or offline media — tapes, removable disks.
- Encrypt backups, especially off-site ones; keep the keys separate from the copies.
- Separate the backup storage from working networks.
- Monitoring: alerts on failed jobs, deleted copies and changed retention policies. Such events call for an immediate check; send them to security monitoring, for example SOC as a Service.
Testing restores
A backup you have never restored from is an assumption, not a guarantee.
- Regularly restore files, virtual machines, databases and Active Directory in an isolated environment.
- Set up automatic verification: does the restored machine boot, does the application respond.
- Measure the actual restore time and compare it with the RTO.
- After every test, update the procedure: what was restored, how long it took, what got in the way.
Recovery plan
During a disaster there is no time to decide where to start. Describe in advance:
- Restore order: network and Active Directory, then databases, then applications.
- Roles: who decides, who restores, who checks and informs the business.
- Where to restore if the primary site is unavailable: a backup server room, a private or public cloud. Options are covered in “Moving servers to the EU: when it makes sense”.
- Where the instructions and backup access credentials are kept — so they are available even when the main systems are down.
If the cause is an attack, close the way in first and only then restore; otherwise the attackers will encrypt the restored systems too. First steps during an attack: “Cyberattacks on business: 10 basic defences”.
Common mistakes
- All copies on the same storage or in the same domain as the working systems.
- The backups are reachable from an admin account that can be stolen.
- Application databases, Active Directory or Microsoft 365 are not backed up.
- Retention is a few days, while the attack is noticed later.
- A restore has never been tested.
Checklist
- Three copies on two media types, one of them off-site
- There is an offline, air-gapped or immutable copy
- Servers, databases, Active Directory, configurations and Microsoft 365 are backed up
- Backup frequency matches the RPO, the restore method matches the RTO
- Daily, weekly and monthly restore points exist
- The backup system has separate accounts and multi-factor authentication
- Off-site copies are encrypted, keys are stored separately
- Failed jobs and deleted copies are monitored
- Restores are tested regularly, the actual restore time is known
- A recovery plan with order, roles and accessible instructions exists
How Bereg-IT can help
We start with a backup audit: what is backed up, where it is stored, how fast it restores. Then we build a 3-2-1 strategy — including backup as a service (BaaS) in the cloud or on your own servers — set up restores of files and applications, including Active Directory, SharePoint, Microsoft SQL Server and Oracle, and automatic integrity checks of the copies. Among other tools, we work with Veeam. More on IT infrastructure and cloud solutions; you can start with a consultation or an audit.
The first consultation is free. Send a request and an IT engineer will get in touch.
Sources
- P. Ruggiero, M. A. Heckathorn, Data Backup Options, US-CERT (2012) — the 3-2-1 rule: https://www.cisa.gov/sites/default/files/publications/data_backup_options.pdf
- Veeam, Best Practice Guide — Protect — the 3-2-1-1-0 rule and protecting the backup server: https://bp.veeam.com/security/Design-and-implementation/Protect.html
- CISA, MS-ISAC, NSA, FBI, #StopRansomware Guide (September 2023) — offline, encrypted backups: https://www.cisa.gov/stopransomware/ransomware-guide
- National Cybersecurity Coordination Center at the NSDC of Ukraine, Review of the National Cybersecurity System of Ukraine 2025 (in Ukrainian) — attacks on backup systems: https://www.rnbo.gov.ua/files/2026/NATIONAL_CYBER_SCC/kiber_2025.pdf
- Microsoft Learn, Shared responsibility in the cloud — customer responsibility for data: https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (2010) — RTO and RPO: https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final