+ * Why do I need Backup?
+
+ First, disks die. The rate for well-treated (!) disk is about 5%
+ per year, which is high enough to worry about. There is some
+ indication that this may be even worse for some SSDs. This applies
+ both to LUKS and plain dm-crypt partitions.
+
+ Second, for LUKS, if anything damages the LUKS header or the
+ key-stripe area then decrypting the LUKS device can become
+ impossible. This is a frequent occuurence. For example an
+ accidental format as FAT or some software overwriting the first
+ sector where it suspects a partition boot sector typically makes a
+ LUKS partition permanently inacessible. See more below on LUKS
+ header damage.
+
+ So, data-backup in some form is non-optional. For LUKS, you may
+ also want to store a header backup in some secure location. This
+ only needs an update if you change passphrases.
+
+
+ * How do I backup a LUKS header?
+
+ While you could just copy the appropriate number of bytes from the
+ start of the LUKS partition, the best way is to use command option
+ "luksHeaderBackup" of cryptsetup. This protects also against
+ errors when non-standard parameters have been used in LUKS
+ partition creation. Example:
+
+
+ cryptsetup luksHeaderBackup --header-backup-file h /dev/mapper/c1
+
+ To restore, use the inverse command, i.e.
+
+ cryptsetup luksHeaderRestore --header-backup-file h /dev/mapper/c1
+
+
+ * How do I backup a LUKS or dm-crypt partition?
+
+ There are two options, a sector-image and a plain file or
+ filesystem backup of the contents of the partition. The sector
+ image is already encrypted, but cannot be compressed and contains
+ all empty space. The filesystem backup can be compressed, can
+ contain only part of the encrypted device, but needs to be
+ encrypted separately if so desired.
+
+ A sector-image will contain the whole partition in encrypted form,
+ for LUKS the LUKS header, the keys-slots and the data area. It can
+ be done under Linux e.g. with dd_rescue (for a direct image copy)
+ and with "cat" or "dd". Example:
+
+ cat /dev/sda10 > sda10.img
+ dd_rescue /dev/sda10 sda10.img
+
+ You can also use any other backup software that is capable of making
+ a sector image of a partition. Note that compression is
+ ineffective for encrypted data, hence it does not make sense to
+ use it.
+
+ For a filesystem backup, you decrypt and mount the encrypted
+ partition and back it up as you would a normal filesystem. In this
+ case the backup is not encrypted, unless your encryption method
+ does that. For example you can encrypt a backup with "tar" as
+ follows with GnuPG:
+
+ tar cjf - <path> | gpg --cipher-algo AES -c - > backup.tbz2.gpg
+
+ And verify the backup like this if you are at "path":
+
+ cat backup.tbz2.gpg | gpg - | tar djf -
+
+ Note: Allways verify backups, especially encrypted ones.
+
+ In both cases GnuPG will ask you interactively for your symmetric
+ key. The verify will only output errors. Use "tar dvjf -" to get
+ all comparison results. To make sure no data is written to disk
+ unencrypted, turn off swap if it is not encrypted before doing the
+ backup.
+
+ You can of course use different or no compression and you can use a
+ symmetric key if you have one and have a backup of the secret key
+ that belongs to it.
+
+ A second option for a filestem-level backup that can be used when
+ the backup is also on local disk (e.g. an external USB drive) is
+ to use a LUKS container there and copy the files to be backed up
+ between both mounted containers. Also see next item.
+
+
+ * Do I need a backup of the full partition? Would the header and
+ key-slots not be enough?
+
+ Backup protects you against two things: Disk loss or corruption
+ and user error. By far the most questions on the dm-crypt mailing
+ list about how to recover a damaged LUKS partition are related
+ to user error. For example, if you create a new filesystem on a
+ LUKS partition, chances are good that all data is lost
+ permanently.
+
+ For this case, a header+key-slot backup would often be enough. But
+ keep in mind that a well-treated (!) HDD has roughly a failure
+ risk of 5% per year. It is highly advisable to have a complete
+ backup to protect against this case.
+
+
+ * *What do I need to backup if I use "decrypt_derived"?
+
+ This is a script in Debian, intended for mounting /tmp or swap with
+ a key derived from the master key of an already decrypted device.
+ If you use this for an device with data that should be persistent,
+ you need to make sure you either do not lose access to that master
+ key or have a backup of the data. If you derive from a LUKS
+ device, a header backup of that device would cover backing up the
+ master key. Keep in mind that this does not protect against disk
+ loss.
+
+ Note: If you recreate the LUKS header of the device you derive from
+ (using luksFormat), the master key changes even if you use the same
+ passphrase(s) and you will not be able to decrypt the derived
+ device with the new LUKS header.
+
+