#1838 Issue `closed`: How to interrupt the automatic Rear restore to same hardware and get to Relax-and-Recover shell?¶

Labels: support / question, fixed / solved / done

ccjung opened issue at 2018-06-21 13:39:¶

Relax-and-Recover (ReaR) Issue Template¶

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

ReaR version ("/usr/sbin/rear -V"):Relax-and-Recover 2.1-git.2325.fc6e788.master / 2017-07-16
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):

NAME="SLES"
VERSION="11.4"
VERSION_ID="11.4"
PRETTY_NAME="SUSE Linux Enterprise Server 11 SP4"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:11:4"

ReaR configuration files ("cat /etc/rear/site.conf" or "cat /etc/rear/local.conf"):

# Default is to create Relax-and-Recover rescue media as ISO image
# set OUTPUT to change that
# set BACKUP to activate an automated (backup and) restore of your data
# Possible configuration values can be found in /usr/share/rear/conf/default.conf
#
# This file (local.conf) is intended for manual configuration. For configuration
# through packages and other automated means we recommend creating a new
# file named site.conf next to this file and to leave the local.conf as it is.
# Our packages will never ship with a site.conf.
AUTOEXCLUDE_MULTIPATH=n
BOOT_OVER_SAN=y
REAR_INITRD_COMPRESSION=lzma
OUTPUT=ISO
ISO_MAX_SIZE=4000
BACKUP=NETFS
BACKUP_URL=iso:///iso_fs/REAR_BACKUP
ISO_DIR=/iso_fs/REAR_ISO
TMPDIR=/iso_fs/REAR_TEMP
OUTPUT_URL=null
BOOT_FROM_SAN=y
EXCLUDE_MOUNTPOINTS=( /iso_fs /opt/commvault /opt/IBM/ITM /opt/splunkforwarder /opt/teamquest /var/opt/BESClient /hana/backup /hana/data /hana/log /hana/shared /usr/sap /usr/sap/basis /usr/sap/srm /PA_backup )
EXCLUDE_COMPONENTS=( /dev/mapper/20017380034880032 /dev/mapper/20017380034880033 /dev/mapper/20017380034880034 /dev/mapper/2001738003488003b /dev/mapper/2001738003488003e /dev/mapper/2001738003488003f /dev/mapper/20017380034880040 /dev/mapper/20017380034880041 /dev/mapper/20017380034880042 /dev/mapper/20017380034880043 /dev/mapper/20017380034880044 /dev/mapper/20017380034880045 /dev/mapper/20017380034880046 /dev/mapper/20017380034880047 /dev/mapper/20017380034880048 /dev/mapper/20017380034880049 /dev/mapper/2001738003488004a /dev/mapper/2001738003488004b )

System architecture (x86 compatible or POWER and/or what kind of virtual machine): POWER
Are you using BIOS or UEFI or another way to boot? Use Power HMC SMS
Brief description of the issue:
If we use Rear to restore to the same hardware, the restore is automatic and we do not see the following menu and be able to go the the Relax-and-Recover shell:
View disk layout (disklayout.conf) 4) Go to Relax-and-Recover shell
Edit disk layout (disklayout.conf) 5) Continue recovery
View original disk space usage 6) Abort Relax-and-Recover

For a Disaster Recovery test, we will be restoring to same hardware and want to go to the Relax-and-Recover shell to run addiitonal scripts.

How do we get the option to be able to interrupt the automatic restore to the same hardware and do additonal tasks before continuing with the restore?

Thank you.

Work-around, if any:

jsmeix commented at 2018-06-22 07:21:¶

@suseusr168
you use Relax-and-Recover 2.1-git.2325.fc6e788.master / 2017-07-16
which is too old for what you like to get.

I recommend to use our current ReaR upstream GitHub master code
because that is the only place where we fix bugs - i.e. bugs in older
ReaR versions are not fixed by us (i.e. by ReaR upstream).

To use our current ReaR upstream GitHub master code do the following:

Basically "git clone" it into a separated directory and then
configure and run ReaR from within that directory like:

# git clone https://github.com/rear/rear.git

# mv rear rear.github.master

# cd rear.github.master

# vi etc/rear/local.conf

# usr/sbin/rear -D mkbackup

Note the relative paths "etc/rear/" and "usr/sbin/".

Alternatively use our curent latest ReaR 2.4 release
from one of the "OpenSUSE Build Service packages" at
http://relax-and-recover.org/download/

When you have our current ReaR upstream GitHub master code
or our curent latest ReaR 2.4 release you can do the following:

See the Relax-and-Recover Release Notes 2.4 at
http://relax-and-recover.org/documentation/release-notes-2-4
that read (excerpts):

Version 2.3 (December 2017)
Abstract
...
Improved MIGRATION_MODE autodetection when the disk layout
looks ambiguous. Now ‘rear recover’ switches by default more often
into MIGRATION_MODE where manual disk layout configuration
happens via several user dialogs so that by default ‘rear recover’
shows more often user dialogs compared to before but the
intended behaviour can be enforced via the MIGRATION_MODE
config variable (for details see default.conf).

And our current default.conf
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf
reads (excerpt):

