[Rear-users] REAR recovery to changed hardware
gratien.dhaese at it3.be
Mon Mar 23 20:07:08 CET 2009
it is feasible, as I have knowledge of a customer who implemented P2V,
but very customized to his proper environment so that it becomes
unusable for general usage.
Make-Cloning (mkclone): needs all kernel modules copied to the rescue
image, and most likely udevd to handle this modules easily. I would
suggest to have a minimal dhcpcd too. These 2 steps cover the minimal
requirements that the rescue system needs (all disk and network
drivers and DHCP IP address).
Furthermore, the destination system needs to discover automatically
(in cloning-recover mode) the hardware it has on-board (e.g. hwinfo
stuff from SuSe is a good example; but unfortunately that doesn't
exist on RHEL a.o.). Why? To load only the modules it really needs.
The rest is the same as rear recover, except for the last bit we need
to make to new destination system bootable.
Cloning to smaller disks: that is not too easy but doable (did it with
mkCDrec). The partition sizes must be adapted - sounds simple but
becomes tricky sometimes.
You see - the basics are easy. You need to make 2 new workflows:
- cloning (do not want to use the name clone - sounds too funny :)
However, the hwinfo stuff must be generic that works on all platforms
- I've been looking into this a few months ago, but have to trace it
back. Too busy lately to remember older stuff.
On 23 Mar 2009, at 16:37, <Kai-Uwe.Schurig at t-systems.com> wrote:
> we are about to evaluate REAR in a HP-Server environment for desaster
> recovery and maybe also as a P2V solution.
> Backup/Recovery on identical hardware seems to be working fine, I will
> do some further tests an post the results later.
> When we try to restore a REAR backup from a physical machine (e.g.
> HP DL
> 380 G5) to a virtual machine (e.g. a VM in a VMware VI3 environment)
> get a error message like "ERROR: required physical device
> /dev/cciss/c0d0 could not be found".
> This is clear, because the hard disk controller in the vm is a virtual
> LSI logic (mptspi) and not a HP Smart Array (cciss) as in the physical
> Regarding http://rear.sourceforge.net/faqs.php#differentdisk the
> recovery to changed hardware is a planned feature.
> Also there is a statement "As a very crude workaround you can try to
> patch and modify the files in /etc/rear/recovery to suit your new
> hardware layout. If you do it correctly, then recovery will work
> We would like to implement an automatism for this kind of
> that guides the user through this possibly very difficult process."
> Looking at /etc/rear/ I don't see any files which can be patched. I
> seems that the relevant files are in /usr/share/rear, especially in
> recreate directory?
> Can somebody give us a hint what file(s) we have to patch and what
> modifications we should do to make the restore running on the new
> hardware layout?
> A second step is to enable recovery to smaller hard disks, which is
> related to our planned P2V usage.
> We are about to make a decision how to contribute to make the recovery
> to changed hardware working, at least for our test environment (HP
> Server as source and VMWare VI3 VM as destination). We need the
> information to check what effort is necessary to implement this
> If we get this running, we will of course make this information
> available for all other REAR users.
> Thanks and Best Regards,
> Kai-Uwe Schurig
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly
> easily build your RIAs with Flex Builder, the Eclipse(TM)based
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> Rear-users mailing list
> Rear-users at lists.sourceforge.net
More information about the rear-users