BackupRestore changed

Added instructions for LUKS volume creation, cleaned up language
This commit is contained in:
IX4 SVS 2013-10-29 23:36:06 +00:00
parent 1cb3fec625
commit 333c838029

View File

@ -9,36 +9,71 @@ Backup, Restore, Migration Tools
Qubes supports easy backups and restores of your VMs, and specifically very easy migration between two systems.
There are currently two command-line tools for this: `qvm-backup` and `qvm-backup-restore`, both of which are available in Qubes Alpha 2 (qubes-core-dom0 \>= 1.1.8). Users of Qubes Alpha 1 can still download the `qvm-backup` too [here](http://qubes-os.org/yum/misc/qvm-backup) and use it to make a full backup of their system, and later restore it on Qubes Alpha 2, using qvm-backup-restore (the latter is not avilable on Alpha 1).
There are currently two command-line tools for this: `qvm-backup` and `qvm-backup-restore`, both of which are available in Qubes Alpha 2 (qubes-core-dom0 \>= 1.1.8). Users of Qubes Alpha 1 can still download the `qvm-backup` too [here](http://qubes-os.org/yum/misc/qvm-backup) and use it to make a full backup of their system, and later restore it on Qubes Alpha 2, using qvm-backup-restore (the latter is not available on Alpha 1).
Making a full backup of your VMs
--------------------------------
1. Mount the external media on which to place the backup:
1. Prepare an encrypted external medium to store the backup
It is strongly recommended to use encrypted media for the backup. `qvm-backup` will not encrypt the backup!
Steps to create a fully encrypted LUKS volume on the external USB hard drive /dev/sdb:
**WARNING**: Everything on your external USB drive will be deleted with this process!
``` {.wiki}
mount /dev/<backup_device> /mnt/backup
$ sudo wipefs -a /dev/sdb
$ sudo cryptsetup luksFormat /dev/sdb
$ sudo blkid /dev/sdb
$ sudo cryptsetup open --type luks UUID=the-long-UUID-you-just-got-from-blkid backup
$ sudo mkfs.ext4 -m 0 /dev/mapper/backup
```
```Note:``` It's strongly recommended to use encrypted media for the backup (`qvm-backup` will not encrypt the backup). One can use e.g. LUKS for full encryption (type: `man cryptsetup` for details), in which case the `/dev/<backup_device>` would be something like `/dev/mapper/backup` -- a diskmapper device created by cryptsetup from the actual encrypted media.
1. Do the backup:
1. Mount the encrypted medium on which the backup will be stored
``` {.wiki}
qvm-backup /mnt/backup
$ sudo mkdir /backup
$ sudo blkid /dev/mapper/backup
$ sudo vi /etc/fstab
(add a line similar to this:
UUID=the-SECOND-long-UUID-you-just-got-for-the-mapper-device /mnt/backup ext4 defaults 1 2
)
$ sudo mount /mnt/backup
```
Now anything we store in /mnt/backup is stored on the encrypted LUKS volume of our external USB drive.
1. Backup your VMs
``` {.wiki}
$ sudo qvm-backup /mnt/backup
```
The `qvm-backup` tool will take care about backing up the VMs configuration, and all your AppVMs private storages, and, if necessary, will also backup any custom templates or netvms that any of your AppVMs might be using.
1. Lock the encrypted volume
``` {.wiki}
$ sudo umount /mnt/backup
$ sudo cryptsetup close backup
```
Restoring VMs from a backup
---------------------------
1. Mount the media with a backup:
1. Do the restore:
1. Mount the media with your backups
``` {.wiki}
qvm-backup-restore /mnt/backup/<specific_backup_dir>
$ sudo mount /mnt/backup
```
The `qvm-backup-restore` tool will restore all the VMs (and any backed up custom template VMs), update Qubes database, and will add appmenus for the restored VMs. Your existing VMs will not be removed, unless there was a name conflict, i.e. there existed a VM with the same name on the host and in the backup. In this case, `qvm-backup-restore` will refuse to continue, and will ask you to remove the conflicting VM from the host first.
1. Restore VMs
``` {.wiki}
$ sudo qvm-backup-restore /mnt/backup/<specific_backup_dir>
```
The `qvm-backup-restore` tool will restore all the VMs (and any backed up custom template VMs), update the Qubes database and add appmenus for the restored VMs. Your existing VMs will not be removed.
If there is a name conflict, i.e. you try restoring a VM with the same name as a VM already on the host, `qvm-backup-restore` will refuse to continue and will ask you to remove (or rename) the conflicting VM from the host first.