Передайте 15 ТБ крихітних файлів

Я архівую дані з одного сервера на інший. Спочатку я розпочав rsyncроботу. На це знадобилося 2 тижні, щоб створити список файлів лише для 5 ТБ даних і ще тиждень для передачі 1 ТБ даних.

Тоді мені довелося вбити роботу, оскільки нам потрібно трохи часу на новому сервері.

Було домовлено, що ми будемо орієнтуватися на нього, оскільки нам, ймовірно, не потрібно буде звертатися до нього знову. Я думав розбити його на шматки 500 Гб. Після того як я tarце тоді я збирався скопіювати це наскрізь ssh. Я використовую tarі , pigzале це все ще надто повільно.

Чи є кращий спосіб це зробити? Я думаю, що обидва сервери є на Redhat. Старий сервер - Ext4, а новий - XFS.

Розміри файлів коливаються від кількох кбіт до декількох МБ, і 24 мільйони jpegs в 5 ТБ. Тому я здогадуюсь приблизно 60-80 мільйонів за 15 ТБ.

редагувати: Після гри з rsync, nc, tar, mbuffer та pigz протягом декількох днів. Вузьким місцем буде IO диска. Оскільки дані наводяться на 500 дисках SAS та близько 250 мільйонів JPG. Однак зараз я дізнався про всі ці приємні інструменти, які я можу використовувати в майбутньому.

У мене були дуже хороші результати , використовуючи 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) диск у власні зручності.

Дві причини:

1. Немає накладних витрат на файлову систему, що є головним винуватцем продуктивності
2. Не шукаючи, ви дивитесь на послідовне читання / запис з обох сторін

Якщо старий сервер виводиться з експлуатації і файли можуть бути в автономному режимі протягом декількох хвилин, то найчастіше найшвидше просто витягнути накопичувачі зі старого ящика та підключити їх до нового сервера, встановити їх (повернутись зараз в Інтернет) і скопіювати файли на нові сервери, рідні диски.

Використовуйте 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 або Attic.

Якщо ні, перевірте рішення netcat + tar + pbzip2 , адаптуйте параметри стиснення відповідно до свого обладнання - перевірте, що таке вузьке місце (CPU? Network? IO?). Pbzip2 добре охоплює всі процесори, забезпечуючи кращу продуктивність.

Ви використовуєте RedHat Linux, тому це не застосовуватиметься, але як інший варіант:

Я мав великий успіх у використанні ZFS для зберігання мільйонів файлів, оскільки вставки - це не проблема.

Якщо це був варіант для вас, ви можете зробити знімки та використовувати zfs для надсилання додаткових оновлень. Я мав великий успіх, використовуючи цей метод для передачі, а також архівних даних.

ZFS - це насамперед файлова система Solaris, але її можна знайти в ілюмінаціях (відкритий вилок Sun's 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 -"