Back when I upgraded my web server I also implemented logrotate to save off the logs each day so they don’t grow too large. At the time it seemed like a good idea to just save the logs for a year since I had the disk space. In retrospect that was a mistake. Why?
Logrotate numbers each file as it’s rotated out. What probably should have been obvious in restospect was that each time logrotate rotates it increments each log file by 1, and that number is part of the name. So each time the logs were rotated every log file was changed. This didn’t seem to affect the server at all, but since each file was changed it got backed up each night. This made the backups take considerably longer and used more bandwidth than necessary.
So I changed the logrotate configuration to only keep a month of logs. I’ll still backup all 31 files each night, but that’s less than the 70+ I’m already doing, and less than the 365 once a year passes. This changed will give me a little over a month of logs and if I really want more history I can archive the new file off every week. The decision for 365 was more due to laziness than a justifiable decision.
I also found logrotate isn’t smart enough to know when it has extra files. When I reduced the files to keep from 365 to 31 logrotate just deleted file 32 and kept all the higher numbered logs so I’ll have to delete them manually. I’ll go back in and delete the files but since they’re not updated anymore they won’t be backed up each night.
Now the logrotate file for my web logs looks like this:
/usr/sbin/apache2ctl graceful > /dev/null
It’s not so much the compressed log archives that I want to keep small, but I want to keep the active log itself small enough so that I can easily open it and read through it when necessary. So while a weekly archive file would still be manageable, opening or copying the active log file.
I retrospect it was pretty obvious the way logrotate would work, I just didn’t think about it too much.Easy enough to fix.