Dom0 backup/snapshot?

[Insurgo]

@redmind

I guess I’ll just have to wait for someone to make a simple/stupid user-guide, hopefully something official and approved by Devs, that will allow full backup/rollback of dom0.

The short version, Read Only unapproved by devs version of above post, not related to external backups, would be to:

Content of /lib/systemd/system-shutdown/root-autosnap:

#!/bin/sh

#This permits wyng-backup to backup root-autosnap and root-autosnap-back, taken at each system shutdowns like any other QubesOS LVMs.

#We delete the backup of last shutdown snapshot (last last shutdown)
/usr/sbin/lvremove --noudevsync --force -An qubes_dom0/root-autosnap-back || true
#We take a snapshot of root-autosnap into root-autosnap-back
/usr/sbin/lvcreate --noudevsync --ignoremonitoring -An -pr -s qubes_dom0/root-autosnap -n root-autosnap-back
#We remove root-autosnap
/usr/sbin/lvremove --noudevsync --force -An qubes_dom0/root-autosnap || true
#We create root-autosnap from root
/usr/sbin/lvcreate --noudevsync --ignoremonitoring -An -pr -s qubes_dom0/root -n root-autosnap

sudo chmod +x /lib/systemd/system-shutdown/root-autosnap

@redmind

So I am looking for a solution that will allow me to revert changes in dom0.

I would not advise doing this on your daily driver, but you could test on a secondary install on another computer first.

@redmind

I’m ok with something that I start manually just before I’m installing an update, or intend to make a change in dom0, with the option to roll-back to that point in time if something goes wrong.
I don’t understand to complexity and/or security implications of it but I can think of two main cases:
a. User did something in dom0 which didn’t solve the problem, and they want to roll-back and try something else
b. The OS is up but something is broken (bad update, or a user-made change)
c. The OS not coming up after reboot (anything from a driver issue to

So basically, the following would cover a and b above. But not c.

Before doing changes, you should reboot once, to have a dom0 clean state on halt.
Then in qubes calling of sudo /lib/systemd/system-shutdown/root-autosnap will create an an additional unclean state (autosnap-back being your state at halt). Do your change on dom0. Reboot if that needs testing.

You keep two states:

• root-autosnap: last state.
• root-autosnap-back: last last state.

At this point in time, calling sudo lvconvert --merge /dev/qubes_dom0/root-autosnap-back would revert dom0 to the state prior of your change, on reboot (when dom0 root volume will be deactivated). This is also why your ‘c’ case above would not work from qubes if it is not in a bootable state. But booting from QubesOS installation media in recovery mode would permit you to apply another state.

The reason we like automatic snapshots on shutdown is because it is a safer to not explode space consumptions (auto-cleanup), to make sure we do not keep too many states, which go exponential over time. This is why they need to be removed without being forgotten in a timely manner. So we rotate them in the shutdown script.

Otherwise, you could play manually with that concept, and even create named snapshots of your own to revert to later on:
/usr/sbin/lvcreate --noudevsync --ignoremonitoring -An -pr -s qubes_dom0/root -n dom0-root-NamedBackupPriorOfChange

But that backup won’t have any automated way to be cleaned automatically.
You would have to remove it when unneeded
sudo lvremove /dev/qubes_dom0/dom0-root-NamedBackupPriorOfChange

If you realize you need to revert to that unclean state upon reboot (logs corrupted once again):
sudo lvconvert --merge /dev/qubes_dom0/dom0-root-NamedBackupPriorOfChange

Once again, please test on a separate installation first, not on your daily driver.

Where wyng-backup picks it up here is that root-autosnap is the last snapshot taken.
Since wyng-backup backups LVMs, if wyng keeps track of root-autosnap, asking it to send a session (--dedup) would send only the incremental backup (changes) that occured since the last backup was made. This is why we love wyng, and why having dom0 rotation at shutdown as every other LVM volume would make sense, so that wyng just deals with it without the need of additional logic or wrappers.