1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
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
188
189
190
191
192
193
|
Backupninja Module
-------------------
This module helps you configure all of your backups with puppet, using
backupninja!
! Upgrade notice !
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
your backups to be duplicated on your backup server. The important
part that changed has to do with the rdiff-backup handler, if you
weren't using that, you don't need to worry.
If you were, 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.
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!
Getting started
---------------
First you will need to import the module:
import "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 => "backup.example.com",
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;
}
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,
...
}
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/checkbackups.pl, 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
|
