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

Cal Sawyer cal-s at blue-bolt.com
Tue Jul 24 15:44:42 CEST 2012


The good news is that i finally succeeded in recovering the mdadm system
to a VM.  diskrestore.sh threw some weird partition-size values which
resulted in ReaR lacking the disk space to complete the recovery run. 
More on that in a new thread, maybe.

On 24/07/12 13:51, Les Mikesell wrote:
> On Tue, Jul 24, 2012 at 4:23 AM, Johannes Meixner <jsmeix at suse.de> wrote:
>>> In addition, /mnt/local/etc/fstab is an exact copy of the
>>> original, so booting the restored machine will fail
> [...]
>> Perhaps your etc/fstab comes from the backup restore?
>> For example /etc/fstab from backup.tar.gz may contain additional
>> entries (e.g. manually added entries) which may not be automatically
>> recreated by "rear recover". Therefore I think it is recommended
>> to have /etc/fstab in the backup and exclude it only if needed
>> when the backup is restored.
>>
Definitely - prefer a restored fstab which retains system-specific settings

>> I think a good default for such a functionality could become
>> in particular tricky for the various external backup methods.
> You may also have to change the grub configuration and possibly build
> a new initrd.   It think it would be nice to have an option to have
> the restore script chroot into the mounted system after the restore is
> complete and prompt you through the likely steps - even if it doesn't
> know how to make the correct changes itself.   And to be able to
> reboot back to that point (the chroot environment) from the iso
> without a lot of extra steps if the first boot attempt fails.
grub.conf is created from the original, retaining "root=/dev/mdX".  ReaR
did, however, rebuild initrd, which was good to see.

In my post-recovery  scenario, these files needed immediate hands-on
attention:

[/usr/local//boot/grub/grub.conf
[usr/local]/etc/fstab

Also disabled mdmonitor and moved mdadm.conf out of the way to stop
CentOS from complaining about nothing - all outside of the remit of ReaR
(maybe - see sysprep below?).  I realise that mdadm->sdX conversion
poses a number of problems for automated reconfiguration that may be
insurmountable without some/a_lot_of user interactivity, further
complicated by the diverse Linuxes supported by ReaR (and completely
ignoring LVM on top of that)

I agree - a post-recovery script wojuld make alot of sense. 
Alternately, "rear sysprep" anyone?  The idea being that a preparatory
guided configuration run could assist with crating persistent
device-restore decisions which would permit reliable unattended
ReaR-mkbackup of a source server with the knowledge that the archive
will import smoothly onto some user-defined target with a minmum of
admin intervention.



Q: Can mappngs/disk_devices describe md->sd?  How would you define
/dev/md, which doesn't exist in nature. mappings seems to be used
(exclusively?) for HP cciss<->sd conversion.  Can mappings describe
partitions instead of disks?

-- 
Cal Sawyer | Systems Engineer
BlueBolt Ltd, London



More information about the rear-users mailing list