"Fossies" - the Fresh Open Source Software Archive

Member "rear-2.5/doc/user-guide/10-integrating-external-backup.adoc" (10 May 2019, 5122 Bytes) of package /linux/privat/rear-2.5.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format (assuming AsciiDoc format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field.

Relax-and-Recover can be used only to restore the disk layout of your system and boot loader. However, that means you are responsible for taking backups. And, more important, to restore these before you reboot recovered system.

However, we have successfully already integrated external backup programs within ReaR, such as Netbackup, EMC NetWorker, Tivoli Storage Manager, Data Protetctor to name a few commercial backup programs. Furthermore, open source external backup programs which are also working with ReaR are Bacula, Bareos, Duplicity and Borg to name the most known ones.

Ah, my backup program which is the best of course, is not yet integrated within ReaR. How shall we proceed to make your backup program working with ReaR? This is a step by step approach.

The work-flow mkrescue is the only needed as mkbackup will not create any backup as it is done outside ReaR anyhow. Very important to know.

Think before coding

Well, what does this mean? Is my backup program capable of making full backups of my root disks, including ACLs? And, as usual, did we test a restore of a complete system already? Can we do a restore via the command line, or do we need a graphical user interface to make this happen? If the CLI approach is working then this would be the preferred manor for ReaR. If on the other hand only GUI approach is possible, then can you initiate a push from the media server instead of the pull method (which we could program within ReaR)?

So, most imprtant things to remember here are:

  • CLI - preferred method (and far the easiest one to integrate within ReaR) - pull method

  • GUI - as ReaR has no X Windows available (only command line) we cannot use the GUI within ReaR, however, GUI is still possible from another system (media server or backup server) and push out the restore to the recovered system. This method is similar to the REQUESTRESTORE BACKUP method.

What does ReaR need to have on board before we can initiate a restore from your backup program?

  • the executables (and libraries) from your backup program (only client related)

  • configuration files required by above executables?

  • most likely you need the manuals a bit to gather some background information of your backup program around its minimum requirements

Steal code from previous backup integrations

Do not make your life too difficult by re-invented the wheel. Have a look at existing integrations. How?

Start with the default configuration file of ReaR:

$ cd /usr/share/rear/conf
$ grep -r NBU *
default.conf:# BACKUP=NBU stuff (Symantec/Veritas NetBackup)
default.conf:COPY_AS_IS_NBU=( /usr/openv/bin/vnetd /usr/openv/bin/vopied /usr/openv/lib /usr/openv/netbackup /usr/openv/var/auth/[mn]*.txt )
default.conf:COPY_AS_IS_EXCLUDE_NBU=( "/usr/openv/netbackup/logs/*" "/usr/openv/netbackup/bin/bpjava*" "/usr/openv/netbackup/bin/xbp" )
default.conf:PROGS_NBU=( )

What does this learn you?

  • you need to define a backup method name, e.g. BACKUP=NBU (must be unique within ReaR!)

  • define some new variables to automatically copy executables into the ReaR rescue image, and one to exclude stuff which is not required by the recovery (this means you have to play with it and fine-tune it)

  • finally, define a place holder array for your backup programs (is empty to start with).

Now, you have defined a new BACKUP scheme name, right? As an example take the name BURP (http://burp.grke.org/).

Define in /usr/share/rear/conf/default:

# BACKUP=BURP section (Burp program stuff)

Of course, the tricky part is what should above arrays contain? That you should already know as that was part of the first task (Think before coding).

This is only the start of learning what others have done before:

$ cd /usr/share/rear
$ find . -name NBU

What does this mean? Well, these are directories created for Netbackup and beneath these directories are scripts that will be included during the mkrescue and recover work-flows.

Again, think burp, and you probably also need these directories to be created:

$ mkdir --mode=755 /usr/share/rear/{finalize,prep,rescue,restore,verify}/BURP

Another easy trick is to look at the existing scripts of NBU (as a starter):

$ sudo rear -s mkrescue | grep NBU
Source prep/NBU/default/400_prep_nbu.sh
Source prep/NBU/default/450_check_nbu_client_configured.sh
Source rescue/NBU/default/450_prepare_netbackup.sh
Source rescue/NBU/default/450_prepare_xinetd.sh
$ sudo rear -s recover | grep NBU
Source verify/NBU/default/380_request_client_destination.sh
Source verify/NBU/default/390_request_point_in_time_restore_parameters.sh
Source verify/NBU/default/400_verify_nbu.sh
Source restore/NBU/default/300_create_nbu_restore_fs_list.sh
Source restore/NBU/default/400_restore_with_nbu.sh
Source finalize/NBU/default/990_copy_bplogrestorelog.sh