Feature #12214

Document a way to manually backup persistent data

Added by intrigeri 2017-02-06 19:21:58 . Updated 2019-09-03 13:32:41 .

Status:
Duplicate
Priority:
Normal
Assignee:
Category:
Persistence
Target version:
Start date:
2017-02-06
Due date:
% Done:

0%

Feature Branch:
segfault:doc/12214-persistence-backup
Type of work:
End-user documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

We want to have a good backup system for persistent data (Feature #5301). Some progress has been made on this front since 1.5 years, but it’s unclear when we can actually implement it. Meanwhile, how about we spend the smallest possible amount of time documenting how to do such backups by hand? I’ve been requested that several times recently, and so far neither users requesting it nor I had realized that… most of the work is already done in wiki/src/doc/first_steps/persistence/copy.mdwn :)

So it seems that a low-hanging fruit, with a pretty good cost/benefit ratio, is waiting to be picked: we could expand a little bit the scope of that page existing page, just enough to satisfy this additional use case (that I can specify more clearly if needed), and then link it from wiki/src/doc/first_steps/persistence.mdwn in a way that makes users aware of it.

What do you think?

Files

backup.mdwn (1944 B) segfault, 2018-02-13 15:44:41
Backup Documentation.png (139255 B) segfault, 2018-07-30 12:39:14

Subtasks

Related issues

Related to Tails - Feature #11627: Consider updating the default system partition's size Resolved 2016-08-10
Related to Tails - Feature #12705: Update the size of the system partition to >= 4 GiB Resolved 2017-06-15
Related to Tails - Feature #14624: Document how to migrate persistence to a new USB stick or update the system partitions of an existing device Duplicate 2017-09-12
Related to Tails - Bug #10391: Useless step in https://tails.boum.org/doc/first_steps/persistence/copy/ Rejected 2015-10-19
Related to Tails - Bug #15685: Test manually creating a disk image as a backup technique Resolved 2018-06-25
Related to Tails - Feature #13457: Test backup script by a2 Resolved 2017-07-12
Is duplicate of Tails - Feature #14605: Improve documentation on "Manually copying your persistent data to a new USB stick" Resolved 2017-09-05
Blocks Tails - Feature #16711: Core work 2019Q3 → 2019Q4: Technical writing Resolved 2016-01-08

History

#1 Updated by sajolida 2017-03-04 20:41:49

I think it’s a good idea. I’m happy to review plans of people interested
in working on this (or do it myself if I have the time).

#2 Updated by intrigeri 2017-03-05 09:23:41

  • Type of work changed from Discuss to End-user documentation

Thanks! I think that’s all I needed to drop the “needs discussion” bit.

#3 Updated by cbrownstein 2017-03-29 22:00:26

I’m thinking: Should we detail (1) the process for creating a LUKS partition on a new device; and (2) how to copy persistent files to that LUKS partition? The instructions in

wiki/src/doc/first_steps/persistence/copy.mdwn

suggest installing Tails on the new device, which shouldn’t be needed for backup purposes.

Comments?

#4 Updated by intrigeri 2017-04-05 15:50:43

  • Assignee set to sajolida
  • QA Check set to Info Needed

#5 Updated by sajolida 2017-04-07 15:16:08

#6 Updated by Anonymous 2017-04-27 10:12:10

cbrownstein wrote:
> I’m thinking: Should we detail (1) the process for creating a LUKS partition on a new device; and (2) how to copy persistent files to that LUKS partition? The instructions in […] suggest installing Tails on the new device, which shouldn’t be needed for backup purposes.
>
> Comments?

This sounds like a good idea to me. However, both types of copy might be needed: some people will want to have an external backup, others will want to have a copy of their entire Tails device.

There could be two type of instructions:

- using the command line
- using GUI tools

#7 Updated by cbrownstein 2017-04-29 20:57:24

  • Assignee changed from sajolida to cbrownstein

#8 Updated by Velexx 2017-04-30 16:59:47

I personally always need a way to backup my data as the #1 rule of data security, even more important than all the encryption and anonymity stuff. It can’t wait. Having all my data on just one flash drive is intolerable: for example may God help me if I ever forget to eject it before I unplug it.

So even though I’m just a beginner to linux, here’s what I worked out and use:

I have a secondary USB tails stick with plenty of extra space on it as ‘persistent’ space set up.

I plug that in when I’m already running my primary copy of Tails and enter the password to decrypt it.

It opens up as a ‘TailsData’ drive.

Then I enter a command similar to this one (mine is modified a bit for my own situation) in my root terminal (cause I hate the non-root one) to copy a few things of interest to me and keep them safe:

cp -uvr /live/persistence/TailsData_unlocked/bookmarks /media/amnesia/TailsData/ ; cp -uvr /live/persistence/TailsData_unlocked/icedove /media/amnesia/TailsData/ ; cp -uvr /home/amnesia/Persistent /media/amnesia/TailsData/

Which will also perform updates instead of recopying the same files.

It works great except that:

1. it tends to create the new directories and backups without further access, so if/when I don’t like that I hit it with this command:
chmod -R 777 /media/amnesia/TailsData/bookmarks /media/amnesia/TailsData/icedove /media/amnesia/TailsData/Persistent

2. if I load Tails off the secondary USB stick the persistent volume doesn’t work within booting the secondary Tails: from checking little files created there Tails seems to somehow detect that the Persistent volume has been interfered with and disable it for the Tails boot. But the secondary copy of Tails serves me as on OS backup, and the persistent volume still works as a plugin when loaded within the primary Tails, so they are both functional for me even if they don’t work together at the same time.

If it helps me, maybe it helps someone else too.

#9 Updated by Velexx 2017-04-30 18:04:34

UPDATE: I just realized that the following command to backup everything persistent, from primary Tails currently running to secondary USB stick of Tails mounted for its with persistent encrypted space, might work if secondary free space is not limiting; I can’t test it now because my secondary USB stick is too small:

cp -uvr /live/persistence/TailsData_unlocked/. /media/amnesia/TailsData/

(Like I said, I’m new)

And the reason I prefer the root terminal is I hate having to ask for permission on my own computer. :)

