Virtual backup targets are repositories that run as virtual machines instead of on dedicated hardware. They are quick to deploy, need no purchase order for servers and can be created in an afternoon on capacity the organization already has. For a pilot, a small site or a temporary need, that convenience is hard to beat. The open question is when a virtual machine stops being enough, and which risks come with putting backups on the infrastructure they protect.
This post sets out where a virtual backup target fits, where it does not and what to check before relying on one.
A virtual backup target is storage software installed in a virtual machine, with virtual disks that sit on a datastore of the host cluster. To the backup software it looks like any other repository, whether it presents a file share, a block device or an S3 endpoint. Underneath, its data lives on the same physical storage as other virtual machines unless the hosts and datastores are deliberately kept apart.
| Consideration | Virtual target | Physical target |
|---|---|---|
| Time to deploy | Hours | Days to weeks, depending on hardware delivery |
| Upfront hardware cost | None if spare capacity exists | Servers and drives |
| Failure domain | Shared with the host cluster and its storage | Independent of the virtual environment |
| Administrative boundary | Hypervisor administrators can reach its disks | Can be isolated from virtualization admins |
| Performance | Shared with other workloads on the hosts | Dedicated to backup |
| Capacity ceiling | Limited by datastore size and cost | Limited by the storage system's design |
| Cost per terabyte at scale | High on primary storage | Lower on capacity-optimized hardware |
There are four situations in which a virtual target is a sound choice. The first is evaluation: testing storage software and its integration with the backup product before buying hardware. The second is a small or remote site with a handful of virtual machines and no room for another server. The third is a short-term need, such as a landing zone during a migration. The fourth is a secondary copy for a specific workload, where the primary copy sits on independent storage.
In each case the virtual target is either temporary or not the only copy. That is the pattern to hold on to.
The main weakness is that a virtual target depends on the environment it protects. If the cluster's storage fails, the production virtual machines and the backup repository's virtual disks are lost together. If the virtualization platform is unavailable after a failed upgrade, the repository is unavailable too, at the moment a restore is needed. A backup is supposed to be usable when the primary system is not. HCI versus external backup storage makes the same argument for hyper-converged clusters.
Placing the virtual target on separate hosts with separate storage reduces the overlap. At that point, though, the hardware is dedicated to backup in all but name, and the virtualization layer adds little.
Immutability inside a virtual machine protects against deletion through the storage software's own interfaces. It does not protect against someone deleting the virtual machine or its disks from the hypervisor. An attacker who gains hypervisor administrator rights, a common objective in ransomware incidents, can remove a virtual repository without ever touching its software. What survives a compromised backup server traces which copies remain after that kind of access.
This is the reason a virtual target should not hold the only immutable copy. Whatever lock it enforces is conditional on the hypervisor layer staying intact.
A virtual target shares processors, memory, network and storage with production workloads. Backups run at night when hosts are quieter, so the contention often goes unnoticed. A mass restore runs when everything else is also trying to recover, and the repository competes with the virtual machines it is restoring. Capacity is the other limit. Datastores on primary storage are priced for performance, and filling them with weeks of backup retention is an expensive use of that space. Beyond a few tens of terabytes, dedicated capacity-optimized hardware is usually cheaper.
Several signals show that a virtual target has been outgrown. The repository's virtual disks are among the largest consumers of the datastore. Backup windows lengthen as host load rises. The security review asks where the immutable copy is and who can delete it. Or the virtual target, deployed as a pilot, has become the production repository without anyone deciding it should. Backup capacity alerts covers how to catch the capacity side of this early.
ARTESCA is object storage software used as a backup target. It is deployed as a software appliance on industry-standard x86 servers the customer chooses or supplied as a pre-configured hardware appliance, which places the repository outside the virtual environment it protects and under its own administrative accounts. Immutability is provided by S3 Object Lock on each object, and in compliance mode no account, including ARTESCA administrators, can remove a lock before it expires.
ARTESCA can span several servers and grows within the same deployment from roughly 50 TB to 8.5 PB. It is used as a target for Veeam and other backup software.
A virtual backup target is enough when losing it together with the host cluster would not leave the organization without backups. If another copy exists on independent storage, the virtual target is a convenience. If it is the only copy, or the only immutable one, it is a risk that happens to be easy to deploy.