Thu, 27 Mar 2014 13:51:32 +0000
From: sajolida@???
> > The backup step would ensure that persistence has been enabled and
> > mounted, and then go into /live/persistence/TailsData_unlocked/
> > then run something that would be the equivalent of something like
> > this
> >
> > tar cjf - . | gpg --cipher-algo AES -c -
> > > /home/amnesia/YYYY-MM-DD-backup.tbz2.gpg
>
> Here the user should be prompted about where to save the backup.
> Because there might not be enough RAM on the computer to handle that,
> so they might prefer to write that file directly in some other place,
> like an external hard drive or USB stick.
>
I was thinking about that, but the problem here is that it runs as
root, wouldn't a filechooser allow them to save to any abitrary
location they wanted? I'll admit to never having touched a line of gtk2
in my life untill I started in on this, but the only way I saw based on
the documentation would be to fork the file picker dialog box as the
amnesia user to prevent them from picking something bad.
Maybe if there isn't an way I can figure out how to make a widget stay
in a safe spot, I could just say that it will go in ~/backup and if you
want it to be in a different place, you can just make that a symlink
right before you do the job? I never even thought of a backup being too
big that it couldn't be stored in RAM.
> > then test it with something that does something like this
> >
> > cat /home/amnesia/YYYY-MM-DD-backup.tbz2.gpg | gpg - | tar djf -
> >
> > If that gives outputs anything, we give some sort of
> > abort/retry/fail message to the user. If all goes well, then the
> > user has a file they can back up with a secure method.
>
> I'm also wondering whether it would be worth to ask the user which
> folders of the persistence setup to backup. But maybe that's not
> needed for a first prototype, as we might assume that the info in
> persistence is kept to the minimum.
>
> And also, do you think we should treat differently the data in
> persistence that is not so personal, like APT lists and APT packages.
> Those might compress pretty badly and occupy space for nothing in the
> backups.
Hrm, the apt cache is a pretty big part of my current backups. I'm not
sure this would make it into the first version, however. If you have
the apt list and packages stored, it's likely for a reason. Honestly, I
like 'backup all the things' approach because then one couldn't
accidentally not backup something they needed.
>
> > The restore step would do the current delete partition steps (if
> > there was already a persistence partition found), then most of the
> > current steps to create a partition, but instead of asking the user
> > what they want to use their new partition for, it would instead ask
> > the user to pick an encrypted backup file and would untar it into
> > the directory that the partition was mounted for initialization.
>
> Ack.
>
> > Does anything look bad with this plan?
>
> And what are your plans regarding the menus entries proposed to the
> user? For the moment we have:
>
> ??? Applications
> ??? Tails
> ??? Configure persistent volume
> ??? Delete persistent volume
>
> Maybe that could go all together in another entry, say "Backup and
> restore persistent volume"?
>
I was thinking two seperate items: Backup persistent volume and Restore
Persistent Volume. In fact, I was wondering if restore was even going
to be worth it considering how little it would be used compared to
backup. I would certainly hope one does very large number of backups
compared to restores.
