I had the opportunity to work for a customer whose infrastructure is using massively software RAID via md on a SAN storage. Their install base is made of RHEL6 VMs and they wanted to use MondoRescue for their imaging. What else as some could say 
Recent versions of RHEL do use UUIDs everywhere, including to address MD devices in grub configuration, or mdadm ones. That doesn’t make the disaster recovery easier, if you recreate the device from scrtch with a new UUID. So the best approach is to store the information at backup and recreate them with the same UUID they had at restore time. But even if UUIDs on filesystems are supported since quite a long time now, it wasn’t the case for MD devices up to recent SVN revisions. In fact multiple issues were found, trying to make this support work correctly, which were gathered in some existing (and old) MondoRescue trac bugs (#73, #473, #500) or some especially raised at this occasion (#595 and #596).
I have now extended one of my test program to add MD tests as well, and it allowed me to finally solve all the remaining issues linked to this support. Hopefully ! In particular, we now also restore correctly the metadata format of the MD device, in order to be compliant with the boot loaders, as not all of them, or their versions, support all metadata versions. Not clear ? Well try to boot on a md device with the 1.2 version of metadata (created by default with latest mdadm create command) and you’ll rapidly understand
So as you could have guessed, the next step is now to produce a new set of packages in order for you to test As usual they will be available under ftp://ftp.mondorescue.org/test/ where you can pick probably your distribution of choice.
But that’s not all what I’d like to fix for the upcoming 3.0.2. I need to look closely at the bug #600 as we have an issue with the latest MondoRescue version on RHEL 5.x where x is recent as well. After I’ve fixed this one, I think we’ll be good to publish 3.0.2 officially, and start chasing other bugs for the next one
Tags: Linux, Mondorescue, Open Source, RHEL
2012/04/07 at 21:04 |
It is nice to see Mondorescue improve in this regard.
In Relax and Recover the layout configuration stores all UUIDs in order to recreate a complete identical setup (incl. LVM UUIDs, MD UUIDs, swap UUIDs and FS UUIDs) but also labels, extent sizes/block sizes, etc… The layout configuration is well documented and a layout configuration is easy to create on any system by doing: rear savelayout
To make sure Rear recreates a compatible environment, our tools are based on the native distribution so once you restore from the “native” rescue image everything is guaranteed to work with the restored distribution. We prefer this over a generic rescue image that is out of our control as we can include original log-files, layout configuration, backup tools and a complete automatic workflow for restoring that particular system.
I think it would be great to have a workshop to discuss common problems and solutions, the Rear developers are having a few workshops at LinuxTag in Berlin, if you happen to be there we should meet !
2012/04/11 at 00:22 |
I won’t be in Berlin this year for LinuxTag. But I still think that exchanging ideas around DR is an interesting one.
For MondoRescue we also use the native tools, even if I plan to leave the choice in a next version to the end-user. Which could aloow having both capabilities, creating a busybox based/distro based version, or using a Live-CD, giving also offline backup as well (and support then fr other OS directly).
Bruno.
2012/04/25 at 22:23 |
[...] version will fix again some problem met by customers or community users. Among these, as detailed earlier, the crash at restore time that was affecting users of MD software raid volumes, and the fact that [...]