Re: [Tails-dev] Feedback wanted on planned implementation of…

Nachricht löschen

Nachricht beantworten
Autor: intrigeri
Datum:  
To: The Tails public development discussion list
Betreff: Re: [Tails-dev] Feedback wanted on planned implementation of Feature #5301 - Clone or Backup Persistent Volume
Hi,

CustaiCo wrote (01 Apr 2014 11:08:44 GMT) :
> Ok, so I took a look at this. It seems mainly focused on doing
> differential backups and backing up to cloud based storage services. Is
> this something that one wants to do?


JFTR, I would not say it's focused on the cloud. The cloud backends
were added in the last few years, and duplicity supported sftp way
earlier.

> I couldn't imagine putting my data into the cloud, even if it
> was encrypted.


I would love pushing incremental, encrypted backups of my Tails
persistent volume to a sftp server I control.

> There is also the issue of the archive directory. It says you need to
> keep it 'in order to manage persistence for current and future
> enhancements.' So, we then have to persist this but exclude it from the
> backup?


Indeed.

> I'm not opposed to using something that can make this easier, but the
> main task that I want to accomplish with this is get a backup of
> persistence without having to have a root password enabled, and get it
> restored.


Sure.

BTW, you'll want to save room for backup'ing ACLs when we start using
it more on the persistent volume. Neither GNU tar nor duplicity
support that, so perhaps duplicity is not the best bet.

> If it's critical that it be able to differential backups and
> all that in the future, I can go with this.


I would definitely not say it is "critical".

> Otherwise I don't
> see this being any easier, or maybe even more difficult than the very
> basic strategy.


> Perhaps I am being myopic. If the code acutally do the
> backup once I have a filehandle to work with gets very big whatsoever,
> I'll certainly look for something that's been written already.


Your call, but:

  * I expect it's only slowly that we'll discover the list of corner
    cases we have to deal with manually, thanks to using a low-level
    tool; so, we may realize in months, if not years, that oh well,
    we've written yet another tar wrapper/overlay, and have to either
    maintain it forever, or design a migration and have users go
    through it;


  * if we have to move to another backup tool, then we'll have to deal
    with the migration (e.g. support restoring old-style backups for
    a while, advising to create new-style ones).


But it's entirely possible that I am being overly cautious about this
all. I would hate me for discouraging you, and the simplest approach
definitely makes sense, at least as a "tracer bullet". Go, go, go :)

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc