Which backup tools should we use for linux?
You might scoff, but... btrfs send/receive is insanely fast and painless. To mitigate btrfs shenanigans, snapshots end up on non-btrfs filesystems too. I wrote a tool [2] which produces PGP signatures and sha512sums of snapshots to achieve reproducible integrity measurements regardless of FS.
Of course, in the time it took to polish up snazzer a bit for public release, many [3] other [4] cool [5] solutions [6] have materialized [7]... :)
[1] https://github.com/csirac2/snazzer
[2] https://github.com/csirac2/snazzer/blob/master/doc/snazzer-m...
[3] https://github.com/masc3d/btrfs-sxbackup
[4] https://github.com/digint/btrbk
[5] https://github.com/jimsalterjrs/sanoid/
No backup solution is perfect, anything including your backups can fail. The three rules of backups:
* If it isn't backed up you don't really care about it
* If you really care about something back it up using at least two unrelated systems, one or more remote and one or more offline (soft-offline will do).
* If you haven't tested the backups, you don't have backups.
> Which backup tools should we use for linux?
I'm still using simple hand-rolled scripts to manage backups via rsync (for an old but still good tutorial on that sort of thing see http://www.mikerubel.org/computers/rsync_snapshots/) and (where consistency and/or downtime between backup start and end times might be an issue) LVM snapshots. I've needed tweak them a bit over the years as my needs have changed and as I've become more paranoid about the "testing backups" thing, but I'd have had to do that with other tools too.
1. https://github.com/jborg/attic/search?q=corrupt&type=Issues&...
What I wonder more is why the corruption of the file data wasn't caught by the backup software since it uses checksums for deduplication.
A third option is user error such as that between the (user) checksums and the backup there were changes to some files.
http://librelist.com/browser/attic/2015/3/31/comparison-of-a...
That said, I freaking love attic. It's the best backup program ever.
Of particular concern is that Obnam has a theoretical collision
potential, in that if a block has the same MD5 hash as another
block, it will assume they are the same. This behaviour is the
default, but can be mitigated by using the verify option. I tried
with and without, and interestingly did not notice any speed
difference (2 seconds, which is statistically insignificant) and
also did not encounter any bad data on restoration. So I don't
know why it's off by default.
The theoretical possibility of a catastrophic occurrence in your
program can be ignored if it's less likely than the entire
installation being wiped out by meteor strike.
1) Access to an existing object, or its checksum.
2) Can write a *new* object where they intentionally
produce a collision with an existing object.
This means that you've changed an attack where someone can maliciously clobber an existing object to an edge case where their object just won't get backed up.
I like duplicity but it's not perfect. zbackup seems faster/more integrated and also not have the reputation for losing data that attic has.
Never lost data with duplicity in about 5 years of use.
I have a backup solution that corrupts your data, but is even faster than Attic: tar cp > /dev/null