Emergency backup recovery (v4)
This page describes how to perform an emergency restore of a backup created on Qubes R4.X (which uses backup format version 4).
The Qubes backup system has been designed with emergency disaster recovery in mind. No special Qubes-specific tools are required to access data backed up by Qubes. In the event a Qubes system is unavailable, you can access your data on any GNU/Linux system with the following procedure.
Required scrypt
Utility
In Qubes 4.X, backups are encrypted and integrity-protected with
scrypt. You will need a copy of this
utility in order to access your data. Since scrypt
is not pre-installed on
every GNU/Linux system, it is strongly recommended that you store a copy of it
with your backups. If your distribution has scrypt
packaged (e.g., Debian),
you can install the package in the standard way using your distribution’s
package manager. Otherwise, you’ll need to obtain a compiled binary
(instructions below) or compile the program from source yourself. (Don’t forget
to verify signatures first!) Note that
versions of scrypt
up to 1.2.0 (inclusive) do not support the -P
option for
easier scripting, which means you’ll need to enter the passphrase for each file
separately, instead of using echo ... | scrypt
.
Here are instructions for obtaining a compiled scrypt
binary. This example
uses an RPM-based system (Fedora), but the same general procedure should work
on any GNU/Linux system.
-
If you’re not on Qubes 4.X, import and authenticate the Release 4 Signing Key.
[user@restore ~]$ sudo rpm --import qubes-release-4-signing-key.asc
-
Download the
scrypt
RPM.[user@restore ~]$ dnf download scrypt
or, if that doesn’t work:
[user@restore ~]$ curl -O https://yum.qubes-os.org/r4.0/current/vm/fc28/rpm/scrypt-1.2.1-1.fc28.x86_64.rpm
-
Verify the signature on the
scrypt
RPM.[user@restore ~]$ rpm -K scrypt-*.rpm scrypt-*.rpm: digests signatures OK
The message
digests signatures OK
means that both the digest (i.e., the output of a hash function) and PGP signature verification were successful. -
Install
rpmdevtools
.[user@restore ~]$ sudo dnf install rpmdevtools
-
Extract the
scrypt
binary from the RPM.[user@restore ~]$ rpmdev-extract scrypt-*.rpm
-
(Optional) Create an alias for the new binary.
[user@restore ~]$ alias scrypt="scrypt-*/usr/bin/scrypt"
Emergency Recovery Instructions
Note: In the following example, the backup file is both encrypted and compressed.
-
Untar the main backup file.
[user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456 backup-header backup-header.hmac qubes.xml.000.enc vm1/private.img.000.enc vm1/private.img.001.enc vm1/private.img.002.enc vm1/icon.png.000.enc vm1/firewall.xml.000.enc vm1/whitelisted-appmenus.list.000.enc dom0-home/dom0user.000.enc
To extract only specific VMs: Each VM in the backup file has its path listed in
qubes.xml.000.enc
. Decrypt it. (In this example, the password ispassword
.)[user@restore ~]$ cat backup-header | grep backup-id backup-id=20190128T123456-1234 [user@restore ~]$ scrypt dec -P qubes.xml.000.enc qubes.xml.000 Please enter passphrase: 20190128T123456-1234!qubes.xml.000!password [user@restore ~]$ tar -i -xvf qubes.xml.000
Now that you have the decrypted
qubes.xml.000
file, search for thebackup-path
property inside of it. With thebackup-path
, extract only the files necessary for your VM (vmX
).[user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456 \ backup-header backup-header.hmac vmX/
-
Set the backup passphrase environment variable. While this isn’t strictly required, it will be handy later and will avoid saving the passphrase in the shell’s history.
[user@restore ~]$ read -r backup_pass
-
Verify the integrity of
backup-header
. For compatibility reasons,backup-header.hmac
is an encrypted and integrity protected version ofbackup-header
.[user@restore ~]$ set +H [user@restore ~]$ echo "backup-header!$backup_pass" |\ scrypt dec -P backup-header.hmac backup-header.verified && \ diff -qs backup-header backup-header.verified Files backup-header and backup-header.verified are identical
Note: If this command fails, it may be that the backup was tampered with or is in a different format. In the latter case, look inside
backup-header
at theversion
field. If it contains a value other thanversion=4
, go to the instructions for that format version: -
Read
backup-header
:[user@restore ~]$ cat backup-header version=4 encrypted=True compressed=True compression-filter=gzip backup_id=20161020T123455-1234
-
Set
backup_id
to the value in the last line ofbackup-header
:[user@restore ~]$ backup_id=20161020T123455-1234
-
Verify the integrity of your data, decrypt, decompress, and extract
private.img
:[user@restore ~]$ find vm1 -name 'private.img.*.enc' | sort -V | while read f_enc; do \ f_dec=${f_enc%.enc}; \ echo "$backup_id!$f_dec!$backup_pass" | scrypt dec -P $f_enc || break; \ done | gzip -d | tar -xv vm1/private.img
If this pipeline fails, it is likely that the backup is corrupted or has been tampered with.
Note: If your backup was compressed with a program other than
gzip
, you must substitute the correct compression program in the command above. This information is contained inbackup-header
(see step 4). For example, if your backup is compressed withbzip2
, usebzip2 -d
instead in the command above. -
Mount
private.img
and access your data.[user@restore vm1]$ sudo mkdir /mnt/img [user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/ [user@restore vm1]$ cat /mnt/img/home/user/your_data.txt This data has been successfully recovered!
-
Success! If you wish to recover data from more than one VM in your backup, simply repeat steps 6 and 7 for each additional VM.
Note: You may wish to store a copy of these instructions with your Qubes backups in the event that you fail to recall the above procedure while this web page is inaccessible. All Qubes documentation, including this page, is available in plain text format in the following Git repository:
https://github.com/QubesOS/qubes-doc.git