Лучший способ скопировать миллионы файлов между двумя серверами

У меня есть около 5 миллионов маленьких (5-30 тыс.) Файлов в одном каталоге, которые я хотел бы скопировать на другой компьютер в той же гигабитной сети. Я попытался использовать rsync, но после нескольких часов работы он замедлится до сканирования, я полагаю, из-за того, что rsync должен каждый раз проверять файл источника и назначения?

Моей второй мыслью было бы использовать scp, но я хотел узнать мнение других людей, чтобы узнать, есть ли лучший способ. Благодарность!

Примерно так должно хорошо работать:

tar c some/dir | gzip - |  ssh host2 tar xz

Возможно, также опустите gzip и флаг "z" для извлечения, так как вы находитесь в гигабитной сети.

Я уверен, что тот факт, что у вас есть все ПЯТЬ МИЛЛИОНОВ файлов в одном каталоге, приведёт в замешательство множество инструментов. Я не удивлен, что rsync не справился с этим изящно - это довольно «уникальная» ситуация. Если бы вы могли найти способ структурировать файлы в какую-то структуру каталогов, я уверен, что стандартные инструменты синхронизации, такие как rsync, будут гораздо более отзывчивыми.

Тем не менее, просто для того, чтобы дать какой-то реальный совет - возможно, одним из решений было бы физическое перемещение накопителя на конечный компьютер, чтобы вы могли сделать копию файлов на реальном сервере (не по сети). Затем переместите диск назад и используйте rsync, чтобы поддерживать актуальность.

Чтобы скопировать миллионы файлов через гигабитный коммутатор (в доверенной среде), вы также можете использовать комбинацию netcat (or nc)и tar, как уже было предложено пользователем 55286. Это приведет к потоковой передаче всех файлов как одного большого файла (см. Быстрое копирование файлов - Linux! (39 ГБ) ).

# requires netcat on both servers
nc -l -p 2342 | tar -C /target/dir -xzf -   # destination box
tar -cz /source/dir | nc Target_Box 2342    # source box

У нас было около 1 миллиона файлов в каталоге (около 4 лет).

И мы использовали robocopy для перемещения файлов в каталог YYYY / MM (около 35-45 000 файлов в месяц). Мы поместили скрипт robocopy в файл .bat, например так:

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081201 /MINAGE:20090101 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\12
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090101 /MINAGE:20090201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\01
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090201 /MINAGE:20090301 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\02

краткие заметки .. /ns /nc /nfl /npэто для того, чтобы избежать раздувания файла журнала с дополнительной информацией /log+..., чтобы записать сводную информацию в файл журнала.

/minage and /maxage is to copy files modified with in that date range. 

так, например, файлы, измененные> = 01 / ноябрь 2008 года (включительно) для файлов, измененных <01 / декабря / 2008 (не включительно)

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11

/mov переместить файлы

затем приходит исходный каталог

затем идет каталог назначения (каталоги будут создаваться на лету по мере необходимости).

На передачу за 1 месяц ушло около 40–60 минут (около 35–45 000 файлов). Мы считаем, что на передачу за 1 год уходит около 12 часов или меньше.

Использование Windows Server 2003.

Все вещи записываются в файл журнала ... Время начала, Время окончания и Количество скопированных файлов.

Робокопия спасла день.

Вы знаете, я добавил -1 решение для tar, но - в зависимости от среды - возникает еще одна идея. Вы можете подумать об использовании dd (1) . Проблема скорости с чем-то вроде этого заключается в том, что для открытия и закрытия файла требуется много движений головы, что вы будете делать пять миллионов раз. Вы могли бы гарантировать, что они назначены непрерывно, вместо этого вы могли бы использовать их, что уменьшило бы количество движений головы в 5 и более раз.

Я предпочитаю использовать lz4 как самый быстрый инструмент сжатия на данный момент. Опция SSH -c arcfour128 использует более быстрый алгоритм шифрования, чем по умолчанию. [1]

Таким образом, передача каталога выглядит примерно так:

tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'

Обратите внимание, что в Debian команда lz4 - это lz4c, а в CentOS - lz4.

Robocopy отлично подходит для таких вещей. Он попытается снова после тайм-аутов сети, а также позволяет установить задержку между пакетами, чтобы теперь переполнить канал.

[Редактировать]

Обратите внимание, что это приложение только для Windows.

Я знаю, что это может быть глупо - но вы думали просто скопировать их на внешний диск и перенести на другой сервер? Это может быть самым эффективным и простым решением.

В настоящее время мы изучаем эту проблему. Нам нужно передать около 18 миллионов небольших файлов - всего около 200 ГБ. Мы добились наилучшей производительности, используя обычный старый XCopy, но это все еще заняло ДОЛГОЕ время. Около 3 дней с одного сервера на другой, около 2 недель на внешний диск!

