On Thu, 03 Apr 2014 11:20:47 +0200
intrigeri <intrigeri@???> wrote:
> 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,
I did a bit more research on this -- the ACL thing did not look easy
to fix with the solution I was planning.
What about something like DAR (
http://dar.linux.free.fr/ )? It already
supports ACL backups. It already supports encrypting the archive with a
symmentric key and a strong algorithm, and it looks like it should be
configurable pretty easily with files. It seems like it would support
differential backups at a later time pretty easy.
The only problem I see using that is that I'm not entirely sure how I'm
going to get it the key phrase in a secure enough way to the program,
and that there aren't any existing perl wrappers I can find for the
program.