##
# MIGRATION_MODE recovery during "rear recover"
#
# There is some basic autodetection during "rear recover" when
# disks on the replacement hardware seem to not match compared to
# what there was stored in disklayout.conf on the original system.
# If a mismatch is autodetected then ReaR goes into its
# MIGRATION_MODE where manual disk layout configuration happens.
# In this case ReaR asks the user via several user dialogs what to do.
# Only the disk size is used to determine whether or not
# disks on the replacement hardware match the disks on the original system.
# Problems only appear when more than one disk with same size is used.
# Examples:
# When on the original system and on the replacement hardware two disks
# with same size are used the disk devices may get interchanged
# so that what there was on /dev/sda on the original system may get
# recreated on /dev/sdb on the replacement hardware and vice versa.
# When on the original system one disk is used for the system and
# another disk with same size for the ReaR recovery system and backup
# the disk devices may get interchanged on the replacement hardware
# so that "rear recover" could result an ultimate disaster
# (instead of a recovery from a disaster) if it recreated the system
# on the disk where the ReaR recovery system and backup is
# which would overwrite/destroy the backup via parted and mkfs
# (cf. https://github.com/rear/rear/issues/1271).
# Therefore to be on the safe side and to avoid such problems
# ReaR goes by default automatically into its MIGRATION_MODE
# when more than one disk with same size is used on the original system
# or when for one of the used disk sizes on the original system
# more than one disk with same size is found on the replacement hardware
# i.e. when there is more than one possible target disk.
# Accordingly ReaR goes by default not into its MIGRATION_MODE
# only if for each used disk size on the original system eaxctly one
# possible target disk with same size is found on the replacement hardware.
# By setting MIGRATION_MODE='true' one can enfore MIGRATION_MODE.
# The by-default empty MIGRATION_MODE results that MIGRATION_MODE
# is set via the above described autodetection during "rear recover".
# MIGRATION_MODE is set to a default value here only
# if not already set so that the user can set it also via
#   export MIGRATION_MODE='true'
# directly before he calls "rear recover":
test "$MIGRATION_MODE" || MIGRATION_MODE=''

I.e. to enforce the MIGRATION_MODE dialogs
when the replacement disk has same size call
export MIGRATION_MODE='true'
before you call rear recover.

Furthermore in our current ReaR upstream GitHub master code
or our curent latest ReaR 2.4 release there is in any case a
user confirmation dialog (with 30 seconds timeout) where
one can in any case interrupt the automatic proceeding restore
when the replacement disk has same size, see
https://github.com/rear/rear/issues/1271#issuecomment-346633365

Finally in our current ReaR upstream GitHub master code
or our curent latest ReaR 2.4 release there is in MIGRATION_MODE
an additional user confirmation dialog after the backup was restored
so that the user can - if needed - adjust certain things, see
https://github.com/rear/rear/pull/1758
for some details and the reasoning behind.

jsmeix commented at 2018-06-22 12:12:¶

@suseusr168
FYI
how that user confirmation dialog looks like that appears
in any case also when the replacement disk has same size
on one of my test systems (SLES15 on KVM/QEMU virtual machine)

RESCUE d228:~ # rear -D recover
...
Comparing disks
Device sda has expected (same) size 21474836480 (will be used for recovery)
Disk configuration looks identical
UserInput -I DISK_LAYOUT_PROCEED_RECOVERY needed in /usr/share/rear/layout/prepare/default/250_compare_disks.sh line 146
Proceed with recovery (yes) otherwise manual disk layout configuration is enforced
(default 'yes' timeout 30 seconds)

UserInput: No real user input (empty or only spaces) - using default input
UserInput: No choices - result is 'yes'
User confirmed to proceed with recovery

and how it looks when that dialog is not confirmed
i.e. when a false value like n is entered (excerpt):

Comparing disks
Device sda has expected (same) size 21474836480 (will be used for recovery)
Disk configuration looks identical
UserInput -I DISK_LAYOUT_PROCEED_RECOVERY needed in /usr/share/rear/layout/prepare/default/250_compare_disks.sh line 146
Proceed with recovery (yes) otherwise manual disk layout configuration is enforced
(default 'yes' timeout 30 seconds)
n
UserInput: No choices - result is 'n'
User enforced manual disk layout configuration
Using /dev/sda (same name and same size) for recreating /dev/sda
Current disk mapping table (source -> target):
    /dev/sda /dev/sda
UserInput -I LAYOUT_MIGRATION_CONFIRM_MAPPINGS needed in /usr/share/rear/layout/prepare/default/300_map_disks.sh line 211
Confirm or edit the disk mapping
1) Confirm disk mapping and continue 'rear recover'
2) Edit disk mapping (/var/lib/rear/layout/disk_mappings)
3) Use Relax-and-Recover shell and return back to here
4) Abort 'rear recover'
(default '1' timeout 300 seconds)

versus how it looks with export MIGRATION_MODE='true' before rear recover

RESCUE d228:~ # export MIGRATION_MODE='true'

RESCUE d228:~ # rear -D recover
...
Enforced manual disk layout configuration (MIGRATION_MODE is 'true')
Using /dev/sda (same name and same size) for recreating /dev/sda
Current disk mapping table (source -> target):
    /dev/sda /dev/sda
UserInput -I LAYOUT_MIGRATION_CONFIRM_MAPPINGS needed in /usr/share/rear/layout/prepare/default/300_map_disks.sh line 211
Confirm or edit the disk mapping
1) Confirm disk mapping and continue 'rear recover'
2) Edit disk mapping (/var/lib/rear/layout/disk_mappings)
3) Use Relax-and-Recover shell and return back to here
4) Abort 'rear recover'
(default '1' timeout 300 seconds)

ccjung commented at 2018-06-22 14:48:¶

@jsmeix ,
Setting the variable export MIGRATION_MODE='true' worked!

After the restore, we saw the RESCUE prompt and was able to run our DR script.

We will download Rear 2.4 and test it out.

Thank you for your prompt response and your help!

jsmeix commented at 2018-06-25 08:19:¶

@suseusr168
thanks for your explicit positive feedback!
It helps a lot to get explicit feedback that things work as intended
and that there is not another possibly still unknown issue in ReaR.

[Export of Github issue for rear/rear.]

#1838 Issue closed: How to interrupt the automatic Rear restore to same hardware and get to Relax-and-Recover shell?¶