Мы используем rsync для обновления зеркала нашего основного файлового сервера на удаленный резервный сервер. Одна из проблем, с которыми мы сейчас сталкиваемся, заключается в том, что на нашем файловом сервере содержится> 1 ТБ файлов в основном меньшего размера (в диапазоне 10-100 КБ), и когда мы передаем такой объем данных, мы часто заканчиваем тем, что соединение разрывается на несколько часов после перевод. Rsync не имеет функции возобновления / повторной попытки, которая просто повторно подключается к серверу, чтобы продолжить с того места, на котором он остановился - вам нужно пройти процесс сравнения файлов, который в конечном итоге оказывается очень длинным с учетом количества файлов, которые у нас есть.
Рекомендуемое решение - разделить большую передачу rsync на серию более мелких передач. Я решил, что лучший способ сделать это - по первой букве имен каталогов верхнего уровня, что не дает нам идеально равномерного распределения, но достаточно хорошо.
Я хотел бы подтвердить, разумна ли моя методика для этого или есть более простой способ достичь цели.
Для этого я перебираю A-Z, a-z, 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/
Я использую show и hide над include и exclude, потому что в противном случае --delete-excluded удалит все, что не соответствует префиксу $.
Это самый эффективный способ разбить rsync на более мелкие части? Есть ли более эффективный инструмент или флаг, который я пропустил, чтобы упростить задачу?
Моим решением был другой двухпроходный подход, при котором я терял часть дискового пространства. Я выполняю rsync --only-write-batch на сервере, затем rsync сам пакетный файл до места назначения, зацикливаясь, пока rsync не завершится успешно. Как только пакет полностью завершится, rsync --read-batch в пункте назначения воссоздает все изменения.
Для меня это также принесет некоторые непредвиденные выгоды:
потому что меня больше беспокоит то, что резервная копия «существует», чем «пригодна для использования». Я на самом деле не выполняю пакет чтения на принимающей стороне каждый день - большую часть времени пакет относительно небольшой
Я экспериментировал с --checksum-seed = 1 ... Возможно, я неправильно читаю документацию, но я думаю, что это делает командные файлы более синхронизируемыми (т.е. когда я не выполняю --read-batch any в данный день пакет на следующий день синхронизируется быстрее, потому что пакет предыдущего дня является хорошей основой)
если пакет становится слишком большим для отправки «вовремя» через Интернет, я могу переместить его на внешний диск. Под своевременностью я подразумеваю, что если я не могу получить пакет и прочитать его до того, как начнется резервное копирование на следующий день.
хотя я лично не делаю этого, я мог бы иметь две резервные копии вне офиса в разных местах и отправлять пакет им обоим.
Не совсем отвечаю на ваш вопрос, но другой вариант, который я использую довольно часто, заключается в двухпроходном подходе: сначала создайте список файлов, затем разделите список файлов для передачи и загрузите список файлов в rsync / cpio / cp и т. Д. .
rsync --itemize-changes <rest of options> распечатает список файлов для передачи с кучей полезных метаданных, из этого вывода довольно легко извлечь имена файлов, а затем выполнить фактическое копирование с помощью rsync --files-from или другой инструмент.
Это может быть полезно в вашей ситуации - восстановление после прерванной передачи будет намного быстрее.
Я бы посоветовал вам продолжить изучение проблемы с подключением, а не пытаться решить ее, создавая еще одну «проблему».
Это не обычное поведение. Вы используете rsync через SSH или rsyncd?
Насколько мне известно, большинство «закрытых» соединений происходит, когда между конечными точками не передаются данные.