up vote 0 down vote favorite
share [g+] share [fb]

I am currently re-architecting our backup solution and would like some input on how to do the replication portion. We have two sites, one much larger than the other, that we need to back up. I have two Linux servers that will share out their volumes via either NFS/iSCSI/SMB (I haven't fully decided which to go with yet). The files that will be stored on these volumes will most likely be VMDK - so just single, large files - which will contain backups using either VMWare Data Recovery or Veeam (also haven't decided which to use).

Now comes the tricky part.. I would like to replicate these VMDK's to both servers. So server A will have it's own VMDK, and server B will have it's own VMDK. Should I use something like Rsync to periodically replicate the files themselves to the other server, or would it be better to utilize something like DRBD+GFS2 to replicate stuff as it changes at the block level, essentially giving me an active/active clustered file system? Keep in mind that the VMDK's will not be modified in both locations. That is, server A will never modify a VMDK that is primarily housed on server B and vice-versa

Please let me know if you need any more information and thanks for any input!

link|improve this question
78% accept rate
feedback

1 Answer

up vote 3 down vote accepted

I've worked on a couple of similar systems in the past (for VM storage replication, no less!). In general I'm more comfortable with the scheduled-rsyncs solution as we found DRBD setup to be tricky and a little brittle, but you do have the disadvantage that if a failure happens betweens rsyncs you lose the changes. How frequently do these files change / how recent does a backup have to be in case of failure?

DRBD is better in the sense that the block devices are being updated continuously, which is a big plus and allowed faster VM-failover for us. But we did find the setup (and debugging if something went wrong) more difficult. I'd generally say use DRBD if you need that kind of redundancy, or rsync if you consider these more cold/infrequent backups.

(We also tried some fairly wild stuff: iSCSI (actually, SRP)-exported block devices from two different servers, with software RAID applied to the block devices on server #3. But we didn't keep that around long enough to test it much.)

link|improve this answer
1  
I've seen some ugly losses with DRBD too - I'd definitely go with rsync or perhaps AFS – symcbean Apr 11 '11 at 13:37
I don't think I need instant updates, but it would be nice to just have it done at the block level and not deal with file level stuff. What happens if rsync is syncing a file and the file changes? If a file has a few bytes added in the middle of the file, does it retransmit the entire second half of the file or just the few bytes added? What kind of losses with DRBD? How long ago? (ie, could they have been bugs that have since been fixed? – Dan Apr 11 '11 at 14:40
rsync does a pretty decent job handling file diffs, and in my experience it will only transmit the few altered bytes which changed. If the file changes during the transfer, I don't think it should affect the sync: the diff is performed at the beginning of the process, so the new changes just aren't synced. As for DRBD: we didn't experience any data loss, but did find that if we lost the sync between the servers it was hard to recover. We were using the most recent version as of December 2010. – ajdecon Apr 11 '11 at 22:08
The trick with rsync is that one end will read the entire file to find changed blocks. You're talking a 10-30GB file. If you are going to do block-level synchronization, you absolutely want a layer that was keeping track of which remote blocks were stale as they were modified. Then a sync begins transmitting data almost instantly. I don't know how efficient DRBD is at this, but many storage vendors specialize in just this facet, even over a WAN, for disaster recovery. – zerolagtime Apr 12 '11 at 3:52
I'm going to test a bit more with rsync but right now it seems to be taking a looooong time to transfer the data... I have a feeling I'm going to end up with DRBD in the end... thanks for the input. – Dan Apr 25 '11 at 18:11
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.