У меня есть около 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.
Все вещи записываются в файл журнала ... Время начала, время окончания и количество скопированных файлов.
Робокопия спасла день.
Я предпочитаю использовать lz4 как самый быстрый инструмент сжатия на данный момент. Опция SSH -c arcfour128 использует более быстрый алгоритм шифрования, чем по умолчанию. [1]
Таким образом, передача каталога выглядит примерно так:
tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'
Обратите внимание, что в Debian команда lz4 - это lz4c, а в CentOS - lz4.
Вы знаете, я добавил -1 решение для tar, но - в зависимости от среды - возникает еще одна идея. Вы можете подумать об использовании dd(1). Проблема скорости с чем-то вроде этого заключается в том, что для открытия и закрытия файла требуется много движений головы, что вы будете делать пять миллионов раз. Вы могли бы гарантировать, что они назначены непрерывно, вместо этого вы могли бы использовать их, что позволило бы сократить количество движений головы в 5 и более раз.
Robocopy отлично подходит для таких вещей. Он попытается снова после истечения времени ожидания сети, а также позволяет установить задержку между пакетами, чтобы теперь затопить канал.
[Редактировать]
Обратите внимание, что это приложение только для Windows.
Я знаю, что это может быть глупо - но вы думали просто скопировать их на внешний диск и перенести на другой сервер? Это может быть самым эффективным и простым решением.
Мы изучаем эту проблему в настоящее время. Нам нужно передать около 18 миллионов небольших файлов - всего около 200 ГБ. Мы добились наилучшей производительности, используя обычный старый XCopy, но это все еще заняло ДОЛГОЕ время. Около 3 дней с одного сервера на другой, около 2 недель на внешний диск!
Через другой процесс нам нужно было продублировать сервер. Это было сделано с Acronis. Прошло около 3 часов !!!
Мы будем исследовать это еще немного. Предложение дд выше, вероятно, даст аналогичные результаты.
Уже много хороших предложений, но хотелось добавить Beyond Compare. Недавно я перенес около 750 000 файлов от 5 КБ до 20 МБ с одного сервера на другой через гигабитный коммутатор. Это даже не сбой вообще. Конечно, это заняло некоторое время, но я ожидаю, что с таким большим количеством данных.
Обход файловой системы.
Вы можете размонтировать этот раздел, чтобы файлы находились на нем, или смонтировать его только для чтения? Сделайте это, тогда что-то вроде:
dd if=/dev/PARTITION | ssh username@host "dd of=diskimage.bin"
Затем вы можете смонтировать diskimage.bin в качестве устройства обратной связи на стороне назначения и скопировать из него файлы в вашу фактическую файловую систему назначения, или, возможно, использовать надлежащие инструменты, чтобы сшить его обратно в пустой раздел на стороне назначения (опасно, но, возможно, возможно, хотя я никогда не делал этого.)
Если вы действительно мужественные вы можете dd его непосредственно обратно в раздел на стороне назначения. Я не рекомендую это.
Я бы посмотрел, как работает 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, запущенных одновременно, чтобы гарантировать, что сетевой канал был насыщен данными, хотя я подозреваю, что доступ к диску мог быть ограничивающим фактором.
Есть что-то еще, чтобы рассмотреть. Попробуй это:
Таким образом, нет никаких накладных расходов для итерации или сжатия каталога, потому что это было сделано во время записи файлов. Есть только один файл для перемещения - VHD.
В Windows я установил размер TCP-пакета по умолчанию, например, 16348. Это означает меньшие издержки на заголовок IP.
Одна вещь, с которой я столкнулся, это то, что лучше всего сохранять размер файла до 100 Мб для передачи по сети или через USB. Для этого я использую Rar.exe - чтобы разделить файлы.
Работает как чемпион. Это эквивалент 'dd' в Linux. Концепция монтирования сжатой файловой системы в каталог также нормальна для Linux, поэтому применяется та же логика. Вы должны убедиться, что все файлы закрыты до начала операции, как и в других методах.
Это дает дополнительное преимущество, заключающееся в том, что можно устанавливать квоту на размер папки. Если виртуальный жесткий диск имеет фиксированный размер, превышение этого предела не приведет к остановке сервера, а только к ошибке при создании или записи файла.
VHD, отформатированный как NTFS, также может обрабатывать миллионы файлов в папке.
Вы можете попробовать следующее (может быть в пакетах файлов)
Как подсказывает sth, вы можете попробовать tar поверх ssh.
Если вам не требуется шифрование (изначально вы использовали rsync, но не упомянули, что это rsync+ssh), вы можете попробовать использовать tar через netcat, чтобы избежать накладных расходов ssh.
Конечно, вы также можете сократить время, необходимое для использования gzip или другого метода сжатия.