I searched for an answer but didn’t find a good one. AI gave me an answer but it’s rather nuanced and technical in nature. (The answer being that the backup will finish, taking the most recent image on disk, no matter how many times I restart the qube.)
As the title states:
Can you start and use a qube after having started a backup of it? If so, what happens when you stop it, possibly repeating the process multiple times (e. g.: start backup, start and stop qube three times in a row).
The context is that I started a backup of a qube that I would like to do some work in now and I am unsure whether I can start and possibly stop it without interfering with the backup.
I know it is possible to start a backup of an already running qube, where the state before starting the qube will go into the backup. But that’s a slightly different matter.
I assume this is related to the images being kept on disk vs. the live image used when a qube is started, and also possibly related to the number of revisions being kept on disk.
On the off chance that you’re using the Btrfs or XFS installation layout (file-reflink driver), it would definitely be fine in that case.
For the default LVM Thin installation layout, I’m not a 100% sure if it could cause problems or not. (Maybe during some unfortunate time window?) The logic there is more complex and I’m not super familiar with it.
I would treat this as storage-pool dependent rather than a safe general rule. First check the pool driver with qvm-pool -i vm-pool (or whichever pool the qube uses). If it is the default LVM thin setup and the backup is already running, I would avoid start/stop cycles unless the work is urgent; let the backup finish, then start the qube and make another backup if you changed anything important. On reflink-based pools it is much less worrying, as rustybird said.
I thought* the backup process started by grabbing a handle on the current latest version of each volume as it was at last shutdown… and even for an lvm-thin based qube it would not change, even with multiple shutdown/startups.
Now I’m not so sure. Can anyone give an authoritative “yes, you can use your qubes during backup” answer?
* My thinking is nothing better than a swift amateur eyeballing of likely looking code in qubes-core-admin.
Can you start and use a qube after having started a backup of it? If
so, what happens when you stop it, possibly repeating the process
multiple times (e. g.: start backup, start and stop qube three times
in a row).
The context is that I started a backup of a qube that I would like to
do some work in now and I am unsure whether I can start and possibly
stop it without interfering with the backup.
That’s a good question. I also wondered about this for a long time. To
the degree that I’ve developed a superstitious belief that I must not
start a qube, or work on a qube, that I am making a backup of.
This superstitiuos belief has forced me to make full system backups only
during the night. Due to this, I also happen to not do my weekly
periodical backups, due to laziness (it is late at night and who is
going to bother with plugging in, decrypting an external SSD, run the
Qubes backup GUI, select the qubes, etc. etc. etc. – I am halfway
asleep already).
It would be better for me to have a clarification to this question:
Can I work on my QubesOS normally as I would be, while doing a full
system backup in the background?
Or, is full system backup such a special type of event that my system
must not be doing anything else. And that, the whole QubesOS must be
blocked for that amount of time for doing anything other than the
backup process.
Eh, if the backup run succeeds I wouldn’t worry about it. I was only saying I find the lvm_thin driver and the underlying LVM stack harder to reason about for some corner cases. But hopefully those would present as noisy failures.
Some things that come to mind:
Don’t delete any of the qubes that are going to be backed up, because the whole backup would fail.
Don’t install updates for the qubes-core-dom0 package, which would restart the qubesd systemd service and interrupt the backup.
Don’t start any of the qubes that are going to be backed up for which you’ve disabled snapshots of some of their storage volumes with qvm-volume config qubename:volumename revisions_to_keep -1.
Relatable… That’s a good job for a little wrapper script around the qvm-backup CLI though, so you only have to plug in the drive, kick off the script, and enter your passphrases. You can also preconfigure some qubes in their settings to never be selected for backups by default.