Я использую rsnapshot для создания ежечасных / ежедневных / еженедельных / ежемесячных резервных копий моей "рабочей" -доля. Теперь я пытаюсь скопировать весь резервный каталог на внешний диск с помощью rsync.
Я использовал эту команду / параметры в сеансе экрана (да, rsync-exclude.txt находится в каталоге, из которого я запускаю команду)
rsync -avzHP --exclude-from 'rsync-exclude.txt' /share/backup/ /share/eSATADisk1/backup/;
Все это работает на QNAP TS-439, внутренний диск - это один диск (без RAID), формат EXT4, внешний диск - 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 источник перед началом копирования; Другой способ - смонтировать источник в режиме только для чтения.
Это долгий путь, но если вы не можете найти другое решение, я бы предложил попробовать отформатировать USB-накопитель как EXT4. Может быть, проблема в этом: https://bugzilla.samba.org/show_bug.cgi?id=7670
При наличии достаточного количества жестких ссылок в исходной папке и достаточно небольшого целевого тома копирование с помощью rsync --hard-links может завершиться ошибкой. Rsync не работает из-за исчерпания максимального количества жестких ссылок в месте назначения <...> реальная проблема не в rsync, а в базовой файловой системе.
-l для символических ссылок, зачем ему делать что-то для жестких ссылок?
(Извините, это ответ, а не комментарий, у меня еще нет прав на комментарий, и этот ответ требует ответа)
Еще одно замечание, которое должно быть комментарием: это все собственное оборудование или вы используете виртуальную машину, подключенную к сети?
игнорируйте мой предыдущий комментарий относительно того, почему вы используете жесткие ссылки, я пропустил rsnapshot комментарий.
Было бы полезно иметь тест, который сначала проверяет rsync между двумя локальными каталогами на локальном диске, а затем на вашем удаленном диске. Этот небольшой тест показывает -H вариант wokrs как и ожидалось. В -i вариант для ls показывает inodes, таким образом показывая, что ссылки были сохранены без дополнительных копий.
$ 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 к удаленному хосту все еще поддерживаются жесткие ссылки
Вы пробовали добавить -l вариант?
Я знаю страницу руководства говорит что это включено в -a но страницы руководства не всегда точны на 100%.