intrigeri:
> Hi,
>
> CustaiCo wrote (17 Mar 2014 23:00:10 GMT) :
>> 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
>
> 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 :)
I also thought about a loopback LUKS device in a file.
Cons:
- Maybe backups done this way would be much bigger than duplicity backups.
- duplicity supports incremental backups even if they have some limitations.
Pros:
- duplicity backups are not in one file, and can be a bit messy on the
file system.
Another candidate could be obnam but I never tried it.
Would this be worth a Discuss or Research ticket in Redmine?
--
sajolida
