My backup paradigm is to use 3 iterative backup copies of my system captured over time. These are usually full disk copies (DOS/Windows world). Started this years back in response to disk failures and/or virus attacks. Copy C made 90 days back. Copy B made 60 days back. Copy A made 30 days back. I would rotate Copy C to the current backup roll 30 days from the last backup and repeat. I would also perform the disk backup prior to and after any major updates.
I reviewing all the backup posting/comments it do not appear there is “convent” way to accomplish this with Qubes.
Would anyone have any suggestions or thoughts on implementing this approach with Qubes?
The backup tool can be run from the command line with qvm-backup, I do daily backup of the app-vms and weekly backups of everything including templates.
The command line tool can use the same profiles as the GUI tool, making it easy to schedule different groups.
The backups are time stamped, you can make a shell script that automatically deletes old backups, but I do that part manually.
When backing up dom0 using the Qubes backup tool (explained below), only the home directory is backed up. Therefore, if there are files outside of the home directory you wish to save, you should copy them into the home directory prior to creating a backup. Here is an example of how to back up Qubes config files and RPC policies:
$ mkdir -p ~/backup/etc/qubes/
$ cp -a /etc/qubes/* ~/backup/etc/qubes/
$ mkdir ~/backup/etc/qubes-rpc/
$ cp -a /etc/qubes-rpc/* ~/backup/etc/qubes-rpc/
Would this need to be performed for each VM that has files?
Would doing this in a template VM be bad in that it would potentially expose all the file in the template to all VM created with that template?
No, you don’t need to do that in appVMs, you just need to back up both the template and the appVM.
In appVMs the root file system is a non-persistent copy of the template used to create the vm, and when you back up the appVM is are only making a back-up of the files in /rw which contains all the user files for that vm.
One way to handle dom0 is to just create a tar file in the home directory before backup. It will automatically be included in the dom0 backup. When restoring you just unzip the archive to choose what to actually copy back into place.
I know you have other requirements but the below is what I have been doing in automating my own revolving set backups.
I use a much more complicated but automated backup methodology where each VM that was used (by checking VM time stamps) is backed up each day on a revolving set of drives. I use several USB docking stations attached to sys-usb and powered up/down using Kasa network controllable AC power plugs to enable the specific target drive docking station for the night which is then checked with S.M.A.R.T software, to query the drive’s physical health, and then finally mount the drive in sys-usb for the backups.
In my case each VM that was used since the last backup is imaged as an individual backup file in that VM’s subdirectory on the drive and then tested by reading it back in verify mode if I choose. I have a QubesBackup directory on each drive and a directory for each target VM under that. This allows me to scan for the backup volume and skip any non-backup drive (e.g. thumb drives, cd’s) that happens to be attached in sys-usb at the same time for another purpose.
Before each backup I also prune the directory tree on that drive of the older backups of each VM type to make new space available while retaining a minimum X copies of each VM. I check the space required of all the VM’s needed to back up for that session and free up the proper amount of disk space where required. Only the oldest backups of each type are removed to make room for newer backups.
This way I am always garunteed to have enough copies of eack VM across many TB of drive space to go back in time to any recent version of a VM state and the revolving set remains powered down by Kasa when the backup drives not actually in use, to preserve the life of the drives. After each nightly backup completes the computer saves the current backup log in dom0 for review on next boot, and the system syncs the file systems, unmounts all drives, shuts down the current backup drive via Kasa, and finally shuts down the whole system.
Recovery of the system using multiple VM backups across multiple drives is certainly more complicated but I always have a set of the most recent backups across multiple drives which means I never really have to worry much about backup drive failures as long as I check their health. I used to copy each set of backups to a redundant network file server but found that to be very time intensive in copying over the network and almost completely unnecessary for my purposes. But I have had many backup drive failures in the past and now believe you can never be too safe. Check your drives regularly. One set of drives recently purchased, the first drive lasted only 22 uptime hours and the second failed while writing just the second backup file to it. Bad batch of drives.
All I need to do is start the backup script in dom0 at the end of the day and it does the rest. One command mode shuts down all unnecessary VM’s first before backups and another argument backs up just what is not currently running so I can continue to work simultaneously if I like.
Don’t know if you are still interested in deploying a backup strategy for Qubes. If it’s the case I summarized and linked some refs to incremental backup discussions on Qubes here
But for full disk copies such as your strategy suggest, I came across this