On 04/08/2019 16.29, Per Jessen wrote:
Carlos E. R. wrote:
You can see the asterisks on "--include=..." are not expanded.
Which they surely should be, unless quoted or escaped.
But they are not quoted nor escaped - you can see the exact command line I used in the previous post. The reason is, I understand, that bash knows it is an --option in the command line, not a parameter, which do get expanded.
Aha, that's interesting, I was not aware.
Me neither :-)
So, it is working except for the --link-dest thing - which is crucial to me, but is another issue. If that doesn't work, I'll have to use btrfs snapshots somehow.
Or use two rsyncs ...
I don't see how that will help to create the hard links to the old backup copy.
Maybe create them manually, afterwards?
You mean another rsync run, this time inside the server? I can only do that, besides the CPU load and time (about 10 hours) if the server disk can hold two different copies of the backup, and I suspect it can't. The backup is about 3.9TB, the capacity is 8TB. No, if rsync done to an rsyncd daemon doesn't support --link-dest (as it seems), the best remaining practical method is making use of btrfs snapshots (untested: does btrfs allways detect an overwrite of an existing file as the same file byte per byte and "link" it?). And of course, in that case I still have to send it all, using those 8 hours or more. The other method is not using the rsyncd daemon on the server, but using ssh transport on the client. All the job done on the client. I'll start a new thread about the --link-dest problem later. It should just work. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)