wiki/src/blueprint/backups.mdwn

   1 [[!meta title="Backups of the persistent volume"]]
   2
   3 [[!toc  levels=2]]
   4
   5 We want to allow our users to backup the data they have in their persistent
   6 volume.
   7
   8 See the thread on tails-dev:
   9
  10 <https://mailman.boum.org/pipermail/tails-dev/2014-April/005388.html>
  11
  12 Backup techniques
  13 =================
  14
  15 We shouldn't maintain yet another shiny new piece of code to do that. Or we
  16 might hit tons of corner cases to handle, that one initially does not think of.
  17 And once we take it all into account, then we get a large piece of code to
  18 maintain all by ourselves, because it was meant only for Tails' needs.
  19
  20 So, we should try to reinvent this wheel, and use an existing, proven solution instead.
  21
  22 Tar + GPG
  23 ---------
  24
  25 A simple approach might be to combine tar and GPG:
  26
  27     tar cjf - . | gpg --cipher-algo AES -c - > /home/amnesia/YYYY-MM-DD-backup.tbz2.gpg
  28
  29 Initial implementation might be easy but that will probably end up being quite a
  30 big piece of custom code.
  31
  32 Duplicity
  33 ---------
  34
  35 <http://duplicity.nongnu.org/>
  36
  37 It supports something that's basically "tar | gpg" for the first iteration, and
  38 it also leaves room for future improvements, thanks to its support for
  39 incremental and remote backups. Also, it allows users to restore or inspect
  40 their backups outside of Tails, without having to manually decipher yet another
  41 backup file format.
  42
  43 ### Cons
  44
  45 - Duplicity creates tons of messy files on the file system.
  46
  47 Loopback LUKS
  48 -------------
  49
  50 ### Pros
  51
  52 - One file per backup.
  53
  54 ### Cons
  55
  56 - We still need to find another tool to create the device and copy the files.
  57 - Maybe backups done this way would be much bigger than duplicity backups.
  58 - Duplicity supports incremental backups even if they have some limitations.
  59
  60 Obnam
  61 -----
  62
  63 Obnam only supports encrypting to a GnuPG key, so this would require another
  64 layer of encryption (such as a LUKS container file, or something else) if we
  65 want to support encrypting with a passphrase (and I think we should).
  66
  67 grsync + encrypted device
  68 ------------------------------
  69
  70 [grsync](http://www.opbyte.it/grsync/) is a GUI for the renown and rock-solid `rsync`, already shipped in Tails.
  71
  72 Grsync is [packaged for debian](https://packages.debian.org/squeeze/grsync).
  73
  74 The documentation for the creation of the encrypted device [[is already written|doc/encryption_and_privacy/encrypted_volumes]].
  75
  76 ### Pros
  77
  78 * not that much things to code
  79 * grsync can be easily preconfigurated, eventually with multiple profiles
  80 * this solution separate backup and encryption work
  81 * allows remote backups
  82
  83 ### Cons
  84
  85 * seems not really actively developped
  86 * not possible to do incremental backups
  87 * needs a separate encrypted device for backups or reuse the "loopback LUKS"
  88   solution
  89 * does not check if enough space is available on the destination before running
  90
  91 ### How to test?
  92
  93 * create an encrypted device.
  94 * install the grsync package.
  95 * paste [those lines](http://dustri.org/p/38e76b) in a .grsync file, then double-click on it.
  96 (grsync ask you first to confirm the profile you want to use. Just click on "Open")
  97 * define the destination (i.e your encrypted device)
  98 * test wildly! and please report your results
  99
 100 ### Todo
 101
 102 * some files are normally not readable by rsync (for example persistence.conf, apt/*)
 103   Grsync can bypass that with the option "Run as superuser", we should investigate the consequences of using such an option.
 104   We still have the possibility to ignore those files: we just have then to add `--exclude="apt"` in the preconfiguration file.
 105 * decide if we activate the option `--delete` by default.
 106 * test restoration (see File → Invert source and destination), then at least check files permissions.
 107 * test backup + restoration with symlinks and hardlinks in the Persistent folder.
 108 * eventually test remote backups.
 109
 110 rdup
 111 ----
 112
 113 <https://github.com/miekg/rdup>
 114
 115 rdup separates the logic of backing up from the actual copying. It
 116 supports filters to compress and encrypt individual files (typically
 117 using gpg or mcrypt) as well as path names and can do both full as
 118 well as incremental backups.
 119
 120 ### Pros
 121
 122 * simple and small command line programs
 123 * more sophisticated than tar+gpg and probably addresses many of the
 124   corner cases that would otherwise have to be handled by increasingly
 125   complicated scripts
 126 * in Debian Squeeze / Wheezy / testing
 127
 128 ### Cons
 129
 130 * still requires a script of some sort to drive it
 131 * probably requires a gui to make it simple to use
 132
 133 Other solutions
 134 ---------------
 135
 136 We should investigate how others have already solved this problem.
 137
 138 User experience
 139 ===============
 140
 141 - The user should be prompted about where to save the backup as this will most
 142   probably end up directly on a storage device and not go through RAM.
 143
 144 - Ask the user which folders of the persistence setup to backup. But maybe
 145   that's not needed for a first prototype, as we might assume that the info in
 146   persistence is kept to the minimum.
 147
 148 - The restore step would do the current delete partition steps (if there was
 149   already a persistence partition found), then most of the current steps to
 150   create a partition, but instead of asking the user what they want to use their
 151   new partition for, it would instead ask the user to pick a backup and would
 152   restore it.
 153
 154 - There could be a single menu entry called "Backup and restore persistent
 155   volume". Combining both actions in a single menu entry makes it clear that
 156   they are directly related, and limits the number of menu entries.
 157
 158 - There should be a graphical way to restore backups. It is important let
 159   non-techy users restore their backups if necessary.
 160
 161 Implementation
 162 ==============
 163
 164 - Avoid running the GUI as root and rather run the GUI as amnesia or a dedicated
 165   user and execute precise actions through policykit (execute a command with
 166   pkexec or implement a dbus service)
 167
 168 - Write the code in GTK3 for Tails 1.1 which will be the next major release,
 169   based on Debian Wheezy.