#1220 Issue closed: turn off 30 seconds counter while rear recover

Labels: support / question, fixed / solved / done, external tool, Dedicated Priority Support

RolfWeilen opened issue at 2017-03-06 14:13:

Relax-and-Recover (rear) Issue Template

Please 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.00-git201701271258 / 2017-01-27

Hi
On the rear recover work, on all steps there is an 30 seconds counter. After this time rear goes to the next step. Can i set this counter higher or even turn it off to wait for user action? In my case i don't need to go automatically to the next step.
Regards
Rolf

jsmeix commented at 2017-03-07 10:38:

Not for me.
For me "rear recover" runs fast as lightning.

First and foremost see
https://raw.githubusercontent.com/rear/rear/master/.github/ISSUE_TEMPLATE.md

Furthermore you may have a look at
"Debugging issues with Relax-and-Recover" in
https://en.opensuse.org/SDB:Disaster_Recovery

RolfWeilen commented at 2017-03-07 10:50:

Sorry about missing information.

  • rear version (/usr/sbin/rear -V):
    Relax-and-Recover 2.00-git201701271258 / 2017-01-27

  • OS version (cat /etc/rear/os.conf or lsb_release -a):
    OS_VENDOR=RedHatEnterpriseServer
    OS_VERSION=7

  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
    $ cat /etc/rear/site.conf
    AUTOEXCLUDE_MULTIPATH=N
    OUTPUT=ISO
    #OUTPUT_URL=file:/var/lib/rear/output/
    OUTPUT_URL=null
    ISO_DEFAULT=manuel
    TIMESYNC=NTP
    BACKUP=TSM
    TSM_RESULT_SAVE=n
    TSM_RESULT_FILE_PATH=
    USE_DHCLIENT=y
    USE_STATIC_NETWORKING=n

    Include only rootvg

    ONLY_INCLUDE_VG=(h50l270vg00)

    Add an group Entry

    GRUB_RESCUE=n

  • Are you using legacy BIOS or UEFI boot?
    legacy BIOS

  • Brief description of the issue:

  • Work-around, if any:
    No work arround

jsmeix commented at 2017-03-07 11:16:

I am not a RHEL user but I don't see something
obviously wrong in your /etc/rear/site.conf
except the typo "ISO_DEFAULT=manuel"
which should probably be "ISO_DEFAULT=manual"
but that only affects the recovery system bootloader
and not what happens during "rear recover".

I think you need to do
"Debugging issues with Relax-and-Recover"
https://en.opensuse.org/SDB:Disaster_Recovery
to find out what causes the delays during "rear recover".
The ReaR log file has timestamps so that one should
see where there is a 30 seconds delay.

FYI:
At first glance it seems the functions in
usr/share/rear/lib/bootloader-functions.sh
that work with ISO_DEFAULT are not well
prepared for unsupported ISO_DEFAULT values
because I only find this setting

        # If ISO_DEFAULT is not set, set it to default 'boothd'
        if [ -z "$ISO_DEFAULT" ]; then
                ISO_DEFAULT="boothd"
        fi

but no fallback setting in case of
unsupported ISO_DEFAULT values.

RolfWeilen commented at 2017-03-07 11:33:

Hi

capture

gozora commented at 2017-03-07 11:36:

Hello @RolfWeilen,

Maybe try to set WAIT_SECS=0 in your /etc/rear/local.conf

RolfWeilen commented at 2017-03-07 14:45:

Hi
thanks for the info, but it does not work. If i wait more the 30 sec, rear goes to next step and finaly will start the restore.

add line in /etc/rear/site.conf
WAIT_SECS=0

Enter date/time (YYYY-MM-DD HH:mm:ss) or press ENTER [30 secs]: Skipping Point-In-Time Restore, will restore most recent data.

The TSM Server reports the following for this node:
# Last Incr Date Type File Space Name


1 07-03-2017 13:54:40 XFS /
2 07-03-2017 13:54:05 XFS /app/lib
3 07-03-2017 13:54:40 XFS /boot
4 07-03-2017 13:54:41 UNKNOWN /dev
5 07-03-2017 13:54:40 XFS /home
6 07-03-2017 13:54:41 XFS /usr/local
7 07-03-2017 13:54:44 XFS /var/log
8 07-03-2017 13:54:44 XFS /var/log/suva
Please enter the numbers of the filespaces we should restore.
Pay attention to enter the filesystems in the correct order
(like restore / before /var/log) !
(default: 1 2 3 5 6 7 8): [30 secs] We will now restore the following filesystems:
/
/app/lib
/boot
/home
/usr/local
/var/log
/var/log/suva
Is this selection correct ? (Y|n) [30 secs]

jsmeix commented at 2017-03-07 15:14:

I think I cannot help further here
because I know nothing at all about TSM
(or any other third-party backup solution).

RolfWeilen commented at 2017-03-07 15:53:

Hi
This has nothing to with tsm. I found the code in the scripts.
Set to 0 means 30. I try to increase the value to higher as 30. A value to wait for user interaction does not exist. So i will set the WAIT_SECS=999999.

This value is then used in the needed tsm restore scripts.
./verify/TSM/default/390_request_point_in_time_restore_parameters.sh
./verify/TSM/default/400_verify_tsm.sh

./verify/default/040_validate_variables.sh
if [[ ! -z "$WAIT_SECS" ]]; then
WAIT_SECS=$( is_numeric $WAIT_SECS ) # if 0 then bsize was not numeric
[[ $WAIT_SECS -eq 0 ]] && WAIT_SECS=30
WAIT_SECS=30

RolfWeilen commented at 2017-03-07 16:09:

Hi
Thanks the parameter WAIT_SECS works! No i can wait for 1 year for an user interaction.
TSM restores by default the latest backup data. Alternatively you can specify
a different date and time to enable Point-In-Time Restore. Press ENTER to
use the most recent available backup
Enter date/time (YYYY-MM-DD HH:mm:ss) or press ENTER [31104000 secs]:

Thank you for your help
regards
Rolf

RolfWeilen commented at 2017-03-07 16:14:

Leave a comment


[Export of Github issue for rear/rear.]