I have a filesystem, /mnt/tosh, that I want to transfer periodically to a backup over ssh using rsync.
It contains a subdir /mnt/tosh/vorbis that itself contains dirs that contain hard links, eg
glower /mnt/tosh/vorbis/yayas> ls -l
total 111872
-rw-rw-r-- 2 jg jg 9708988 Sep 30 2023 yayas001.mp3
-rw-rw-r-- 2 jg jg 9081135 Sep 30 2023 yayas002.mp3
-rw-rw-r-- 2 jg jg 9071545 Sep 30 2023 yayas003.mp3
-rw-rw-r-- 2 jg jg 11862262 Sep 30 2023 yayas004.mp3
-rw-rw-r-- 2 jg jg 21782906 Sep 30 2023 yayas005.mp3
-rw-rw-r-- 2 jg jg 16468352 Sep 30 2023 yayas006.mp3
-rw-rw-r-- 2 jg jg 7306102 Sep 30 2023 yayas007.mp3
-rw-rw-r-- 2 jg jg 10929144 Sep 30 2023 yayas008.mp3
-rw-rw-r-- 2 jg jg 8580986 Sep 30 2023 yayas009.mp3
-rw-rw-r-- 2 jg jg 9743549 Sep 30 2023 yayas010.mp3
glower /mnt/tosh/vorbis/yayas>
. but after doing this:
$ rsync -avH --delete -e ssh --max-alloc=100M /mnt/tosh minako:/drobojoin
I'm finding spurious repeated hard link dotfiles on the target after it completes:
minako /drobojoin/tosh/vorbis/yayas> ls -la
total 224096
drwxrwxr-x 2 jg jg 4096 Jul 16 14:29 .
drwxrwxr-x 194 jg jg 4096 Aug 23 11:09 ..
-rw-rw-r-- 3 jg jg 9708988 Sep 30 2023 yayas001.mp3
-rw-rw-r-- 3 jg jg 9708988 Sep 30 2023 .yayas001.mp3.3008
-rw-rw-r-- 3 jg jg 9081135 Sep 30 2023 yayas002.mp3
-rw-rw-r-- 3 jg jg 9081135 Sep 30 2023 .yayas002.mp3.3008
-rw-rw-r-- 3 jg jg 9071545 Sep 30 2023 yayas003.mp3
-rw-rw-r-- 3 jg jg 9071545 Sep 30 2023 .yayas003.mp3.3008
-rw-rw-r-- 3 jg jg 11862262 Sep 30 2023 yayas004.mp3
-rw-rw-r-- 3 jg jg 11862262 Sep 30 2023 .yayas004.mp3.3008
-rw-rw-r-- 3 jg jg 21782906 Sep 30 2023 yayas005.mp3
-rw-rw-r-- 3 jg jg 21782906 Sep 30 2023 .yayas005.mp3.3008
-rw-rw-r-- 3 jg jg 16468352 Sep 30 2023 yayas006.mp3
-rw-rw-r-- 3 jg jg 16468352 Sep 30 2023 .yayas006.mp3.3008
-rw-rw-r-- 3 jg jg 7306102 Sep 30 2023 yayas007.mp3
-rw-rw-r-- 3 jg jg 7306102 Sep 30 2023 .yayas007.mp3.3008
-rw-rw-r-- 3 jg jg 10929144 Sep 30 2023 yayas008.mp3
-rw-rw-r-- 3 jg jg 10929144 Sep 30 2023 .yayas008.mp3.3008
-rw-rw-r-- 3 jg jg 8580986 Sep 30 2023 yayas009.mp3
-rw-rw-r-- 3 jg jg 8580986 Sep 30 2023 .yayas009.mp3.3008
-rw-rw-r-- 3 jg jg 9743549 Sep 30 2023 yayas010.mp3
-rw-rw-r-- 3 jg jg 9743549 Sep 30 2023 .yayas010.mp3.3008
minako /drobojoin/tosh/vorbis/yayas>
If I just transfer the vorbis dir in isolation, ie:
$ rsync -avH --delete -e ssh /mnt/tosh/vorbis minako:/drobojoin/tosh
I don't get the spurious files. So it seems to be related to the scale or complexity of the transfer. There's an easy workaround of course (ie to exclude vorbis from a first pass and transfer separately later). But I think it must be a bug. Annoying.
My Blueiris windows server vm stopped sending motion detection emails for the camera in garage which is set to send any time.. the rest are more for overnight events.. checked the ai log and there was a few time outs on it.. did the usual reboots stop/ start services.. still the same.. had a full backup of the vm on veeam from a few months ago.. restored that and it's back to normal.. wondering if a windows update was the problem.. anyway will run with the restore and bin the now powered off duffer
Corrupt disk on my shared storage.. managed to move all the vms off to local storage.. new disk arriving tomorrow..
Removed the disk and checked and appears ok... bit odd.. all checks come back as healthy...
Definitely the hardware, not just filesystem corruption?
Rebuilt the storage from scratch along with the new disk.. xpenology on an hp elitedesk using the arc installer... so far so good.. vm motioning back to the shared storage