#3094 Issue closed: BACKUP=BACULA: Unattended restore of the Bacula server

Labels: support / question, fixed / solved / done, external tool

ZENAdmin-Ops opened issue at 2023-11-29 00:57:

  • ReaR version ("/usr/sbin/rear -V"): 2.7

  • If your ReaR version is not the current version, explain why you can't upgrade:

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): Debian 11

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

OUTPUT=ISO
OUTPUT_URL=file:///home/zen/debian11-DR6-recovery.iso
#BACKUP=BACULA
#BACULA_CONF_DIR=”/opt/bacula/etc”
#BACULA_BIN_DIR=”/opt/bacula/bin”
#PROGS_BACULA=( bacula-fd bconsole bacula-console bextract bls bscan btape smartctl )
USE_DHCLIENT="No"
USE_STATIC_NETWORKING="Yes"
KERNEL_CMDLINE="ip=10.254.242.85 nm=255.255.255.0 netdev=eth0 gw=10.254.242.1 unattended"
SSH_FILES='yes'
SSH_UNPROTECTED_PRIVATE_KEYS='yes'


BACKUP=BACULA
BEXTRACT_VOLUME=Vol-*
BACULA_CONF_DIR="/opt/bacula/etc"
BACULA_BIN_DIR="/opt/bacula/bin"
COPY_AS_IS_BACULA+=(
/opt/bacula/bin
/opt/bacula/plugins
/opt/bacula/scripts
)

REQUIRED_PROGS+=(
sshfs
)

ISO_DEFAULT="automatic"
ISO_RECOVER_MODE="unattended"
POST_RECOVERY_COMMANDS=(/opt/bacula/scripts/rear/do_restore.sh)
  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR): Hyper-V VM

  • Description of the issue (ideally so that others can reproduce it):

Hello,

I'm trying to perform an automated / unattended restore.

So, ideally the following occurs without any human intervention

  • ISO boots
  • GRUB boots to Relax and Recover without Secure Boot (at the moment I have to choose this myself - 1st boot menu option)
  • login root automatically (working)
  • rear recover automatically (working)
  • run my restore script automatically (not working)

I currently have the script configured in POST_RECOVERY_COMMANDS (clearly this is wrong)

Rear is at the rear shell, just waiting
This is where I need the do_restore.sh to be executed

  • Then reboot, and boot into the restored system (3rd / default boot menu option)

Two questions

  1. Are there options in Rear to control Grub menu, or do I need to investigate configuring Grub myself?
  2. How to automatically run my restore script in the Rear shell

jsmeix commented at 2023-11-29 07:20:

@ZENAdmin-Ops

regarding ISO_DEFAULT="automatic":

This is only when SYSLINUX boots the ISO image on BIOS systems,
see usr/share/rear/conf/default.conf
for ReaR 2.7 online at
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L905

We have GRUB2_DEFAULT_BOOT when GRUB2 is used
to boot the ReaR recovery system, see in default.conf
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L3339

Regarding "run my restore script automatically":

What does your restore script do?
Does it do the whole system recreation from scratich
including storage setup (i.e. disk partitioning,
creating filesystems and mounting them at /mnt/local)
then restoring the backup
and finally installing the bootloader, cf. the section
"Disaster recovery means installation (reinstalling from scratch)" in
https://en.opensuse.org/SDB:Disaster_Recovery
OR
does your restore script only restore the backup?

Because you use

POST_RECOVERY_COMMANDS=(/opt/bacula/scripts/rear/do_restore.sh)

I assume your restore script only restores your Bacula backup.

I am not a BACKUP=BACULA user
so I cannot really help with BACKUP=BACULA specific issues.

Can you explain why you need a selfmade restore script
to restore your Bacula backup?
Or in other words: Can you explain why the current implementation
in ReaR to restore the backup with BACKUP=BACULA
does not work for your needs?
I.e. what does not work or what functionality is missing in
usr/share/rear/restore/BACULA/default/400_restore_backup.sh
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/restore/BACULA/default/400_restore_backup.sh

From plain looking at the code in
restore/BACULA/default/400_restore_backup.sh
it looks as if it behaves rather interactive
so it seems the current BACKUP=BACULA implementation
may not (yet) support unattended restore?
But I could be wrong and misunderstand how
restore/BACULA/default/400_restore_backup.sh
actually works.

ZENAdmin-Ops commented at 2023-11-29 09:28:

Hello,

You're correct, the restore script only restores the backup.

I'm restoring the Bacula server, so I don't have access to the Bacula system to perform the restore, only the Bacula backups.

Seemed easier to write my own script to perform the restore in this scenario, but use Rear to create the volumes and mount etc.

If I were to use a different backup option when building Rear, are there some that provide more automation options, which I could utilise to meet my needs?

Thanks

jsmeix commented at 2023-11-29 11:08:

@ZENAdmin-Ops
because I am not a BACKUP=BACULA user
I cannot try out things on my own
so I would prefer to solve this issue
in two separated steps:

First a manual restore of the Bacula server
with your backup restore script.

When this works the next step is
to get that done in an unattended way.

An offhanded untested proposal
how to manually restore the Bacula server
with your backup restore script:

Because
restore/BACULA/default/400_restore_backup.sh
does not do what you need
you cannot run "rear recover" with BACKUP=BACULA.

To manually restore a backup we have
BACKUP=REQUESTRESTORE
which interrupts "rear recover" after formatting
and mounting the filesystems and expects the backup data
was properly restored to continue "rear recover".
So you have to do something to restore your backup
manually before continuing,
see its description in default.conf
for ReaR 2.7 online at
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L2641

What BACKUP=REQUESTRESTORE does is implemented in
restore/REQUESTRESTORE/default/200_prompt_user_to_start_restore.sh
for ReaR 2.7 online at
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/restore/REQUESTRESTORE/default/200_prompt_user_to_start_restore.sh

So with BACKUP=REQUESTRESTORE
after formatting and mounting the filesystems
you get a ReaR shell (that runs within "rear recover")
where you can run your backup restore script
or you specify your backup restore script as
REQUESTRESTORE_COMMAND
so you have your backup restore script call
available in the command history in that ReaR shell.

To run a script in the ReaR recovery system
you normally must explicitly include
the script plus all what it needs to run
in the ReaR recovery system
usually via

COPY_AS_IS+=( /path/to/script ... )

In your case your backup restore script is
/opt/bacula/scripts/rear/do_restore.sh
and you have

COPY_AS_IS_BACULA+=(
...
/opt/bacula/scripts
)

so /opt/bacula/scripts/rear/do_restore.sh should be
automatically included in the ReaR recovery system.

During "rear mkbackup" you use BACKUP=BACULA
but for "rear recover" you have to change that
to BACKUP=REQUESTRESTORE before you run "rear recover".

So after booting the ReaR recovery system
log in there and first manually replace
BACKUP=BACULA with BACKUP=REQUESTRESTORE
in /etc/rear/local.conf
and then run "rear recover".

ZENAdmin-Ops commented at 2023-11-29 23:16:

@jsmeix

I was able to get this working as I would like

Thanks!


[Export of Github issue for rear/rear.]