rsync с --hard-links зависает
У меня есть большой каталог под названием servers, который содержит много жестких ссылок, сделанных rsnapshot, Это означает, что структура более или менее похожа на:
./servers
./servers/daily.0
./servers/daily.0/file1
./servers/daily.0/file2
./servers/daily.0/file3
./servers/daily.1
./servers/daily.1/file1
./servers/daily.1/file2
./servers/daily.1/file3
...
Снимки были созданы с rsnapshot компактным способом: если /servers/daily.0/file1 такой же как /servers/daily.1/file1они оба указывают на один и тот же индекс, используя жесткую ссылку, вместо того, чтобы просто копировать полный снимок каждый цикл./servers/daily.0/file1/servers/daily.0/file1
Я попытался скопировать его со структурой жестких ссылок, чтобы сэкономить место на диске назначения, используя:
nohup time rsync -avr --remove-source-files --hard-links servers /old_backups
Через некоторое время rsync зависает - новые строки не добавляются nohup.out файл, и нет файлов, кажется, перемещаться с одного диска на другой. Удаление nohup не решил проблему.
Есть идеи, что случилось?
Адам
3 ответа
Мой ответ, который я даю из с трудом заработанного опыта, таков: не делай этого. Не пытайтесь скопировать иерархию каталогов, которая интенсивно использует жесткие ссылки, например, созданные с использованием rsnapshot или же rsync --link-dest или похожие. Он не будет работать ни с чем, кроме небольших наборов данных. По крайней мере, ненадежно. (Конечно, ваш пробег может отличаться; возможно, ваши резервные наборы данных намного меньше моего).
Проблема с использованием rsync --hard-links Чтобы воссоздать жестко связанную структуру файлов на стороне назначения, трудно обнаружить жесткие ссылки на стороне источника. rsync чтобы найти жесткие ссылки, нужно построить карту inode в памяти, и, если у вашего источника относительно мало файлов, это может взорваться. В моем случае, когда я узнал об этой проблеме и искал альтернативные решения, я попытался cp -a, который также должен сохранять структуру жестких ссылок файлов в месте назначения. Он долго откалывался, а потом, наконец, умер (с сегфоутом или чем-то в этом роде).
Я рекомендую выделить целый раздел для вашего rsnapshot резервный. Когда он заполнится, подключите другой раздел к сети. Гораздо проще перемещаться по наборам данных с жесткими ссылками как целые разделы, а не как отдельные файлы.
В этот момент кажется, что rsync зависает, он завис или просто занят? Проверьте активность процессора с top и активность диска с iotop -o,
Это может быть занято копированием большого файла. Вы бы увидели это в iotop или аналогичный, или на экране rsync, если вы запустили его с --progress вариант.
Он также может быть занят сканированием списков инодов для проверки связанных файлов. Если используется инкрементная рекурсия, которая по умолчанию используется для рекурсивных передач в большинстве случаев, если и клиент, и сервер имеют rsync v3.0.0 или новее, он мог просто попасть в каталог с множеством файлов и запустить проверку связи между всеми файлами в нем и всех найденных ранее. --hard-links опция может сильно загружать процессор при работе с большими наборами файлов (поэтому она не включена в список опций, подразумеваемых общими --archive опция). Это проявится в высокой загрузке ЦП в тот момент, когда rsync кажется приостановленным / зависшим.
У меня такая же проблема. Моя проблема была решена путем добавления --no-inc-recursive вариант.