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