Як швидко скопіювати велику кількість файлів між двома серверами

Мені потрібно передати величезну кількість mp3-файлів між двома сервісами (Ubuntu). Під величезним я маю на увазі близько мільйона файлів, які в середньому становлять 300K. Я спробував, scpале це зайняло б близько тижня. (близько 500 Кб / с) Якщо я передаю один файл HTTP, я отримую 9-10 Мб / с, але я не знаю, як їх передати.

Чи є спосіб швидко їх передати?

Я б рекомендував дьоготь. Коли файлові дерева вже схожі, rsync працює дуже добре. Однак, оскільки rsync зробить кілька пропусків аналізу для кожного файлу, а потім скопіює зміни, це значно повільніше, ніж tar для початкової копії. Ця команда, ймовірно, зробить те, що ви хочете. Він буде копіювати файли між машинами, а також зберігати як дозволи, так і права власності користувачів / груп.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Відповідно до коментаря Макінтоша нижче, це команда, яку ви використовували б для rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Зовнішній жорсткий диск і кур'єрська доставка в один день.

Я б використовував rsync.

Якщо ви експортуєте їх через HTTP із наявними списками каталогів, ви також можете використовувати wget та аргумент --mirror.

Ви вже бачите, що HTTP швидше, ніж SCP, оскільки SCP шифрує все (і, таким чином, вузькі місця на процесорі). HTTP та rsync рухаються швидше, оскільки вони не шифрують.

Ось деякі документи щодо налаштування rsync в Ubuntu: https://help.ubuntu.com/community/rsync

Ці документи говорять про тунелювання rsync через SSH, але якщо ви просто переміщуєте дані в приватній локальній мережі, вам не потрібен SSH. (Я припускаю, що ви перебуваєте в приватній локальній мережі. Якщо ви отримуєте 9-10 Мб / сек через Інтернет, то я хочу знати, які у вас зв’язки!)

Ось деякі інші дуже основні документи, які дозволять вам встановити відносно незахищений сервер rsync (без залежності від SSH): http://transamrit.net/docs/rsync/

Без особливих обговорень використовуйте сітчастий ніж, мережевий швейцарський ніж. Немає накладних протоколів, ви безпосередньо копіюєте в мережевий сокет. Приклад

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

Якщо у вас багато файлів, якщо ви йдете з rsync, я б спробував отримати версію 3 або вище на обох кінцях . Причина полягає в тому, що менша версія буде перераховувати кожен файл перед початком передачі. Нова функція називається інкрементально-рекурсійною .

Новий алгоритм інкрементальної рекурсії тепер використовується, коли rsync спілкується з іншою версією 3.x. Це запускає передачу швидше (перш ніж всі файли були знайдені) і вимагає набагато менше пам’яті. Див. Параметр --рекурсивний на сторінці сторінки щодо деяких обмежень.

rsync, як і інші, вже рекомендували. Якщо накладні витрати процесора на шифрування є вузьким місцем, використовуйте інший менш інтенсивний алгоритм процесора, як, наприклад, удар. Наприклад, щось подібне

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

Переміщуючи 80 ТБ даних (мільйони крихітних файлів) вчора, перехід rsyncна режим tar виявився набагато швидшим , оскільки ми перестали пробувати

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

і tarзамість цього перейшов ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Оскільки ці сервери знаходяться в одній локальній мережі, адреса призначення встановлена ​​на NFS у вихідній системі, яка робить натиск. Не робити це ще швидше, ми вирішили не зберігати atimeфайли:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

На графіку нижче зображено різницю, яку змінив від rsync до tar. Це була ідея мого начальника, і мій колега виконав її і зробив великий запис у своєму блозі . Мені просто подобаються гарні фотографії . :)

