Any good reason not to use date-based logfile rotation (rdiff-backup)?

Question

rdiff-backup is a really nice tool for backing up Linux servers.

One problem, though, is logrotation: Since rdiff-backup doesn't know how to detect renamed files, every daily backup contain a complete copy of all rotate log files.

A possible fix would be to convert the logrotate configuration to use a dateext filename scheme with static filenames (like e.g. wtmp-20110301).

I'm thinking about converting our servers to this scheme, in order to save a couple of GB per week in our backup.

Could you think of any major drawbacks of a complete conversion of logfile rotation to a dateext scheme?

Tru64 did something like this and it worked out OK. There was also a symlink to the current log file. — Mark Wagner, Mar 09 '11 at 20:42

score 2 · Accepted Answer · edited Apr 13 '17 at 12:14

2

Very good question.

One thing you have to keep in mind is that dateext overwrites files if it is called twice on that same day.

I've been looking into the same, which has resulted in a relating question: Preventing logrotate's dateext from overwriting files

edited Apr 13 '17 at 12:14

Community

1

answered May 06 '11 at 09:11

Thirler

156
1
5

Thanks for mentioning a reason not to use dateext! – flight Oct 13 '11 at 14:17

score 1 · Answer 2 · edited Feb 28 '18 at 22:07

Thank you for going with yyyymmdd format. Sometimes people pick values out of strftime that aren't padded with 0s which can cause problems.

The main reason log files are rotated by number is because it is easier to zap out old files with a limited range of names (1..9)... the only "risk" I would see is if logrotate missed a run and an old logfile was left laying around enough times you could potentially hit capacity limits on the filesystem, but if you're monitoring your disk space, you are or will be accustomed to cleaning out log directories anyway.

Any good reason not to use date-based logfile rotation (rdiff-backup)?

2 Answers2