[Rear-users] New feature: savelayout and checklayout

Schlomo Schapiro schlomo at schapiro.org
Thu Dec 16 16:15:23 CET 2010


Am 16.12.2010 15:51, schrieb Jeroen Hoekx:
> On 16 December 2010 13:10, Schlomo Schapiro <schlomo at schapiro.org> wrote:
>> Maybe in the future we can merge these two areas so that the checklayout
>> relies on the data in the recovery area, thus making extra savelayout
>> runs unnecessary.
> I'd rather see it happen the other way around :-)

Sure, please submit a well-tested (on the major distros!) patch.

> This happened last week:
> - Dag fixes bug SF#3132182 wrt Smart Array controllers
> - The next rescue system is our first one to include working hpacucli code
> - The smart array controller recreates the arrays
> - The restore fails because reported disk sizes in the new system are
> different from those taken just a few minutes earlier (smaller,
> presumably, the controller is smart about bad blocks?)

Yeah, that really really sucks.

> I think it's critical to have more control about the disk layout
> during the restore phase.

Yes, it is the missing link to complete the P2V feature. Adapt the disk
layout to the new hardware.

> This week, I hadn't got much else to do and so I've started working on
> it. It's not quite finished yet, but apart from file system
> attributes, it can already restore a system. If it detects the system
> is identical, no user interaction is necessary (apart from DRBD
> primary/secondary :-), otherwise it prompts to check the layout file,
> creates a dependency list and generates code to restore the layout. A
> final prompt asks the user to confirm this file.

Sounds great. So far ReaR has had a very high success rate with system
recovery of even "strange" systems because we use vgcfgrestore to
recreate the LVM environment. This will also restore advanced LVM
features which are totally lost in the current level of detail of the
layout description. Some work went into advanced MD features because
users had troubles with restoring their MD setups exactly as it was.

Personally I find that this aspect of ReaR (very high level of trust in
system recreation) is an important part of ReaR. I have doubts that we
could achieve the current level of "guaranteed recreation" with a simple
layout file.

> I know It's a major change, but perhaps you're interested in it and
> see a way to move things further.
> For code: https://code.launchpad.net/~jeroen-hoekx/+junk/rear-layout

I think we would be very interested to enable ReaR to have several
recovery strategies:
1. if the system is precisely like the original -> current code with
2. if the system is different -> new code with layout file and automatic
guessing and user verification
3. if the system is slightly different -> new code with layout file,
automatic guessing and no user verification (e.g. disk sized slightly
different due to new model, new RAID ...)

The user should be informed that the layout-based code can handle only
simple LVM setups.

Would you mind building a patch for that? I would also be happy to see
the following changes to be part of that:
* savelayout functionality part of dr stage (and thus called for each
mkrescue/mkbackup run)
* savelayout workflow is IMHO not really required any more because one
MUST create a new rescue media if the layout changed. checklayout could
be converted into an option of mkrescue like this (and this would make
the cron jobs even simpler):
** rear mkrescue --quick (and keep the ISO somewhere and give the old
ISO to the user if the layout did not change)
** rear mkrescue --onlyifchanged (and do nothing if the layout did not
change, but how to report to the user that it is not an error that we
did not produce a new ISO?)
** The code to pass args into the workflow is already there :-)
* verify stage should decide if old or new code is used
* verify stage should ask the user to approve the new layout (if
approval is necessary)
* recreate stage should recreate stuff with old or new code (IMHO this
could be put into each script with an if $LAYOUT then ; new code ; else
old code ; fi clause). Please rearrange the scripts in recreate stage if
you believe they need to be rearranged.

A patch like that would be most welcome. If you want to send me a
working copy instead of a diff (to better track major changes and
renames) this can be also arranged.

If we see that the new code performs as well as the old code we could
then switch the defaults or maybe fall-back to the old code for complex
LVM setups that the new code cannot handle (yet).

What do you think?

Kind Regards,

More information about the rear-users mailing list