On Thu, 03 Apr 2014 11:20:47 +0200 intrigeri <[email protected]> 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.
signature.asc
Description: PGP signature
_______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
