Я архивирую данные с одного сервера на другой. Сначала я начал rsync работа. Ему потребовалось 2 недели, чтобы создать список файлов только для 5 ТБ данных и еще неделю, чтобы передать 1 ТБ данных.
Затем мне пришлось прервать работу, так как нам нужно время простоя на новом сервере.
Было решено, что мы заблокируем его, так как нам, вероятно, больше не понадобится к нему доступ. Я думал разбить его на куски по 500 ГБ. После того как я tar тогда я собирался скопировать это через ssh. Я использовал tar и pigz но это все еще слишком медленно.
Есть ли способ лучше? Я думаю, что оба сервера находятся на Redhat. Старый сервер - это Ext4, а новый - XFS.
Размеры файлов варьируются от нескольких килобайт до нескольких мегабайт, а в 5 ТБ содержится 24 миллиона JPEG. Так что я предполагаю около 60-80 миллионов на 15 ТБ.
edit: После игры с rsync, nc, tar, mbuffer и pigz в течение нескольких дней. Узким местом будет дисковый ввод-вывод. Поскольку данные распределяются по 500 дискам SAS и примерно 250 миллионам файлов в формате JPEG. Однако теперь я узнал обо всех этих хороших инструментах, которые я могу использовать в будущем.
У меня были очень хорошие результаты, используя tar, pigz (параллельный gzip) и nc.
Исходная машина:
tar -cf - -C /path/of/small/files . | pigz | nc -l 9876
Машина назначения:
Извлекать:
nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here
Для хранения архива:
nc source_machine_ip 9876 > smallstuff.tar.gz
Если вы хотите увидеть скорость передачи, просто пропустите pv после pigz -d!
Я бы остановился на решении rsync. Современный (3.0.0+) rsync использует инкрементный список файлов, поэтому ему не нужно создавать полный список перед передачей. Таким образом, перезапуск не потребует от вас повторного выполнения всего переноса в случае возникновения проблем. Разделение передачи на каталог верхнего или второго уровня оптимизирует это еще больше. (Я бы использовал rsync -a -P и добавить --compress если ваша сеть медленнее, чем ваши диски.)
Настройте VPN (если это Интернет), создайте виртуальный диск некоторого формата на удаленном сервере (сделайте его ext4), смонтируйте его на удаленном сервере, затем смонтируйте его на локальном сервере (используя протокол уровня блоков, такой как iSCSI) и используйте dd или другой инструмент уровня блоков для передачи. Затем вы можете скопировать файлы с виртуального диска на реальный диск (XFS) по своему усмотрению.
Две причины:
Если старый сервер выводится из эксплуатации, а файлы могут быть отключены на несколько минут, то часто быстрее всего просто вытащить диски из старой коробки и подключить их к новому серверу, смонтировать их (сейчас снова в сети) и скопировать файлы. к новым серверам родные диски.
Используйте mbuffer, и если он находится в защищенной сети, вы можете избежать этапа шифрования.
(Может работать множество разных ответов. Вот еще один.)
Создайте список файлов с помощью find -type f (это должно закончиться через пару часов), разделить его на небольшие части и передать каждый кусок, используя rsync --files-from=....
Вы рассматривали сникернет? Под этим я подразумеваю перенос всего на тот же диск, а затем физическое перемещение этого диска.
Около месяца назад Samsung представила накопитель на 16 ТБ (технически это 15,36 ТБ), который также является SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard-drive-16tb
Думаю, этот диск как раз для этого подойдет. Вам все равно придется копировать все файлы, но поскольку у вас нет сетевой задержки и, вероятно, вы можете использовать SATA или аналогичный быстрый метод, это должно быть намного быстрее.
Если есть шанс получить высокий коэффициент успешности при дедупликации, я бы использовал что-то вроде Borgbackup или чердак.
Если нет, проверьте netcat + tar +pbzip2 Решение, адаптируйте параметры сжатия в соответствии с вашим оборудованием - проверьте, что является узким местом (ЦП? сеть? ввод-вывод?). Pbzip2 отлично подходит для всех процессоров, обеспечивая лучшую производительность.
Вы используете RedHat Linux, поэтому это не применимо, но как другой вариант:
Мне очень удалось использовать ZFS для хранения миллионов файлов, поскольку inode не является проблемой.
Если бы это был вариант для вас, вы могли бы сделать снимки и использовать zfs для отправки дополнительных обновлений. Я добился большого успеха, используя этот метод как для передачи, так и для архивирования данных.
ZFS - это в первую очередь файловая система Solaris, но ее можно найти в illumos (ветвь OpenSolaris с открытым исходным кодом). Я знаю, что мне также повезло с использованием ZFS под BSD и Linux (с использованием FUSE?), Но у меня нет опыта в этом.
Начать rsync демон на целевой машине. Это значительно ускорит процесс передачи.
Вы можете сделать это с помощью tar и ssh, например:
tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"
Или, если вы хотите сохранить отдельные файлы:
tar zcf - <your files> | ssh <destination host> "tar zxf -"