HCI vs. external backup storage is a question that surfaces at refresh time. A hyper-converged cluster is running short of space, backups make up a growing share of what it holds, and the simplest proposal is to add nodes. The alternative is to move backup data to storage outside the cluster and let the cluster grow only for the workloads it runs. Both are valid ways to buy capacity. They differ in what that capacity costs, what it is protected against and how it grows next time.
This post looks at where backup capacity should grow, with the cost and failure-domain reasoning behind each choice.
Hyper-converged infrastructure combines compute, storage and virtualization in each node, and it scales by adding nodes. That model suits production workloads whose need for processors, memory and disk rises together. Backup data behaves differently. It needs a great deal of capacity, modest compute and almost no memory, and it grows with retention policy as much as with the size of production.
When backups are kept on the cluster, either on a virtual backup repository or on a datastore set aside for them, every terabyte of backup growth is paid for at the price of a full node.
| Consideration | Expand the HCI cluster | External backup storage |
|---|---|---|
| Unit of growth | A node with compute, memory and disk | Capacity, with compute sized for storage only |
| Licensing affected | Hypervisor and HCI software, often per core or per node | Storage software or appliance only |
| Failure domain | Shared with production | Separate from production |
| Administrative boundary | Same cluster administrators | Can be held by a separate account set |
| Effect of a cluster outage | Backups unavailable with the workloads | Backups remain reachable |
| Effect of a platform change | Backups move with the cluster | Backups stay where they are |
A node added for backup capacity brings processors and memory that backups do not use, and those processors are frequently licensed. The cluster's own data protection also applies: storage policies that keep two or three copies of each block, or erasure coding with its overhead, reduce the usable share of every raw terabyte. The figure to compare is cost per usable terabyte of backup data after both effects, not the list price of a node.
Comparing usable backup capacity shows how to bring quotes with different protection schemes into one unit so the two options can be set side by side.
Cost aside, backups that live on the cluster they protect share its fate. A storage layer fault, a failed upgrade, a ransomware incident that reaches the hypervisor management plane or a mistaken deletion of a datastore can remove production and its backups in the same event. A backup is meant to be the copy that survives whatever happens to the primary system, which is difficult to argue when both sit on the same disks under the same administrator accounts.
The same reasoning applies to immutability. A lock enforced by a virtual machine on the cluster is only as strong as the cluster's own access controls. What survives a compromised backup server works through which copies remain when the virtual infrastructure is no longer trusted.
There are cases for a small backup footprint on HCI. Short-retention snapshots and a few days of local restore points give fast recovery from everyday mistakes. A remote office with a two-node cluster and no room for further hardware may keep a local copy there and send a second copy to a central site. In both cases the on-cluster copy is a convenience, and the copy that counts for disaster and cyber recovery sits elsewhere.
Moving backups off the cluster only helps if the target is independent of it. That means separate hardware, separate administrative credentials, a network path that does not depend on the cluster's virtual switching and immutability enforced by the storage itself. It also needs enough write throughput to hold the backup window and enough read throughput for a mass restore, which should be measured, not assumed. Mass VM recovery planning covers what a large restore asks of the repository.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. It sits outside the hyper-converged cluster, presents an S3 endpoint to the backup software and has 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.
Capacity grows within the same deployment from roughly 50 TB to 8.5 PB, with servers sized for storage. ARTESCA is used as a target for Veeam and other backup software, and it remains in place if the cluster's hypervisor or hardware changes.
At refresh time, it helps to split the capacity request in two. One line is growth in production workloads, which belongs on the cluster. The other is growth in backup data, which can be priced both ways. With the two separated, the node count for the cluster often comes down, and the backup line can be judged on usable cost, independence from production and how it will grow over the next three years.