handlers

included handlers

To preform the actual backup, backupninja processes each backup action configuration file in the directory /etc/backup.d/. Depending on the file's suffix, a different handler script will be in charge of processing the action. Here are the handler scripts which are included in the backupninja distribution:

.dup
handler for backing up with duplicity
.ldap
handler for backing up ldap databases.
.maildir
Handler to incrementally backup maildirs (very specialized).
.mysql
handler for backing up mysql databases.
.pgsql
handler for backing up PostgreSQL databases.
.rdiff
handler for keeping remote, incremental copies of specified portions of the file system.
.rsnap
rsync + hardlinking handler
.rub
rsync + hardlinking handler
.sh
run the configuration file as a shell script.
.svn
Handler to backup subversion repositories.
.sys
a handler for recording miscellaneous and useful system and hardware data.

using ninjahelper

The included script ninjahelper is a curses based, menu driven "wizard" which will walk you through creating backup actions. One advantage of using ninjahelper is that some actions have complicated dependencies: you can safely choose some options only if certain conditions are met. Ninjahelper attempts to take these conditions into account when creating backup actions.

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.