У меня есть большой каталог под названием 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 не решил проблему.
Есть идеи, что случилось?
Адам
Мой ответ, который я даю на основании с трудом заработанного опыта: не делайте этого. Не пытайтесь скопировать иерархию каталогов, в которой интенсивно используются жесткие ссылки, например, созданная с помощью rsnapshot или rsync --link-dest или похожие. Он не будет работать ни с чем, кроме небольших наборов данных. По крайней мере, не достоверно. (Ваш опыт, конечно, может отличаться; возможно, ваши наборы данных резервных копий намного меньше моих.)
Проблема с использованием rsync --hard-links для воссоздания жестко связанной структуры файлов на стороне назначения заключается в том, что обнаружение жестких ссылок на стороне источника жесткий. rsync должен построить карту inodes в памяти, чтобы найти жесткие ссылки, и если ваш источник не имеет относительно небольшого количества файлов, это может и будет взорваться. В моем случае, когда я узнал об этой проблеме и искал альтернативные решения, я попробовал cp -a, который также должен сохранять жесткую структуру файлов в месте назначения. Он долго сбивался и наконец умер (с ошибкой или чем-то в этом роде).
Я рекомендую выделить целый раздел для вашего rsnapshot резервное копирование. Когда он заполнится, подключите другой раздел. Гораздо проще перемещать наборы данных с жесткими связями как целые разделы, а не как отдельные файлы.
В этот момент кажется, что rsync завис, завис или просто занят? Проверьте активность процессора с помощью top и дисковая активность с iotop -o.
Возможно, он был занят копированием большого файла. Вы бы увидели это в iotop или аналогичный, или на дисплее rsync, если вы запускали его с --progress вариант.
Он также может быть занят сканированием списков inodes для проверки связанных файлов. Если используется инкрементная рекурсия, которая используется по умолчанию для рекурсивных передач, в большинстве случаев, если и клиент, и сервер имеют rsync v3.0.0 или новее, он мог просто попасть в каталог со многими файлами и запустить проверку связи между всеми файлами. в нем и все найденные ранее. В --hard-links вариант может быть очень Процессор интенсивно загружает большие наборы файлов (поэтому он не включен в список опций, подразумеваемых общим --archive вариант). Это будет проявляться в высокой загрузке ЦП в то время, когда rsync кажется приостановленным / зависшим.
У меня такая же проблема. Моя проблема была решена добавлением --no-inc-recursive вариант.
Из https://download.samba.org/pub/rsync/rsync.html:
Если инкрементная рекурсия активна (см.
--recursive), rsync может передать отсутствующий жестко связанный файл до того, как обнаружит, что другая ссылка для этого содержимого существует где-то в другом месте иерархии.Это не влияет на точность передачи (то есть какие файлы жестко связаны друг с другом), а только на ее эффективность (т.е. копирование данных для новой, ранней копии файла с жесткой связью, которая могла быть найдена позже при передаче в другой член жестко связанного набора файлов).
Один из способов избежать этой неэффективности - отключить инкрементную рекурсию с помощью
--no-inc-recursiveвариант.