#2164 Issue closed: Creating a custom rescue system

Labels: support / question, fixed / solved / done

GreenBlood opened issue at 2019-06-27 10:24:


First of all thanks a lot for rear, it's really a wonderful piece of software !

This issue is not a bug report, more like a generic question.
I'm wondering what would it take to create a custom made rescue image ?
I use rear in a business context as an automated DR system, and I restore the VMs on another environmnent. Right now I managed to modify the base rescue image to adapt options like DHCP, BACKUP_URL and whatnot but for monitoring purposes I think I need a more "complete" operating system acting as the rescue medium.

For example I would need curl to send error notifications to our API, and some scripting intelligence before or after the recovery per se. I can not use the REQUIRED_PROGS directive because I cannot assume that the source VM has the required program(s), and I'm not sure how I would include it manually in the rescue image afterwards.

So I thought the simpler option would be to create manually a rescue image to have more control over the rescue process. I noticed most of the files come from the skel folder so I'm wondering if I "just" have to put those in my custom OS (along with configuration of course) to make it magically a rear rescue system.

Looking forward to answers from you guys.

jsmeix commented at 2019-06-28 06:59:

In contrast to REQUIRED_PROGS programs that are specified in PROGS
get included in the recovery system only when they are available
on the original system where "rear mkrescue/mkbackup" is run.

See usr/share/rear/conf/default.conf (excerpts):

# Program files (as found in PATH) to include in the rescue/recovery system:
# These progs are optional, if they are missing, nothing happens
# Required programs in the rescue/recovery system:
# Same as above, but if they are missing, we abort.

Use COPY_AS_IS to include arbitrary files (that are no programs)
in the rescue/recovery system.

Furthermore all config files (in particular /etc/rear/local.conf)
are sourced and executed as scripts so that you can do any
bash scripting inside your config files, e.g. in /etc/rear/local.conf

# Include curl in the recovery system only when available:
type -P curl && REQUIRED_PROGS+=( curl )

which is basically the same as

# Include curl in the recovery system only when available:
PROGS+=( curl )

or whatever code you need in your particular case.

The precondition is that all files and programs you need in
your rescue/recovery system must exist on the original system
where "rear mkrescue/mkbackup" is run because otherwise
there is no way how ReaR could get them.

When you like to create one same full featured rescue/recovery system
that you can use to recreate various different but similar systems
you need to create that full featured rescue/recovery system
on a sufficiently complete original system.

To recreate different but similar systems with that one same
full featured rescue/recovery system you need to use
RECOVERY_UPDATE_URL, see its description in default.conf
and for background information about the idea behind and
its limitations and how it was finally implemented see
and follow the links therein.

GreenBlood commented at 2019-07-01 08:02:

Thanks for this thorough answer jsmeix,

I think I missed the "PROGS" option when looking through the configuration files.

I'll look into it. Maybe I could put static builds of softwares manually during the recovery programs (or dynamic with LDD like rear does).

I think I'll look more into how rear build the rescue system. The problem I have is that I feel "trapped" into the rescue system, as I'm supposed to automate as much as possible (the rescue and the monitoring) and since the rescue machines run in an Openstack Cloud I thought it would be easier to just use cloud-init to do the work for me.

Thanks again for all this information.

jsmeix commented at 2019-07-01 08:13:

One limitation of RECOVERY_UPDATE_URL is that you
cannot update /etc/rear/local.conf with RECOVERY_UPDATE_URL
because /etc/rearlocal.conf contains the RECOVERY_UPDATE_URL value
so that /etc/rear/local.conf must be read (i.e. sourced by the usr/sbin/rear main script)
before usr/share/rear/init/default/030_update_recovery_system.sh can be run.

If needed usr/share/rear/init/default/030_update_recovery_system.sh could be
enhanced to source /etc/rear/local.conf again but that would require the
/etc/rear/local.conf content "behaves sufficiently idempotent" (cum granu salis).

Regarding "OpenStack Cloud" you may have a look at the mails
OpenStack disaster recovery using ReAR [sic!]
Supporting Relax-and-Recover as a disaster recovery option for OpenStack

jsmeix commented at 2020-06-24 10:44:

I assume the question has been sufficiently answered.

[Export of Github issue for rear/rear.]