Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, Jul 21, 2015 at 09:27:12AM +0200, Raphaël Jadot wrote: > Hello, > > In my office we were in process of migrating some data that were previously installed on drdb HA (the data was on a qcow2 image, separated from the system, a debian release, also on a qcow2 image) > > The secondary resource was destroyed because of a physical issue on > server, so we had to recover data from primary resource. As the > overall system was not installed by me, and I have only a very basic > knowledge of drbd, we were in process of copying all the data on > another server. Almost all was done, only was missing a database > which we needed to wait the evening to stop, dump and copy. > > I was incredibly unlucky but only a couple of hours before dumping the > database, the metadata of the drbd volume became corrupted. How? > Trying to reattach the resource, here are the outputs > > output is > 1: Failure: (119) No valid meta-data signature found. That can have a lot of reasons. One would be actual corruption (by something, maybe something completely unrelated), which then would likely not be limited to this area. Or something as simple as wrong/unlucky DRBD version. > ==> Use 'drbdadm create-md res' to initialize meta-data area. <== > Command 'drbdsetup 1 disk /dev/vdc /dev/vdc internal --set-defaults --create-device' terminated with exit code 10 > > > system messages are: > [ 3230.620185] block drbd1: Starting worker thread (from drbdsetup [3865]) > [ 3230.620324] block drbd1: disk( Diskless -> Attaching ) > [ 3230.620564] block drbd1: Error while reading metadata, magic not found. > [ 3230.621442] block drbd1: disk( Attaching -> Diskless ) > [ 3230.621502] block drbd1: drbd_bm_resize called with capacity == 0 > [ 3230.621508] block drbd1: worker terminated > [ 3230.621511] block drbd1: Terminating drbd1_worker > > > As I'm totally new in drbd, I may ask a dumb question, but is there a possibility to recover data in this condition, knowing that I have no other mirror on which I could sync? DRBD is "transparent". If all else fails, you can always access the lower level device directly. Do so only if you intend to bypass DRBD, and are prepared to either re-create DRBD meta data completely, or at least do a full sync later. Or, of course, if you intend to "un-deploy" DRBD, and just want to get at the data. In this case, that would be /dev/vdc (maybe double check first that vdc is in fact the correct device). Depending on how exactly your system is set up, and what is supposed to be on that device, you could do something similar to "mount -o ro -t ext4 /dev/vdc /some/mount/point". -- : Lars Ellenberg : http://www.LINBIT.com | Your Way to High Availability : DRBD, Linux-HA and Pacemaker support and consulting DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed