#159 Issue closed: Using a non-existing backup method fails in recovery (e.g. REQUEST_RESTORE instead of REQUESTRESTORE)¶
Labels: enhancement, documentation
tastle73 opened issue at 2012-09-13 13:30:¶
I'm trying to restore a CentOS 5.8 system using this config:
RESCUE birch:~ # less /etc/rear/local.conf
# sample local configuration
# Create Rear rescue media as ISO image
OUTPUT=ISO
# optionally define (non-default) backup software, e.g. TSM, NBU, DP, BACULA
BACKUP=REQUEST_RESTORE
# the following is required on older VMware VMs
MODULES_LOAD=( vmxnet )
# to see boot messages on the serial console (uncomment next line)
# KERNEL_CMDLINE="console=tty0 console=ttyS1"
The ISO boots fine and the partitions are set up. But at the very end when it looks likes it's going to chroot /mnt/local to install the initrd it crashes like this:
2012-09-13 08:35:25 Including finalize/Fedora/i386/17_rebuild_initramfs.sh
2012-09-13 08:35:25 Original OLD_INITRD_MODULES='scsi_mod dm-message dm-log ata_piix dm-zero ehci-hcd dm-raid45 shpchp dm-mem-cache dm-region_hash sd_mod dm-mirror ext3 uhci-hcd dm-mod ohci-hcd libata megaraid_sas dm-snapshot jbd'
2012-09-13 08:35:25 New INITRD_MODULES='scsi_mod dm-message dm-log ata_piix dm-zero ehci-hcd dm-raid45 shpchp dm-mem-cache dm-region_hash sd_mod dm-mirror ext3 uhci-hcd dm-mod ohci-hcd libata megaraid_sas dm-snapshot jbd sg sr_mod'
chroot: cannot run command `/bin/bash': No such file or directory
2012-09-13 08:35:25 WARNING !!!
initramfs creation failed, please check '/var/log/rear/rear-birch.log' to see the error
messages in detail and decide yourself, wether the system will boot or not.
2012-09-13 08:35:25 Including finalize/Linux-i386/21_install_grub.sh
2012-09-13 08:35:25 Installing GRUB boot loader
2012-09-13 08:35:25 ERROR: Could not find directory /boot/grub
=== Stack trace ===
Trace 0: /bin/rear:245 main
Trace 1: /usr/share/rear/lib/recover-workflow.sh:34 WORKFLOW_recover
Trace 2: /usr/share/rear/lib/framework-functions.sh:79 SourceStage
Trace 3: /usr/share/rear/lib/framework-functions.sh:40 Source
Trace 4: /usr/share/rear/finalize/Linux-i386/21_install_grub.sh:30 source
Trace 5: /usr/share/rear/lib/_input-output-functions.sh:131 StopIfError
Message: Could not find directory /boot/grub
===================
2012-09-13 08:35:25 Running exit tasks.
2012-09-13 08:35:25 Finished in 77 seconds
2012-09-13 08:35:25 Removing build area /tmp/rear.HjthDkoNLxN1921
rmdir: removing directory, /tmp/rear.HjthDkoNLxN1921
If I do a complete backup using rsync to a NAS it's fine.
dagwieers commented at 2012-09-13 15:55:¶
What version of Relax-and-Recover are you using ?
tastle73 commented at 2012-09-13 16:06:¶
root@birch ~]# rpm -q rear
rear-1.13.0-56.git201209050817.el5
dagwieers commented at 2012-09-14 00:30:¶
From the post on the mailing list it was clear that the cause of the
error is the lack of restore when Relax-and-Recover ask you to perform
the (manual) restore. That is what REQUESTRESTORE means.
Can I close this ticket ?
cal-s commented at 2012-09-17 11:04:¶
in docs/03-configuration:
BACKUP=REQUESTRESTORE::
No backup, just ask user to somehow restore the filesystems
The intent is not very clear at all :) in addition to REQUESTRESTORE being misnamed in the doc. Is there somewhere else that this option is described in more detail?
dagwieers commented at 2012-09-17 12:09:¶
I agree the documentation could be improved. Please send a pull-request for documentation improvements.
The most detail is in the scripts itself:
[dag@moria rear]$ find . -name REQUESTRESTORE
./usr/share/rear/restore/REQUESTRESTORE
[dag@moria rear]$ cat ./usr/share/rear/restore/REQUESTRESTORE/default/20_prompt_user_to_start_restore.sh
#
# the user has to do the main part here :-)
#
#
LogPrint "$REQUESTRESTORE_TEXT"
if [[ "$REQUESTRESTORE_COMMAND" ]]; then
LogPrint "Use the following command to restore the backup to your system in '/mnt/local':
$REQUESTRESTORE_COMMAND
"
LogPrint "Please restore your backup in the provided shell, use the shell history to
access the above command and, when finished, type exit in the shell to continue
recovery.
"
rear_shell "Did you restore the backup to /mnt/local ? Are you ready to continue recovery ?" \
"$REQUESTRESTORE_COMMAND"
else
LogPrint "Please restore your backup in the provided shell and, when finished, type exit
in the shell to continue recovery."
rear_shell "Did you restore the backup to /mnt/local ? Are you ready to continue recovery ?"
fi
So REQUESTRESTORE is correctly named in the documentation, and during
recovery the process clearly indicates what is expected from the user.
You can provide a separate message (via REQUESTRESTORE_COMMAND to the
user to hint what the restore command should be. This "backup" method is
in fact a placeholder and the default backup method (lacking any
information to the backup strategy since none was provided in the
configuration).
dagwieers commented at 2012-09-17 12:11:¶
I guess the failure here is that the OP used REQUEST_RESTORE instead
of REQUESTRESTORE and as a result there was no backup method used,
so Relax-and-Recover fails automatically during the chroot bash test...
The irony here is that if the OP would not have selected any backup
method, BACKUP=REQUESTRESTORE would have correctly been the used
configuration.
@cal-s Thanks for noticing !
dagwieers commented at 2012-09-17 12:17:¶
A solution to the above case could be to test whether any recovery
script would be selected for the BACKUP method specified and if there
is no script found an error could be shown to the user that this BACKUP
method has no recovery script. That's the only way we can be sure that
the user made an error.
tastle73 commented at 2012-09-17 13:25:¶
We can help you test this in any way you see fit. We're not using a live system as we are evaluating the product for our use.
On Sep 17, 2012, at 8:17 AM, Dag Wieers notifications@github.com wrote:
A solution to the above case could be to test whether any recovery script would be selected for the BACKUP method specified and if there is no script found an error could be shown to the user that this BACKUP method has no recovery script. That's the only way we can be sure that the user made an error.
—
Reply to this email directly or view it on GitHub.
Tom Astle
RedHat Certified System Administrator
Technical Solutions Tier II
E-Mail: tom@pcc.com
For Support: (800) 722-1082 x2
cal-s commented at 2012-09-17 14:16:¶
Please explain the intent behind the BACKUP variable as set (maybe) in local.conf? I have it set (see below), which allows direct restore from a NETFS location:
BACKUP_URL=nfs://server/xfs/backup/rear/14092012
BACKUP=NETFS
Is "BACKUP=whatever" not even used during mkbackup and only used on restore (i would guess it's put somewhere for restore reference)? When one sets (or not) BACKUP=REQUESTRESTORE, is it left for the user to then: "Please restore your backup in the provided shell", assuming they know where and what said backup was. How would one deal with this? untar the mkbackup tarball/tape to /mnt/local and proceed?
dagwieers commented at 2012-09-17 14:33:¶
The BACKUP method is used during mkbackup. But obviously
BACKUP=REQUESTRESTORE means, we don't manage the backup with
Relax-and-Recover and ask the user to restore using whatever means
necessary. Again, the REQUESTRESTORE_COMMAND may give a hint to what
the restore procedure should be. On the other hand, it is not required.
It all depends on whether you want Relax-and-Recover to take care of the
backup, whether the rescue image should include specific tools and what
the process is to restore. If you know all of this in advance,
REQUESTRESTORE is not for you. If you have any specific needs,
Relax-and-Recover can guide you with those.
Obviously the default for all users is that we don't know anything
about your specific case, so that means: REQUESTRESTORE. We do not do
anything in advance, and you are on your own for restoring the data.
schlomo commented at 2012-09-18 19:20:¶
Honestly, I don't think we need to take care of typos in the
configuration,
or only to a very limited extend.
If we really want to check for non-existant backup methos then each
method
should set a flag in the pre stage so that we can bail out with a
meaningful message later on, if the flag is not set.
IIRC we do something similar for the boot loader already.
dagwieers commented at 2012-09-19 20:19:¶
@schlomo Fair comment.
[Export of Github issue for rear/rear.]