Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I use back-in-time to backup my Linux installation. It serves as an advanced wrapper for the rsync command.

Today I tried to add /var/log to the list of folders to be backed up and it caused some serious performance problems. The job seems to stuck on a particular file and the CPU usage of the rsync parent process reaches 100%. I then used lsof to see which file caused the problem and it seems to be the /var/log directory.

I did some googling and some experiments with the different rsync options and found --checksum to be the offender. Without the parameter, an incremental backup finishes properly in minutes. With it, the process will stuck when rsync tries to sync a constantly changing log file. This kind of make sense, but it still seems to be a bug to me.

Am I using the option correctly? Is there a workaround for this?

share|improve this question
up vote 0 down vote accepted

You might consider performing a log rotation before the sync. Skip the active files, and just backup the archives. You could even make the rsync an postrotate action after the logs are normally rotated.

share|improve this answer
Yeah, I've been trying to do that, but back-in-time only allow me to change a small set of options. I can't specify the minimum modification age, so I may need to manually build an exclusion list which doesn't seem to be a robust method. – Nov 20 '11 at 21:05

Keep in mind that the checksum is only there to verify that the file transfer has completed successfully.. a means to ensure the file is not corrupt if you will.

This may not be the answer you're looking for but --checksum is going to be slow. There is no way around it. If I were you I would create a quick bash script to compress all of your logs before you run the backup.

Something quick would suffice:

for file in /path/to/log/dir/*;
zip `basename $file`.zip *;
rm -f "$file";

Then run your backup. This would save rsync from creating checksums of possibly huge log files anyway.

Be nice... I know it's not the answer you were looking for.

Good luck

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.