Backups that leave the host
KLYRN VM backs each machine up to a separate server over a key that can do nothing else, on a schedule that starts the day the machine is made.
A backup on the same disks as the machine it protects survives a deleted file and nothing worse. KLYRN VM sends backups to a backup server: another machine, reached over SSH, that the compute node can write to and cannot otherwise use.
A key that can only deliver
Each compute node has its own key. On the backup server that key is tied to one command, the backup receiver, and to that node's own folder. It cannot open a shell and cannot read another node's backups. That was probed on a live server, not assumed.
A running machine, without stopping it
The backup is taken through the hypervisor while the machine runs, and the copy on the backup server is sparse: a 200 GB disk holding 30 GB takes about 30 GB.
From the first day
A new machine gets a schedule when it is made. A machine with no schedule and no backup is listed as unprotected, with a button that fixes it. The Backups page leads with coverage: how many machines have a current backup, and the ones that do not, each with its reason.
When one fails
A failed backup says what failed: the backup server was full, or refused the connection, or the host lost its link. It is tried again before anybody is asked, and what it left behind is cleaned up. If the clean-up is refused, that is an alert in its own right, because leftovers that pile up silently are how a backup server fills.
Restoring
Over the machine, or as a copy beside it. A copy needs the console once to get back on the network; nothing is written into the restored guest, on purpose, because that would undo what its owner configured. The backups guide shows the page.