> what about these approaches:
>
> - use lvm for backuppc pool, and schedule some kind of incremental dd of
> the device by taking a snapshot of the lvm volume
That should work - or the similar concept of software raid1 where you
periodically fail/remove/add a mirror to rotate offsite. You need a
disk type that can be hot-swapped (usb, firewire, some SATA, some SCSI).
The issue here is that a raid1 rebuild is a block-by-block rebuild which can be very time consuming, especially on large disks. The concept is sound and fully functional but this time is a killer.
> - use coda or other replicating filesystem on the backuppc pool? could
> be?
I'm not sure if these work well without high-bandwidth connections.
The big weakness of such filesystems like coda, gfs, gluster, luster, etc is I/O performance. Backuppc is primarily I/O bound with the exception of compression using CPU time and rsync using a lot of RAM. That makes these filesystems perform very slowly in a use like this reguardless of the network interface.
> - use some dedicated storage that to hardware replication (like
> datadomain)
>
> any opinion is very appreciated..
I think the zfs filesystem with snapshot and incremental send/receive
capability sounds promising. I just haven't had time to test it.
This is just a mattery of proper scripting to make the snapshot, send it, verify a good transfer, and delete the local snapshot as well as promote the remote snapshot.
I have done some googling for an rsync filesystem that could monitor one filesystem and automatically rsync the file between the source and destination via a fuse module but I find nothing that exists today.
I have found the fuse filesystem mysqlfs which is interesting in that standard mysql replication could be used on the local and remote filesystem in realtime. unfortunately mysqlfs is not ready to be a primary filesystem and the fuse layer is likely to cause some major performance issues. as a note on the mysql storage of files, even with this sitting on fuse *some* operations are amazingly fast while others suffer from un-optimized fuse and yet others dont lend themselves to mysql's talents.
What I have been doing is having an alternate install of rsync3 on both machines and use that to sync. rsync3 isnt the perfect solution but it is capable of doing this task. rsync2 eats up a ton of RAM which is why I use rsync3.
