Аварійне відновлення. План аварійного відновлення

1. Системи GNU / Linux Red Hat для high availability
2. 1 Аварійне відновлення / disaster recovery
3. 1.2 Рекомендації по організації сховища даних
4. 1.3 Віддзеркалення даних між ЦОД як інструмент disaster recovery planning
5. 2 Висока доступність ІТ-систем / High Availability з Bacula
6. 2.2 Підвищення доступності системи за допомогою кластерного рішення / high availability clustering
7. 2.2.1 Архітектура high availability cluster
8. 2.2.2 Кластерні ресурси
9. 2.2.3 Синхронізація конфігурації Bacula
10. 2.2.4 Каталог PostgreSQL
11. 3 Стандартні рішення по аварійному відновленню / disaster recovery solutions
12. 3.1 Підготовка до аварійного відновлення системи / system disaster recovery
13. 3.2 Стандартне аварійне відновлення систем GNU / Linux
14. 3.3 Аварійне відновлення GNU / Linux на «голе залізо» / Linux disaster recovery
15. 3.4 Аварійне відновлення Windows на «голе залізо» / Windows disaster recovery
16. 3.5 Аварійне відновлення конфігурації Bacula / Bacula Disaster Recovery
17. 3.6 Аварійне відновлення служби Director / Director Disaster Recovery
18. 3.7 Аварійне відновлення Storage Daemon
19. 3.8.1 Використання процедури гарячого резервування або передачі журналів
20. 3.8.2 Використання резервної копії каталогу

В даному документі детально розглядаються принципи і процедури, які необхідно дотримуватися для реалізації стратегії аварійного відновлення і підвищення доступності, т.зв. disaster recovery & high availability ІТ-систем з Bacula Enterprise Edition.

В даному документі містяться рекомендації з підготовки до створення резервних копій і відновлення пo Bacula в аварійних ситуаціях. Документ також містить різні стратегії, що дозволяють обмежити час простою служб резервного копіювання після перебою в роботі системи. Крім цього, ПО Bacula дозволяє різними способами підвищити доступність системи. Деякі з цих способів реалізуються відносно просто, однак, не повністю автоматично. Інші способи більш складні, але можуть скоротити час простою системи до пари секунд.

Будь ласка, візьміть до уваги, що повний план аварійного відновлення інформаційної системи, т.зв. disaster recovery plan - досить складний і об'ємний документ. Планування, тобто disaster recovery planning, має відповідати вимогам кожної конкретної організації (площадки) і може бути розроблено тільки при тісній співпраці з особами, що приймають ключові рішення і службовцями центру обробки даних (ЦОД). План аварійного відновлення ІТ-інфраструктури визначає черговість і пріоритетність вирішення проблем, що виникають в інформаційних системах при аваріях, збої і катаклізмах. Документ містить конкретний і детальний покроковий алгоритм дій ІТ-співробітників в разі збоїв різних інформаційних систем. Для створення плану аварійного відновлення необхідно визначити потенційні ризики, оцінити максимальний час простою і час на відновлення різних елементів інфраструктури. План аварійного відновлення завіряється топ-менеджментом компанії. Для спрощення написання плану аварійного відновлення ми створили шаблон, а також метод створення документа. Ви можете завантажити шаблон плану аварійного відновлення, заповнивши форму:

Системи GNU / Linux Red Hat для high availability

Даний документ містить рішення для ПО Bacula Enterprise 4.0 і пізніших версій. Рішення для аварійного відновлення, тобто disaster recovery solution і підвищення доступності, тобто high availability clustering описані для систем GNU / Linux Red Hat а також баз даних PostgreSQL.

1 Аварійне відновлення / disaster recovery

1.1 Попередні рекомендації для disaster recovery planning

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

