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

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

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

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

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

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

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

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

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

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

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

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

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

С предустановленным программным обеспечением ваш NAS QNAP должен иметь 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% точны.

кратко: Для устранения проблемы вы можете попробовать использовать опцию --no-inc-recursive с rsync.

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

1. Если rsync находит существующую жесткую ссылку как в источнике, так и в назначении перед тем, как столкнуться с новой жесткой ссылкой, которая присутствует только в источнике, новая жесткая ссылка может быть правильно сохранена, поскольку старая уже была обнаружена.

2. Если новая жесткая ссылка, которая уникальна для источника, будет обнаружена первой, и соответствующая оригинальная жесткая ссылка еще не была найдена, rsync будет рассматривать новую жесткую ссылку как поврежденную и скопирует файл в назначение вместо того, чтобы сохранить жесткую ссылку.

Для второго сценария использование опции -vvvv (для включения очень подробного режима) позволяет вам отслеживать процесс и подтверждать, что сохранение жесткой ссылки не удается, когда предшествующая жесткая ссылка не была обнаружена. Напротив, успешное сохранение жесткой ссылки указывает на то, что оригинальная жесткая ссылка была найдена в назначении заранее.

Согласно документации rsync:

Если инкрементальная рекурсия активна (см. --recursive), rsync может передать отсутствующий жестко связанный файл, прежде чем обнаружит, что другая ссылка на это содержимое существует где-то еще в иерархии.

Это не влияет на точность передачи (т.е. на то, какие файлы жестко связаны между собой), только на ее эффективность (т.е. копирование данных для новой, ранней копии жестко связанного файла, которую можно было бы найти позже в передаче в другом элементе набора жестко связанных файлов).

Один из способов избежать этой неэффективности — отключить инкрементальную рекурсию, используя опцию --no-inc-recursive.

Чтобы предотвратить эту неэффективность, вы можете отключить инкрементальную рекурсию, используя опцию --no-inc-recursive. Этот подход гарантирует, что rsync сначала просканирует всю иерархию, что позволит ему правильно идентифицировать и сохранить все жесткие ссылки в процессе синхронизации.