#1692 Issue `closed`: Bareos-fd does not start.¶

Labels: fixed / solved / done, minor bug, external tool

StarT3 opened issue at 2018-01-11 23:28:¶

Relax-and-Recover 2.3 / 2017-12-20
Got it from
sh -c "echo 'deb http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/xUbuntu_14.04/ /' > /etc/apt/sources.list.d/rear.list" & apt-get install rear
Ubuntu 14.04.4 LTS
config :

OS_VENDOR=Ubuntu
OS_VERSION=14.04
BACKUP=BAREOS
OUTPUT=ISO
BAREOS_CLIENT="vm544617-fd"
OUTPUT_URL=nfs://"some ip here"/bareos

* Are you using legacy BIOS or UEFI boot? Not sure, vm on hyper-v, should be BIOS as Ubuntu 14 does not support Gen2 VM under Hyper-v.

Brief description of the issue:
"rear recover" stuck at "Waiting for job to start" forever because of bareos-fd start failure. In my case Bareos-fd configuration "myself.conf" points to plugin directory "Plugin Directory = /usr/lib64/bareos/plugins". As there were no such directory in RESCUE environment, bareos-fd did not start. Bareos director had errors:
Fatal error: bsock_tcp.c:134 Unable to connect to Client: vm544617-fd
It is common for bareos config to define plugin directory. I use default bpipe plugin to get mysql backup.
Work-around, if any:
Comment "Plugin Directory = /usr/lib64/bareos/plugins" either on original host before mkrescue or in RESCUE environment and run bareos-fd manually.
nano /etc/bareos/bareos.d/client/myself.conf

gdha commented at 2018-01-12 07:50:¶

@StarT3 Could you show us what the content is of your myself.conf and what does that plugin directory contain? Would it be sufficient to add it into the COPY_AS_IS array?

jsmeix commented at 2018-01-12 10:52:¶

@StarT3

some general info FYI:

By default the ReaR recovery system is minimal which means
that things which are not mandatory might be not automatically
included in the ReaR recovery system.

You can specify anything what you need in addition
to what is automatically included in the ReaR recovery
system via the config variables

COPY_AS_IS
REQUIRED_PROGS
LIBS
MODULES
MODULES_LOAD
FIRMWARE_FILES

In your particular case it may work to specify
in your /etc/rear/local.conf something like

COPY_AS_IS=( "${COPY_AS_IS[@]}" /usr/lib64/bareos/plugins )

Furthermore if you need special commands to be run in the
ReaR recovery system (e.g. launching a special service)
you can specify that via config variables like

PRE_RECOVERY_SCRIPT
NETWORKING_PREPARATION_COMMANDS

In your particular case it may also work to automate
commenting "Plugin Directory = /usr/lib64/bareos/plugins"
in your Bareos-fd configuration myself.conf via an
appropriate command (e.g. a 'sed' command)
that gets run as PRE_RECOVERY_SCRIPT.

For more info about each of the various config variables
see usr/share/rear/conf/default.conf

If things like commenting "Plugin Directory"
or having /usr/lib64/bareos/plugins in the
recovery system are mandatory for Bareos
such things could be added to the ReaR scripts
to enhance the default Bareos support in ReaR.

But I am not a Bareos user so that I cannot reproduce anything
or even fix anything that is specific for Bareos.

In general regarding third-party backup tools and ReaR see
"Relax-and-Recover versus backup and restore" at
https://en.opensuse.org/SDB:Disaster_Recovery

StarT3 commented at 2018-01-12 23:14:¶

Thank you for support.
Here is full content of /etc/bareos/bareos-fd.d/client/myself.conf

Client {
  Name = vm544617-fd
  Maximum Concurrent Jobs = 20
  Heartbeat Interval = 60

  # remove comment from "Plugin Directory" to load plugins from specified directory.
  # if "Plugin Names" is defined, only the specified plugins will be loaded,
  # otherwise all storage plugins (*-fd.so) from the "Plugin Directory".
  #
  Plugin Directory = /usr/lib/bareos/plugins
  # Plugin Names = ""

  # if compatible is set to yes, we are compatible with bacula
  # if set to no, new bareos features are enabled which is the default
  # compatible = yes
}

I believe such config is common for small web servers with light mysql databases.
COPY_AS_IS is not really necessary, bpipe plugin used to backup/restore databases typically is in separate job and should be run after whole server restored and running (mysql software should be running at that time).

PRE_RECOVERY_SCRIPT should do the trick. It should comment line in myself.config, and start bareos-fd. Currently testing:
PRE_RECOVERY_SCRIPT=("sed -e '/Plugin Directory = / s/^#*/#/' -i /etc/bareos/bareos-fd.d/client/myself.conf" && "bareos-fd")
Not sure if it would work, testing.

jsmeix commented at 2018-01-15 10:54:¶

@gdha
is there something you like to fix or enhance in ReaR
because currently it is a "minor bug" for BACKUP=BAREOS
or is it only a "support question" that was "fixed/solved/done" ?

gdha commented at 2018-01-15 16:22:¶

@StarT3 What does the plugin directory exactly contain? Is it critical for BAREOS or can it be left out? Or was that plugin directory empty?

StarT3 commented at 2018-01-15 18:32:¶

In my case i use plugin called bpipe, it is installed by default with Bareos. Main purpose - consistent backup of databases.

The bpipe plugin is a generic pipe program, that simply transmits the data from a speciﬁed program to Bareos for backup, and from Bareos to a speciﬁed program for restore. The purpose of the plugin is to provide an interface to any system program for backup and restore. That allows you, for example, to do database backups without a local dump. By using diﬀerent command lines to bpipe, you can backup any kind of data (ASCII or binary) depending on the program called.
On Linux, the Bareos bpipe plugin is part of the bareos-filedaemon package and is therefore installed on any system running the ﬁledaemon.

I think this particular plugin is not needed for the REAR recovery phase because bpipe connects to existing (working) SQL service. It should be used on the next stage, when we have recovered, up and running server, and we need to recover (or update) production databases. There are a lot of other plugins (for example Percona, python based plugins and so on), and we cannot provide everything for every of them. But it would be nice if REAR could take care at least of Plugin directory string in config. Less headache for users, i've spent several hours to understand what is wrong with my recovery.
By default Plugin Directory = /usr/lib/bareos/plugins string is commented in /etc/bareos/bareos-fd.d/client/myself.conf. So most users do not use plugins. We could:

Parse /etc/bareos/bareos-fd.d/client/myself.conf and include all plugin directories we found using COPY_AS_IS
Just create empty folder /usr/lib/bareos/plugins in rear environment (default folder for plugins, could be empty). It would resolve the error.
Comment Plugin Directory = /usr/lib/bareos/plugins string with PRE_RECOVERY_SCRIPT.
Do nothing. If anyone as dumb as myself would encounter such error, googling should lead to that GitHub thread and it would take minutes to resolve it manually.
I'm not sure if it is support question or minor bug or feature request.

gdha commented at 2018-01-16 11:00:¶

@StarT3 @jsmeix We can add a rescue script to add those directories (/usr/lib/bareos/plugins or /usr/lib64/bareos/plugins) when found, no?
E.g. prep/BAREOS/570_check_bareos_plugin_dir.sh script (still to be written)?

jsmeix commented at 2018-01-16 13:06:¶

I think adaptions and enhancements for third-party backup tool support in ReaR
is best implemented by those who make a particular third-party backup tool
or at least by those who use a particular third-party backup tool.

@aussendorf
could you have a look here and could you do a pull request
if there is a need for adaptions and enhancements
to get support for Bareos plugins in ReaR?

@gdha
in general I do not use any of the third-party backup tools
so that in general I can neither reproduce any issue nor fix
or enhance things that are related to third-party backup tools.

jsmeix commented at 2018-01-26 09:39:¶

With https://github.com/rear/rear/pull/1708 merged
this issue should be at least avoided or even fixed.

Now the the Bareos plugin directory gets included in the ReaR recovery system
which makes the Bareos stuff in the recovery system more consistent
in a generically working way which is preferred over possibly complicated
automated changing Bareos config files in the recovery system,
cf. "Maintain backward compatibility" at
https://github.com/rear/rear/wiki/Coding-Style
that reads (excerpt)

Preferably use simple generic functionality
that works on any Linux system.
Better very simple code than
oversophisticated (possibly fragile) constructs.

[Export of Github issue for rear/rear.]

#1692 Issue closed: Bareos-fd does not start.¶