DRBD or similiar RAID over net on slow/limited networks

I am looking for ways to create some kind of file replication without losing too much performance on file operations. A real RAID is not an option due to non-technical constraints.

As far as I understand, DRBD tries to act like a real RAID1, distributing the changes immediately. From what I read, this only makes sense, if the servers are really close to eachother (same rack). However, I can live with a certain lag (eg. 15-30 minutes) between the replication of the filesystem and a partial loss of data in case of HD failure.

Can you point me into some direction? Is there a non-realtime file replication? Or would I be better of simply calling rsync over and over again? Are there any benchmarks on comparing DRBD with different latencies with Software-RAID systems.

Possibly GlusterFS will be a solution. http://www.gluster.org/

In my experience it's capable of coping with slow networks well enough.

Two more ideas for you:

• Use DRBD in mode "A" (=async mode) and turn up the buffers (max should be about 8 MB). This will allow drbd to lag behind a little bit.
• Use rsync, but also use the rsync-server-mode on your targets. That way the checksumming process will speed up.

You could also use NBD with MDADM, i am just evaluating a similar scenario for a client, but i did not come round to doing benchmarks yet.

If lag and some loss of data is not a concern you could write your own small rsync script, something like:

rsync -av --delete /etc /root /home /usr /etc /var /opt [email protected]:/

And run it every 15 minutes. However it may be too slow in gathering and transmitting all data and not yet be done before the next one runs. Although when rsync has run at least once it's quite fast in subsequent runs.

You can also try rsnapshot: http://www.debian-administration.org/articles/217

"Like many backup solutions rsnapshot is a script which is built upon a foundation of OpenSSH and Rsync - the latter being used to synchronise directory contents without using excessive bandwidth, and the former to ensure the communication is encrypted and secure."