Category Archives: Bacula

Upgrading Debian 8 Jessie to Debian 9 Stretch

If configuration files are changed the old version will usually be copied to a backup file (*.dpkg-old). Nevertheless it is a good idea to make a system backup yourself before upgrading.

Description how to upgrade

  • https://www.cyberciti.biz/faq/how-to-upgrade-debian-8-jessie-to-debian-9-stretch/

Network

  • Device names stay the same (eth0, ...). Debian 9 only uses a new naming scheme for new installations.

Bacula 7.4.4

  • So far I had no problems to connect bacula-fd v7.4.4 to a bacula server v7.0.5

FreeRadius 3.0.12

  • Major upgrade from version 2. The configuration will not be automatically merged. You have to do this manually.
  • Basic configuration stays pretty much the same. Some configuration variables have been renamed or moved to a different position.
  • New configuration directories:
    /etc/freeradius/3.0
    /etc/freeradius/3.0/mods-available
    /etc/freeradius/3.0/mods-enabled
    /etc/freeradius/3.0/sites-available
    /etc/freeradius/3.0/sites-enabled
  • https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/README.rst

ejabberd 16.09

Postfix 3.1.4

  • Had no problems with a basic configuration and a couple of virtual mailbox domains.
  • http://www.postfix.org/announcements.html

amavisd-new 2.10.1-4

  • Almost no changes from previous version 2.10.1-2
  • https://launchpad.net/debian/+source/amavisd-new/+changelog

spamassassin 3.4.1

  • No need to change anything if you have a default installation
  • https://svn.apache.org/repos/asf/spamassassin/branches/3.4/build/announcements/3.4.1.txt

courier-*

  • New user/group "courier". File permissions need to be adjusted:
    /etc/courier
    /var/lib/courier
  • Some configuration changes (pid file, certificates location, etc.)

ntp 4.2.8p10

  • No longer subject to DRDoS Amplification Attack
  • Option "limited" added (to default restriction in configuration file)
  • Source restriction added (to configuration file)

OpenSSH 7.4

  • Major upgrade from version 6.7
  • No longer subject to ssh client roaming problem (s. Qualys Security Advisory)
  • New "AddKeysToAgent" client parameter (a private key that is used during authentication will be added to ssh-agent)
  • Default for "PermitRootLogin" changed from "yes" to "prohibit-password".
  • Default for "UsePrivilegeSeparation" changed from "yes" to "sandbox"
  • Default for "UseDNS" changed from "yes" to "no"
  • New option to require 2 different public keys for authentication; may be used for two-man rule / four-eyes principle (s. "AuthenticationMethods=publickey,publickey")
  • https://www.openssh.com/txt/
Share

Automatically run bacula's copy / migrate jobs

Recently I had some trouble to get bacula's copy jobs running. Here are my experiences.

By the way: There are no differences between copy and migrate jobs in terms of configuration (except for the job type in the job resource of bacula-dir.conf), so you can use this little tutorial for both of them.

First of all you need to realize that bacula's copy jobs do not run automatically, no matter how you run or configure them. Even though it would be a nice idea to have a copy job run automatically after the corresponding backup job has finished (e.g. to transfer the backed up files from disk to tape), bacula does not support this feature yet. You have to run the copy job yourself after the corresponding backup job has finished. But how do you do this?

My first approach was to start the copy job one minute after the original backup job has started. Consider the following scenario in your bacula-dir.conf:

Job {
  Name = "Backup1"
  Type = Backup
  Schedule = "DailyCycle"
  ...
}
Job {
  Name = "Copy1"
  Type = Copy
  Schedule = "DailyCycleCopy"
  Priority 100
  ...
}
Schedule {
  Name = "DailyCycle"
  Run = Full mon-sun at 20:00
}
Schedule {
  Name = "DailyCycleCopy"
  Run = Full  mon-sun at 20:01
}

In this example, the copy job runs one minute after the corresponding backup job (assuming that all other settings e.g. for the pool and storage resources are done right). But it WON'T work. Yes, the copy job starts one minute after the backup job, and because of its lower priority (100 is a lower priority than the default 10) it waits until the backup job has finished and does not run in parallel. But the copy job cannot find the backup job. It might find the backup job from the day before, or it might terminate immediately without doing anything. Maybe it has to do with the database update of the backup job that will take too long. So the copy job runs before the backup job has updated the database. In my case I was using a local MySQL database for the bacula server installation.

Next I was stumbling across the "Run = ..." keyword in the job resource. It is supposed to run another job right before its own job. I was doing something like this:

Job {
  Name = "Backup1"
  Type = Backup
  ...
}
Job {
  Name = "Copy1"
  Type = Copy
  Run = "Backup1"
  Schedule = "DailyCycle"
  Priority 100
  ...
  }

Again because of its lower priority, the copy job should first start the backup job, wait until the backup job has finished and then start itself. I don't know how the Run directive should work. But for me it was not working at all. The backup job did not start at all, and the copy job terminated immediately without doing anything.

Last I was following some advice from the internet and tried using the RunScript directive:

Job {
  Name = "Backup1"
  Type = Backup
  Schedule = "DailyCycle"
RunScript {
Command = "echo 'run job=Copy1 yes' | bconsole'"
RunsWhen = After
RunsOnFailure = No
RunsOnSuccess = Yes
RunsOnClient = No
}
  ...
}

Job {
  Name = "Copy1"
  Type = Copy
  ...
  }

First it did not work either. This is because of the pipe symbol "|" in the Command directive. I had to change it to point to an external shell script wrapper without using any special characters:

  ...
RunScript {
Command = "/etc/bacula/startJob.sh Copy1"
...

/etc/bacula/startJob.sh:

#!/bin/bash
echo "run job=$1 yes " | bconsole

Here we go. Finally copy jobs were working. The backup job was starting at the scheduled time. After finishing successfully it runs the external shell script which in turn starts the copy job. There is enough time for the backup job to finish, so the copy job recognizes the just finished backup job and transfers its data to tape.

I was using bacula version 5.2.x. Maybe this behaviour will change in future bacula versions.

 

Share