Копіюючи велику кількість файлів, я виявив, що такі інструменти, як tar та rsync, є неефективнішими, ніж вони повинні бути через накладні витрати на відкриття та закриття багатьох файлів. Я написав інструмент з відкритим кодом, який називається швидким архіватором, який швидше, ніж tar для цих сценаріїв: https://github.com/replicon/fast-archiver ; вона працює швидше, виконуючи кілька одночасних файлових операцій.

Ось приклад швидкого архівації та tar на резервну копію понад двох мільйонів файлів; для швидкого архівації потрібно 27 хвилин для архівації, проти дьогтю - 1 годину 23 хвилини.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Для передачі файлів між серверами можна скористатися швидким архіватором з ssh, наприклад, таким:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

Я також використовую дьоготь за допомогою netcatпідходу, за винятком того, що я вважаю за краще використовувати socat- набагато більше енергії для оптимізації для вашої ситуації - наприклад, шляхом налаштування mss. (Також смійтеся, якщо хочете, але я вважаю socatаргументи легше запам’ятати, оскільки вони послідовні). Тому для мене це дуже часто зустрічається останнім часом, оскільки я переміщую речі на нові сервери:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Псевдоніми необов’язкові.

Ще одна альтернатива - Unison . У цьому випадку може бути трохи ефективніше, ніж Rsync, і налаштувати слухача дещо простіше.

Схоже, у верхній відповіді може бути кілька помилок друку. Це може працювати краще:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

• Мережева файлова система (NFS), а потім скопіюйте їх будь-чим, наприклад, Midnight Commander (mc), Nautilus (від gnome). Я використовував NFS v3 з хорошими результатами.
• Samba (CIFS), а потім скопіюйте файли все, що завгодно, але я поняття не маю, наскільки це ефективно.
• HTTP з , wget --mirrorяк Еван Андерсон запропонував або будь-який інший клієнт HTTP. Будьте обережні, щоб не було неприємних символьних посилань чи оманливих файлів індексу. Якщо у вас є MP3, ви повинні бути в безпеці.
• rsync . Я використав його з досить хорошими результатами, і одна з його приємних особливостей полягає в тому, що ви можете перервати і відновити передачу пізніше.

Я помітив, що інші люди рекомендували використовувати netcat . На основі свого досвіду роботи з ним я можу сказати, що це повільно порівняно з іншими рішеннями.

Завдяки чудовій відповіді Скотта Пака (я раніше не знав, як це зробити з ssh), я можу запропонувати це вдосконалення (якщо bashце ваша оболонка). Це додасть паралельне стиснення, показник прогресу та перевірку цілісності через мережеве посилання:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pvце хороша програма перегляду прогресу для вашої труби і pigzє паралельною програмою gzip, яка використовує стільки потоків, скільки у вашому процесорі за замовчуванням (я вважаю, що до 8 макс.). Ви можете налаштувати рівень стиснення, щоб краще відповідати співвідношенню процесора до пропускної здатності мережі та замінити його, pxz -9eі pxz -dякщо у вас набагато більше процесора, ніж пропускна здатність. Вам потрібно лише переконатися, що дві суми відповідають після завершення.

Цей варіант корисний для дуже великого обсягу даних, а також для мереж з високою затримкою, але не дуже корисний, якщо посилання нестабільне і перепадає. У цих випадках rsync - це, мабуть, найкращий вибір, оскільки він може відновитись.

Вибірка зразка:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

Для блокових пристроїв:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Очевидно, переконайтеся, що вони однакового розміру чи обмеження з count =, пропустіть =, шукайте = тощо.

Коли я копіюю файлові системи таким чином, я часто спочатку dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefsнулю більшість невикористаного простору, що прискорює xfer.

Я не думаю, що ти будеш робити краще, ніж scp, якщо не встановиш швидші мережеві карти. Якщо ви робите це через Інтернет, це не допоможе.

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

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

Для 100 Мбіт / с теоретична пропускна здатність становить 12,5 Мб / с, тому при 10 МБ / с ви робите досить добре.

