На даний момент у мене є два сервери CentOS. Мені потрібно знати, як і яким найшвидшим способом було б "смолати" каталог директорій із зображеннями та SCP?

Це найшвидший спосіб, який я щойно запропонував, тому що таргінг триває вічно ... Я запустив команду:

tar cvf imagesbackup.tar images

І я збирався просто обрізати це.

Повідомте мене, якщо є швидший шлях. У мене віддалений / SSH доступ до обох машин.

Замість використання tar для запису на локальний диск, ви можете писати безпосередньо на віддалений сервер по мережі за допомогою ssh.

server1$ tar -zc ./path | ssh server2 "cat > ~/file.tar.gz"

Будь-яка рядок, що слідує за вашою командою "ssh", запускатиметься на віддаленому сервері замість інтерактивного входу. Ви можете передавати вхід / вихід до цих віддалених команд і через SSH так, як якщо б вони були локальними. Введення команди в лапки дозволяє уникнути плутанини, особливо при використанні перенаправлення.

Або ви можете витягнути файл tar на іншому сервері безпосередньо:

server1$ tar -zc ./path | ssh server2 "tar -zx -C /destination"

Зверніть увагу на рідко використовуваний -Cваріант. Це означає "спочатку змінити цей каталог, перш ніж робити що-небудь".

Або, можливо, ви хочете "витягнути" з цільового сервера:

server2$ tar -zx -C /destination < <(ssh server2 "tar -zc -C /srcdir ./path")

Зауважте, що <(cmd) конструкція нова для bash і не працює в старих системах. Він запускає програму і посилає вихід на трубу, і замінює цю команду в команду так, ніби це файл.

Я міг би просто так написати наступне:

server2$ tar -zx -C /destination -f <(ssh server2 "tar -zc -C /srcdir ./path")

Або наступним чином:

server2$ ssh server2 "tar -zc -C /srcdir ./path" | tar -zx -C /destination

Або ви можете врятувати себе від горя і просто скористатися rsync:

server1$ rsync -az ./path server2:/destination/

Нарешті, пам’ятайте, що стискання даних перед передачею зменшить вашу пропускну здатність, але при дуже швидкому з'єднанні це може фактично змусити операцію зайняти більше часу . Це пов’язано з тим, що ваш комп’ютер може не в змозі стиснутись досить швидко, щоб не відставати: якщо стиснення 100 МБ займе більше часу, ніж потрібно для відправлення 100 МБ, то швидше надіслати його нестисненим.

Крім того, ви можете розглянути можливість трубопроводів gzip самостійно (а не використовувати параметр -z), щоб ви могли вказати рівень стиснення. Я мав досвід, що при швидких мережних з'єднаннях зі стислими даними використання gzip на рівні 2 або 3 (за замовчуванням - 6) дає найкращу загальну пропускну здатність у більшості випадків. Так:

server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"

Мені б сподобатись синхронізувати це над собою - це стискає і добре обробляє втрати зв'язку.

Якщо ви їх просто відкашляєте, і нічого іншого це не витратить багато часу з мінімальним збільшенням швидкості.

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

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

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

Я б використовував такий спосіб:

md5sum /images/* > md5sum.txt
scp -r images/* user@host:/images/

На новому сервері

md5sum /images/* > md5sum_new.txt

І тоді просто diff. А оскільки scp підтримує стиснення на льоту, немає необхідності в окремих архівах.

Редагувати

Я зберігатиму інформацію про MD5, оскільки вона була корисною для ОП. Але один коментар вразив мене новим розумінням. Тож трохи пошуку надали цю корисну інформацію. Зверніть увагу, що сюжетом тут є SFTP, а не безпосередньо SCP .

На відміну від FTP, SFTP додає накладні витрати для передачі файлів. Коли файл передається між клієнтом та сервером, він розбивається на менші шматки, які називаються "пакетами". Наприклад, припустимо, що кожен пакет становить 32 КБ. Протокол SFTP робить контрольну суму на кожен файл 32 КБ під час його надсилання та включає цю контрольну суму разом з цим пакетом. Одержувач отримує цей пакет і розшифровує дані, а потім перевіряє контрольну суму. Сама контрольна сума "сильніша", ніж контрольна сума CRC32. (Оскільки SFTP використовує 128-бітну або більш високу контрольну суму, таку як MD5 або SHA, і оскільки це робиться для кожного пакету, відбувається дуже детальна перевірка цілісності, яка виконується в рамках передачі.) Таким чином, протокол сама по собі повільніше (через додаткові накладні витрати), але успішне завершення передачі означає, фактично,

На додаток до пропозиції md5sum Pacey, я використовую наступне:

У пункті призначення: nc -w5 -l -p 4567 | tar -xvf -

Потім на джерело: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

Це все ще tar / untar, і шифрування немає, але це безпосередньо на інший сервер. Почніть їх обидва в тандемі ( -w5дає 5 грацій.) І стежте за тим, як він проходить. Якщо пропускна здатність обмежена, додайте -z до дьогтю на обох кінцях.

Один момент - не всі хости мають rsync і, можливо, хости можуть мати різні версії tar. З цієї причини можна рекомендувати в якості першого порту дзвінка використовувати cpio, що нехтується часто.

Ви можете cpio over ssh, щоб зробити спеціальну реплікацію структур файлів / директорій між хостами. Таким чином, ви маєте тонший контроль над тим, що надсилається над баченням, як вам потрібно "годувати" cpio, nom-nom. Це також більш портативний аргумент, cpio не сильно змінюється - це важливий момент, якщо ви доглядаєте за кількома хостами в неоднорідному середовищі.

Приклад копіювання / експорту / домашньої та підкаталовок на віддалений хост:

cd /export/ find . home -print | cpio -oaV | ssh 10.10.10.10 'cd /export/home; cpio -imVd'

Вищенаведене копіюватиме вміст / export / home та будь-які підкаталоги до / export / home на віддалений хост.

Сподіваюся, це допомагає.

У вас є ssh доступ, у вас є доступ до rsync.

rsync -av -e ssh /storage/images/ user@[ip or domain name]:/storage/images/

або

rsync -av -e "ssh -l user" /storage/images/ [ip or domain name]:/storage/images/

Якщо ви отримаєте помилку на кшталт "помилка rsync: деякі файли не вдалося перенести (код 23) на main.c (977) [sender = 2.6.9]", перевірте свого користувача та групи між серверами; у вас може виникнути невідповідність.

Використовуйте опцію rsync "-z", якщо ви хочете, щоб rsync стискав передачу. Цей параметр використовуватиме більше процесора, але меншу пропускну здатність, тому пам’ятайте про це.

Існує варіант "- прогрес", який дасть вам відсоток перерахованого, що дуже добре, якщо вам подобається така річ.

Вони перебувають у спільній мережі замість того, щоб Інтернет потребував для передачі файлів? NFS або FTP можуть бути набагато швидшими, ніж накладні витрати SCP, хоча ви б втратили шифрування під час передачі.

Або ви завжди можете використовувати смолисті труби:

(cd /path && tar -cjf - * ) | ssh user@host 'tar -xjf - -C /path'

'j' = bzip2, ви можете використовувати 'z' для gzip або --lzma, якщо ваш tar підтримує його.