Backup responsibility
SimpleVirt protects the platform. You protect the data inside your virtual machines.
This page draws the line precisely, so there is no gap you only discover during a restore.
What SimpleVirt backs up
SimpleVirt-Command controller state
SimpleVirt-Command can back up and restore its own state: the host inventory and the credentials that let the controller manage each host, operator accounts and roles, cluster definitions, datastore declarations, HA configuration and state, the ISO library catalogue, directory (LDAP/AD) settings, the task log, certificates, and — when the controller runs on its bundled database — a dump of that database.
- Take a backup: Administration → Backup → Download, or
GET /api/v1/backup. It streams a single gzip tar file. - Restore: upload it in the same place, or
POST /api/v1/restore. The controller swaps in the restored state and restarts on it.
Both operations are recorded in the audit log, because the backup file contains secrets — host credentials, Kubernetes join tokens, the local password store. Store it with the care you would give a password database: encrypted at rest, access-controlled, and not on the storage you are trying to be able to recover from.
Host configuration
Each SimpleVirt host holds its own configuration — its networking, its datastore mounts, its
VM definitions — and an in-place upgrade preserves all of it, along with the VM disks
under /var/lib/libvirt and the local accounts. A host reinstalled from scratch, however,
starts empty: its configuration is rebuilt by re-adding it to the controller and
re-applying the cluster's networking and storage, not restored from a file.
What SimpleVirt does not back up
The data inside your virtual machines. Guest filesystems, databases, application state — none of it is captured by anything SimpleVirt provides. There is no VM backup, no backup schedule, no catalogue, and no restore of a virtual machine.
The controller backup above does not contain a single byte of guest data. Restoring it onto a rebuilt controller gives you back a controller that knows about your fleet; it gives you back nothing that was inside a VM.
What you must put in place
Before you run anything you care about on SimpleVirt, have a backup product that covers guest data. In practice that means one of:
- An in-guest backup agent — your backup product's agent installed inside each VM, writing to a repository outside the cluster. This is the most portable option and the one that gives you application-consistent copies of databases, because the agent coordinates with the application.
- Storage-tier backup — snapshots and replication performed by the NFS appliance or array that hosts your datastore, managed by that system rather than by SimpleVirt.
Whichever you choose:
- Keep copies off the datastore holding the VM. A copy that dies with the datastore is not a backup.
- Cover the controller too. Download a SimpleVirt-Command backup on a schedule and store it with your other backups.
- Test a restore. An untested backup is an assumption.
How the pieces you do have fit a recovery plan
SimpleVirt gives you two things that look like protection. Both are useful. Neither is a backup, and knowing the difference is what keeps a recovery plan honest.
Snapshots — a short-term undo, not a backup
Take a snapshot before a change you might want to reverse within the hour: a patch, an upgrade, a configuration edit. Revert it or delete it when you know the outcome.
What a snapshot cannot do for you:
- It is crash-consistent. SimpleVirt does not quiesce the guest, so the snapshot captures the VM as if the power had been cut. A database recovers from it the way it recovers from a crash.
- It lives on the same datastore as the VM, inside the VM's own disk image. It does not survive the loss of that datastore.
- It is not available on SimpleVirt HCI storage, where disks are raw images that cannot hold one. SimpleVirt refuses the operation up front and says why.
- It does not survive a migration or an HA recovery. Moving the VM to another host or to other storage, or having HA restart it on a survivor, destroys every rollback point. The Migrate wizard warns you before you commit.
The controller backup — recovery of management, not of workloads
If the controller VM is lost, install a fresh SimpleVirt-Command from the ISO and restore the backup. You get back the fleet inventory, users, clusters, HA configuration and the credentials that let the controller manage the hosts. The hosts keep running their VMs throughout — they do not stop because the controller is gone. What you lose while the controller is down is management, and HA failover (see Known limitations).
Take a controller backup before every controller upgrade and after significant fleet changes: adding or removing hosts and clusters, changing roles or directory settings.
Putting it together
| If you lose… | Recovered by | What you still need |
|---|---|---|
| A change you made inside a VM (within the hour) | VM snapshot revert | — |
| The controller VM | SimpleVirt-Command backup restore onto a fresh controller | — |
| A VM's data (deletion, corruption, ransomware) | Your backup product | SimpleVirt provides nothing here |
| A datastore, array or site | Your backup product, plus rebuilding the datastore | SimpleVirt provides nothing here |
| A host | HA restart or manual re-registration of the host | Guest data still comes from your backup product if the storage went with it |
Related
- Known limitations — the full statement of what this release does not do
- Operations — controller backup as part of the upgrade sequence
- Installation — protecting the controller's disk