Feature #17334

Document how to rescue the content of Persistence from a broken Tails

Added by sajolida 2019-12-12 14:12:25 . Updated 2020-01-10 19:01:23 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Persistence
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
End-user documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

@goupille pointed out that the new documentation on making backups of Tails is not useful anymore to people who might need to rescue data from a Tails that doesn’t start anymore.

I don’t think that we could ever write a single piece of documentation that works well in both cases but we could reuse the backup doc to create a new one pretty easily.

It would look like:

  1. Create new Tails
  2. Create Persistence on new Tails
  3. Restart on new Tails
  4. Plug in broken Tails
  5. Unlock Persistence of broken Tails from GNOME Files
  6. rsync
  7. Restart on new Tails

To prevent confusion when using “/doc/first_steps/persistence/copy.html”, we could:

  • Call it “/doc/first_steps/persistence/rescue.html”
  • Rename the backup doc as “/doc/first_steps/persistence/backup.html”

Subtasks

Related issues

Blocks Tails - Feature #17247: Core work 2020Q1 → 2020Q2: Technical writing Confirmed

History

#1 Updated by sajolida 2019-12-12 14:17:40

  • Description updated

@goupille: Would this solve your concern?

@cbrownstein: This will be less work than writing /doc/first_steps/persistence/copy.html and could prevent data loss, so I think that it qualifies as core work.

@intrigeri: I’m wondering about step 3. When people restart on their new Tails, it will be much easier for them to unlock the (empty) Persistence of the new Tails and run rsync from the new Tails. But I wonder whether it might cause trouble to copy files from the broken Tails onto the new Tails while Persistence is in use on the new Tails. Given the scope of this doc, I think that it would work to instruct people to close all applications before doing the copy but I might have overlooked other potential problems.

#2 Updated by intrigeri 2019-12-15 08:01:57

> intrigeri: I’m wondering about step 3. When people restart on their new Tails, it will be much easier for them to unlock the (empty) Persistence of the new Tails and run rsync from the new Tails. But I wonder whether it might cause trouble to copy files from the broken Tails onto the new Tails while Persistence is in use on the new Tails. Given the scope of this doc, I think that it would work to instruct people to close all applications before doing the copy but I might have overlooked other potential problems.

I also think it would work.

Idea: at step “2. Create Persistence on new Tails”, recommend users to disable every persistence feature, so when they unlock it, nothing gets mounted under /home/amnesia and this whole class of potential problems goes away.

#3 Updated by sajolida 2019-12-15 18:43:43

Smart!!!

#4 Updated by goupille 2020-01-10 19:01:23

@sajolida: sorry I didn’t answered here, yes it would be nice to have that documented !

#5 Updated by sajolida 2020-03-18 02:23:28

  • blocks Feature #17247: Core work 2020Q1 → 2020Q2: Technical writing added