• Переконайтеся в тому, що у вас є відповідний завантажувальний файл для резервної копії системи і резервна копія каталогу, і що вони збережені на альтернативній машині. Це дозволить вам швидко відновити систему (system disaster recovery).
• Переконайтеся в тому, що каталог зберігається кожен день. Ви також можете додати бінарні і конфігураційні файли Bacula в набір файлів FileSet резервної копії BackupCatalog.
• Якщо є можливість, щодня копіюйте ваш каталог на альтернативну машину (catalog disaster recovery). Якщо у вас є відповідний завантажувальний файл, дана процедура не обов'язкова, але може бути корисною, якщо ви не хочете перезавантажувати все підряд.
• Зробіть копію файлів Bacula з розширенням .conf, зокрема файлів bacula-dir.conf і bacula-sd.conf, оскільки в разі відмови сервера, ці файли будуть потрібні для його відновлення, а їх досить складно відновити з пам'яті. Використання вихідної версії системи управління, наприклад, git або svn спільно з віддаленим репозитарием в директоріях з файлами і скриптами може допомогти вам відстежувати конфігураційні зміни створювати бекап віддалено після кожної зміни.
• Перш ніж виконувати відновлення в аварійній ситуації, проведіть тести з використанням USB накопичувача або CD диска.
• Переконайтеся в тому, що ви «запам'ятали» структуру розділів дисків для всіх серверів. Процес можна спростити при використанні USB-ключа Bacula Systems для Linux і Windows.

1.2 Рекомендації по організації сховища даних

Чи є у вас стороннє сховище для резервних копій даних на випадок, якщо згорить або буде інший спосіб зруйновано будівлю, в якому розташовуються ваші комп'ютери і сервери? Зберігати дані «на стороні» можна на магнітних стрічках, які, в свою чергу, можна зберігати в сховище або навіть в банківському сейфі. Все набагато складніше, якщо мова йде про великий дисковому масиві, з яким необхідно звертатися з особливою обережністю. Звичайно, ви можете організувати перехресне резервне копіювання даних з використанням декількох ЦОД, якщо у вас вони є. Або ж можна створювати копії даних за допомогою послуг постачальника хмарних послуг. Однак використання хмарного сховища може обернутися вельми великими витратами, особливо, якщо мова йде про зберігання великих обсягів даних. Щоб знизити не тільки витрати, але і навантаження на мережу, можна скористатися методом створення інкрементальних резервних копій. Однак також варто подумати про швидкість відновлення даних. Деякі постачальники хмарних послуг надають доступ до своїх ЦОД в екстрених ситуаціях і «заливають» дані на диски безпосередньо зі сховища.

Малюнок 1. Перехресне резервне копіювання з використанням декількох ЦОД

Малюнок 2. Використання сховища провайдера хмарних сервісів

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

1.3 Віддзеркалення даних між ЦОД як інструмент disaster recovery planning

Відновлення системи з резервної копії без повністю функціональної резервної копії - завдання не з простих. Віддзеркалення серверів з резервними копіями Bacula між декількома ЦОД допоможе уникнути стресу в критичній ситуації. У наступному розділі ми розповімо про те, як знизити час простою служби резервного копіювання та відновлення Bacula за допомогою запуску служби Director і каталогу в кластерному режимі з реплікацією конфігураційних, бінарних файлів і БД. Якщо ви прийняли рішення про створення дзеркал серверів з Bacula Storage Daemon, вам слід вирішити, яким чином томи будуть доступні на шпалери хостах. У разі великого обсягу даних віддзеркалення може в два рази збільшити вартість рішення. Якщо ви вирішите зробити область зберігання доступною для двох вузлів, то дане рішення повинно узгоджуватися з планом аварійного захисту. Наприклад, якщо згорить будинок, в якому зберігається пристрій зберігання даних (магнітні стрічки або диски) і первинний сервер Storage Daemon, згорить, дзеркальний сервер Storage Daemon буде практично марний для відновлення даних. В такому випадку ви будете захищені виключно від відмови серверного обладнання, на якому зберігатися Storage Daemon. У такій ситуації можна прийняти рішення про створення дзеркал тільки критичних пулів.

2 Висока доступність ІТ-систем / High Availability з Bacula

2.1 Як вибрати рішення для high availability, яке відповідає вашим потребам

<5 хв High availability cluster високої доступності і реплікація БД на рівні блоку Необхідний навик використання технології кластеризації, наприклад HACMP, HeartBeat- / Pacemaker, і т.д. <1-3 годин Резервні апаратні засоби і реплікація БД Необхідна чітка процедура для відновлення Bacula і використання внутрішньої реплікації PostgreSQL. 12> годин Резервні апаратні засоби і реплікація БД Необхідна чітка процедура для відновлення Bacula. Ви можете відновити каталог PostgreSQL з моменту останнього резервного копіювання.

