Мы делаем резервные копии с помощью rsync следующим образом:
rsync -axH --inplace --delete --delete-excluded \
--exclude-from=excludes --stats \
--link-dest="${previous?}" "${source?}"/ "${dest?}"/"${stamp?}"
$ previous указывает на предыдущую резервную копию, поэтому неизмененные файлы будут созданы с использованием жестких ссылок. Целевая файловая система $ dest находится на внешнем жестком USB-диске, на котором нет ничего, кроме коллекции резервных копий.
Этот метод в большинстве случаев работает удивительно быстро. В тестовой системе каждая резервная копия имеет размер около 200 ГБ и содержит несколько больших maildirs - тем не менее, весь rsync (при условии, что с момента последнего запуска мало что изменилось) занимает всего около минуты.
Однако в редких случаях, может быть, в среднем каждые 100 запусков, это занимает очень много времени, около 20 минут или больше. Статистика rsync не показывает ничего необычного. Хост-система не проявляет необычной активности во время таких прогонов. Ничего интересного в системном журнале.
На некоторых файловых системах (для $ dest) это хуже, чем на других. Вышеуказанные цифры относятся к EXT4. Например, в JFS нормальный запуск занимает около 3 минут, а исключительный запуск менее серьезен, но по-прежнему является для нас проблемой.
Взгляд на отладочные данные rsync показывает, что во время длительных прогонов обнаруживается, что некоторые (большие) файлы не обновлены, хотя они не были изменены на отправителе. Для этих файлов не создаются жесткие ссылки, как показывает их индексный дескриптор. Но статистика rsync не показывает больше переданных байтов, чем обычно, и, судя по светодиодным индикаторам активности жесткого диска, в этих случаях работает только целевой диск. Копируются ли эти файлы в место назначения из одного каталога в другой? Это оказывается не только проблемой производительности, но также может привести к ненужному расходу места.
В случае необходимости: непосредственно перед резервным копированием самая старая из существующих резервных копий удаляется с помощью:
rsync -a --delete empty/ "${dest?}"/"${old?}"
где «пустой» - это пустой каталог. Это намного быстрее, чем rm -fr.
Может ли кто-нибудь предложить возможные объяснения этого и, возможно, лекарство?
Использование протокола rsync версии 3.1.0 версии 31.
Краткий ответ: виновником было то, как мы удалили старые каталоги резервных копий, а именно rsyncing пустого каталога. Теперь мы используем:
find "${old?}" -delete Это также быстро и позволяет избежать проблем.
Более длинный ответ: на самом деле, прогоны, которые длились исключительно долго, были абсолютно детерминированными. Мы всегда храним несколько, скажем, n резервных копий и удаляем самую старую перед выполнением новой. Каждое (n + 1) -е резервное копирование занимало много времени. Похоже, что при удалении старой резервной копии с помощью rsync часть ее каким-то образом становится недействительной для операции --link-dest, поэтому некоторые файлы не связаны жестко, а копируются (очевидно, копируются из самой файловой системы назначения). Эта процедура копирования запускает новый «период», который заканчивается, когда первая его резервная копия удаляется, что происходит после n запусков. Скорее всего, это связано с ошибкой в rsync или ядре, но я не буду исследовать дальше.