Я також повторюю пропозицію зробити rsync, ймовірно, через ssh. Щось на зразок:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

При 100 Мбіт / с ваші процесори повинні мати можливість обробляти шифр / дешифрувати, не помітно впливаючи на швидкість передачі даних. І якщо ви перервите потік даних, ви зможете відновити місце, де ви зупинилися. Будьте обережні, із "мільйонами" файлів запуску пройде деякий час, перш ніж він фактично нічого не передасть.

Я стикався з цим, за винятком того, що я передавав журнали Oracle.

Ось розбивка

• scp

  inefficient and encrypted (encrypted = slower than unencrypted 
  depending on the link and your processor) 
  

• rsync

  efficient but typically encrypted (though not necessarily)
  

• FTP / HTTP

  both seem to be efficient, and both are plaintext. 
  

Я використовував FTP з великим успіхом (де великий успіх еквівалентний ~ 700 Мбіт / с у мережі Gb). Якщо ви отримуєте 10 Мб (що дорівнює 80 Мб / с), можливо, щось не так.

Що ви можете сказати нам про джерело та призначення даних? Це один привід на один привід? RAID на USB?

Я знаю, що на це питання вже є відповідь, але якщо ваша мережа йде так повільно на кроссоверському кабелі Gb / s, щось абсолютно потрібно виправити.

Ви не згадували, чи є дві машини в одній локальній мережі або якщо захищений канал (тобто використання SSH) є обов'язковим, але інший інструмент, який ви можете використовувати, - це netcat .

Я б використовував наступне на приймальній машині:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

Потім на стороні відправки:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

Він має такі переваги:

• Немає накладних процесорів для шифрування, яке має ssh.
• gzip -1Забезпечує легке стиснення без насичення процесора , так що робить хороший компроміс, даючи трохи стиснення при збереженні максимальних пропускної здатності . (Можливо, це не вигідно для даних MP3, але це не шкодить.)
• Якщо ви можете розділити файли на групи, ви можете запустити дві або більше труби паралельно і дійсно гарантувати, що ви насичуєте пропускну здатність своєї мережі.

наприклад,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

Примітки:

• Яким би способом ви не передавались, я, мабуть, запускаю rsync або unison після цього, щоб переконатися, що у вас все є.
• Ви можете використовувати tarзамість цього, cpioякщо хочете.
• Навіть якщо ви в кінцевому підсумку використовуєте ssh, я б переконався, що він не використовує ніякого стиснення, і пропускає через gzip -1себе натомість, щоб уникнути насичення процесора. (Або принаймні встановіть CompressionLevel на 1.)

Простий scp з належними параметрами легко досягне 9-10 Мб / с через локальну мережу:

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

З тими опціями, ймовірно, що пропускна здатність стала в 4 рази або 5 разів швидшою, ніж немає варіантів (за замовчуванням)

Якщо у вас є ftp-сервер на стороні src, ви можете використовувати ncftpget з сайту ncftp . Він працює префектом з невеликими файлами, оскільки він використовує всередині tar.

Одне порівняння показує це: переміщення невеликих файлів 1.9 ГБ (33926 файлів)

1. Використання scp займає 11м59с
2. Використання rsync займає 7м10с
3. Використання ncftpget займає 1м20с

Ви також можете спробувати скористатися командою BBCP, щоб здійснити передачу. Це буферний паралельний ssh, який справді кричить. Зазвичай ми можемо отримати 90% + лінійну ставку за умови, що ми можемо тримати трубу.

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

Зазвичай ми намагаємось реально намагатися уникнути необхідності пересуватися. Ми використовуємо пули ZFS, до яких завжди можна просто "додати" більше місця на диску. Але іноді ... потрібно просто перемістити речі. Якщо у нас є "жива" файлова система, яка може зайняти години (або дні), щоб скопіювати навіть під час повного вибуху .. ми робимо два кроки zfs надсилати повсякденне:

