I have a local server which Rsync's from some computers on the LAN. It's a part of a backup solution.

This Rsync runs via cronjob twice a day. Occationally people add gigantic amounts of data, like a Terabyte or so. When that happens there is no guarantee that the Rsync will finish before the second Rsync takes off.

What happens in such circumstances?
Is that something to be avoided?


If I'm ever worried about one cronjob starting before another is finished, I usually create a temporary file under /tmp (like /tmp/lockFile_$$) that gets removed as the last step in the first cronjob and just have the second cronjob start with a loop on that files existence, sleeping 5-10 seconds in each loop and breaking out of the loop once the file disappears (possibly sending root an email every so many iterations so you have an easier time noticing stalled jobs).

If the choking point on the first one is network bandwidth, you may try to play around with the --compress and --compress-level options to rsync.

If the choke point is CPU, you may try giving the rsync process a lower nice value

If it's iowait time, you might consider either ionice if you're using cfq on Linux, or splitting the rsync command into several concurrent processes so that one process can be waiting on I/O while another is transmitting instead of going in serial. Most platforms also let you tune I/O functionality. On Linux, during the first cronjob you might consider temporarily switching to the deadline scheduler (to prioritize reads over writes) and temporarily increasing the read_ahead_kb since you're pulling in whole large files from disk.

  • Thanks for the info, its interesting. But best of all would be if Rsync-ing over another wouldn't do any harm to begin with. – Hermann Ingjaldsson Jun 4 '13 at 11:44
  • Are the two rsync's identical except for when they get ran? – Bratchley Jun 4 '13 at 14:36
  • yes they're the same. – Hermann Ingjaldsson Jun 4 '13 at 16:23
  • Then you're probably alright, with possible duplication of effort, though. Rsync writes files in the destination directories with randomized names beginning with a period before renaming them to the proper name (unlinking other files with that name). The second rsync comes along, it will skip all the work the earlier rsync has already done, get to the current file, see it's not at the destination (or destination is older) then try its own sync. So you'll end up with two rsync processes doing the same thing twice, possibly slowing both down if I/O is saturated because of this. – Bratchley Jun 4 '13 at 18:03
  • To clarify: "probably alright" in the sense that unless the performance is outrageously slower it will work, just inefficiently so. Contrasted with whether the second is a sync that happens after the first is assumed to be finished (potentially causing data coherency issues). here is an example of two of the temporary files rsync creates while it's in the middle of doing its thing. – Bratchley Jun 4 '13 at 18:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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