#2164 Issue `closed`: Creating a custom rescue system¶

Labels: support / question, fixed / solved / done

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

Hi,

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
PROGS=( )
#
# Required programs in the rescue/recovery system:
# Same as above, but if they are missing, we abort.
REQUIRED_PROGS=( ...

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
https://github.com/rear/rear/issues/841
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!]
at
http://lists.relax-and-recover.org/pipermail/rear-devel/2019-June/thread.html
and
Supporting Relax-and-Recover as a disaster recovery option for OpenStack
at
http://lists.relax-and-recover.org/pipermail/rear-devel/2019-April/thread.html

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

I assume the question has been sufficiently answered.

[Export of Github issue for rear/rear.]