[rear-users] Restoring mdadm system to a single-disk destination fails
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
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
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