2

On the source server (A), I got a file /opt/resources/xxx and a hard link /etc/apache2/sites-available/xxx pointing to this file.

On another server (B) I got the same structure /etc/apache2/sites-available/xxx hard linked to /opt/resources/xxx

I rsync on server (A) towards server (B) all changes under /opt

When I change file xxx on server A, and then rsync to server B these changes are reflected. /opt/resources/xxx on server B contains my changes I made on the same file on server A.

The only thing I don't understand is that the file /etc/apache2/sites-available/xxx doesn't contain the change.

It appears as if rsync breaks the hard link, but probably I'm missing some configuration option.

Which one ?

Francis

Improve this question

2 Answers 2

Reset to default
7

-H is the option for preserving hard links; it is not included in -a.

Improve this answer
1
  • 2
    Your answer is not correct. Option -H has nothing to do with asked issue. Option -H is used to preserve harlinks on target when e.g. two or more files on source are hardlinked so files rsynced to target will be also hardlinked. Without his option files on target will be copies (which consumes more space on disk). To solve asked issue --inplace option must be used because it seems that rsync by default uploads changed file with temporary name, delete old file and rename temporary to origin name. Deletion causes issue = breaking existing hardlinks on target.
    – mikep
    Nov 8, 2019 at 8:42
6

rsyncs handling of hardlinks depends on you sending ALL linked files in a single transfer (syncing both /etc/apache2/sites-available/ and /opt/resources/ to server B at once):

Note that rsync can only detect hard links between files that are inside the transfer set. If rsync updates a file that has extra hard-link connections to files outside the transfer, that linkage will be broken.

This is because by default, rsync writes the file to a new location then moves it over the top of the previous file, essentially erasing the original hard link and replacing it with a new file. It suggests using the --inplace option to change this default, but warns that there are risks to that, most notably:

(2) the file's data will be in an inconsistent state during the transfer, (3) a file's data may be left in an inconsistent state after the transfer if the transfer is interrupted or if an update fails

Improve this answer
1
  • Yes, --inplace solved issue. But when debugging rsync upload process by adding more --verbose options there is no mention about deletion origin file when --inplace is not used - there is just mention about renaming e.g. renaming file file.txt.CB4RX0 to file.txt. I have tested that after renaming hardlinked file on linux with mv command hardlinks are still preserverd - so renaming does not break hardlinks (only deletion). So how it is possible that renaming operation in rsync world breaks hardlinks? Btw. to find hardlinks of some file use find / -samefile /x/file.txt -printf "%p\n".
    – mikep
    Nov 8, 2019 at 8:35

You must log in to answer this question.

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