Через другой процесс нам нужно было продублировать сервер. Это было сделано с Acronis. Прошло около 3 часов !!!

Мы будем исследовать это еще немного. Предложение ДД выше, вероятно, даст аналогичные результаты.

Уже куча хороших предложений, но хотелось добавить Beyond Compare . Недавно я перенес около 750 000 файлов от 5 КБ до 20 МБ с одного сервера на другой через гигабитный коммутатор. Это даже не сбой вообще. Конечно, это заняло некоторое время, но я ожидаю, что с таким большим количеством данных.

Я бы посмотрел, как работает zip-> copy-> unzip

или какой бы ни была ваша любимая система сжатия / архивирования.

Упакуйте их в один файл, прежде чем копировать, затем распакуйте их снова после копирования.

В аналогичной ситуации я попытался использовать tar для пакетирования файлов. Я написал крошечный скрипт для передачи вывода команды tar на целевой компьютер напрямую в принимающий процесс tar, который разделил файлы.

Тар-подход почти удвоил скорость передачи по сравнению с scp или rsync (YMMV).

Вот команды tar. Обратите внимание, что вам нужно включить r-команды, создавая файлы .rhosts в домашних каталогах каждого компьютера (удалите их после завершения копирования - это печально известные проблемы безопасности). Также обратите внимание, что, как обычно, HP-UX неудобен - тогда как остальная часть мира использует «rsh» для команды удаленной оболочки, HP-UX использует «remsh». «rsh» - это своего рода ограниченная оболочка на языке HP.

box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "

Первая команда tar создает файл с именем «-», который в данном случае является специальным токеном, означающим «стандартный вывод». Созданный архив содержит все файлы в текущем каталоге (.) Плюс все подкаталоги (по умолчанию tar является рекурсивным). Этот архивный файл передается в команду remsh, которая отправляет его на компьютер box2. Во вставке 2 я сначала перехожу на правильный каталог приема, затем извлекаю из '-' или 'стандартного ввода' входящие файлы.

У меня было 6 из этих команд tar, работающих одновременно, чтобы гарантировать, что сетевое соединение было насыщено данными, хотя я подозреваю, что доступ к диску мог быть ограничивающим фактором.

Обход файловой системы.

Вы можете размонтировать этот раздел, чтобы файлы находились на нем, или смонтировать его только для чтения? Сделайте это, тогда что-то вроде:

dd if=/dev/PARTITION | ssh username@host "dd of=diskimage.bin"

Затем вы можете смонтировать diskimage.binв качестве устройства обратной петли на стороне назначения и скопировать из него файлы в вашу фактическую файловую систему назначения, или, возможно, использовать соответствующие инструменты, чтобы сшить его обратно в пустой раздел на стороне назначения (опасно, но, вероятно, возможно). хотя я этого никогда не делал.)

Если вы действительно смелы, вы можете ddвернуться прямо в раздел на стороне назначения. Я не рекомендую это.

Вы можете попробовать следующее (может быть в пакетах файлов)

• tar пакет файлов
• сжать их
• если возможно, скопируйте с помощью scp
• Gunzip
• распаковать файлы

Как подсказывает sth, вы можете попробовать tar поверх ssh.

Если вам не требуется шифрование (изначально вы использовали rsync, но не упомянули, что это rsync + ssh), вы можете попробовать использовать tar через netcat, чтобы избежать накладных расходов ssh.

Конечно, вы также можете сократить время, необходимое для использования gzip или другого метода сжатия.

Есть что-то еще, чтобы рассмотреть. Попробуй это:

• Создать VHD, динамический размер
• Смонтируйте его, возможно, как каталог
• Установите атрибут «сжать весь диск»

Делая это, НЕТ накладных расходов на итерацию или сжатие каталога, потому что это было сделано во время записи файлов. Есть только один файл для перемещения - VHD.

В Windows я установил размер TCP-пакета по умолчанию, например, 16348. Это означает, что заголовок IP-адреса будет меньше.

Однако я столкнулся с тем, что для передачи по сети или USB лучше сохранять размеры файлов менее 100 Мб. Для этого я использую Rar.exe - чтобы разделить файлы.

Работает как чемпион. Это эквивалент 'dd' в Linux. Концепция монтирования сжатой файловой системы в каталог также нормальна для Linux, поэтому применяется та же логика. Вы должны убедиться, что все файлы закрыты до начала операции, как и в других методах.

Это дает дополнительное преимущество, заключающееся в том, что можно устанавливать квоту на размер папки. Если виртуальный жесткий диск имеет фиксированный размер, превышение этого предела не приведет к остановке сервера, а только к ошибке при создании или записи файла.

VHD, отформатированный как NTFS, также может обрабатывать миллионы файлов в папке.