Simple/Brutal encrypted full system backup (Veracrypt)?

Is it possible to backup an entire qubes system (listerally everything) to an external HDD veracrypt container.

My ideal scenario is to be able to restore everything exactly as it was, brutally. Pop in a new HDD and just move it all over from a single veracrypt container, if need be.

I know it is inefficient, the idea is to avoid any complications, losing or forgetting to include files that are not part of the qubes backup solution, or qubes restore problems.

Please let me know if this can be done and how?

Not tested, but maybe using dd or partimage to backup the raw disk to a file and restore it on a new drive.

You may just have to reinstall the bootloader from a chroot after copying the whole disk.

Thanks for jumping in on this thread!

Couple of questions

  1. So I would need an separate linux system, with physical access to the qubes HDD and an empty HDD. Then DD or partimage Qubes HDD to the empty HDD. Isn’t the Qubes HDD encrypted how can it just be DDed over?
  2. If the raw transfer is complete why would bootloader not be there ?
  3. With Raw transfer to that empty HDD, how do I reinstall bootloader correctly ?

The Qubes OS disk shouldn’t be in use during the operation, so you need a different operating system. This could be a live usb. The encryption is only part of the disk, so you don’t care about it for copying in one way or the other.

No idea, experience told me it rarely works when doing that. I’m not actually sure I did that with EFI, so maybe it would work.

Using grub-install / grub-mkconfig. Maybe /etc/fstab and /etc/default/grub will need to be updated because of UUID changes with the new disk.

I think it can be possible.

Make a veracrypt container, boot something like Ubuntu as LiveCD, make a copy of your Qubes OS disk with clonezilla and/or dd to a file inside veracript container.

Note, there are some issues you will probably have during recovering process:

  • after recovering you will be missing EFI boot record of Qubes OS, because it is not stored on the disk, but in the motherboard. You can add it manually with efibootmgr (check out Qubes OS docs about EFI boot).
  • the name of the device (like /dev/sda) and some UUIDs of partitions/disk can be different on other laptop. It will affect LVM not being able to ask for password and open. Booting to Live CD and fixing stuff. The same situation that can happen to any GNU/Linux installation being moved.

Also if you want to remove Qubes OS from the device without traces after making a backup to veracrypt, you should also manually remove this EFI boot record, because it is stored in the memory of motherboard, not the disk.

If I were you, I would buy a second disk and tried the whole process of backing up and recovering to this empty second disk, before destroying or affecting valuable data on the original Qubes OS disk. Also make all necessary backups before starting anything, just in case something goes wrong.

Tell about the results on the forum.

2 Likes

I’m reminded of this post, which may be relevant to you:

As for Veracrypt, my understanding is that it should not be necessary, since Qubes already uses LUKS full-disk encryption (except /boot). In other words, you would be cloning a disk that’s already encrypted.

I thought Veracrypt would provide authenticity and integrity check, but it doesn’t… VeraCrypt - Free Open source disk encryption with strong security for the Paranoid

1 Like

Why should it? It is a task for the filesystem. Keeping hash of the whole container is impossible, and keeping millions of hashes of some chunks looks like task for a filesystem considering it knows about files data ranges and can manage this stuff better. Also it avoids loosing extra space for such hashes/checksums.

LVM is no match for Veracrypt for several reasons. Veracrypt has containers with no header unlike LVM (header-less mode in LVM exists but is not good), inner/outer containers allowing plausible deniability.
And as you mentioned, /boot and /efi partitions and partition table as whole are also not protected, nor encrypted.