Как быстро скопировать 40 млн файлов на другой сервер?

Question

[Андрей]

Есть сервер с картинками
на нем 40 млн файлов, есть маленькие по 5-10 кб, есть побольше 50-100
Обычное копирование этого добра с одного сервера на другой через rsync идет очень медленно (несколько дней, а то и недель)

Есть ли какие-то варианты делать это не по файлам, а может сразу весь образ диска переписать
или копировать по секторам. Хотелось бы уметь это делать за несколько часов.

Comments

[Tyranron]

Сначала в tar закатать пробовали? tar -> scp/rsync -> untar

[Андрей]

Tyranron: нет, думали про это, но не проверяли будет ли это быстрее

[Tyranron]

andreyvlru: вообще должен, так как на одном большом файле скорости передачи есть куда "разогнаться", в отличии от кучи мелких файлов. Другой вопрос, что требуется дополнительное место, что не всегда вариант. Ну и я не уверен в том, насколько лучше станет.

[АртемЪ]

Ну для начала надо бы кроме количества файлов знать общий объем и ширину канала до удаленного сервера.

[Андрей]

Гигабит

Answer 1

[Армянское Радио]

Как-то так:

dd if=/dev/sda bs=65536 | ssh target-ip 'dd of=/dev/sda bs=65536'.

На агрегированном канале 2x1Gbit выдает 100 мегабайт в секунду. Если подшаманить размеры блока bs= и mtu, и еще шифрование у ssh выключить, можно, я думаю, и все 200 мегабайт выжать.

Проводить, на отмонтированном! (или смонтированном в readOnly) диске!
Не зря dd расшифровывается как DestroyData.
Варианты настройки шифрования (-c) и скорость (лучше - больше):

Comments

[Андрей]

ssh на таком потоке не укладывает сервер по CPU?

[Андрей]

Спасибо, будем пробовать

[Армянское Радио]

andreyvlru: Ну одно ядро оно конечно же съест (70% на HP GL380 Gen8 с двумя процессорами по 6 ядер).
Если поставить шифрование arcfour256 (ssh -c arcfour256), будет примерно 160 Мегабайт в секунду на агрегированном канале или 80 на обычном гигабите.

сравнение скорости алгоритмов

[Андрей]

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

[Армянское Радио]

andreyvlru: Отсутствие когерентности при чтении. Если кто-то что-то запишет на диск, может оказаться так, что скопировался кусок старых метаданных и кусок новых. Помните старый фильм?

Чтобы проделывать такие трюки на смонтированной ФС, нужно, чтобы она это поддерживала.

[Андрей]

Армянское Радио: понятно

[Евгений]

andreyvlru: для копирования "на лету" без от монтирования на боевом сервере очень помогает LVM с его снепшотами

[Андрей]

Наконец попробовали
все данные скопировались за 9 часов!!!! до этого мы тратили неделю на перенос

Answer 2

[Владислав]

Я переносил через zfs send | zfs recv via ssh. Скорость была ограничена только скоростью чтения/записи HDD.

Comments

[pfg21]

на полупустом разделе send/receive быстрее и тупого dd и разбора файловой системы cp получались.
игрался на бтрфс.

Answer 3

[jcmvbkbc]

tar -cC source-dir . | ssh target-ip "tar -xC target-dir"

Answer 4

[Ilya Evseev]

Обзор разных способов быстрого копирования:
moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Answer 5

[Влад Животнев]

rsync по каталогам через GNU parallel.

Answer 6

[Виктор Компанеец]

Основная проблема - как размещены файлы по дереву каталогов. Часто затык связан с построением списка файлов, а не с его обработкой.

Answer 7

[pfg21]

если межсерверная сеть полностью контролируема и никого лишнего в ней нет, то вместо ssh можно заюзать netcat. минус шифрация == плюс к скорости/ресурсам