Якщо станеться відмова сервера, на якому зберігатися каталог, будуть втрачені всі записи про резервних копіях каталогу. Відстеження електронних листів і завантажувальних файлів допоможе відновити файли, але цей спосіб не зовсім зручний. Щоб уникнути слежностей, можна скористатися функцією PostgreSQL Continuous Archiving і створити бінарні резервні копії каталогу, а також не користуватися стандартною процедурою створення SQL дампа. дивіться http://www.postgresql.org/docs/9.0/

Архітектура Bacula Enterprise

2.2 Підвищення доступності системи за допомогою кластерного рішення / high availability clustering

Дане рішення є високотехнологічне рішення high availability server для Bacula. Якщо ви не знайомі з цією технологією, ви можете зіткнутися з високими витратами на навчання. Ваші рішення повинні бути продиктовані вашими потребами. За допомогою резервного обладнання можна інтегрувати рішення Bacula і стандартні кластерні рішення на базі Linux, наприклад Heartbeat або Pacemaker (дивіться http://www.linux-ha.org )

У разі відмови диспетчер ресурсів типу Pacemaker або Heartbeat автоматично ініціює відновлення і забезпечить доступність ПО з однієї з працюючих машин в кластері. Pacemaker - це нова версія Heartbeat, яка дозволяє працювати зі складними конфігураціями кластерів. Bacula не вимагає іспольованія складних кластерів, тому рекомендуємо вам створювати просту конфігурацію типу Primary / Slave. Інша частина документа буде присвячена використанню Heartbeat як диспетчера ресурсів. Реплікацію даних PostgreSQL сервера можна виконати за допомогою інструменту DRBD (реплікація дані з використанням блокових пристроїв) від LINBIT (дивіться http://linbit.com )

2.2.1 Архітектура high availability cluster

Для великого підприємства, можливо, буде потрібно робота декількох серверів Storage Daemon для служби Director (SD1 і SD2 на малюнку нижче) А ще вам, можливо, буде потрібно виділений сервер PostgreSQL Catalog для Director (SGBD на малюнку нижче). Всі сервера повинні бути оснащені:

Малюнок 4. Використання Bacula в середовищах декількох ЦОД / high availability cluster

• RAID дисками з можливістю зворотного запису
• Множинними Ethernet-каналами з можливістю визначення і обробки відмови при використанні модуля ядра в якості сполучного елемента. Ці канали повинні бути підключені до різного незалежного мережевого обладнання
• Оперативно підключається обладнанням і резервним джерелом живлення. У даній архітектурі кожен сервер, який використовується для установки компонентів Bacula, повинен бути захищений з використанням другого сервера, розташованого в іншому ЦОД. Кожна пара кластерних вузлів повинна мати виділений прямий оптоволоконний Ethernet-канал і повинна підтримувати механізм STONITH. У разі наявності єдиної точки відмови у всіх серверів Storage Daemon (наприклад, через те, що не використовувався метод віддзеркалення дисків між ЦОД, або ж прямого підключення авточенджера), вам не обов'язково захищати їх на одному рівні. При цьому, буде досить використовувати кілька резервних елементів.

2.2.2 Кластерні ресурси

Роль агента ресурсу полягає в абстрагуванні від служби, яку надає агент, і формуванні узгоджується уявлення про кластері. Це дозволяє кластеру не залежати від ресурсів, якими він управляє. Кластеру не потрібно «розуміти», як працюють ресурси, так як він покладається в своїй роботі на агент ресурсу, що дозволяє йому виконувати потрібні завдання при ініціалізації команди запуску, зупинки та моніторингу.

Як правило, агенти ресурсів представлені у вигляді скриптів оболонки, проте, вони можуть бути написані на будь-якій мові (наприклад, C, Python або Perl). При використанні ПО Bacula будуть використовуватися такі стандартні ресурси в диспетчері ресурсів:

• Віртуальний IP адреса

Малюнок 5. Визначення Pacemaker / Heartbeat

• Служба Bacula Director
• Служби Bacula Storage
• Резервні файлові системи
• Служба PostgreSQL Catalog
• Файлова система з даними і файлами конфігурації PostgreSQL

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

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

2.2.3 Синхронізація конфігурації Bacula

У разі використання даного рішення диспетчер ресурсів (Heartbeat) визначить, чи відбувся відмова вузла або служби, і перезапустить її в потрібному місці. Однак рішення не гарантує, що конфігурація Bacula буде синхронізована між вузлами. Найпростіше в цьому випадку періодично використовувати службу rsync на головному вузлі, а також використовувати її автоматично після команди перезавантаження.

2.2.4 Каталог PostgreSQL

Захист SQL каталогу (PostgreSQL або MySQL) - завдання досить масштабна. Існує безліч різних способів виконання поставленого завдання. Найбільш складною частиною є створення конфігурації з високою доступністю PostgreSQL. Щоб перезапустити службу на вторинному вузлі після збою, дані повинні бути реплікуються між вузлами.

Для реплікації можна використовувати високотехнологічне обладнання, стандартну реплікацію PostgreSQL, або реплікацію DRBD (RAID1 для всієї мережі, дивіться http://linbit.com )

У системах на основі відкритого коду регулярно застосовуються кластери, які використовують рішення на базі HeartBeat, DRBD і PostgreSQL. Досить просто знайти інформацію і джерела з таких видів кластерів.

Малюнок 6. Архітектура DRBD

DRBD - це програмний модуль на основі відкритого вихідного, що розробляється більше 10 років. Він був офіційно включений до складу Linux Kernel 2.6.33. Він простий, характеризується високою продуктивністю і гнучкістю. Він підтримує технологію забезпечення безпечних транзакцій. Все це означає, що DRBD дозволяє реплицировать дані безпечним і надійним способом, не залежно від навантаження. Служба підтримки LINBIT надає допомогу при установці модуля, забезпечує цілодобову підтримку, а також надає підтримку при виникненні одиничного випадку відмови.

Вартість даного методу реплікації даних може на 10-15% збільшити витрати на використання дискового сховища, однак, модуль має переваги, що гарантують безпеку і надійну роботу системи під час операцій по переходу в режим резервної роботи / режим взаємної поглинає конфігурації. Завдяки використанню модуля практично відсутня ймовірність втрати даних при використанні неправильної послідовності команд. Передача потокового реплікація з використанням PostgreSQL виконується швидше, однак, вимагає ретельного дотримання процедур перед повторною активацією реплікації. Оскільки DRBD відмінно інтегрується з HeartBeat (LINBIT є стороною, яка надає офіційне супровід диспетчера ресурсів HeartBeat), після ініціалізації і синхронізації томів, HeartBeat повинен отримати правильне визначення.

3 Стандартні рішення по аварійному відновленню / disaster recovery solutions

Оскільки ПО Bacula дозволяє створювати резервні копії та відновлювати будь-які системні файли Unix / Linux, наприклад, файли char і блокові файли, а також файли hardlinks, symlinks і т.д, його можна використовувати для відновлення системи безпосередньо.

3.1 Підготовка до аварійного відновлення системи / system disaster recovery

Найбезпечніший спосіб аварійного відновлення системи - це попереднє створення повного бекапа.

Якщо ви використовуєте утиліту для відновлення системи на «голе залізо», вам буде потрібно запустити інструмент аналізу мережі та диска до створення резервної копії системи.

Можливо, вам буде потрібно виключити несистемні дані з обсягу даних для бекапа, наприклад, дані з директорії / home, і використовувати утиліту для створення резервних копій цих файлів з використанням іншої політики. Якщо ваша мережа включає безліч ідентичних серверів (на яких встановлена ​​одна і та ж ОС, однією і тією ж версією), ви можете використовувати функцію Bacula Enterprise File Deduplication.

3.2 Стандартне аварійне відновлення систем GNU / Linux

Вам необхідно виконати наступні кроки по відновленню системи з резервної копії та її запуску:

1. Завантажте нову або відновлену систему з Використання USB-флешки або CD диска для аварійного Відновлення
2. Встановіть мережевий Підключення (по локальній мережі)
3. Повторно розбійте жорсткий диск (і) на розділи так, як смороду були розбіті Ранее
4. Повторно отформатируйте розділи
5. Встановіть або запустіть утіліту Bacula File Daemon (статичну версію)
6. Виконайте відновлення всіх файлів з використанням Bacula
7. Повторно встановіть програму початкового завантаження
8. перезавантажитеся

Більш детальну інформацію щодо відновлення ви знайдете в документації до ПЗ Bacula Enterprise.

3.3 Аварійне відновлення GNU / Linux на «голе залізо» / Linux disaster recovery

ПО Bacula Systems містить утиліту для відновлення системи Linux на «голе залізо» , Що, в окремому випадку, дозволяє досить швидко відновлювати сервера. Ця утиліта була розроблена для автоматичного збору та обробки даних мережевої конфігурації і структури дисків, необхідних для відновлення системи, після створення кожного повного бекапа.

1. Завантажте нову або відновлену систему з використанням USB-флешки або CD диска для відновлення системи на "голе залізо"
2. Встановіть з'єднання з мережею (по локальній мережі). Не примушуйте себе продовжувати до тих пір, поки не буде встановлено підключення до мережі
3. Повторно розбийте жорсткий диск (і) на розділи так, як вони були розбиті до використання утиліти для відновлення на «голе залізо»
4. Виконайте відновлення всіх файлів з використанням Bacula, використовуючи утиліту відновлення на «голе залізо»
5. Повторно встановіть програму початкового завантаження
6. перезавантажитеся

3.4 Аварійне відновлення Windows на «голе залізо» / Windows disaster recovery

ПО Bacula Systems містить утиліту для відновлення системи Windows на «голе залізо» , Що, в окремому випадку, дозволяє досить швидко відновлювати сервера. Більш детальну інформацію ви знайдете в документації по відновленню Windows на «голе залізо» з використанням рішень Bacula Systems.

3.5 Аварійне відновлення конфігурації Bacula / Bacula Disaster Recovery

При використанні пакетів програм Bacula Enterprise всі файли, які необхідні для запуску і конфігурації ПО Bacula, розташовуються в каталозі / opt / bacula. Установка основних залежностей, наприклад, клієнтських бібліотек PostgreSQL або MySQL (з використанням формату пакетів ПО Bacula Systems), і відновлення цього каталогу на новому сервері передбачає швидкий запуск нової копії Bacula. Цей метод може бути використаний і для відновлення служби Director, як описано в розділі 3.6.

3.6 Аварійне відновлення служби Director / Director Disaster Recovery

Якщо ваші конфігураційні і бінарні файли збережені на іншому резервному сервері (наприклад на сервері Storage Daemon, або сервері каталогу) як рекомендується, ви зможете відновити службу Director, виконавши такі дії:

• Скорегуйте шлях до нового бінарним файлу в завантажувальному скрипті bacula-ctl-dir
• Закоментуйте всі директиви Job Schedule в файлі bacula-dir.conf
• Скопіюйте IP адреса служби Director на тимчасовий сервер
• Переконайтеся в тому, що тимчасовий сервер Director може підключатися до сервера, на якому розташований каталог
• Запустіть тимчасову службу Director Daemon
• Запустіть процедуру відновлення на «голе залізо» або стандартну процедуру відновлення на сервері з Director
• Зупиніть виконання тимчасової служби Director і деконфігуріруйте IP адреса Director
• Перезавантажитеся для використання оновленої служби Director
• Протестуйте службу Director, створивши одну резервну копію і виконавши відновлення файлів на сервері Storage Daemon

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

3.7 Аварійне відновлення Storage Daemon

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

3.8.1 Використання процедури гарячого резервування або передачі журналів

NTT розробила систему реплікації без поділу ресурсів для PostgreSQL з передачею журналів транзакцій. Мета рішення - мінімізувати час простою і збільшити продуктивність системи. Таким чином, час відновлення системи після відмови може бути скорочено до 15 секунд, а непередбачені витрати можуть збільшитися на 7% і то, в разі найскладніших завдань в поточній реалізації рішення.

Малюнок 7: Гаряче резервування каталогу PostgreSQL

Даний метод дозволяє забезпечити доступність валидной копії каталогу в мережі. У разі відмови сервера з каталогом вам потрібно буде лише активувати PostgreSQL в режимі master на вузлі з резервною копією, змінити віртуальний IP адреса і перезапустити службу Director.

3.8.2 Використання резервної копії каталогу

Якщо ви створюєте резервні копії БД щодня (як годиться), а також згенерували завантажувальний файл, ви можете швидко відновити БД (або ASCII SQL файл). Зробіть копію вашої поточної БД, повторно її Ініціалізуйте, після цього ви зможете запустити ПО Bacula. Якщо після цього ви спробуєте використовувати команду відновлення, вона не буде виконана, так як БД буде порожня. Після відновлення БД, ви можете виконати процедуру імпорту БД. При відновлення БД з ASCII SQL файлу, в залежності від розміру каталогу, процедура може зайняти до декількох годин. Відновлення можна виконати швидше, якщо використовувати бінарні бекапи каталогу.

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