VM and container backup used to be handled by different teams with different tools. Virtual machines belonged to the infrastructure group and its established backup product. Containers belonged to the platform team, which often started with no backup at all and later added a Kubernetes-native tool. As both mature, the question arises whether their backups can share one repository, and what has to be true for that to work safely.
This post looks at how the two kinds of backup differ, what a shared repository has to provide and where separation is still needed inside it.
A virtual machine backup captures a disk image. The backup software reads changed blocks through the hypervisor, and the result is a chain of full and incremental restore points per machine. A container backup captures an application: its Kubernetes resource definitions and the data in its persistent volumes. The container images themselves are usually not backed up, because they can be pulled again from a registry.
The two also differ in rhythm. Virtual machines are long-lived and backed up nightly. Containerized applications change often, namespaces are created and removed, and backup policies are frequently attached to applications through labels instead of a fixed list.
| Aspect | Virtual machine backup | Container backup |
|---|---|---|
| Unit protected | Whole machine disk image | Application: resources plus volume data |
| Typical data volume | Large, steady | Smaller per application, growing with adoption |
| Object pattern on S3 | Fewer, larger objects | Many small objects and metadata files |
| Who administers it | Infrastructure or backup team | Platform or application team |
| Restore target | Same or another hypervisor | Same or another cluster or namespace |
| Common repository interface | S3, among others | S3 almost universally |
The common ground is the last row. Both kinds of backup software can write to S3-compatible object storage, which makes a shared repository technically simple. The operational case follows. One repository means one system to patch, one capacity plan, one set of immutability settings and one place to check after an incident. For a small team, removing a second storage system is a real saving. Backup storage consolidation sets out when that saving outweighs the concentration of risk.
Sharing hardware does not mean sharing everything. Each backup tool should have its own buckets and its own access keys, scoped so that neither can read or delete the other's data. Where the two are run by different teams, separate accounts or tenants on the object store keep administration apart as well. Retention and Object Lock settings are set per bucket, so the virtual machine backups can hold a 30-day lock while container backups use a different period.
This separation is what limits the damage if one tool's credentials are exposed. Limiting the reach of backup service accounts describes how to scope keys so that a compromise stays contained.
A shared repository has to be sized on two dimensions. Virtual machine backups dominate capacity, measured in terabytes. Container backups contribute far more objects per terabyte, and their retention processing lists and deletes many small objects. The repository needs enough metadata performance for the second pattern without slowing the large sequential writes of the first.
Timing matters too. If both tools run their heaviest jobs in the same overnight window, the repository sees peak load from both at once. Staggering the schedules is usually enough. Tuning job concurrency covers how to keep parallel streams within what a repository can absorb.
There are sound reasons for separate repositories. A container platform in a different site or cloud region should have its backup target near it. Regulated workloads may require physically separate storage. And if the virtual machine repository is a legacy system that speaks only a proprietary protocol, the container backups will need their own S3 target anyway. In that last case, the new S3 target is often the one that both converge on over time.
A shared repository is most useful after a wide incident. Applications are frequently split across both worlds, with a database on a virtual machine and its front end in containers. Recovering the service means restoring both from points close together in time. Having the restore points in one place, under one immutability regime, makes it easier to choose a consistent pair. Choosing a clean recovery point explains how to pick points when the time of compromise is uncertain.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. It presents an S3 endpoint that virtual machine and Kubernetes backup tools can both write to, with separate buckets and access keys for each. 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 grows within the same deployment from roughly 50 TB to 8.5 PB and is used as a target for Veeam and other backup software.
Four checks cover most of the risk. Each backup tool has its own bucket and keys. Immutability is enabled and verified on every bucket. The job schedules have been compared for overlap. And one combined restore, a virtual machine and a containerized application from the same night, has been run end to end. With those in place, one repository can serve both without either team giving up control of its own backups.