Як зробити резервну копію сервера зберігання даних?

Я дивлюся на реалізацію дуже великого сервера зберігання даних, який буде використовуватися як жива NAS для декількох інших серверів (усіх Linux).

Я дуже маю на увазі між корисним простором між 4 ТБ та 20 ТБ (хоча навряд чи ми дійсно зробимо це 20 ТБ).

Сервер пам’яті буде RAID 10 для захисту даних та продуктивності, але нам все одно потрібне рішення для резервного копіювання, включаючи резервне копіювання за межами сайту.

Моє запитання: як створити резервну копію стільки даних !?

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

Мені потрібно складати бюджет на другий сервер зберігання за межами сайту чи є краще рішення?

Існує багато способів обробки даних такого розміру. Багато чого залежить від вашого оточення та того, скільки грошей ви готові витратити. Загалом, існує декілька загальних стратегій "вилучення даних із сервера":

• Через мережу Ethernet Як це сказано в коробці, дані передаються в Some Where Else для обробки. Копіювання 1GbE триватиме 20 ТБ, але це можна зробити. Апаратне забезпечення може допомогти (наприклад, посилання 10GbE або в деяких випадках NIC-зв'язок).
• Через підсистему зберігання Якщо ви перебуваєте на Fiber Channel, надішліть її на інший пристрій у мережі FC. Якщо у вас є SAS, надішліть його на пристрій, підключений до SAS. Взагалі швидше, ніж Ethernet.
• Надіслати його на інший дисковий масив Надіслати його на інший пакет пам’яті, приєднаний до того ж сервера.

Ось 100 км перегляду. Як тільки ви почнете збільшувати масштаби, речі стають набагато більш фрагментарними. Як вже було сказано, LTO5 - це специфічна стрічкова технологія, розроблена для таких видів навантажень високої щільності. Інший ідентичний масив пам’яті є хорошою ціллю, особливо якщо ви можете використовувати щось на зразок GlusterFS або DRBD, щоб отримати там дані. Крім того, якщо вам потрібна резервна ротація або просто можливість продовжувати працювати, якщо масив не вдасться вплинути на те, що ви поставите на місце.

Після того, як ви зупинитесь на 100-кілометровому способі перегляду, наступне велике завдання - потрапити в програмне забезпечення. Фактори, що впливають на це, - це те, що ви можете встановити на своєму сервері зберігання даних (в першу чергу, якщо це NetApp, це одне, сервер Linux з купою пам’яті - цілком інша справа, як і сервер Windows з купою пам’яті) , яке обладнання ви вибираєте (наприклад, не всі пакети резервного копіювання FOSS добре обробляють стрічкові бібліотеки), і який тип збереження резервного копіювання потрібно.

Вам дійсно потрібно розібратися, якого типу відновлення після катастроф ви хочете. Проста реплікація в реальному часі простіша, але не дозволяє відновити її лише з минулого тижня. Якщо здатність до відновлення з минулого тижня для вас важлива, тоді вам потрібно розробити такі речі. За законом (у США та інших місцях) деякі дані потрібно зберігати протягом 7+ років.

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

Про резервне копіювання стрічки ...

LTO5 може утримувати 1,5 Тб стиснення даних без огляду. Годування цих монстрів вимагає дуже швидкої роботи в мережі, яка є або Fiber Channel, або 6Gb SAS. Оскільки в резервному режимі потрібно створити резервну копію більше 1,5 ТБ, вам потрібно розібратися в автонавантажувачі (ось приклад: посилання , автозавантажувач на 1 гніздо на 24 слота від HP). За допомогою програмного забезпечення, яке їх підтримує, вони оброблятимуть зміну стрічок середньої резервної копії для вас. Вони чудові. Вам все одно доведеться витягувати стрічки, щоб надсилати їх за межі сайту, але це чортове видовище краще, ніж навішувати всю ніч, щоб завантажувати стрічки самостійно, коли резервна копія вимагає їх.

Якщо стрічка надає вам " legacy, ew " heebiegeeebies, віртуальна бібліотека стрічок може бути більшою вашою швидкістю (наприклад, ця з посилання Quantum:) . Вони претендують на бібліотеки стрічок для резервного копіювання програмного забезпечення, фактично зберігаючи речі на диску з надійними (сподіваєтесь) методами дедуплікації. Фанатніші навіть копіюють віртуальні стрічки на реальні стрічки для вас, якщо вам подобається така річ, яка може бути дуже зручною для обертання поза межами сайту.

Якщо ви не хочете спілкуватися з рівномірними віртуальними стрічками, але все ще хочете робити резервні копії прямого диска, вам знадобиться масив пам’яті, достатньо великий, щоб обробляти ці 20 ТБ, а також скільки потрібних даних про зміну мережі. триматися. Різні резервні пакети вирішують це по-різному. Деякі технології дедуплікації справді приємні, інші - хакіти. Я особисто не знаю стан програмних пакетів резервного копіювання FOSS в цій області (я чув про Bacula), але їх може бути достатньо. У багатьох комерційних пакетах резервного копіювання є місцеві агенти, які ви встановлюєте на сервери для резервного копіювання, щоб збільшити пропускну здатність, що має багато достоїнств.

Автоматичний автомат LTO-5? вам знадобиться десь від трьох до 15 стрічок для резервного копіювання цього масиву, що не є надзвичайно великим числом. Jukebox подбає про зміну стрічок для вас, а гарне програмне забезпечення для резервного копіювання (наприклад, бакула) буде відслідковувати, які файли (файли) є на якій стрічці.

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

Напевно, ви повинні дивитись на створення резервної копії на диску , оскільки стрічка займе тривалий час, а відновлення послідовного доступу триватиме назавжди.

Однозначно скористайтеся диференційованими або покроковими резервними копіями - лише резервне копіювання змін на будь-якій частоті, яка має сенс для вас.

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

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

Завжди думайте про процедуру відновлення . Ми один раз заїхали, коли нам довелося відновити файл із декількох сотень гіга завдань для резервного копіювання, що вимагало багато пам’яті та багато часу, щоб відновити індекс резервного копіювання та відновити. Врешті-решт ми не змогли виконати це за день, і довелося побудувати виділений сервер відновлення, щоб наш основний сервер резервного копіювання продовжував працювати за ніч!

- додано--

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

Спочатку перерахуйте ризики, від яких ви захищаєтесь. Деякі поширені ризики:

• Катастрофа: Щось дуже прикро трапляється з усім вашим сайтом.
• Людські помилки (це те, що відбувається _all_the_time_):
  • Хтось вирішує реалізувати можливість «гарячої заміни» вашого сервера зберігання способом, який не призначений виробником.
  • Хтось запускає процес, який мовчки пошкоджує дані, які надійно створюються резервними копіями за пару місяців до того, як проблема буде помічена.
  • Хтось видаляє важливий звіт, який повинен вийти за годину і коштує тисячі доларів.

Потім оцініть вартість різних рішень щодо запобігання ризику, наприклад:

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

Потім оцініть стратегії обертання (наскільки далеко ви хочете відновитись, скільки даних ви можете дозволити собі втратити).

Потім виберіть те, що ваші дані варті.

У мене є замовник з двома подібними системами на 12 ТБ у двох різних будинках, підключених на 1 Гб. Один - виробнича система; це резервне копіювання поступово (із щоденними знімками) до іншого за допомогою великої утиліти rdiff-backup . rdiff-резервне копіювання повинно бути доступним у вашому стандартному сховищі дистрибутива.

Позамінне резервне резервне копіювання (віддалене дзеркало)

використовувати rsync, хоча ssh (лише зміни) - спочатку резервне копіювання має бути зроблено локально, але після цього резервне копіювання буде вітерцем залежно від змін

якщо вам потрібно зберегти версії із зміною rdiff-backup

http://www.nongnu.org/rdiff-backup/

Файлова система btrfs в Linux звучить багатообіцяюче, але все ще на важкому розвитку

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

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