Cool tools, CopyFS and lsyncd
gordan.bobic at gmail.com
Tue May 10 09:51:32 EDT 2011
On 05/05/2011 10:27 PM, Omen Wild wrote:
> Quoting Gordan Bobic<gordan.bobic at gmail.com> on Thu, May 05 01:58:
>> I actually use lsyncd to trigger file syncing to a backup volume on every
>> write-close, and the backup volume is running CopyFS to ensure that every
>> version of the file that was ever saved (well, within reason, space
>> allowing) can be retrieved. But as I said, restoring from a backup is much
>> slower than fsck would be.
> I figure this was lost in the greater discussion going on about fsck, but
> I was wondering if you would be willing to share a little more about your
Sure. It's a little off topic, since it's not really zfs specific, so I
hope the others don't mind.
> Have you had any issues with CopyFS? The idea looks really cool, but the
> code has been unmaintained for a while.
I'm aware that it is currently unmaintained, but I haven't run into any
serious problems. There are a couple of minor annoyances that I keep
meaning to look into but haven't gotten around to yet, but nothing major.
1) If you try to:
# copyfs-fversion /full/path/to/file
it complains about the lading / and fails to return anything.
But if you:
# cd /; copyfs-fversion full/path/to/file
it works fine.
2) There is a build warning about a type mismatch on xattrs, but it
doesn't seem to break anything.
3) Doesn't come with /sbin/mount.copyfs, but you can ln -s that to
/bin/copyfs-mount and that works fine, you can then use it in fstab.
> Does lsyncd deal well with changes that happen faster than the network
> can keep up? I need to get a good offsite backup strategy going.
The operation is completely asynchronous, so your target will be more
and more out of sync as your local changes exceed your bandwidth. But
when the load goes away, it will eventually catch up. Since the changes
are asynchronous, it won't slow down the local machine.
More information about the zfs-discuss