I copied files from one server to another with rsync 3.0.6 on CentOS 6:

rsync --exclude=".bash*" --progress --verbose -lpogtzr /home/

but many synced files have different checksum on the destination server. I copied again files (sometimes with z flag, sometimes without it) and now all seems ok.

HDDs are ok. Services was active in the old server when I made the first copy. Later I stopped services on both servers before starting another rsync to copy only differences in a faster way. I always made a dry-run before.

How it may be happened? Shouldn't be rsync a stable program?

  • The problem is terrible. Actually we switched back to the old server because it was impossible to copy files. We requested an hardware check to the farm and they told us all is ok Oct 28, 2015 at 19:09
  • Do the files with different checksums have the same content? How do the checksums differ? Show us some examples (actual output of ls -l). Oct 30, 2015 at 23:53
  • The resulting files on the destination server are corrupted, so no, the content is not the same. Oct 31, 2015 at 9:58
  • I checked checksums with md5sum Oct 31, 2015 at 9:59
  • 1
    You should either shutdown the sqlite daemon temporarily while rsyncing the databases, or dump the databases to a text file and backup that. The rsynced copies are most likely corrupted because the db changed while it was being rsynced.
    – cas
    Nov 12, 2015 at 21:44

1 Answer 1


I think I've understood what is happened. I made the first rsync when services was active so resulting files was corrupted (this is ok).

Then I stopped services and I did a second rsync to copy only differences in a faster way.

This didn't worked. Maybe the -t flag is the culprit? Maybe the mtime of files is not updated every time you write a byte but only when you open a file for writing?

  • The -t flag uses the granularity of the filesystems. This can cause problems if the source and destination have different granularity, by the way; in such cases use --modify-window to add a tolerance. Nov 2, 2015 at 22:16
  • destination is ext3, source ext4. In my case --modify-window does the opposite Nov 3, 2015 at 6:23

Not the answer you're looking for? Browse other questions tagged .