Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

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'm trying to using rsync to backup some files, about half a TB. It's now it a state where it keeps sending the same files everytime it runs.

for example:

rsync -av /data/source/* user@host:/data/dest
sending incremental file list

I then verify those files are copied over... then the next time it runs it does the same thing

rsync -av /data/source/* user@host:/data/dest
sending incremental file list

any idea why it's getting stuck on these files? I've tried to wipe the whole dest directory out and start over but no luck.


share|improve this question

migrated from Mar 2 '10 at 19:31

This question came from our site for professional and enthusiast programmers.

Have you done a diff on the files, and checked all the information on their ls -l list? They could, in principle, be modified at either edn without you being aware of it, and maybe rsync doesn't leave the files in the right state on the destination. – Charles Stewart Mar 3 '10 at 13:51

Use --itemize-changes to get rsync to output what is actually being changed

The answer from ire_and_curses misunderstands the point of -t which is to preserve modification times, not to decide whether or not to transfer files. Options that determine whether or not to skip files are: -c which decides whether to skip identical files based on checksum, and -I which ignores size and time when deciding whether to skip files.

Also, although rsync may be sending the files again, it shouldn't be transferring all the contents - running with -v should print a summary of how much data was matched in the transfer.

For checking, the following should help:

  • md5sum of the files on either end - to show you if the contents have changed
  • ls -l should show you if the timestamps have changed.
share|improve this answer

I remember a similar problem with two systems' clocks not quite behaving. I had to use --modify-window=60 to account for "temporal anomalies".

share|improve this answer

You must log in to answer this question.