Create a backup job on bareos
March 10, 2017

Create a backup job on bareos

Posted on March 10, 2017  •  7 minutes  • 1489 words  •  Suggest Changes

In the last posts, we setup bareos and connected a client to the bareos server, there are however no backup jobs auto-magically added to the bareos server so that’s our job. At first creating a job seems difficult and complex, but most of the options only become interesting in specific applications and a simple basic job can be configured pretty easy. That’s what I am going to do now, create a backup job that will incremental backup the /etc directory of my Linux client.

Job requirements

First we need to understand the target of the job, this step is important, if you don’t do it you might end up with something completely different due to the options possible with bareos.


Since we have a pretty well defined time of day to run the backup job, let’s start with first creating the specific schedule. In bareos all the configurations are nicely filtered in config files. In the directory /etc/bareos since we are configuring jobs that will be “directed” by the director, we need to go in the director configuration : /etc/bareos/bareos-dir.d/ there we can find the schedule directory. There might already be some examples there. But let’s create a new schedule :

nano /etc/bareos/bareos-dir.d/schedule/Nightly.conf

with the content :

Schedule {
  # name (required)
  Name = "Nightly"
  # run time
  # allot of options are available,
  # you can create multiple "Run =" times
  # for now lets keep it simple
  # this will run once a day, every day at 21:10
  Run = daily at 21:10

You can make very complex schedules, but let’s start with something simple and easy. For more complex examples and options check the bareos manuel. Most important is the Run part, where we define the run frequency and the run time. Since /etc is rather small, it can be ran daily at an arbitrary time, but let’s do it outside work hours.  Before you forget, all config files should be owned by the bareos user :

chown bareos.bareos Nightly.conf


Next we need to let bareos know what we want to have backed up, by default one of the filesets is already useful for Linux : LinuxAll. This fileset will backup all the root and all its subdirectory’s. This however is way to much and for our storage servers would simply not be possible. So let’s go ahead and create a new file :

nano /etc/bareos/bareos-dir.d/fileset/LinuxConfig.conf

with content :

FileSet {
  # name (required)
  Name = "LinuxConfig"

  # include directory
  Include {
    Options {
      # calculate a signature for all files
      # both MD5/SHA1 are available, this is definitly for long term storage
      # a good idea to activate, note that the hash ads a bit of storage overhead
      Signature = MD5
      # compress every file with compression software
      # best known are : LZ4/GZIP (see manual for the others)
      # LZ4 is super fast in both compression and decompression
      # I would activate this always.
      Compression = LZ4
      # if supported by the OS, the read time won't be adapted
      # this would generate a bunch of writes for no reason on the client machine.
      noatime = yes
    # the directory we are including
    # note: no trailing slashes!
    File = /etc

Most important parts is the Include { File = /etc } this will make sure it includes /etc directory and all its subdirectory’s (this is also an option, but on by default)

notable options here are signature, a great feature, cause you don’t want to put back a corrupt backup … (it happens) While it has been proven that MD5 hashes can be broken it still is extremely difficult to do. But if you have that fear, you can use SHA1 which is a bit more CPU intense and takes up 4 more bytes per file but more difficult to break.

Another important feature is compression, I like LZ4 cause its fast, the CPU penalty is small compared to the storage you can gain. Note that this is run on the client. (file-daemon on client side)

Last option I included is noatime, while most storage systems already have atime off. Some system might still have it on, but I don’t see the point of knowing when a file has been read by a backup process.


Next part is combining all the property’s of a job that would execute the requirements we set. This is the ‘default’ setup we start from when making jobs. Real jobs are called jobs, and can overwrite these defaults.

JobDefs {
  # name (required)
  Name = "BackupLinuxConfig"
  # type can be backup/restore/verify
  Type = Backup
  # the default level bareos will try
  # can also be Full/Differential(since last full)/Incremental(since last incremental)
  Level = Incremental
  # the default client, to be overwritten by the job.conf
  Client = bareos-fd
  # what files to include/exclude
  FileSet = "LinuxConfig"
  # the schedule we just created
  Schedule = "Nightly"
  # where to store it
  Storage = File
  # the message reporting
  Messages = Standard
  # the pool where to store it
  Pool = Incremental
  # the higher the value priority the lower it will be dropped in the queue
  # so for important jobs priority=1 will run first
  Priority = 10
  # the bootstrap file keeps a "log" of all the backups, and gets rewritten every time a 
  # full backup is made, it can be used during recovery
  Write Bootstrap = "/var/lib/bareos/%c.bsr"
  # in case these value's get overwritten
  # define where would be a good pool to write 
  # note that full backup will be used atleast once because no full
  # backup will exist
  Full Backup Pool = Full
  Differential Backup Pool = Differential
  Incremental Backup Pool = Incremental

The client is here bareos-fd, which is a default configured client pointing to its own installation. The fileset and schedule we just created is now being referenced here. Since all backups start from a “full” backup, there needs to be a backup pool.

Now that we have a good “sketch” (jobdef) for our backup job, creating the real backup is easy.


Getting the final job to work is easy, just reference the jobdefs and overwrite the value’s you want changed.

nano /etc/bareos/bareos-dir.d/job/svennd-etc-backup.conf

with content :

Job {
  # required
  Name = "svennd-etc-backup"
  # the default settings
  JobDefs = "BackupLinuxConfig"
  # overwrite the client here
  Client = "svennd"

And that’s it.

Running the job

Obviously the job will start every day at 21:10, but as a test, its great if you can just start to run it now. Before you can start, be sure to check that all files you created are owned by bareos user if not :

chown bareos.bareos file.conf

Then we can go to the _bconsole _and reload the configuration, this is required. If you don’t do it only at the next restart of bareos-dir will the new configuration be picked up.


and run _reload _:


Once this worked and no errors where reported you can run the job we just made:

* run job=svennd-etc-backup
Using Catalog "MyCatalog"
Run Backup job
JobName:  svennd-etc-backup
Level:    Incremental
Client:   svennd
Format:   Native
FileSet:  LinuxConfig
Pool:     Incremental (From Job IncPool override)
Storage:  File (From Job resource)
When:     2017-03-10 15:48:01
Priority: 10
OK to run? (yes/mod/no): yes
Job queued. JobId=3

note : although I specify the jobname here, you can just run “run” and you will be prompted for the exact job you wish to run.

The log would report after a bit :

10-Mar 10:21 bareos-dir JobId 1: No prior Full backup Job record found.
10-Mar 10:21 bareos-dir JobId 1: No prior or suitable Full backup found in catalog. Doing FULL backup.
10-Mar 10:21 bareos-dir JobId 1: Start Backup JobId 1, Job=lungo-01-etc-backup.2017-03-10_10.21.46_43
10-Mar 10:21 bareos-dir JobId 1: Created new Volume "Full-0001" in catalog.
10-Mar 10:21 bareos-dir JobId 1: Using Device "FileStorage" to write.

As I said before the first backup would be a full one, and the next one, should start being incremental. If we run the job command a few times (you can use arrow up like in bash) and login in the web interface, under jobs:

bareos backup incremental overview in webinterface

And voila our first client is being backed up. Its should now be pretty easy to add more clients and get them backed up (just add more jobs under the job/ and overwrite the client). In the next post, we will look at how the backups are stored and how we can fine tune this setup. The target of backups of course is restoring the data, so that’s also to come…


If you enjoyed this website, consider buying me a Dr. Pepper

Buy me a Dr PepperBuy me a Dr Pepper