[Rear-users] REAR recovery to changed hardware
schlomo at schapiro.org
Mon Mar 23 22:44:19 CET 2009
first of all let me tell you that I am very happy that you are willing to go
into these issues, these are the topics that might carry ReaR to a 2.0 release!
Please do read our concept guide (in %doc or
http://rear.svn.sf.net/viewvc/rear/trunk/usr/share/rear/doc/) to better
understand the ReaR design principles (multi-dimensional framework, workflows ...).
I would like to add some further information to the actual questions:
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.
Did you try out the HP Smart Array recovery (from 1.7.14) ? I would like to get
some more confirmations that it is complete.
> 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) we
> 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 again.
> We would like to implement an automatism for this kind of modifications
> 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 the
> recreate directory?
Sorry, my mistake. I forgot to upload the updated web site after I did 1.7.14,
please check again (/etc/rear/recovery has been moved to /var/...)
> 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.
Look at the files in the recovery subdir, they are somewhat self-explanatory.
You then need to look at /usr/share/rear/recreate and read all the scripts there
to understand how the files in the recovery subdir are actually used.
> 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 feature.
> If we get this running, we will of course make this information
> available for all other REAR users.
The best way to contribute is to read our code and write code that looks similar
and follows similar desing patterns, make sure it works and submit patches. We
will be happy to assist you as much as we can and we prefer you talk to us
before making design decisions rather than writing a large patch which does not
fit the ReaR design.
Feel free to call me at 030-24301-1229 during normal office hours to discuss
technical details or bounce some ideas (we did spend some brain energy on the
questions that need to be solved). For example where in ReaR to place your code...
For cloning and P2V you should also consider the following questions:
- will the source system be running at the same time that you use the rescue
media? If yes, then you have to decide how to prevent IP/hostname conflicts. Or
you define that this is not supported (like now)
- will your data retrieval method (e.g. backup software) handle a changed
hostname in the rescue media? Please note that by default NFS uses the hostname
to determine the subdirectory under the NETFS_URL! Most backup software will
only restore data to the same hostname and requires special parameters to
restore the data to another host.
In general I would suggest you to break the problem into the following sub-projects:
1) get DHCP client into ReaR. Since all distros do that different I would prefer
to have it as distribution-dependant code (with symlinks for identical parts).
There should be a config option wether to use the current IP or DHCP (and - if
you feel like it - some smart code to autodect DHCP usage).
For systems that are configured with DHCP, the DHCP client behaviour of the
rescue system should mirror that of the source system (e.g. set hostname via
DHCP or not). This part might also be postponed to a later development stage if
you first want to concentrate on setting the IP.
2) build VMware P2V support:
- get VMware VM drivers (e1000/pcnet32, mptspi etc.) into rescue media. This
could be achieved by adding it to MODULES_LOAD or by adding a special P2V_VMWARE
parameter that does all kind of specialized setup to optionally enable a restore
under VMware VMs. That would give "rear mkrescue" a dual use option without
deciding upfront on the actual recovery scenario. Great for flexible disaster
- Make sure that the appropriate SCSI device nodes exist on the source system
(or write a mknod script,
mknod is included in ReaR by default)
- Write a script that replaces all /dev/cciss/c?d?p? with /dev/sd? in
/var/lib/rear. For simplicity sake it the correct replacement could be writte
down once manually for up to 8 disks with up to 8 partitions each (or something
like this) if an algorithmic solution is too complex (remember, we use BASH !)
- run many tests till you find everything that I did not think about here :-)
For development/testing you will probably at least once need to tweak it all by
hand. Use ssh to work from a normal desktop (and not the VMware Console) and
remember to copy your results to the restored system before rebooting :-)
3) build disk layout editor
- easier is probably to leave this to the user and offer some kind of script in
an editor that can be manually adjusted.
- cool would be an automatic solution to make a "best guess" and ask the user
for confirmation. Look at mkcdrec for code that can be reused (also BASH :-) )
- as a result you will save a lot of disk space on your VMFS ... :-)
4) add udev to rescue media and take along all modules
- Since this is a lot of MB it should be optional (maybe even enabled by default)
- make sure that it works on SUSE, RHEL (and clones) and Debian
- suffer a lot from the many udev implementations that came with different
distros and kernel 2.6 versions (e.g. test also with SLES9 and Debian 3)
5) add some glue inbetween and you will have to clone and generic P2V feature
ready and we do a 2.0 release and celebrate a lot.
We will be happy to assist you there, please call by phone for details and what
we can do.
PS: In the end it should be /var/lib/rear/recovery for FHS 2.2 compatibility.
Some inbetween versions used /var/rear /recovery and previously it was
/etc/rear/recovery which was not liked by Fedora...
More information about the rear-users