incremental data is compressed. permissions are retained even
with an unprivileged backup user.
- backup of mysql databases (via mysqlhotcopy and mysqldump).
- backup of ldap databases (via slapcat and ldapsearch).
- passwords are never sent via the command line to helper programs.
- 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).
.\" TeX users may be more comfortable with the \fB<whatever>\fP and
.\" \fI<whatever>\fP escape sequences to invoke bold face and italics,
.\" respectively.
.SH OPTIONS
.TP
.B \-h, \-\-help
Show summary of options
.TP
.B \-d, \-\-debug
Run in debug mode, where all log messages are output to the current shell.
.TP
.B \-f, \-\-conffile FILE
Use FILE for the main configuration instead of /etc/backupninja.conf
.TP
.B \-t, \-\-test
Run in test mode, no actions are actually taken.
.TP
.B \-n, \-\-now
Perform actions now, instead of when they might be scheduled.
.SH EXAMPLES
.TP
Backupninja can be used to impliment whatever backup strategy you choose. It is intended, however, to be used like so:
.TP
First, databases are safely copied or exported to /var/backups. Often, you cannot make a file backup of a database while it is in use, hence the need to use special tools to make a safe copy or export into /var/backups.
.TP
Then, vital parts of the file system, including /var/backups, are nightly pushed to a remote, off-site, hard disk (using rdiff-backup). The local user is root, but the remote user is not privileged. Hopefully, the remote filesystem is encrypted.
.TP
There are many different backup strategies out there, including "pull style", magnetic tape, rsync + hard links, etc. We believe that the strategy outlined above is the way to go because: (1) hard disks are very cheap these days, (2) pull style backups are no good, because then the backup server must have root on the production server, and (3) rdiff-backup is more space efficient and featureful than using rsync + hard links.
.SH SSH KEYS
.TP
In order for rdiff-backup to sync files over ssh unattended, you must create ssh keys on the source server and copy the public key to the remote user's authorized keys file. For example:
BACKUPNINJA.CONF \- Configuration file(s) for \fBbackupninja (1)\fP.
.\" Please adjust this date whenever revising the manpage.
.\"
.\" Some roff macros, for reference:
.\" .nh disable hyphenation
.\" .hy enable hyphenation
.\" .ad l left justify
.\" .ad b justify to both left and right margins
.\" .nf disable filling
.\" .fi enable filling
.\" .br insert line break
.\" .sp <n> insert n+1 empty lines
.\" for manpage-specific macros, see man(7)
.br
.SH SYNOPSIS
.B "/etc/backupninja.conf "
.br
.B "/etc/backup.d/* "
.br
.SH DESCRIPTION
.B backupninja.conf
is the general configuration file. 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".
.TP
To perform the actual backup, backupninja processes each configuration file in /etc/backup.d according to the file's suffix:
.br
.sh -- run this file as a shell script.
.rdiff -- this is a configuration for rdiff-backup
.maildir -- this is a configuration to backup maildirs
.mysql -- mysql backup configuration
.ldap -- ldap backup configuration
.sys -- general system reports
.TP
Support for additional configuration types can be added by dropping bash scripts with the name of the suffix into /usr/share/backupninja.
.TP
The configuration files are processed in alphabetical order. However, it is suggested that you name the config files in "sysvinit style."
.TP
For example:
00-disabled.ldap
10-runthisfirst.sh
20-runthisnext.mysql
90-runthislast.rdiff
.TP
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) are skipped.
.TP
Unless otherwise specified, the config file format is "ini style."
.TP
For example:
# this is a comment
[fishes]
fish = red
fish = blue
[fruit]
apple = yes
pear = no thanks \
i will not have a pear.
.PP
.SH SCHEDULING
.br
By default, each configuration file is processed everyday at 01:00 (1
AM). This can be changed by specifying the 'when' in a config 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
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.
If two configurations files are scheduled close to one another in
time, it is possible to have multiple copies of backupninja running if
the first instance is not finished before the next one starts.
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
.br
.SH SEE ALSO
.BR backupninja (1),
.br
.SH AUTHOR
BACKUPNINJA was written by <elijah@riseup.net>.
.br
BACKUPNINJA was packaged by <micah@riseup.net>.
.br
.PP
This manual page was written by <stefani@riseup.net>.
