У нас есть большое количество файлов на удаленном сервере, для которых я бы хотел регулярно создавать резервные копии в локальной системе для дополнительной избыточности. Некоторые детали:
Похожий на:
0123456789/
0123456
abc/
1.fff
2.fff
3.fff
xyz/
9.fff
8.fff
7.fff
9877656578/
5674563
abc/
1.fff
2.fff
3.fff
xyz/
9.fff
8.fff
7.fff
с десятками тысяч этих корневых папок, содержащих лишь несколько внутренних структур папок / файлов, но все корневые папки имеют только числовые значения (0-9).
Я пробежал это прямо rsync -aP в первый раз и потребовалось 3196m20.040s. Частично это связано с тем, что поскольку удаленный сервер включен rsync 2.6.6 Я не могу использовать функции инкрементного файла, имеющиеся в 3.x.x. Составление списка файлов занимает почти 12 часов - примерно 500 файлов за 10 секунд. Я не ожидаю, что последующие запуски займут столько же времени, потому что при первом запуске нужно было загружать все заново, однако даже 12 часов только для списка файлов - это слишком долго.
Именование папок разбито как таковое:
$ ls | grep "^[^67]" | wc -l
295
$ ls | grep "^6" | wc -l
14167
$ ls | grep "^7" | wc -l
14414
Я тестировал запуск этого rsync -aWP --delete-during разбив его, используя --include="/0*/" --exclude="/*/" где я запускаю 8 из них одновременно с 0* 1* 2* 3* 4* 5* 8* 9* а для 6 и 7 я использую 60*-69* и 70*-79* потому что основная нагрузка папок в иерархии начинается с 6 или 7 (примерно 1400 на 6?* или 7?*).
Все это не 6 или 7, всего около 5 минут. Каталоги 6/7 (с разбивкой на 1/10) занимают 15 минут каждый.
Это довольно эффективно, за исключением того, что для выполнения этого задания мне нужно запустить 28 одновременных rsync и это приводит к насыщению доступного количества подключений, не говоря уже о потенциально насыщении сети.
Есть ли у кого-нибудь рекомендации по другому варианту rsync или некоторые дополнительные параметры, которые я мог бы добавить, чтобы предотвратить одновременное использование такого количества соединений без необходимости последовательно размещать это в границах rsync 2.6.6 на одном конце?
Редактировать # 1: Мы платим за пропускную способность к / от этого внешнего провайдера, поэтому в идеале мы должны отправлять по сети только те вещи, которые необходимо отправить, и не более того.
После первоначальной синхронизации в 40 часов для загрузки и синхронизации всех данных последующее сканирование и синхронизация тех же данных (только для получения обновлений) заняли всего 6,5 часов. Команда, используемая для запуска rsync был:
rsync -a --quiet USER@REMOTE_SERVER:ROOT/FOLDER/PATH/ /LOCAL/DESTINATION
Я думаю, что мое первоначальное время загрузки было двояким:
Первоначальный набор данных составляет 270 ГБ и ~ 2 млн файлов, что очень много для сканирования и загрузки через Интернет (в нашем случае у нас есть синхронное соединение 100 Мбит, и оно подключалось к крупному провайдеру CDN)
У меня были включены параметры -P и параметры -v при начальной синхронизации, что вызывало много болтовни локальной консоли, отображающей каждый синхронизируемый файл и информацию о ходе выполнения.
Итак, ответ здесь: просто используйте rsync с не таким большим количеством вариантов многословности (и --quiet в идеале), и это довольно эффективно - даже для огромных наборов данных.
Вот что я лично сделал бы - есть два варианта решения.
Вариант 1 - простой вариант перебора:
2M * 200 КБ - это примерно 400 ГБ, поэтому каждый раз делать полный снимок может быть невозможно. Если это возможно, простым решением было бы выполнить:
ssh <remote host> 'tar -c /directory/to/backup | <gzip/xz/lz4>' > backup.tar.<gz/xz/lz4>
Это работает так: все эти файлы превращаются в единый поток, который проталкивается по конвейеру, а не Rsync / SFTP перечисляет миллионы файлов.
Оттуда я бы использовал borg для дедупликации tar-файла, чтобы вы могли эффективно хранить несколько версий. Это распространенный трюк для очень быстрой передачи тонны небольших файлов. Обратной стороной является то, что вы не можете выполнять дедупликацию, которую выполняет RSync.
Если 400 ГБ на интервал слишком велико, я бы подумал о следующем:
Вариант 2 - умный вариант.
Вы можете выполнить следующее, за исключением того, что вы создадите архив для каждого каталога верхнего уровня и сравните хэш с существующим файлом на сервере резервного копирования. Если другое - перенесите, иначе ничего не делайте.
2M файлы означают много метаданных, поэтому ваш rsync запуски выполняются медленно из-за того, что как локальной, так и удаленной стороне необходимо просмотреть все метаданные.
Вы должны максимизировать ОЗУ на обоих концах и в идеале работать с rsync версия> 3.x Дело в том, что нельзя обновить rsync на удаленном конце позвольте мне думать, что вы не можете обновить RAM.
Последней попыткой было бы расставить приоритеты на обе локальная и удаленная сторона, кеширование метаданных. Вы можете попробовать установить vfs_cache_pressure=10, перезапустить rsync по крайней мере два раза и сравните производительность второго прогона после изменения параметра выше.