Qubes VM snapshots using git / SVN

[Patrick]

Quote https://www.whonix.org/wiki/Qubes/Disposable_VM

Qubes does not have a built-in snapshot capability like VirtualBox that
can completely revert all changes back to a particular VM state.

Probably not useful for most users since it is getting geeky but I hope I am wrong. However, may be interesting for advanced users…

I am using git to be able to revert back more than to the previous (not last) state of a template. Someone added a while ago here a suggestion to SVN (when you click expand) since that as the contributor added works better than git for binary files such as VM images.

Git works but it is awfully slow on huge (any Qubes) VM images. But perhaps someone wants to discover / document git / SVN. Would also be interesting to find out if (much more modern and imo usable) git can be tweaked to become efficient on binary files. (We don’t have to share these images. Just looking for a hack to record / roll back to past template states.

(That is useful when a Qubes upgrade bug breaks booting the template or during development to test in-place upgrades.)

[entr0py]

This functionality would be very useful (and very geeky as you say).

However, I am not interested in pursuing until Qubes 4.0 since slowness & disk space issues outweigh benefits to me currently. With COW filesystem (lvm-thin) in Qubes 4.0, snapshots would be awesome! I remember reading that @tasket has implemented something like this using btrfs or zfs. Maybe not version control - but just free clones.

[rustybird]

I remember reading that @tasket has implemented something like this using btrfs or zfs. Maybe not version control - but just free clones.

The Qubes btrfs experience (instant free clones and whole filesystem snapshots, as well as block checksums protecting against silent data corruption) is so awesome that I’m always kind of surprised not everyone is setting up their system this way… Unless you’re very tight on disk space (it has tended to behave weirdly if there’s not enough free space at all times) I can’t recommend it enough.

You should be aware though that lately the Qubes installer has had this bug - you have to “unlock” the proper btrfs option first: https://github.com/QubesOS/qubes-issues/issues/2294#issuecomment-247438318

[adw]

The Qubes btrfs experience (instant free clones and whole filesystem snapshots, as well as block checksums protecting against silent data corruption) is so awesome that I’m always kind of surprised not everyone is setting up their system this way… Unless you’re very tight on disk space (it has tended to behave weirdly if there’s not enough free space at all times) I can’t recommend it enough.

Speaking personally, there are a few reasons I haven’t made the jump to Btrfs yet:

• I’ve heard a lot of horror stories of people losing data on Btrfs due to instability.
• I have no experience with it, so I’m reticent to try to manually set it up myself on a system I’m going to depend upon for daily use.
• The features of Btrfs, while undeniably valuable, are still more in the “nice to have” category for me, whereas stability and reliability are in the “essential” category for me. (For example, I’ve learned to work around the lack of built-in data integrity checking in other file systems by keeping frequent full versioned backups.)

I would be pleased to learn that one or all of these is no longer a problem and that Btrfs is ready for users like me. In that case, I hope it gains full support in the Qubes installer (perhaps even as the default option).

[rustybird]

I’ve heard a lot of horror stories of people losing data on Btrfs due to instability.

Did they happen recently though? I ran into a known issue on R3.0, where the filesystem became readonly after too many snapshots. This was fixable simply by booting a newer kernel once (and deleting some old snapshots so it wouldn’t happen again right away on the old kernel). But since R3.1 it’s been smooth sailing.

Maybe I’ve just been lucky. I’ve used btrfs exclusively, starting - before switching to Qubes - when it was still marked “experimental”, and never lost any data, AFAIK.

I have no experience with it, so I’m reticent to try to manually set it up myself on a system I’m going to depend upon for daily use.

The installer really does its best to hide the automatic btrfs setup option. (Ironically, it was more visible in R3.0, when it wasn’t quite ready IMHO.) But once you’ve bypassed that weird installer bug, you only have to select “btrfs” and then “Click here to create them automatically”, that’s it!

(For example, I’ve learned to work around the lack of built-in data integrity checking in other file systems by keeping frequent full versioned backups.)

Hmm… how do you prevent bad backups (with silently corrupted data) from gradually replacing all the good backups?

[adw]

Did they happen recently though?

Not extremely recently, no.

The installer really does its best to hide the automatic btrfs setup option. (Ironically, it was more visible in R3.0, when it wasn’t quite ready IMHO.) But once you’ve bypassed that weird installer bug, you only have to select “btrfs” and then “Click here to create them automatically”, that’s it!

That’s good! But since I usually like to customize my installation a bit, I’ll have to learn how to set it up from the command-line.

Hmm… how do you prevent bad backups (with silently corrupted data) from gradually replacing all the good backups?

I can’t. That’s why I keep every backup. If a file becomes silently corrupted, I still have the last good version (in the latest backup in which it exists).