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?

closed as off-topic by roaima, garethTheRed, Archemar, dhag, jimmij Nov 13 '15 at 2:56

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – roaima, garethTheRed, Archemar, dhag, jimmij
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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 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?

  • 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 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.