<br><br><div class="gmail_quote">On Sat, Jul 7, 2012 at 4:15 PM, Henri Shustak <span dir="ltr"><<a href="mailto:henri.shustak@gmail.com" target="_blank">henri.shustak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Wow!  Thanks for making it so easy.  I will try that asap.<br>
<br>
</div>If you do not have any luck with the patched version of rsync there are various projects which spring to mind which offer this kind of functionality.<br></blockquote><div><br>For backups, not really for file transfers, there's my pet project, backshift:<br>
<a href="http://stromberg.dnsalias.org/~strombrg/backshift/">http://stromberg.dnsalias.org/~strombrg/backshift/</a><br>It's been operating strictly on SHA hashes from the beginning.  It also compresses its file chunks using xz.  xz is -=not=- blazing fast, but it tends to produce nice, small files, and you generally only need to compress a given file content (chunk, really - large files are divided into multiple chunks) once, so subsequent backups are relatively quick.<br>
<br>In all honesty and candor, it has a little trouble on Windows (Cygwin) because Windows will sometimes ENOENT on a read, but it's been working great on *ix, including multiple Linuxes, *BSD, Solaris, OS/X and Haiku.   It's been hard to get myself to test on Windows.  :)<br>
<br>it also has a pretty comprehensive suite of automated tests and good documentation, to help you feel more confident using it.<br><br>It doesn't use hardlinks at all in its repository, but it's very good at detecting hard links in the files you're backing up - it doesn't just rely on st_nlink, but instead uses a bloom filter.  So you can pretty easily transfer a backshift repo to a new system (using rsync of course!), but you aren't likely to need to as soon, because of the compression; even most metadata is stored compressed.  IOW, the tradeoff is: your initial backups are slow, but they're all small.<br>
<br>It needs a relatively capable filesystem for its repo, like ext4 or xfs.  ext3 and Netapp are known to not work because they can't handle the large directory (one directory in particular grows to 2^20 files) backshift creates.<br>
<br>The format it uses for its repo is custom, but it's pretty straightforward.<br><br>To do a save, you pipe find into it, like cpio.  To do a restore, you ask it to generate a tar archive, and you pipe that to tar xvfp.  This means you don't need to learn a unique file selection language, and it means the software isn't subject to security issues during restore - or rather, no issues that aren't taken care of by patches to your tar program.<br>
<br>HTH someone.  ^_^<br><br><br><br></div></div>