Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Feb 20, 2014 at 06:16:51PM +0100, Lionel Sausin wrote: > Le 20/02/2014 18:08, Wayne a écrit : > >Lionel, > > > >Thanks for the reply. Ok, I think I'll just start with the 'dd' route > >and then do a resize once both systems are upgraded. So how does DRBD > >keep track of the size of the backing device? Is that via the > >/var/lib/drbd/drbd-minor-?.lkbd files? > No idea, sorry - and that means I may just be plain wrong of course... > >I have backups but a resync adds a lot of I/O load to the Primary > >server which is a very busy DB server which is why I'm trying to avoid > >a resync. > Really, the dynamic sync speed is cool, it will only kick in when the > server is not busy. > Of course that may mean very long sync times for you. > >I'll start with the 'dd' method and if that works I'll report my > >findings. > > > >Thanks again, > My pleasure. > Lionel. For those who are interested, using 'dd' did work with one additional step necessary. Note, I'm using DRBD 8.3 right now, not sure if this is different for 8.4. -> drbdadm down $resource - dd the source to the target backing device - adjust drbd.conf to point to the new backing device for $resource - the meta-data needs to be moved so drbd can find it -> drbdmeta $drbd_device v08 $backing_device internal check-resize - drbdadm up $resource Replace $resource, $drbd_device and $backing_device with your local equivalents. The drbd device resync'd only what was necessary and I'm back in business on the new RAID hardware. Wayne