[tahoe-dev] lafs-backup-tool, an alternative to "tahoe backup"
mk.fraggod at gmail.com
Tue Oct 16 01:23:21 UTC 2012
I'd like to announce one more bikeshe^W lafs-related project -
Most features and design goals should be described in README and
base configuration file, where they're controlled.
Intended usage is a poor man's offsite backups with low-space grids,
like cloud backends, where one has to be picky about what is important
enough to backup (hence the filtering facilities) and benefits from
such things as compression (configurable for file paths and sizes).
I use it on local backups, already made by rsync from a live
filesystem, so there's no extra effort to control what's backed-up
first (GridBackup project allows that), as paths are assumed to be
Like "tahoe backup", local deduplication database is kept for
Unlike "tahoe backup", internally it works without recursion and does a
topdown tree traversal using simple os.walk() (and not traversing
excluded paths), building (one line at a time) queue-file, then just
flipping it upside-down using simple coreutils "tac" binary to produce
Since I tend to occasionally use ACLs and capabilities, these are also
backed-up (along with general uid/gid/mode metadata), which is
implemented through ad-hoc cffi bindings.
Closest plan is to add restoration functionality, which can currently
be done with standard tahoe access tools, with one additional step of
running "file && xz -d" on the paths (though encoding information is
stored in the filenode metadata and/or detailed logs).
Any commentaries, reports, accusations and lamentations are, of course,
welcome. I'm also known as MK_FG on #tahoe-lafs @ freenode IRC.
Mike Kazantsev // fraggod.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the tahoe-dev