Skip to content

Improve documentation on "Manually copying your persistent data to a new USB stick"

The closest thing to documentation on backing up a Tails persistent volume (that I have been able to find) is Manually copying your persistent data to a new USB stick. Following these instructions results in the creation of a bootable backup of a Tails drive with a persistent volume.

While effective, there are a couple of “gotcha’s” in this document that can lead to confusing outcomes:

  • In Create a new USB stick, Step 3 says to “Enable again on this new USB stick the persistence features of your choice.” Some users may not remember or understand which persistence features they have enabled, and may be confused as to what to do at this step. If they forget to enable a persistence feature on the backup, the corresponding data will not be backed up after following the subsequent instructions.
  • Manually copying the files with Nautilus and confusing and error-prone:
    • If a user has all of the persistence features enabled, they may try to select all or drag-and-drop everything from /media/amensia/TailsData/ into /live/persistence/TailsData_unlocked. Nautilus does not preserve file ownership and permissions when copying, so if they accidentally copy one of the files owned by the tails-persistence-setup user (e.g. persistence.conf or live-additional-software.conf), it will end up owned by the incorrect user on the backup drive, which prevents the Persistent folders from being symlinked correctly due to the permissions checks documented in the Security section of the Tails persistence design document.
      • I believe this is the root cause of bug reports where users report that the “persistent volume has disappeared, but I’m still prompted for password when booting Tails,” e.g. in this r/tails thread.
    • Nautilus prints numerous obscure warning messages to the Root Terminal, which undermines user confidence.
    • Asking users to click through various warning dialogs from Nautilus about merging/replacing/skipping files also undermines user confidence (“did I actually back up all of my important data?”).
  • There is no documented “restore” process that explains how users can recover their persistent data from the bootable backup created from this documentation.

I’ve been trying to develop a process for reliably backing up and restoring Tails persistent volumes, and I have a proposed modification to this document that I think might fix all of these issues:

  • Retain the Create a new USB stick section, but modify Step 3 to say it doesn’t matter which persistence features you enable on the backup (read on to understand why).
  • Retain the Mount the old persistent volume section without changes.
  • In the Copy your old files to the new persistent volume section, replace steps 2-11 with a single command, run in the Root Terminal: rsync -avh /media/amnesia/TailsData/ /live/persistence/TailsData_unlocked/.

There are several benefits to this change:

  • rsync -a will retain the ownership and permissions of the copied files. That allows us to copy persistence.conf without creating ownership issues that will bork the symlinking of persistent directories on the backup drive.
    • Since we are copying persistence.conf, there is no need for the user to manually configure the persistent settings on the destination to match the source, since the enabled persistent settings are completely described in persistence.conf.
  • rsync -v prints the files that are copied, which allows a cautious user to audit the backup and ensure that their important data was indeed copied to the backup volume.
  • In my testing, rsync does not print any confusing error or warning messages, unlike Nautilus.
  • It requires a user to use the CLI, which it seems the original document may have been trying to avoid, but was also unable to prevent: CLI interaction is required to launch Nautilus in Step 2, and then again to fix permissions in Step 11. This changes replaces two CLI interactions with one, which seems preferable in my view.
  • Dramatically simplifies the Copy your old files section, reducing it from 11 separate steps to just 2.
  • The restoration step, which is currently not documented at all, is trivial: just rsync with source and dest swapped.
  • Users can efficiently update their backups by repeating the steps in the Rescue your files from the old Tails USB stick section, adding the --delete flag to the invocation of rsync.

I am happy to contribute these changes, but first want to make sure they are viable. Would the Tails maintainers, especially those who have a deeper understanding of the Persistence feature than I, welcome this change? Are there any potential gotchas with my proposal that I’ve failed to recognize? As always, I appreciate your time and consideration.

:sajolida:

Parent Task: #5301

Related issues

Original created by @garrettr on 14605 (Redmine)

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information