Backupninja
Configuration in Debian
What is Backupninja ?
Backupninja allows you to coordinate system backup by dropping a
few simple configuration files into /etc/backup.d/. Most
programs you might use for making backups don't have their own
configuration file format. Backupninja provides a centralized
way to configure and schedule many different backup utilities.
Backupninja Features
easy to read ini style configuration files.
you can drop in scripts to handle new types of backups.
backup actions can be scheduled
you can choose when status report emails are mailed to you
(always, on warning, on error, never).
console-based wizard (ninjahelper) makes it easy to create
backup action configuration files.
passwords are never sent via the command line to helper
programs.
in order to backup a db or sql database, you cannot simply copy
database files. backupninja helps you safely export the data to
a format which you can backup.
works with Linux-Vservers.
Download Backupninja
http://dev.riseup.net/backupninja/download/
Backupninja Handlers
http://dev.riseup.net/backupninja/handlers/
Backupninja Usage
http://dev.riseup.net/backupninja/usage/
Backupninja FAQ
http://dev.riseup.net/backupninja/faq/
Installing Backupninja in Debian
#apt-get install backupninja
Reading Package Lists... Done
Building Dependency Tree... Done
Suggested packages:
rdiff-backup hwinfo
The following NEW packages will be installed:
backupninja
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 30.6kB of archives.
After unpacking 131kB of additional disk space will be used.
Get:1
http://ftp.uk.debian.org stable/main backupninja 0.5-3sarge1
[30.6kB]
Fetched 30.6kB in 0s (70.5kB/s)
Selecting previously deselected package backupninja.
(Reading database ... 35707 files and directories currently
installed.)
Unpacking backupninja (from .../backupninja_0.5-3sarge1_all.deb)
...
Setting up backupninja (0.5-3sarge1) ...
Configuring backupninja in Debian
The main configuration file located at
/etc/backupninja.conf
global configuration
The general configuration file is /etc/backupninja.conf. In this
file you can set the log level and change the default directory
locations. You can force a different general configuration file
with "backupninja -f /path/to/conf".
Here is the default backupninja.conf:
# how verbose to make the logs
# 5 -- Debugging messages (and below)
# 4 -- Informational messages (and below)
# 3 -- Warnings (and below)
# 2 -- Errors (and below)
# 1 -- Fatal errors (only)
loglevel = 4
# send a summary of the backup status to
# this email address:
reportemail = root
# if set to 'yes', a report email will be generated
# even if all modules reported success. (default = yes)
reportsuccess = yes
# if set to 'yes', a report email will be generated
# even if there was no error. (default = yes)
reportwarning = yes
#######################################################
# for most installations, the defaults below are good #
#######################################################
# where to log:
logfile = /var/log/backupninja.log
# directory where all the backup configuration files live
configdirectory = /etc/backup.d
# where backupninja handler scripts are found
scriptdirectory = /usr/share/backupninja
# use colors in the log file
usecolors = yes
backup actions
To preform the actual backup actions, backupninja processes each
configuration file in /etc/backup.d according to the file's
suffix:
.sh: run this file as a shell script.
.rdiff: backup action for rdiff-backup.
.dup: backup action for duplicity.
.maildir: backup action for slow, incremental rsyncs of tens of
thousands of maildirs.
.mysql: backup action for safe MySQL dumps.
.pgsql: backup action for safe PostgreSQL dumps.
.ldap: backup action for safe OpenLdap dumps.
.sys: backup action for general system reports and hardware
information.
.svn: backup action for safe backups of subversion repositories.
.trac: backup action for safe backups of trac repositories.
.makecd: backup action for burning backups to CD/DVD or creating
ISOs.
Support for additional configuration types can be added by
dropping bash scripts with the name of the suffix into /usr/share/backupninja.
If you want to know more about backup actions
click here
creating your own handler
You can create additional handlers by adding bash scripts to /usr/share/backupninja.
The bash script is sourced from the main backupninja script, so
there is no need to specify "#!/bin/bash" on the first line. You
can read the backup action's configuration file with the
functions setsection and getconf. Use the command debug to
report errors, warning, and debugging information. If $test is
set, then your script should take no action but report what it
would have done.
For example, suppose we had the backup action /etc/backup.d/50-aquarium.fishes:
[animals]
population = 10
fish = one_fish
fish = two_fish
fish = red_fish
fish = blue_fish
crab = carl
[plants]
population = 3
grass = yes
The corresponding handler /usr/share/backupninja/fishes might
look like this:
setsection animals
getconf population
getconf fish
debug 1 "this is the animal population: $population"
for f in $fish; do
info "found fish $f"
done
if [ ! $test ]; then
/usr/bin/populate_aquarium $population
exit_status=$?
if [ $exit_status == 0 ]; then
info "success!"
else
error "failed to populate aquarium"
fi
else
debug "populate_aquarium $population"
fi
setsection plants
getconf population
info "this is the plant population: $population"
There are output five functions:
debug $msg -- log debugging info
info $msg -- log general information.
warning $msg -- log a warning
error $msg -- log an error
fatal $msg -- log a fatal error and exit
Any messages logged by 'warning', 'error', or 'fatal' are
included in the status report (unless backupninja has been
configured not to generate a status report). Debug messaged
don't show up in logs unless loglevel is set to 5. If
backupninja is run with --debug, then all messages of all log
levels are output to the terminal.
order of processing
The configuration files are processed in alphabetical order.
However, it is suggested that you name the config files in "sysvinit
style."
For example:
10-thiswillnotrun.ldap.disabled
15-runthisfirst.sh
20-runthisnext.mysql
90-runthislast.rdiff
Typically, you will put a '.rdiff' config file last, so that any
database dumps you make are included in the filesystem backup.
Configurations files which begin with 0 (zero) or end in
".disabled" are skipped.
scheduling
By default, each configuration file is processed
everyday at 01:00 (1 AM). This can be changed by specifying the
'when' option in a backup action's config file or in the global
configuration file.
For example:
when = sundays at 02:00
when = 30th at 22
when = 30 at 22:00
when = everyday at 01 <-- the default
when = Tuesday at 05:00
when = hourly
A configuration file will be processed at the time(s) specified
by the "when" option. If multiple "when" options are present,
then they all apply. If two configurations files are scheduled
to run in the same hour, then we fall back on the alphabetical
ordering specified above.
important! The when must occur
before any sections in the config file.
It is possible to have multiple copies of backupninja running if
the first instance is not finished before the next one starts.
For this reason, if you want to make sure that a particular
backup action is processed before another, then you should give
them the same "when" value.
For example, suppose a backup action "reallyslow.rdiff" is
started at 10:00 and takes five hours to complete. If another
action is scheduled at 12:00, it will start running even though
reallyslow.rdiff has not finished. On the other hand, if another
action is scheduled also for 10:00 (and comes alphabetically
after "reallyslow.rdiff"), then it will be run after
reallyslow.rdiff finishes, at about 15:00.
These values for 'when' are equivalent:
when = tuesday at 05:30
when = TUESDAYS at 05
These values for 'when' are invalid:
when = tuesday at 2am
when = tuesday at 2
when = tues at 02
file format
Unless otherwise specified, the config file format is "ini
style." Sections are created by using square bracket. Long lines
are connected with a backslash.
For example:
# this is a comment
[fishes]
fish = red
fish = blue
[fruit]
apple = yes
pear = no thanks \
i will not have a pear.