[Rear-users] New feature: savelayout and checklayout

Jeroen Hoekx jeroen.hoekx at hamok.be
Fri Dec 17 09:21:32 CET 2010


On 16 December 2010 16:15, Schlomo Schapiro <schlomo at schapiro.org> wrote:

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

This is not something I can do all alone. It's not easy. That's why
I've shown the POC code. This really needs some discussion.

> 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.

I agree that it's important. I know the current layout code does not
handle it well and that it's neigh impossible to do so from a layout

I like your idea, it's easy to implement:
* If the system is identical, use vgcfgrestore

The md code can also be adapted, but I believe we can describe it
completely in the layout file.

> 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
> vgcfgrestore
> 2. if the system is different -> new code with layout file and automatic
> guessing and user verification

It seems better to me to share as much code as possible.

> 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 ...)


I tried this before in my previous effort to resize and believe that
it's not the way to do it. It's just too hard to do it wrong.

Not that it's impossible. The layout code is well suited to
automatically skip raid for example, since it generates all dependency
information. But that adds an additional layer of complexity.

Additionally If a user wants fast restores on different hardware, he
can create an /etc/rear/disklayout.conf file already in the current
branch I posted. If you have a DR site, you probably have a mapping of
systems upfront.

> 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)

Agreed, but that doesn't have to wait for this patch to land :-)

> * 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 :-)

I believe that's a too much rear-centric view of the world :-)

In our setup, Bacula is the center of the universe. The monitoring
system uses checklayout to monitor the disk layout for changes and
gives an alert when it's necessary to include the ReaR tape (or

> * 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.

I've seen some limitations with fixed ordering while implementing DRBD
support. Rearranging is just a stop-gap solution. The real solution is
tracking dependencies.

> 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.

The branch on launchpad is a working copy, but you can easily diff it
to trunk using bzr-svn.

> 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).

In my view, the only place where the new code has to be inferior to
the old is LVM and that's easily fixed by using vgcfgrestore if

Thanks for discussing,


More information about the rear-users mailing list