Hi, list. I'd like to announce one more bikeshe^W lafs-related project - lafs-backup-tool.
Most features and design goals should be described in README and base configuration file, where they're controlled. https://github.com/mk-fg/lafs-backup-tool https://github.com/mk-fg/lafs-backup-tool/blob/master/lafs_backup/core.yaml 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 static. Like "tahoe backup", local deduplication database is kept for performance reasons. 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 depth-first queue. 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
signature.asc
Description: PGP signature
_______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev