On 14/10/2020 16.27, Dave Howorth wrote:
On Wed, 14 Oct 2020 11:50:43 +0200 "Carlos E. R." <> wrote:
On 14/10/2020 11.38, Dave Howorth wrote:
On Wed, 14 Oct 2020 10:48:20 +0200 (CEST) "Carlos E. R." <> wrote:
...
OK, the manual says:
"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."
I suspect your second set of rsyncs meets that caveat and so your files are unlinked. Copy the whole lot in one transfer and it may work.
Yes, I imagined this was the case (didn't read that part of the manual) and tried again: OPTIONS="--archive --acls --xattrs --hard-links --sparse --partial-dir=.rsync-partial --stats --human-readable" time rsync $OPTIONS --exclude "sda?_root" root@telcontar.valinor://data/Datum/mountpoint/ /data/ and it worked: Erebor:/data # ls -ltr --inode Portatil_entero_?/rsync_Home/cer/spamassassin.zip 1778503 -rw-r--r-- 2 cer users 7592643 Jun 10 2016 Portatil_entero_7/rsync_Home/cer/spamassassin.zip 1778503 -rw-r--r-- 2 cer users 7592643 Jun 10 2016 Portatil_entero_6/rsync_Home/cer/spamassassin.zip Erebor:/data #
I also know that rsync can create hard-links on the fly in the destination even when there's no such concept on the source side. I know because that's how my incremental full backup works. But I don't remember the full set of flags at the mo. But if you can figure out the flags, that would presumably also correct your problem. I'll look it up if you get stuck.
Actually, the source tree was created that way, they are an incremental backup :-) That's why the number of hard links is significant, not copying them meant disk full on the destination. (Ie, I'm copying an incremental backup set that was done with rsync initially) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)