you can drop in scripts to handle new types of backups.
.IP-
backup actions can be scheduled.
.IP-
you can choose when status report emails are mailed to you (always, on warning, on error, never).
.IP-
console-based wizard (ninjahelper) makes it easy to create backup action configuration files.
.IP-
passwords are never sent via the command line to helper programs.
.IP-
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.
.IP-
works with Linux-Vservers.
.BBackuptypesinclude:
.IP-2
secure, remote, incremental filesytem backup (via rdiff-backup). incremental data is compressed. permissions are retained even with an unpriviledged backup user.
.IP-
basic system and hardware information.
.IP-
encrypted remote backups (via duplicity).
.IP-
safe backup of MySQL, PostgreSQL, OpenLDAP, and subversion databases.
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.
In order for this to work (ie for diff-backup to run 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:
Now, you should be able to ssh from user 'root' on srchost to user 'backup' on desthost without specifying a password. When prompted for a password by ssh-keygen, just leave it blank by hitting return. The "wizard" \fBninjahelper(1)\fP will walk you through these steps.