README 6.79 KB
Newer Older
Micah Anderson's avatar
Micah Anderson committed
1 2 3
Backupninja Module
-------------------

4
This module helps you configure all of your backups with puppet, using
5
backupninja!
Micah Anderson's avatar
Micah Anderson committed
6

7
!! UPGRADE NOTICE !!
Micah Anderson's avatar
Micah Anderson committed
8

9 10
If you were previously using this module, some pieces have changed,
and you need to carefully change your use of them, or you will find
11
your backups could stop working or get duplicated.
12 13 14 15 16 17 18 19 20

The backupninja::client class has been renamed to backupninja, and is
now *required* in all node manifests. Make sure the backupninja class
is now declared in all your node manifests! This new class now defines
defaults which were previously provided by backupninja::client::defaults,
and can now be overridden thanks to the brand new technology of class
parameters. This class also manages the backupninja configuration file,
replacing the backupninja::config ressource.

21 22 23 24 25 26
The backupninja::server class now takes parameters, replacing several
global variables such as $backupdir, $backupserver_tag and
$nagios_server. The $manage_nagios parameter also replaces the
$use_nagios global.

As for handlers, they don't include the backupninja::client anymore and
27 28 29 30 31 32
now read several default values from the backupninja base class. The
$installkey parameter used in several handlers has been renamed to
$keymanage, to keep in line with the base class parameter.

If you were using the rdiff-backup handler, you need to read the
following section carefully.
33

34 35
Changes to the rdiff-backup handler
-----------------------------------
36

37 38 39 40 41 42
You will need to make sure you change all of your "$directory"
parameters to be "$home" instead, and on your backupserver you will need
to move all of your backups into "$home"/rdiff-backup. Previously, they
were put in "$directory", which doubled as the home for the user that
was created. This caused problems with rdiff-backup because of dot files
and other things which were not part of any rdiff-backup.
43

44 45 46 47 48 49 50 51 52 53 54 55 56 57
The rdiff resource name is now used as the subdirectory where rdiff
backups are sent. This was previously hardcoded to "rdiff-backup", but
in order to support multiple rdiff backups per host, we now use the
resource name. So if you were using the following resource:

    backupninja::rdiff { 'main': }

You will want to use the following resource:

    backupninja::rdiff { 'rdiff-backup': }
    file { '/etc/backup.d/90_main.rdiff': ensure => absent; }

Otherwise your backups may be duplicated!

58 59 60 61 62 63 64 65 66 67 68 69
Changes to nagios integration
-----------------------------

The default nagios passive service name has changed from "backups" to
"backups-${name}". If you want it to be automatically created on your
nagios host, you will need to set $backupninja::manage_nagios to true.
on the client.

Use the following resource to remove the old "backups" passive service.

    nagios::service { 'backups': ensure => absent }

70 71 72
Getting started
---------------

73
This module requires Puppet versions 2.7 and up.
74

75
An up-to-date version of the puppet-stdlib module is also required.
76 77 78 79 80 81

Configure your backup server
----------------------------

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

83 84
  include backupninja::server

85 86 87 88 89 90 91 92
The default configuration will store backup data in the "/backup"
directory. To change this you may declare the class with a "backupdir"
parameter:

  class { 'backupninja::server':
    backupdir => '/mnt/backupdata'
  }

93 94
By configuring a backupninja::server, this module will automatically
create sandboxed users on the server for each client for their
95
backups.
Micah Anderson's avatar
Micah Anderson committed
96

97 98 99
Configure your backup clients
-----------------------------

100 101
First, you need to include the backupninja class or declare it with
custom parameters:
102

103 104 105 106 107 108 109 110
  class { 'backupninja':
	loglvl => 3,
	usecolors => false,
	reportsuccess => false,
	reportwarning => true,
    ensure_backupninja_version => '1.0.1-1',
    ensure_rdiffbackup_version => '1.2.8-7'
  }
111 112

In this case, the module will make sure that the backupninja package
113 114 115 116 117 118 119
is installed (using puppet's ensure parameter language) and create the
/etc/backupninja.conf configuration file.

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 class parameter,
as shown in the example.
120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135

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:
Micah Anderson's avatar
Micah Anderson committed
136

137
backupninja::mysql { 'all_databases':
Micah Anderson's avatar
Micah Anderson committed
138 139 140 141 142 143
	user => root,
	backupdir => '/var/backups',
	compress => true,
	sqldump => true
}

144 145
* An example rdiff-backup handler configuration:

146
backupninja::rdiff { 'backup_all':
Micah Anderson's avatar
Micah Anderson committed
147 148 149 150 151
	directory => '/media/backupdisk',
	include => ['/var/backups', '/home', '/var/lib/dpkg/status'],
	exclude => '/home/*/.gnupg'
}

152
* A remote rdiff-backup handler:
153

154 155 156 157 158
backupninja::rdiff { 'main':
    host => 'backup.example.com',
    type => 'remote',
    directory => "/backup/${::fqdn}",
    user => "backup-${::hostname}",
159
}
160

161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187
Automatic creation of ssh-keys for duplicity
--------------------------------------------

backupninja::duplicity can be used to

- create an ssh keypair for a client
- place the keypair on the puppetmaster in a given location
- place the keypair in /root/.ssh on the client

i.e.:

  backupninja::duplicity { "duplicity_${::fqdn}":
    sshoptions        => "-oIdentityFile=/root/.ssh/backupninja_${::hostname}_id_rsa",
    desthost          => 'HOST',
    destdir           => "/var/backup/backupninja/${::fqdn}",
    destuser          => "backupninja_${::hostname}",
    encryptkey        => 'KEYID',
    password          => 'PW',
    backupkeystore    => 'puppet:///keys',
    backupkeystorefspath => '/etc/puppet/modules/keys/files',
    backupkeydestname => "backupninja_${::hostname}_id_rsa",
    createkey         => true,
    installkey        => true,
    ...
  }


188 189 190
Nagios alerts about backup freshness
------------------------------------

191 192 193
If you set the $backupninja::server::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
194 195
/usr/local/bin/checkbackups.pl, to the nagios server to alert about
relative backup freshness.
196

197 198 199 200 201
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
202
 . backups must be under $home/dup, $home/rdiff-backup depending on method