1

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

rsync --exclude=".bash*" --progress --verbose -lpogtzr /home/ 1.2.3.4:/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 – Marco Marsala Oct 28 '15 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). – Gilles 'SO- stop being evil' Oct 30 '15 at 23:53
  • The resulting files on the destination server are corrupted, so no, the content is not the same. – Marco Marsala Oct 31 '15 at 9:58
  • I checked checksums with md5sum – Marco Marsala Oct 31 '15 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 '15 at 21:44
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?

| improve this answer | |
  • 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. – Gilles 'SO- stop being evil' Nov 2 '15 at 22:16
  • destination is ext3, source ext4. In my case --modify-window does the opposite – Marco Marsala Nov 3 '15 at 6:23

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