[DRBD-user] Local Asynchronous Replication

Nick Couchman Nick.Couchman at seakr.com
Mon Jan 24 16:08:09 CET 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

> Hi,
> what level of asynchrony do you need? And (out of curiosity) why?
> Cheers,
> Felix

I'll tell you what I'm trying to do, and maybe that will answer both
questions.  I'm trying to roll my own disk-based backup solution.
Basically, I'll have a Solaris-based system using ZFS to serve volumes
out to the systems that I want to back up over iSCSI.  This way I can
use the ZFS snapshot management capabilities to snapshot the volumes at
various points in time, and use the clone capability to represent that
volume somewhere in the event that I need a restore done.  Also, because
ZFS supports remote send/receive out of the box, it gives me a way to
send those backups off-site very easily for DR purposes.

On the servers I'm trying to back up, I need some form of asynchronous
replication.  These systems will connect over iSCSI to the ZFS system in
order to replicate the volumes.  The reason for the asynchronous
requirements is because I need to make sure that the replication of the
data to the secondary (iSCSI ZFS) disk does not block I/O for the
primary volume - I don't want the fact that I'm replicating the data to
interfere with performance of the volume.  A second concern is that I
need to make sure that all I/O operations are actually being done to the
primary storage on each of those systems and not to the secondary iSCSI
volume, again, mostly for performance reasons.  Finally, I want to be
able to shut down the ZFS backup system and the iSCSI links without
worrying about the system going into any kind of degraded state - it
needs to be able to pick the synchronization right back up when it comes
back up.

The built-in Linux RAID1 driver offers the ability to mark a volume in a
RAID1 set as "write mostly", which takes care of most of the concern for
having I/O operations occur on the primary device, but does not
necessarily insure that write operations will not be blocked by Linux
waiting on them to occur on both volumes.


This e-mail may contain confidential and privileged material for the sole use of the intended recipient.  If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information.  In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way.  If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox.  Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

More information about the drbd-user mailing list