#10 Updated by cbrownstein 2017-04-30 22:25:50

Thank you for the input, Velexx. I think users familiar with the command line (like yourself) could use something along the lines of what you’ve proposed. But, users unfamiliar with the command line might have a problem.

In Bug #12109, sajolida made the following comments, which I think make a lot of sense:

> We usually try to avoid as much as possible having people to do stuff on the command line; and when we do so, we try to keep it as simple as possible

and

> … from my experience with people who are not used to the command line, it’s usually fine for them to copy paste stuff in there blindly but one of the most confusing aspect is that successful commands do not return anything (silence means success).

#11 Updated by sajolida 2017-05-07 07:36:47

  • Status changed from Confirmed to In Progress

#12 Updated by sajolida 2017-05-25 19:32:48

  • related to Feature #11627: Consider updating the default system partition's size added

#13 Updated by intrigeri 2017-06-15 06:33:27

  • related to Feature #12705: Update the size of the system partition to >= 4 GiB added

#14 Updated by Anonymous 2017-06-30 15:27:33

  • related to Feature #5301: Backup system for the Persistence added

#15 Updated by sajolida 2017-07-05 19:02:59

  • blocked by deleted (Feature #12432: Technical writing core work 2017Q2)

#16 Updated by sajolida 2017-07-12 08:13:15

  • related to deleted (Feature #5301: Backup system for the Persistence)

#17 Updated by sajolida 2017-07-12 08:13:25

#18 Updated by BitingBird 2017-08-30 10:54:37

  • Assignee changed from cbrownstein to spriver
  • Target version set to 2018

#19 Updated by BitingBird 2017-08-30 10:55:40

  • Subject changed from Consider documenting a way to manually backup persistent data to Document a way to manually backup persistent data

#20 Updated by BitingBird 2017-08-30 10:57:11

  • Assignee changed from spriver to segfault

#21 Updated by sajolida 2017-09-12 09:23:10

  • related to Feature #14624: Document how to migrate persistence to a new USB stick or update the system partitions of an existing device added

#22 Updated by sajolida 2017-09-23 10:52:36

  • related to Feature #14605: Improve documentation on "Manually copying your persistent data to a new USB stick" added

#23 Updated by sajolida 2017-09-23 10:53:12

  • related to Bug #10391: Useless step in https://tails.boum.org/doc/first_steps/persistence/copy/ added

#24 Updated by Anonymous 2018-01-17 13:44:24

Might also be worth looking at the proposal in Feature #14605.

Segfault: do you still plan to work on this? If yes: fine. If not, maybe crbrownstein or spriver are interested?

#25 Updated by segfault 2018-01-19 22:02:31

> Segfault: do you still plan to work on this? If yes: fine. If not, maybe crbrownstein or spriver are interested?
Yes, but I don’t know when I will have time for it. It would of course be great if someone else wanted to do it.

#26 Updated by intrigeri 2018-02-13 13:28:45

See a PoC Tails stick duplication script: https://mailman.boum.org/pipermail/tails-dev/2018-January/012008.html

#27 Updated by segfault 2018-02-13 14:47:31

intrigeri wrote:
> See a PoC Tails stick duplication script: https://mailman.boum.org/pipermail/tails-dev/2018-January/012008.html

The way I understand it, this ticket is not about shipping a custom backup solution, like these scripts are, but document a way to use existing tools to backup the persistent data. IMO, we should add a comment on Feature #5301 about these scripts, and consider using them when working on Feature #5301.

#28 Updated by segfault 2018-02-13 15:45:20

  • File backup.mdwn added
  • Assignee changed from segfault to sajolida
  • QA Check changed from Info Needed to Ready for QA

I drafted something to document manually backing up to, and restoring from, an encrypted volume.

I took into account the remarks on Feature #14605, which I find valid, and chose to document copying files using the root terminal instead of nautilus with root permissions. For the usage of the command line, I oriented myself on the documentation of how to check the file system of the persistent volume.

sajolida, would you mind reviewing this?

#29 Updated by sajolida 2018-03-14 11:47:06

  • blocks Feature #14758: Core work 2017Q4 → 2018Q1: Technical writing added

#30 Updated by sajolida 2018-03-27 11:27:59

  • blocked by deleted (Feature #14758: Core work 2017Q4 → 2018Q1: Technical writing)

#31 Updated by sajolida 2018-03-27 11:28:04

  • blocks Feature #15411: Core work 2018Q2 → 2018Q3: Technical writing added

#32 Updated by sajolida 2018-04-11 13:40:25

  • Assignee changed from sajolida to cbrownstein

Cody: I’m assiging this one to you as part of the big problem space “Persistent storage vs Backups”.
Please check which parts of it are the best to tackle first.

#33 Updated by segfault 2018-07-30 12:18:18

  • related to Bug #15685: Test manually creating a disk image as a backup technique added

#34 Updated by segfault 2018-07-30 12:40:00

Adding a screenshot of the resulting documentation page

#35 Updated by segfault 2018-07-30 13:09:51

  • Feature Branch set to segfault:doc/12214-persistence-backup

Setting the feature branch. Documentation branches are based on master, right?

#36 Updated by cbrownstein 2018-07-30 19:03:12

Hi!

segfault wrote:
> Setting the feature branch. Documentation branches are based on master, right?

Correct.

I want to review your branch but I don’t know where to pull it from. Alternatively, since only backup.mdwn is being modified, I can apply your changes to master then build and review that.

#37 Updated by segfault 2018-07-30 19:18:12

> I want to review your branch but I don’t know where to pull it from.
My Tails repository is https://gitlab.com/segfault3//tails

#38 Updated by sajolida 2018-08-04 10:01:36

  • Assignee changed from cbrownstein to sajolida
  • Target version changed from 2018 to Tails_3.9

Cody: if you don’t mind I’ll take over this problem space for some time since I’ve been working on Bug #15685 lately.

#39 Updated by sajolida 2018-08-13 13:59:33

  • Target version changed from Tails_3.9 to Tails_3.10.1

#40 Updated by Anonymous 2018-08-17 09:53:45

#41 Updated by sajolida 2018-09-11 18:00:30

  • blocked by deleted (Feature #15411: Core work 2018Q2 → 2018Q3: Technical writing)

#42 Updated by sajolida 2018-09-11 18:00:36

  • blocks Feature #15941: Core work 2018Q4 → 2019Q2: Technical writing added

#43 Updated by sajolida 2018-10-21 20:44:55

  • Target version changed from Tails_3.10.1 to Tails_3.11

#44 Updated by sajolida 2018-12-10 15:40:42

  • Target version changed from Tails_3.11 to Tails_3.12

#45 Updated by sajolida 2019-01-28 18:45:32

  • Target version changed from Tails_3.12 to Tails_3.13

#46 Updated by sajolida 2019-03-15 18:05:39

  • Target version changed from Tails_3.13 to Tails_3.14

#47 Updated by CyrilBrulebois 2019-05-23 21:23:17

  • Target version changed from Tails_3.14 to Tails_3.15

#48 Updated by intrigeri 2019-06-02 14:42:52

  • Status changed from In Progress to Needs Validation

#49 Updated by CyrilBrulebois 2019-07-10 10:33:54

  • Target version changed from Tails_3.15 to Tails_3.16

#50 Updated by sajolida 2019-07-18 16:54:29

  • blocks Feature #16711: Core work 2019Q3 → 2019Q4: Technical writing added

#51 Updated by sajolida 2019-07-18 16:54:31

  • blocked by deleted (Feature #15941: Core work 2018Q4 → 2019Q2: Technical writing)

#52 Updated by intrigeri 2019-08-30 17:50:06

  • Target version deleted (Tails_3.16)

Hi!

We’ve set up an automated process to ask our fellow contributors to update some tickets of theirs, in order to:

  • better reflect your plans;
  • bring down your amount of work-in-progress to a sustainable level;
  • encourage team work and increase the chances that someone finishes the work;
  • avoid a human doing ticket triaging and asking you the same questions on each such ticket.

In particular, this process identifies:

  • Stalled work-in-progress
  • Reviews waiting for a long time

However, in the current state of things, this process is not able to notice those tickets when their Target version has been repeatedly postponed by our Release Managers. Therefore, the ticket triaging team decided on Feature #16545 to remove the Target version whenever in such cases, when it does not feel realistic. This is what I’m doing on this ticket.

You now have a few options, such as:

  • Deassign yourself. That’s fine. If it really matters, someone else, possibly you, may pick it up later. Then, if this ticket is relevant for a Tails team, bring it to their attention; else, forget it and take care of yourself :)
  • If you think you can realistically come back to it and finish the work in the next 6 months, say so on this ticket, for example by setting a suitable “Target version”. This will communicate your plans to the rest of the project and ensure the task pops up on your radar at a suitable time. Of course, you can still realize later that it is not going to work as planned, and revisit today’s choice.

Cheers!

#53 Updated by sajolida 2019-09-03 13:32:42

  • Status changed from Needs Validation to Duplicate
  • Assignee deleted (sajolida)

In Feature #14605, I submitted a branch that improves /doc/first_steps/persistence/copy instead of creating another page like this branch does.

It’s equivalent to the S1 scenario described in https://tails.boum.org/blueprint/backups.

The branch in Feature #14605 requires less manual and error prone actions from the user (eg. no need to identify the full path of the backup volume).

So I’m closing this ticket as a duplicate of Feature #14605.

#54 Updated by sajolida 2019-09-03 13:33:41

  • related to deleted (Feature #14605: Improve documentation on "Manually copying your persistent data to a new USB stick")

#55 Updated by sajolida 2019-09-03 13:33:58

  • is duplicate of Feature #14605: Improve documentation on "Manually copying your persistent data to a new USB stick" added