Looks neat. Thanks!<br><br><div class="gmail_quote">On Mon, Oct 15, 2012 at 7:23 PM, Mike Kazantsev <span dir="ltr"><<a href="mailto:mk.fraggod@gmail.com" target="_blank">mk.fraggod@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi, list.<br>
<br>
I'd like to announce one more bikeshe^W lafs-related project -<br>
lafs-backup-tool.<br>
<br>
Most features and design goals should be described in README and<br>
base configuration file, where they're controlled.<br>
<br>
<a href="https://github.com/mk-fg/lafs-backup-tool" target="_blank">https://github.com/mk-fg/lafs-backup-tool</a><br>
<a href="https://github.com/mk-fg/lafs-backup-tool/blob/master/lafs_backup/core.yaml" target="_blank">https://github.com/mk-fg/lafs-backup-tool/blob/master/lafs_backup/core.yaml</a><br>
<br>
Intended usage is a poor man's offsite backups with low-space grids,<br>
like cloud backends, where one has to be picky about what is important<br>
enough to backup (hence the filtering facilities) and benefits from<br>
such things as compression (configurable for file paths and sizes).<br>
<br>
I use it on local backups, already made by rsync from a live<br>
filesystem, so there's no extra effort to control what's backed-up<br>
first (GridBackup project allows that), as paths are assumed to be<br>
static.<br>
<br>
Like "tahoe backup", local deduplication database is kept for<br>
performance reasons.<br>
<br>
Unlike "tahoe backup", internally it works without recursion and does a<br>
topdown tree traversal using simple os.walk() (and not traversing<br>
excluded paths), building (one line at a time) queue-file, then just<br>
flipping it upside-down using simple coreutils "tac" binary to produce<br>
depth-first queue.<br>
<br>
Since I tend to occasionally use ACLs and capabilities, these are also<br>
backed-up (along with general uid/gid/mode metadata), which is<br>
implemented through ad-hoc cffi bindings.<br>
<br>
Closest plan is to add restoration functionality, which can currently<br>
be done with standard tahoe access tools, with one additional step of<br>
running "file && xz -d" on the paths (though encoding information is<br>
stored in the filenode metadata and/or detailed logs).<br>
<br>
Any commentaries, reports, accusations and lamentations are, of course,<br>
welcome. I'm also known as MK_FG on #tahoe-lafs @ freenode IRC.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Mike Kazantsev // <a href="http://fraggod.net" target="_blank">fraggod.net</a><br>
</font></span><br>_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
<br></blockquote></div><br>