Найкращий спосіб копіювання мільйонів файлів з двох серверів

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

Друга моя думка полягала б у використанні scp, але я хотів отримати зовнішню думку, щоб побачити, чи є кращий спосіб. Спасибі!

Щось подібне повинно добре працювати:

tar c some/dir | gzip - |  ssh host2 tar xz

Можливо, також опустіть gzip та прапор "z" для вилучення, оскільки ви перебуваєте в гігабітній мережі.

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

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

Для копіювання мільйонів файлів через гігабітний комутатор (у довіреному середовищі) ви також можете використовувати комбінацію netcat (or nc)та tar, як уже запропонував користувач55286. Це передасть всі файли як один великий файл (див. Швидке копіювання файлів - Linux! (39 ГБ) ).

# requires netcat on both servers
nc -l -p 2342 | tar -C /target/dir -xzf -   # destination box
tar -cz /source/dir | nc Target_Box 2342    # source box

У нас було близько 1 мільйона файлів у каталозі (файли приблизно 4 роки).

І ми використовували robocopy для переміщення файлів у каталог YYYY / MM (близько 35-45000 файлів на місяць). Ми поміщаємо скрипт robocopy у файл .bat таким чином:

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081201 /MINAGE:20090101 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\12
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090101 /MINAGE:20090201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\01
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090201 /MINAGE:20090301 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\02

короткі примітки .. /ns /nc /nfl /np- щоб уникнути роздуття журнального файлу з додатковою інформацією /log+...- це написати підсумкову інформацію в журнальний файл.

/minage and /maxage is to copy files modified with in that date range. 

так, наприклад, що файли змінені> = 01 / листопад 2008 р. (включно) для файлів, змінених <01 / грудень / 2008 р. (не включно)

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11

/mov для переміщення файлів

потім виходить вихідний каталог

потім з'являється каталог призначення (каталоги будуть створюватися на ходу як і коли потрібно).

Перенесення коштувало близько 40 - 60 хвилин (близько 35-45 000 файлів). Ми вважаємо, що це потрібно близько 12 годин або менше за 1 рік.

Використання Windows Server 2003.

Усі речі реєструються у файлі журналу ... Час початку, час закінчення та кількість скопійованих файлів.

Робокопія врятувала день.

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

Я вважаю за краще використовувати lz4 як найшвидший інструмент стиснення на даний момент. Опція SSH -c arcfour128 використовує швидший алгоритм шифрування, ніж за замовчуванням. [1]

Тож передача каталогів виглядає приблизно так:

tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'

Зверніть увагу, що в Debian командою lz4 є lz4c, а в CentOS - lz4.

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

[Редагувати]

Зауважте, що це лише програма для Windows.

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

Зараз ми розслідуємо це питання. Нам потрібно передати близько 18 мільйонів невеликих файлів - загалом близько 200 ГБ. Найкращі показники ми досягли, використовуючи звичайний старий XCopy, але це все-таки зайняло довгий час. Близько 3 днів від одного сервера до іншого, приблизно 2 тижні до зовнішнього накопичувача!

Через інший процес нам потрібно було дублювати сервер. Це було зроблено з Acronis. Минуло близько 3 годин !!!

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

Вже багато хороших пропозицій, але хотіли закинути в Beyond Compare . Нещодавно я передав близько 750 000 файлів між 5 КБ і 20 МБ з одного сервера на інший через гігабітний комутатор. Це навіть не було гикавки. Зрозуміло, це зайняло деякий час, але я б очікував, що так багато даних.

Я побачив би, як виконуються копіювання zip-> copy-> unzip

або будь-яка улюблена система стиснення / архівування.

Запакуйте їх в один файл, перш ніж скопіювати його, а потім розпакуйте їх знову після його копіювання.

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

Тар-підхід майже подвоїв швидкість передачі порівняно з scp або rsync (YMMV).

Ось команди смоли. Зауважте, що вам потрібно буде включити r-команди, створивши .rhosts файли в домашніх каталогах кожної машини (видаліть їх після того, як їх копіювання буде завершено - вони є сумнівними проблемами безпеки). Зауважте також, що як правило, HP-UX незручно - тоді як інший світ використовує 'rsh' для команди віддаленої оболонки, HP-UX використовує 'remsh'. "rsh" - це якась обмежена оболонка в мові HP.

box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "

Перша команда tar створює файл під назвою "-", що в цьому випадку є спеціальним маркером, що означає "стандартний вихід". Створений архів містить усі файли в поточному каталозі (.) Плюс усі підкаталоги (tar за замовчуванням є рекурсивним). Цей архівний файл вкладається в команду remsh, яка надсилає його до машини box2. У графі 2 я спочатку переходжу на відповідний каталог прийому, потім витягую з '-' або 'стандартного введення' вхідні файли.

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

Обхід файлової системи.

Чи можете ви відімкнути цей розділ, який містять файли на ньому, або змонтувати його лише заново? Зробіть це, то щось на кшталт:

dd if=/dev/PARTITION | ssh username@host "dd of=diskimage.bin"

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

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

ви можете спробувати наступне (може бути в групах файлів)

• тар пакет файлів
• gzip їх
• скопіюйте за допомогою scp, якщо можливо
• пістолет
• зніміть файли

За пропозицією sth, ви можете спробувати tar над ssh.

Якщо вам не потрібно шифрування (спочатку ви використовували rsync, але не згадували, що це rsync + ssh), ви можете спробувати tar через netcat, щоб уникнути накладних даних ssh.

Звичайно, ви також можете скоротити час, який потрібно, використовуючи gzip або інший метод стиснення.

Є ще щось, що варто врахувати. Спробуйте це:

• Створіть VHD, динамічного розміру
• Змонтуйте його, можливо, як каталог
• Встановіть атрибут "стиснення всього диска"

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

У Windows я встановлюю розмір пакета TCP за замовчуванням на більший розмір, наприклад, 16348. Це означає менше накладних витрат IP-заголовка.

Однак, однаково, у мене трапляється те, що найкраще тримати розмір файлів до 100 Мб для мережі або передачі через USB. Для цього я використовую Rar.exe - для розділення файлів.

Працює як чемпіон. Це еквівалент "dd" в Linux. Концепція встановлення стислої файлової системи до каталогу є звичайною і для Linux, тому застосовується та ж логіка. Вам слід забезпечити закриття всіх файлів до початку операції, як і в інших методах.

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

VHD, форматований як NTFS, може також обробляти мільйони файлів у папці.