The requirements were:
- something to back up databases and files from one web server to another
- simple and quick to setup
- free software
- There is no need for the system using a specific programming language, as there is no need for and no meaning in integrating backup functionality in the websites to be backed up. Because the web site might be moved to another (or maybe a cloud service) later, where backup requirements might be different again.
There is a great backup solution comparison list on Wikipedia.
List of alternatives found for file backup, by adequacy (however note that none was tried in practice here so far):
- BackupPC. This seems to be a robust system, as it is based on rsync and GNU tar and stores backups in file-system navigable directory hierarchies, even when doing incremental backups [source]. BackupPC does not look overly modern or stylish, but is extremely small (500 kiB). Another plus is that, as a Perl web application, it can also be installed on a shared web server to back up to that. However, this can also be a problem, as you might need to negotiate with your webhoster to get additional Perl modules installed (most probably, File::RsyncP, to be able to use bandwidth-efficient rsync transfer).
- Amanda. An enterprise-grade backup system like Bacula (see below), but it uses the tar and gzip standard formats. Read about it on amanda.org and its SourceForge project page. Some functionality is only available in an expensive commercial variant. The problem with Amanda is that it cannot be used to store the backed up data on a shared web server. Because while SSH access might be available on the shared web server, no root access is possible, no installation of packages and no access to xinetd configuration, all of which is required by Amanda [source].
- Bacula. A large, enterprise-grade backup system; read the Wikipedia article about Bacula. Because of the complexity, it can tage some time to get this system to run. Also, it uses a proprietary (yet open and documented) file format for storing the backed up data, so it can be uncomfortable to retrieve data.
In addition to file backup, there has to be a solution for MySQL database backup. Ideally an incremental backup solution, but full backups would do as well. Alternatives:
- mysqldump. For full MySQL backups, there is mysqldump.
- mysqlhotcopy. Can be used as a faster alternative to mysqldump for full MySQL backups consisting only of MyISAM and ARCHIVE tables.
- binary logging incremental backups. It is also possible to do incremental MySQL backups by using the binary log feature [source, see section “Making Incremental Backups by Enabling the Binary Log”].
- Zmanda Recovery Manager for MySQL. It is available as free software in its community edition, and created by the folks behind Amanda (see above). Read about it on zmanda.com and the Wikipedia article.
- phpMyBackupPro. Free software, see the phpmybackup SourceForge project.
- MySQLDumper. See the mysqldumper SourceForge project.
- AutoMySQLBackup. See the automysqlbackup SourceForge project.
The backed up database (residing in a file) would then be included in the file backup, and that file would have to be created at the right time. For that, the file backup solution should provide a feature to execute a script on clients before backing them up.