What to backup

Always store your backup medium in a different place that the things you are backing up (i.e. an external hard disk always connected to the computer is not a good backup medium).

Here is a list of things that may be interesting to backup. Look in the following section(s) for how to do these backups and how to restore them.

• Partition table of your hard drives (sfdisk --dump {hdd} > {file})
• SMART data of your hard drives (smartctl -iA {hdd} > {file}). To check on the health of the hard drives, and see if it gets worse over time.
• If using luks encryption: luks headers of each encrypted partition (cryptsetup luksHeaderBackup {partition} --header-backup-file {file}). Beware: if an attacker gets the headers and guesses a password, it can then decrypt your hard drive, even if you change the password.
• If using lvm: the lvm partition layout (cp /etc/lvm/backup/{volume group} {file})
• Root partition. So that you can restore your os to a specific point in time. Note: if the partition is encrypted, it is nearly incompressible (by definition), so you may want to decrypt it before and back up the decrypted data. If you do so, you should always store your backup on an encrypted medium, otherwise you are effectively declassifying data.
• ~/Documents or the whole ~. You can either do a copy of the whole partition as a blob, or you can copy files using rsync.
• If using docker containers, for each container:
  • Volumes used: either by creating an archive of the volume for named volumes, or by creating a compressed archive with tar for a directory mount.
  • Current configuration used to run the container (e.g. docker-compose.yml)

Backup a partition or block device

Using Clonezilla

Clonezilla is a live operating system that is intended to easily backup and restore entire partitions or disks.

• Download clonezilla image from the official download page
• Eventually unzip the downloaded file to find the .img file.
• dd if={clonezilla img file} of={usb key (e.g. /dev/sdb)} ; sync. As always with dd, be careful of what device you choose or you might make your computer unusable.
• Boot the computer and choose to boot from usb.

There is a mode that loads clonezilla into ram, so that you don't need to keep the usb key in.

Storing the backup into an encrypted device

You will need to mount the device before doing the clone.

• After clonezilla boots, choose "Enter shell" instead of "Start clonezilla"
  • Note: there is currently a bug and it is impossible to change the keymap for the shell, therefore it always act as if your keyboard was American.
• Set up the device to which you want to write (e.g. with cryptsetup for a dm-crypt device). You can use sudo to act as root.
  • Mount it as /home/partimg/
• clonezilla as root
• Follow the wizard
  • When prompted on where to store the image, choose "Use existing /home/partimg" (it should be suggested as default)

Cloning an encrypted partition

It is currently impossible to clone a "special" device, like the plaintext device used to access an encrypted partition. Clonezilla can however directly clone the encrypted partition, but won't be able to tell the difference between used and free space. Therefore the images will often be quite enormous compared to what they could be. The advantage is that the image doesn't need to be encrypted when saved, since it's already encrypted data.

To efficiently clone an encrypted partition, consider using dd and gzip.

Using dd and gzip

The idea behind this is to first (optionally) use dd to fill all the available space on the partition with zeroes, then use dd piped into gzip to create a file containing the whole partition content. Since all the free space contains zeroes, it is highly compressible, and should generate an image that is at least as small as the partition used space (probably smaller since the used space is also compressed).

Important! The partition should not be in use. It is better to run a live OS (e.g. a gParted live cd) for this operations. If it is impossible to run another os, consider unmounting the partition and re-mounting it read-only or in another location, the avoid having any background process modify files inside it.

• fdisk -l {partition} to find optimal I/O block size. This parameter will speed up reading and writing data.
• (optional) fill the empty space with zeroes to make the partition more compressible. Beware that doing so very often will increase the disk's wear because of the extensive write operations.
  • Mount the partition somewhere
  • dd if=/dev/zero of={mountpath}/{file that doesn't exist e.g. 'zeroes'} bs={blocksize}; sync
  • Wait until dd says that there is no space left on the partition and exits.
  • rm {zeroes file}: this will make the space available again (it would be nice if we could continue using the partition after the backup is done...)
  • Unmount the partition.
• Mount the device in which you want to store the backup (if not already mounted).
• dd if={partition to copy} bs={blocksize for the partition to copy} |gzip > {image file (that must not exist)} ; sync: this will copy the partition to a compressed image file. To change the amount of compression done, look at the "Change the compression amount" section.
  • Wait until the copy ends.

Save the partition table

It can be interesting to save the partition table for the whole device, as a backup and reminder of how the device is set up.

• sfdisk --dump {device} > {output file}

The saved partition table can later be restored with: sfdisk {device} < {partition table file}. Warning! This could obviously overwrite important data and render a device unusable.

Cloning an entire device

For an entire device the procedure is the same. dd can use a device file as source for the copy in the same way it uses a partition.
If you want to do the optional step of filling the empty space with zeroes to increase compression, you will need to do so by mounting and filling all partitions on the device one by one.

Restore a partition

• gunzip --stdout {image file} | dd of={partition} bs={blocksize} ; sync

Cloning an encrypted partition

An encrypted partition is very difficult to compress by definition. In order to get a better compression, you can first unencrypt the partition (e.g. by using cryptsetup) and then run dd and the other commands on the unencrypted version of the partition (e.g. /dev/mapper/{name}).

If you do so, you should store the resulting file on an encrypted medium.

Change the compression amount

gzip has an option that you can use to choose how much to compress a file. From gzip man page:

-1 or --fast indicates the fastest compression method (less compression) and -9 or --best indicates the slowest compression method (best compression). The default compression level is -6 (that is, biased towards high compression at expense of speed).

To change the amount of compression of an already existing file, do the following:

• gunzip --stdout {filename} | gzip {compression level, e.g. -9} > {new filename}

In case of read errors

Normal behaviour for dd is to stop as soon as a read error occurs. If copying from a faulty drive, you may want to instead copy as much as possible.

• add conv=noerror,sync option to dd commands: this will ignore error and instead write zeroes. The block will be corrupted, but the copy will continue.

Note that this corrupts {blocksize} chunks of data. So if you are using a 1M block size and there is an error anywhere in that, the whole 1M will be corrupted. You may want to choose a smaller block size in those cases.

Backup directory tree using rsync

rsync is a very powerful tool that can be used to backup whole directory trees. The method given here will backup a whole directory tree, hard-linking the files against a previous backup when possible: if a file has not been modified since the previous backup has been done (based on modification date), it is not copied and instead a hard link is done against the existing version. This method obviously requires storing the backup on a file system that supports hard links, such as ext3/4.
This way it is possible to navigate in every backup directory, and have a snapshot of the directory content when the backup was done, but file that haven't been modified won't be copied, thus reducing the disk usage. Any backup directory can be deleted without impacting other backup directories, because of hard links.

If the command is run as root, chown will be done on every file, preserving the original owner and group.

rsync -a --partial --info=progress2  --link-dest={prior backup (no trailing slash)} {directory to backup (with trailing slash)} {backup destination (no trailing slash)}

It is possible to add the option --exclude={pattern} to avoid copying files matching a certain pattern.