1. Зробіть знімок ZFS та перейдіть до нового пулу на новій машині. Нехай пройде стільки, скільки потрібно.
2. Зробіть другий знімок і надішліть його як поступовий. Покроковий знімок включає лише (набагато менший) набір змін з першого, тому він проходить відносно швидко.
3. Після завершення додаткового знімка ви можете повернути оригінал та перерізати його на нову копію, а "час автономного простою" зведений до мінімуму.

Ми також надсилаємо наші відмови zfs через BBCP ... це максимально використовує нашу мережу і мінімізує час передачі.

BBCP доступний у вільному доступі, ви можете перейти в Google, і це компіляція прямого переходу. Просто скопіюйте його у / usr / local / bin як на src, так і на цільові машини, і це майже просто спрацює.

Я думаю, що моя відповідь тут трохи пізно, але я створив хороший досвід використання mc (Midnight Commander) на одному сервері для підключення через SFTP до іншого сервера.

Можливість підключення через FTP знаходиться в меню "Ліворуч" і "Право", ввівши таку адресу:

/#ftp:name@server.xy/

або

/#ftp:name@ip.ad.dr.ess/

Ви можете орієнтуватися та робити файлові операції майже як у локальній файловій системі.

У неї є вбудована опція робити копіювання у фоновому режимі, але я вважаю за краще використовувати команду screen та відключати її від екрана, коли mc копіює (я думаю, що це працює і швидше).

Щоб відповісти @scottpack з параметра rSync

Щоб відобразити хід завантаження, використовуйте команду '--progess' як опцію після -avW в команді, як показано нижче.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Ось швидкий орієнтир для порівняння деяких методів,

• Джерелом є 4-ядерний процесор Intel (R) Xeon (R) E5-1620 при 3,60 ГГц з 250 Мбіт / с і накопичувачем SATA
• Призначення - це 6-ядерний процесор Intel (R) Xeon (R) E-2136 @ 3,30 ГГц з пропускною здатністю 1 Гбіт / с і накопичувачем SSD

Кількість файлів: 9632, Загальний розмір: 814 MiB, Середній розмір: 84 KiB

• RSYNC: 1м40.570с
• RSYNC + КОМПРЕСІЯ: 0m26.519s
• TAR + NETCAT: 1m58.763s
• ТАР + КОМПРЕСІЯ + НЕТКАТ: 0м28.009с

Команда для tar / netcat:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -

rsync або ви можете відзначити його так, щоб все було в одному файлі, а потім scp. Якщо у вас бракує дискового простору, під час його виготовлення можна передати дьоготь безпосередньо через ssh.

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

Я спробував пару інструментів для копіювання файлу 1 Гб. Результат наведений нижче: HTTP найшвидший, wget -c nc секунда в рядку scp найповільніша, і не вдалося пару разів. Жоден спосіб відновити rsync не використовує ssh як бекенд, таким чином, той самий результат. На закінчення я б пішов на http з wget -bqc і дав би йому трохи часу. Сподіваюся, що це допомагає

Мені довелося скопіювати диск BackupPC на іншу машину.

Я використовував rsync.

Машина мала 256 Мб пам'яті.

Процедура, яку я дотримувався, була така:

• виконано rsyncбез -H(зайняло 9 годин)
• коли rsync закінчився, я синхронізував cpoolкаталог і почав з pcкаталогу; Я перерізав передачу.
• потім перезапущений rsyncз -Hпрапором, і всі файли , пов'язані з працею в pcкаталозі були правильно перенесені (процедура знайшла все реальні файли , cpoolа потім приєднують до pcкаталогу) (зайняло 3 години).

Зрештою, я міг переконатися, df -mщо зайвого місця не було витрачено.

Таким чином я уникаю проблеми із пам'яттю та rsync. Я весь час можу перевірити продуктивність за допомогою верху та зверху, і нарешті я переніс 165 ГБ даних.