Rsync -avzHP следует за жесткими ссылками, а не копирует их как жесткие ссылки

Я использую rsnapshot для создания ежечасных / ежедневных / еженедельных / ежемесячных резервных копий моего "рабочего" ресурса. Сейчас я пытаюсь скопировать весь каталог резервного копирования на внешний диск с помощью rsync.

Я использовал эту команду / параметры в сеансе экрана (да, rsync-exclude.txt находится в папке, из которой я запускаю команду)

rsync -avzHP --exclude-from 'rsync-exclude.txt' /share/backup/ /share/eSATADisk1/backup/;

Все это работает на QNAP TS-439, внутренний диск представляет собой EXT4 с одним диском (без RAID), внешний диск - EXT3.

Происходит следующее: Rsync следует за каждой жесткой ссылкой и копирует реальный файл вместо воссоздания обновленной жесткой ссылки на внешнем диске. Я не сразу узнал об этом, поэтому внешний диск оказался разорван с копиями ххх тех же файлов.

Чего я хочу добиться: скопировать всю файловую структуру, сгенерированную rsnapshot, на внешний диск, сохранив жесткие ссылки для экономии места. Примечание: это не обязательно должно быть сделано с помощью rsync.

Спасибо за ваши идеи и время. Я буду признателен за вашу помощь, большое время.

Обновление: я узнал, что rsnapshot не использует символические ссылки, он использует жесткие ссылки, поэтому теперь я использую опцию -H, которая должна сохранять структуру жестких ссылок в соответствии с Rsnapshot для нескольких назначений (или поддерживать структуру жестких ссылок), но все равно не будет работать ... что мне здесь не хватает?

Обновление 2: я нашел другое мнение / утверждение по этой теме здесь: rsync с --hard-links замораживает Стивен Понедельник предлагает не пытаться rsync больших файловых структур, содержащих жесткие ссылки, так как он поглощает много памяти и является сложной задачей для rsync. Поэтому, вероятно, лучшим решением было бы создание .img структуры данных, которую я пытаюсь сделать резервной копией. Что вы думаете?

Опция rsyncкоманды -H(или --hard-links) теоретически сделает то, что вы пытаетесь выполнить, а именно, вкратце: создать копию вашей файловой системы, которая сохраняет жестко связанную структуру оригинала. Как я уже упоминал в своем ответе на другой подобный вопрос , эта опция обречена на провал, когда ваша исходная файловая система выходит за пределы определенного порога сложности жестких ссылок.

Точное расположение этого порога может зависеть от вашей оперативной памяти и общего количества жестких ссылок (и, возможно, ряда других вещей), но я обнаружил, что нет смысла пытаться определить его точно. Что действительно важно, так это то, что этот порог слишком легко преодолеть в реальных ситуациях, и вы не будете знать, что вы его переступили, пока не настанет день, когда вы попытаетесь запустить rsync -aHили забастовку, cp -aкоторая в конечном итоге терпит неудачу ,

Я рекомендую следующее: скопируйте жестко связанную файловую систему как единое целое, а не как файлы. То есть скопируйте весь раздел файловой системы как один большой двоичный объект. Для этого есть ряд инструментов, но наиболее распространенным является dd.

При наличии стоковой прошивки ваш QNAP NAS также должен быть ddвстроенным fdisk. С помощью fdisk, создайте раздел на целевом диске, по крайней мере, такой же, как исходный раздел. Затем используйте ddдля создания точной копии исходного раздела во вновь созданном целевом разделе.

Во время выполнения ddкопии вы должны убедиться, что в исходной файловой системе ничего не изменится, чтобы в конечном итоге вы не получили поврежденную копию в месте назначения. Один из способов сделать это - обратиться umountк источнику перед началом процесса копирования; Другой способ - подключить источник в режиме только для чтения.

-l для символических ссылок, зачем делать что-то для жестких ссылок?

(Извините, это ответ, а не комментарий, у меня еще нет прав на комментарии, и на этот ответ нужен ответ)

Еще одно замечание, которое должно быть комментарием: это все аппаратное обеспечение или вы на виртуальной машине, монтируете сеть?

редактировать

игнорировать мой предыдущий комментарий о том, почему вы используете жесткие ссылки, я пропустил rsnapshotкомментарий.

Было бы полезно иметь тест, который сначала проверяет rsync между двумя локальными каталогами на локальном диске, а затем на вашем удаленном диске. Этот небольшой тест показывает -Hвариант работы, как и ожидалось. -iВариант для lsшоу инодов, тем самым показывая , что ссылки были сохранены без каких - либо дополнительных копий.

$ rsync -avzHP src/ dest
sending incremental file list
created directory dest
./
file111_prime.txt
           9 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/3)
file111.txt => file111_prime.txt

sent 156 bytes  received 59 bytes  430.00 bytes/sec
total size is 18  speedup is 0.08

$ ls -liR
.:
total 8
414044 drwxrwxr-x. 2 nhed nhed 4096 Feb 25 09:58 dest
414031 drwxrwxr-x. 2 nhed nhed 4096 Feb 25 09:58 src

./dest:
total 8
414046 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111_prime.txt
414046 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111.txt

./src:
total 8
414032 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111_prime.txt
414032 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111.txt

Последующий тест rsync -avzHP src/ host:/tmpна удаленном хосте все еще поддерживал жесткие ссылки

Это длинный путь, но если вы не можете найти другое решение, я бы посоветовал попытаться отформатировать USB-накопитель как EXT4. Может быть, это может быть проблема: https://bugzilla.samba.org/show_bug.cgi?id=7670

При наличии достаточно жестких ссылок в исходной папке и достаточно небольшого целевого тома копирование с помощью rsync --hard-links может завершиться неудачно. Rsync терпит неудачу из-за исчерпания максимального количества жестких ссылок в месте назначения <...> реальная проблема не в rsync, а в базовой файловой системе.

Вы пытались добавить -lопцию?

Я знаю, что страница руководства говорит, что она включена, -aно страницы руководства не всегда на 100% точны.