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

Borrar esta mensaxe

Responder a esta mensaxe
Autor: CustaiCo
Data:  
Para: tails-dev
Asunto: Re: [Tails-dev] Feedback wanted on planned implementation of Feature #5301 - Clone or Backup Persistent Volume
Sun, 30 Mar 2014 17:33:30 +0200
intrigeri <intrigeri@???> wrote:

> I agree with the general idea, and will only discuss its
> implementation here.
>
> I'm wary of having to maintain yet another shiny new piece of code
> that does basically tar|gpg. I'm sure the initial implementation would
> be very straightforward, but I'm also convinced that there are tons of
> corner cases to handle, that one initially does not think of. And once
> we take it all into account, then we get a large piece of code to
> maintain all by ourselves, because it was meant only for Tails' needs.
>
> So, I would try not to reinvent this wheel, and use an existing,
> proven solution instead.
>
> I would suggest looking into duplicity (http://duplicity.nongnu.org/)
> first: it supports something that's basically "tar | gpg" for the
> first iteration, and it also leaves room for future improvements,
> thanks to its support for incremental and/or remote backups. Also, it
> allows users to restore or inspect their backups outside of Tails,
> without having to manually decipher yet another backup file format.
>
> There are probably other plausible candidates worth comparing with
> duplicity :)
>
> Cheers,


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? I couldn't imagine putting my data
into the cloud, even if it was encrypted.

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?

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. If it's critical that it be able to differential backups and
all that in the future, I can go with this. 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.