[rear-users] Restoring mdadm system to a single-disk destination fails

Cal Sawyer cal-s at blue-bolt.com
Thu Jul 26 16:23:38 CEST 2012


After ReaR'ing 3 mdraid CentOS5 servers over the past couple of days,
i've found the following issues, all of which i resolved through manual
intervention:

- fstab and grub.conf are not modified by ReaR when source disk was mdraid
- Created disk partitions are not labelled

As Les asked, is that not the intent in the third term in the fs section
of disklayout.conf?  /USR/recreate/GNU/Linux/31_create_filesystems.sh
wants to label in mkfs but doesn't seem to be picking up what it needs. 

Not sure how others feel about it, but creating fstab using disklabels
instead of device names would be very good.

My restore disklayout with extended partitions, in case anyone's interested:

    disk /dev/sda 96636764160 msdos
    part /dev/sda 106896384 32256 primary boot,none /dev/sda1
    part /dev/sda 2097446400 106928640 primary none /dev/sda2
    part /dev/sda 4721310720 2204375040 primary none /dev/sda3
    part /dev/sda 1024 6925685760 extended none /dev/sda4       
    part /dev/sda 20480000000 6925718016 logical none /dev/sda5
    part /dev/sda 96636764160 29453718016 logical none /dev/sda6
    fs /dev/sda1 /boot ext2 uuid=996f046e-7da7-4c7e-8c70-1c1cdfc16037
    label= blocksize=1024 reserved_blocks=5% max_mounts=27
    check_interval=180d bytes_per_inode=4092 options=rw
    fs /dev/sda3 / ext3 uuid=dbae2ba6-8cf2-40e8-81a7-980fbe82368c label=
    blocksize=4096 reserved_blocks=5% max_mounts=-1 check_interval=0d
    bytes_per_inode=4094 options=rw
    fs /dev/sda5 /disk1 ext3 uuid=839110ee-209e-4f2c-8fbe-09eb41bba0e0
    label= blocksize=4096 reserved_blocks=4% max_mounts=36
    check_interval=180d bytes_per_inode=8182 options=rw,usrquota,grpquota
    fs /dev/sda6 /disk2 ext3 uuid=62ba501e-6979-41bc-ace4-708a0fc268f8
    label= blocksize=4096 reserved_blocks=4% max_mounts=24
    check_interval=180d bytes_per_inode=8182 options=rw
    swap /dev/sda2 uuid= label=swap

edited from ReaR's disklayout:

    #disk /dev/hda 4294965248
    disk /dev/sda 146815733760 msdos
    part /dev/sda 106896384 32256 primary boot,raid /dev/sda1
    part /dev/sda 2097446400 106928640 primary raid /dev/sda2
    part /dev/sda 4721310720 2204375040 primary raid /dev/sda3
    part /dev/sda 1024 6925685760 extended none /dev/sda4
    part /dev/sda 40007729664 6925718016 logical raid /dev/sda5
    part /dev/sda 99879542784 46933479936 logical raid /dev/sda6
    disk /dev/sdb 300000000000 msdos
    part /dev/sdb 106896384 32256 primary boot,raid /dev/sdb1
    part /dev/sdb 2097446400 106928640 primary raid /dev/sdb2
    part /dev/sdb 4721310720 2204375040 primary raid /dev/sdb3
    part /dev/sdb 1024 6925685760 extended none /dev/sdb4
    part /dev/sdb 40007729664 6925718016 logical raid /dev/sdb5
    part /dev/sdb 99879542784 46933479936 logical raid /dev/sdb6
    raid /dev/md2 level=raid1 raid-devices=2
    uuid=d69ca2f1:f46a0206:ecd88681:7e3901f1 devices=/dev/sdb3,/dev/sda3
    raid /dev/md4 level=raid1 raid-devices=2
    uuid=582f2ff9:f8135a7c:f539d2d2:cdee3e58 devices=/dev/sdb6,/dev/sda6
    raid /dev/md3 level=raid1 raid-devices=2
    uuid=0ac78da5:d4b36b75:6c31287a:051b7bae devices=/dev/sdb5,/dev/sda5
    raid /dev/md1 level=raid1 raid-devices=2
    uuid=fcf86398:eae7b203:7331e048:50419f1d devices=/dev/sdb2,/dev/sda2
    raid /dev/md0 level=raid1 raid-devices=2
    uuid=a4b6772b:ba38a766:659f832c:5681e404 devices=/dev/sdb1,/dev/sda1
    fs /dev/md2 / ext3 uuid=dbae2ba6-8cf2-40e8-81a7-980fbe82368c label=
    blocksize=4096 reserved_blocks=5% max_mounts=-1 check_interval=0d
    bytes_per_inode=4094 optio
    ns=rw
    fs /dev/md0 /boot ext2 uuid=996f046e-7da7-4c7e-8c70-1c1cdfc16037
    label= blocksize=1024 reserved_blocks=5% max_mounts=27
    check_interval=180d bytes_per_inode=4092
     options=rw
    fs /dev/md3 /disk1 ext3 uuid=839110ee-209e-4f2c-8fbe-09eb41bba0e0
    label= blocksize=4096 reserved_blocks=4% max_mounts=36
    check_interval=180d bytes_per_inode=818
    2 options=rw,usrquota,grpquota
    fs /dev/md4 /disk2 ext3 uuid=62ba501e-6979-41bc-ace4-708a0fc268f8
    label= blocksize=4096 reserved_blocks=4% max_mounts=24
    check_interval=180d bytes_per_inode=818
    2 options=rw
    swap /dev/md1 uuid= label=

If, prior to editing disklayout.conf, i get the destination disk size
via fdisk and use it in disklayout.conf, ReaR no longer tries to mess
around with partition sizes and respects (for better or worse) what i
set out in disklayout,conf - i never saw the check-diskrestore.sh step. 
When i didn't, all bets were off.  I think a method of disabling resize
entirely would be very useful.

Also, neither disklayout.conf or diskrestore.sh is preserved for future
reference - this would be really handy

And, well outside of ReaR's remit, i would suppose: mdmonitor is active
on boot, so the restored system tries to identify and start non-existent
array sets.  After disabling mdmonitor, I still find that i need to
supply "noresume" on the grub boot line to keep boot quiet about RAID
cheers,

regards,

- cal sawyer


On 26/07/12 14:04, Les Mikesell wrote:
> On Thu, Jul 26, 2012 at 2:26 AM, Dag Wieers <dag at wieers.com> wrote:
>>>>> 2) a reminder that /etc/fstab and grub.conf needed to be fixed
>>>> As I already explained, we already fix /etc/fstab and grub.conf. It may
>>>> not be sufficient, but that we don't know.
>>> Is that in a released version?   The current epel package won't change
>>> md device references to sd? when you change the layout to not use
>>> software raid.
>> It does this for other cases, and we would like to also make it support
>> the md -> sd case. That's why I said that "it may not be sufficient" for
>> your case.
>>
> In this case, looking at the fs entries in the modified
> disklayout.conf would tell you that fstab and grub's root= entries are
> pointing to the wrong places.   I'd think that should be at least a
> sanity check with a warning that the machine isn't going to boot - or
> maybe show the needed substitutions and offer to do them.  In any
> case, I'm looking more for user-friendliness in handling the failed
> reboot scenario where you have to reboot from the iso and fix
> something manually than perfection in handling automatic conversions.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pikachu.3ti.be/pipermail/rear-users/attachments/20120726/732ad1b7/attachment.html 


More information about the rear-users mailing list