[DRBD-user] data integrity in drbd

Dan Barker dbarker at visioncomm.net
Fri Aug 26 20:28:14 CEST 2011

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

Reading between the lines on this thread, I think you have mixed access paths, and now believe that drbd is somehow involved in your troubles.

It is perfectly correct to do what you attempted, IE: Break the mirror, test some process, reestablish the mirror using the original data, and continue on.

Assuming the drbd resource r0 as /dev/drbd0, stored on /dev/sdb1 on nodeA (Primary) and nodeB (Secondary):

This scenario would be accomplished by:

On NodeB:
drbdadm disconnect r0
drbdadm primary r0
mount /somewhere /dev/drbd0

... do your test on nodeB ...

umount /dev/drbd0
drbdadm secondary r0
drbdadm -- --discard-my-data connect r0

and the nodes will sync up to the original data. The main node, nodeA always has the resource as primary, and goes from Connected to WFConnection to SyncSource to Connected. No access to the physical device, /dev/sdb1 is done by any process other than drbd. You never stop drbd on either node.

I'm guessing that at some point you mounted /dev/sdb1 instead of /dev/drbd0 and that is the source of your problems; Updates occurred that drbd did not see. Using the full disk rather than a partition (/dev/sdb instead of /dev/sdb1 in this case) could assist in preventing you from shooting yourself in the foot. But, you can ALWAYS shoot yourself in the foot.

I do not understand your comment "I shut down drbd, try to use rsync to recovery the snapshot, but failed" It sounds like there is a Logical Volume Manager involved, or some other underlying block device that supports snapshots.

Again, drbd can only replicate changes to a block device that occur while drbd is handling that device. The observations above can be applied to any block device. If you expect drbd to be able to handle the block device, it must be the only access to that device; Connected or not, Primary or Secondary. 


Dan Barker

-----Original Message-----
From: drbd-user-bounces at lists.linbit.com [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of Arnold Krille
Sent: Friday, August 26, 2011 2:08 PM
To: drbd-user at lists.linbit.com
Subject: Re: [DRBD-user] data integrity in drbd

On Friday 26 August 2011 19:50:29 you wrote:
> In my situation, what should I do to completely resync the data of 
> secondary node, including the drbd metadata ?

Delete the secondaries disk, create the meta-data anew and make it sync completely from the primary. And if something is still wrong in the files on disk, restore them from the backup...

(And don't ask public questions in private:)

Have a nice weekend,


More information about the drbd-user mailing list