If you've got Drush installed—and you really should—you can use the following recipe to setup a backup system that will maintain daily backups for the last two weeks. Most of the logrotate configuration is based on a Wikibooks book that I found.
Find the pieces
Make sure logrotate is installed:
whereis logrotateWhich should print something like:
logrotate: /usr/sbin/logrotate /etc/logrotate.conf /etc/logrotate.d /usr/share/man/man8/logrotate.8.gzSo for this site we'll use the full path /usr/sbin/logrotate to run the program.
If you don't know where drush is installed you'll probably want to repeat the process to determine its location. The site I'm working on right now is hosted by May First, a very Drupal friendly ISP (and an amazing progressive group), so they've installed drush at /usr/bin/drush.
drush needs to be able to find the correct settings.php file to connect to your database. Specify the root of your Drupal site using the -r switch. You can test that it's able to locate your settings using the following command:
/usr/bin/drush -r ~/dev.rudemechanicalorchestra.org/web sql confIf it works you'll see an array with your database connection information.
Hook 'em up
Create the state and configuration files:
touch ~/.logrotate.state ~/.logrotate.configEdit ~/.logrotate.config insert the following text:
~/backup/dev.sql.gz {
rotate 7
daily
nocompress
nocopytruncate
postrotate
/usr/bin/drush -r ~/dev.rudemechanicalorchestra.org/web/ sql dump | gzip > ~/backup/dev.sql.gz
endscript
}logrotate expects that the file will already exist so we need to use drush to create the first one:
/usr/bin/drush -r ~/dev.rudemechanicalorchestra.org/web/ sql dump | gzip > ~/backup/dev.sql.gzTest that logrotate will work correctly:
/usr/sbin/logrotate --state=~/.logrotate.state ~/.logrotate.config --debugIf everything is working correctly you'll see something like:
reading config file /home/members/rmo/sites/dev.rudemechanicalorchestra.org/users/rmodev/.logrotate.config
reading config info for "/home/members/rmo/sites/dev.rudemechanicalorchestra.org/users/rmodev/backup/dev.sql.gz"
Handling 1 logs
rotating pattern: "/home/members/rmo/sites/dev.rudemechanicalorchestra.org/users/rmodev/backup/dev.sql.gz" after 1 days (7 rotations)
empty log files are rotated, old logs are removed
considering log /home/members/rmo/sites/dev.rudemechanicalorchestra.org/users/rmodev/backup/dev.sql.gz
log does not need rotatingSchedule it
Edit your crontab:
crontab -eAnd add the following line which will run logrotate at midnight:
0 0 * * * /usr/sbin/logrotate --state=~/.logrotate.state ~/.logrotate.configSleep a little better
That's it, you should now have two weeks of daily backups. You'll want to check back on it tomorrow and make sure that the backups are actually occurring and that the old ones are being renamed to .sql.gz.1, .sql.gz.2, etc.
No Tildes, and Multisites
I found logrotate to be a little touchy about tildes on my machine, so I made the path explicit.
Also, for multisite use, I did an initial dump for each site of interest and added an additional .logrotate.conf script block for each site. The initial tests show it working.
Automysqlbackup
It's a bit strange to make backups with logrotate, I believe there is a much better tool for the job:
http://sourceforge.net/projects/automysqlbackup/
"A script to take daily, weekly and monthly backups of your MySQL databases using mysqldump"
that looks like a good
that looks like a good alternative. the thing i like is that this solution uses drush which has some cool features like ignoring cache tables.
strange or lucid?
Maybe it could look a bit strange, but it seems like a quite lucid solution.
It is a little odd
I agree it is a little odd to be using logrotate to run backup scripts. But I must admit to using it to rotate backups in the past.