Objective
Build a backup strategy that keeps production data plus at least two backup copies across different failure domains, including one off-site copy, with measurable RPO/RTO targets, protection against malicious deletion, and recurring restore testing.
Prerequisites
- An inventory of data, VMs, databases, configurations, directories, and SaaS services to protect.
- RPO and RTO targets approved by business owners according to criticality.
- Current data volume, growth rate, backup window, and available bandwidth.
- Two backup targets or technologies that provide an independent failure domain and an off-site copy.
- A secure location for encryption keys and recovery credentials.
Step-by-step procedure
Classify workloads and their dependencies
List each critical service and everything required to restore it: VMs, databases, files, certificates, firewall configurations, directory services, DNS, SaaS applications, and secrets. Rank them by criticality and assign an owner. A database backup without its application or identity dependencies may not be enough for a real recovery.
- Every critical service has a complete backup scope and an accountable owner.
Define measurable RPO and RTO
RPO defines the maximum acceptable data loss; RTO defines the maximum recovery time. Translate both into backup frequency, retention, architecture, and restore priority. A daily backup cannot satisfy a one-hour RPO, so the schedule must match the business objective.
Exemple de matrice :
Service;RPO;RTO;Priority
ERP;1h;4h;P1
Fichiers;4h;8h;P2
Archives;24h;48h;P3- Backup frequency and recovery mechanisms are consistent with approved business targets.
Build the three copies
Keep the production data and create at least two backup copies. The first should support fast local recovery; the second must remain available if the main site, storage, or backup server is lost. In Veeam, a Backup Copy or another independent repository can provide the additional copy.
- Each critical workload has three data instances: production plus two backups.
Separate media and failure domains
Use genuinely independent media or technologies where practical, such as local disk plus object storage, NAS plus tape, or an appliance plus a hardened Linux repository. Document shared dependencies so a single hardware failure, software corruption, or ransomware event cannot affect all copies at once.
- The backup copies do not depend on the same storage, server, and single point of failure.
Keep one copy off-site
Place at least one backup in another site, region, or independent cloud service. Measure the bandwidth and recovery time required during a disaster. An off-site copy that takes too long to retrieve can satisfy 3-2-1 while still missing the RTO.
- Loss of the primary site does not prevent access to at least one restorable copy.
Add offline isolation or immutability
Strengthen 3-2-1 with an immutable, offline, or separately administered copy. Restrict deletion rights, use MFA for backup administration, and separate backup credentials from production-domain accounts. Size immutable repositories so capacity remains sufficient until retention expires.
- A compromised production administrator cannot immediately delete every backup copy.
Encrypt without losing the keys
Encrypt backups that contain sensitive data or leave the site, but keep recovery keys outside the protected system. Verify that at least two authorized people know how to retrieve the key during an incident. A perfectly encrypted backup is useless if its key is unavailable.
- Backups are protected and recovery keys remain accessible if the primary environment is lost.
Monitor jobs, capacity, and restore-point age
Monitor failures, warnings, duration, throughput, free space, and the absence of new restore points. Escalate when a critical workload has no successful backup within its RPO. A simple dashboard showing last success, off-site copy status, and last restore test exposes gaps quickly.
- A stale backup or repository nearing capacity generates an operational action.
Test restorations at several levels
Schedule file, VM, and application restore tests and measure the actual RTO. Test the off-site or immutable copy as well as the primary backup. Use an isolated lab for complex systems and validate application behavior with the business owner.
- Each service class has recent evidence that it can actually be restored.
Review the strategy after major changes
Reassess volume, dependencies, and backup coverage after new VMs, cloud migrations, ERP changes, or network redesigns. Confirm that new data enters the jobs and that the off-site copy still completes. A 3-2-1 strategy must evolve with the environment and business targets.
- Inventory, capacity, RPO/RTO, and restore tests remain aligned with the real environment.
Validation
The procedure is validated when:
- Every critical workload has production data plus two distinct backup copies.
- At least one copy is outside the primary failure domain.
- At least one copy is isolated, immutable, or protected by strong credential separation.
- Recent backups meet the RPO and restore tests measure the actual RTO.
- Encryption keys and recovery procedures remain available outside the primary system.
Rollback
- Keep the previous backup design during validation of the new architecture.
- Do not remove an old repository until both new copies have passed a complete restore test.
- If the off-site copy overloads the WAN, temporarily reduce its schedule or scope while preserving the primary backup and correcting capacity.
Troubleshooting / common errors
- If backup jobs succeed but restore tests fail, treat the strategy as failed until restore reliability is corrected.
- If an immutable repository fills too quickly, correct retention and capacity before shortening protection without approval.
- If off-site recovery misses the RTO, test seeding, alternate transport, or a closer recovery tier.