Veeam Backup & Replication Security Best Practice Guide
Backup Data Hardening
The ultimate goal of data protection is having backups available when a restore is needed. With the rise of ransomware, that goal has expanded: it’s no longer enough to be able to restore data - the infrastructure needs to survive the attack that necessitated the restore in the first place. This is what Cyber Resilience adds on top of traditional data protection, and it’s the lens this section applies to the second pillar established in System Resilience: the backup data itself.
Beyond Immutability
Immutability has rightfully dominated the conversation on backup data protection - it’s the single control most directly effective against ransomware, and it earns every page dedicated to it later in this section. But it answers one threat: deletion and modification. It does nothing against a major disaster taking out an entire site, or against silent data corruption that immutability will faithfully preserve right alongside the good data.
Multiple copies, on separate media, in separate locations, are what cover those other failure modes. Immutability and redundancy are not competing strategies - they protect against different things, and a mature architecture needs both.
3-2-1, Applied Rather Than Recited
3-2-1 summarizes the underlying logic: more than one copy, on different media, in more than one location. It’s a starting heuristic, not a specification. Depending on business goals, some environments genuinely need five copies; others run safely on two. Some keep everything offsite; others keep everything on-premises for good operational reasons. What matters is the resilience the combination actually delivers - the ability to restore when one copy fails - not compliance with a specific digit count.
Trust and the Layers Underneath
A repository is only as trustworthy as everything it depends on to run. A repository virtualized as a VM on a hypervisor inherits every risk of that hypervisor: it depends on other systems just to stay operational, and a compromise at that lower layer reaches every layer built on top of it - immutability included. An immutable filesystem is not immutable at all if the hypervisor underneath it can be told to delete the disk it lives on.
This is not a reason to avoid virtualization everywhere - it’s a reason to be deliberate about where it’s acceptable. For a repository specifically, given how much rides on its integrity, bare-metal deployment should be the default recommendation, not virtualization for the sake of convenience. Where virtualization is unavoidable, treat the hypervisor as part of the repository’s trust boundary, not as neutral infrastructure underneath it.
Multiple Copies
Different copies should rely on different underlying technology where possible - a hardened Linux repository, an object storage bucket, a proprietary deduplication appliance, tape - rather than several copies sitting on the same storage type. This protocol gap cuts both ways: it protects against an attacker who has learned to defeat one repository technology and gains nothing against the others, and it protects against a bug or zero-day in a specific storage system - a flaw that takes out every copy relying on it, regardless of whether anyone ever attacks it. Different motive, same defense: diversity of technology means no single failure, exploited or accidental, reaches every copy.
The result is layered resiliency: any single layer can fail as long as at least one other layer survives to restore from.
Secure and Offsite Copies
A copy stored elsewhere is not automatically a secure copy. Moving a backup offsite protects against site-level disasters - fire, flood, a regional outage - but if that copy is reachable with the same credentials and over the same network path as the primary, an attacker who compromises one compromises both.
A secure copy adds isolation on top of distance: separate credentials, a separate network path, and ideally separate management altogether. Air gap is the extreme end of this - a copy with no live connection to the production or backup network at all - and it protects against a threat immutability alone does not: an insider with legitimate administrative access.
Air gap has historically come at a cost: a copy with no live connection is also a copy nobody can restore from, or even verify, without a manual step to reconnect it. Immutability changes this trade-off. An immutable copy is logically air-gapped - untouchable by design, since nothing, not even an administrator, can delete or modify it within its retention period - while remaining online, visible, and readable. You get the isolation of an air gap without losing the ability to restore or verify on demand.