☰

Разбиваете большие rsync-передачи?

tag-icon • tag-icon backup rsync file-transfer
Разбиваете большие rsync-передачи?

Мы используем rsync для обновления зеркала нашего основного файлового сервера на удаленном сервере резервного копирования. Одна из проблем, с которой мы сейчас сталкиваемся, заключается в том, что на нашем файловом сервере > 1 ТБ в основном небольших файлов (в диапазоне 10-100 КБ), и когда мы передаем столько данных, мы часто сталкиваемся с разрывом соединения через несколько часов после начала передачи. В Rsync нет функции возобновления/повтора, которая просто повторно подключается к серверу, чтобы продолжить с того места, на котором остановились, — вам нужно пройти процесс сравнения файлов, который в итоге оказывается очень долгим с учетом количества файлов, которые у нас есть.

Решение, которое рекомендуется обойти, — разбить большую передачу rsync на серию более мелких передач. Я понял, что лучший способ сделать это — использовать первую букву имен каталогов верхнего уровня, что не даст нам идеально равномерного распределения, но вполне достаточно.

Я хотел бы убедиться, что моя методология разумна или есть более простой способ достичь цели.

Для этого я перебираю AZ, az, 0-9, чтобы выбрать один символ $prefix. Сначала я думал просто запустить

rsync -av --delete --delete-excluded --exclude "*.mp3" "src/$prefix*" dest/

(--exclude "*.mp3" — это всего лишь пример, поскольку у нас есть более длинный список исключений для удаления таких вещей, как временные файлы)

Проблема в том, что любые каталоги верхнего уровня в dest/, которые больше не присутствуют в src, не будут выбраны --delete. Чтобы обойти это, я вместо этого пробую следующее:

rsync \
--filter 'S /$prefix*' \
--filter 'R /$prefix*' \
--filter 'H /*' \
--filter 'P /*' \
-av --delete --delete-excluded --exclude "*.mp3" src/ dest/

Я использую showand hideнад includeand exclude, потому что в противном случае --delete-excluded удалит все, что не соответствует $prefix.

Является ли это наиболее эффективным способом разбить rsync на более мелкие части? Есть ли более эффективный инструмент или флаг, который я пропустил, который может сделать это более простым?

решение1

Моим решением этой проблемы стал другой двухпроходный подход, в котором я жертвую некоторым дисковым пространством. Я делаю rsync --only-write-batch на сервере, затем rsync самого пакетного файла в место назначения, повторяя цикл до тех пор, пока rsync не завершится успешно. После того, как пакет полностью завершится, rsync --read-batch в месте назначения воссоздает все изменения.

Для меня это также дало некоторые непредвиденные преимущества:

  • поскольку я больше беспокоюсь о том, что резервная копия «существует», чем о том, что она «пригодна к использованию», я на самом деле не читаю пакет данных на принимающей стороне каждый день — в большинстве случаев пакет относительно небольшой

  • Я экспериментировал с --checksum-seed=1... Возможно, я неправильно читаю документацию, но мне кажется, что это делает пакетные файлы более синхронизируемыми (т. е. когда я не использую --read-batch в какой-либо день, пакет следующего дня синхронизируется быстрее, поскольку пакет предыдущего дня является хорошей основой).

  • если пакет становится слишком большим для отправки "вовремя" через интернет, я могу переслать его по сети на внешний диск. Под "вовремя" я подразумеваю, что если я не успею отправить пакет и прочитать его до начала резервного копирования следующего дня.

  • Хотя лично я этого не делаю, я мог бы иметь два внешних резервных копирования в разных местах и ​​отправлять пакет в оба из них.

решение2

Это не совсем ответ на ваш вопрос, но другой вариант, который я использую довольно часто, — это двухпроходный подход: сначала создаем список файлов, затем разделяем список файлов для передачи и передаем его в rsync/cpio/cp и т. д.

rsync --itemize-changes <rest of options>выведет список файлов для передачи с кучей полезных метаданных, из этого вывода довольно легко извлечь имена файлов, а затем выполнить фактическое копирование с помощью одного из этих rsync --files-fromили другого инструмента.

Может быть полезно в вашей ситуации — возобновление прерванной передачи будет гораздо быстрее.

решение3

Я бы посоветовал вам разобраться в проблеме с подключением, а не пытаться решить ее, создавая еще одну «проблему».

Это не обычное поведение. Вы используете rsync через SSH или rsyncd?

Насколько мне известно, большинство «закрытых» соединений возникают, когда между конечными точками не происходит передачи данных.

Связанный контент