Forge Home


Puppet module to manage backupninja installation and configuration


6,134 latest version

5.0 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 0.4.0 (latest)
released Jan 19th 2018
This version is compatible with:
  • Puppet Enterprise 2018.1.x, 2017.3.x, 2017.2.x, 2017.1.x, 2016.5.x, 2016.4.x
  • Puppet >= 4.7.0 < 6.0.0
  • , , ,

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'soli-backupninja', '0.4.0'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add soli-backupninja
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install soli-backupninja --version 0.4.0

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.



soli/backupninja — version 0.4.0 Jan 19th 2018


Puppet Forge Version Puppet Forge Downloads Puppet Forge Score Build Status

Table of Contents

  1. Module Description - What the module does and why it is useful
  2. Setup - The basics of getting started with backupninja
  3. Usage - Configuration options and additional functionality
  4. Reference - An under-the-hood peek at what the module is doing and how
  5. Limitations - OS compatibility, etc.
  6. Development - Guide for contributing to the module
  7. Contributors

Module Description

This module installs and configures backupninja.


Beginning with backupninja



Configure your backup server

Now you will need to configure a backup server by adding the following to your node definition for that server:

include backupninja::server

By configuring a backupninja::server, this module will automatically create sandboxed users on the server for each client for their backups.

You may also want to set some variables on your backup server, such as:

$backupdir = "/backups"

Configure your backup clients

The backupninja package and the necessary backup software will be installed automatically when you include any of the different handlers (as long as you are not handling it elsewhere in your manifests), for example:

include backupninja::client::rdiff_backup

In this case, the module will make sure that the backupninja package and the required rdiff-backup package are 'installed'/'present' (using puppet's ensure parameter language). If you need to specify a specific version of either backupninja itself, or the specific programs that the handler class installs, you can specify the version you need installed by providing a variable, for example:

$backupninja_ensure_version = "0.9.7~bpo50+1"
$rdiff_backup_ensure_version = "1.2.5-1~bpo40+1"
$rsync_ensure_version = "3.0.6-1~bpo50+1"
$duplicity_ensure_version = "0.6.04-1~bpo50+1"
$debconf_utils_ensure_version = "1.5.28"
$hwinfo_ensure_version = "16.0-2"

If you do not specify these variables the default 'installed/present' version will be installed when you include this class.

Configuring handlers

Depending on which backup method you want to use on your client, you can simply specify some configuration options for that handler that are necessary for your client.

Each handler has its own configuration options necessary to make it work, each of those are available as puppet parameters. You can see the handler documentation, or look at the handler puppet files included in this module to see your different options.

Included below are some configuration examples for different handlers.

  • An example mysql handler configuration:
backupninja::mysql { all_databases:
    user => root,
    backupdir => '/var/backups',
    compress => true,
    sqldump => true
  • An example rdiff-backup handler configuration:
backupninja::rdiff { backup_all:
    directory => '/media/backupdisk',
    include => ['/var/backups', '/home', '/var/lib/dpkg/status'],
    exclude => '/home/\*/.gnupg'
  • A remote rdiff-backup handler:
backupninja::rdiff { "main":
    host => "",
    type => "remote",
    directory => "/backup/$fqdn",
    user => "backup-$hostname",

Configuring backupninja itself

You may wish to configure backupninja itself. You can do that by doing the following, and the /etc/backupninja.conf will be managed by puppet, all the backupninja configuration options are available, you can find them inside this module as well.

For example:

backupninja::config { conf:
    loglvl => 3,
    usecolors => false,
    reportsuccess => false,
    reportwarning => true;

Nagios alerts about backup freshness

If you set the $nagios_server variable to be the name of your nagios server, then a passive nagios service gets setup so that the backup server pushes checks, via a cronjob that calls /usr/local/bin/, to the nagios server to alert about relative backup freshness.

To use this feature a few pre-requisites are necessary:

  • configure nsca on your backup server (not done via puppet yet)
  • configure nsca on your nagios server (not done via puppet yet)
  • server backup directories are named after their $fqdn
  • using nagios2 module, nagios/nagios3 modules/nativetypes not supported yet
  • using a nagios puppet module that can create passive service checks
  • backups must be under $home/dup, $home/rdiff-backup depending on method
  • $nagios_server must be set before the class is included



Public Classes



RedHat and Debian family OSes are officially supported. Tested and built on Debian and CentOS.


Solution Libre modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great.

Fork this module on GitHub


The list of contributors can be found at: