Стратегії Disaster Recovery

RPO визначає частоту резервування або тип реплікації. Щоденний snapshot не забезпечить RPO у 15 хвилин.

RTO

Recovery Time Objective (RTO) — максимально допустимий час від моменту аварії до відновлення сервісу.

Приклади:

• RTO 24 години допускає ручне відновлення з резервної копії;

• RTO 30 хвилин може вимагати готової репліки та автоматизованого перемикання;

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

RPO і RTO потрібно визначати окремо для кожного компонента. Наприклад:

• каталог товарів може мати RPO 24 години;

• платежі — RPO, близький до нуля;

• аналітичне сховище — RTO кілька днів.

Не всі дані мають однакову бізнес-цінність, тому одна стратегія для всієї системи часто є надто дорогою або недостатньою.

Основні стратегії відновлення

Backup and restore

Система відновлюється з резервних копій після створення або підготовки нового середовища.

Переваги:

• найнижча вартість;

• проста архітектура;

• підходить для систем із великим допустимим RTO.

Недоліки:

• відновлення може тривати години;

• потрібно перевіряти сумісність резервної копії;

• можлива втрата даних між копіями.

Ця стратегія не означає «запускати backup вручну раз на місяць». Необхідні автоматизація, контроль успішності та регулярні тести відновлення.

Pilot light

У резервному середовищі постійно працюють лише мінімальні компоненти:

• реплікована база даних;

• конфігурація;

• мережеві ресурси;

• образи або артефакти застосунку.

Під час аварії запускаються обчислювальні ресурси та інші компоненти.

Перевага — швидше відновлення порівняно з повним backup and restore. Недолік — потрібно підтримувати сумісність резервного середовища з основним.

Warm standby

У резервному середовищі вже запущена зменшена копія системи. Вона може не обслуговувати весь production-трафік, але регулярно отримує дані та проходить перевірки.

Після аварії:

1. збільшується кількість ресурсів;

2. змінюється маршрут трафіку;

3. система переводиться в повний режим.

Це компроміс між вартістю та швидкістю відновлення.

Hot standby

Резервне середовище працює майже з тією самою потужністю, що й основне, і готове прийняти трафік.

Переваги:

• малий RTO;

• менше ручних дій;

• простіше виконувати планове перемикання.

Недоліки:

• висока вартість;

• складніша синхронізація;

• потрібно уникати одночасного запису в дві системи без продуманої моделі узгодженості.

Active-active

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

Це найскладніший варіант. Потрібно розв’язати проблеми:

• маршрутизації;

• розподілу стану;

• конфліктів запису;

• ідемпотентності операцій;

• узгодженості даних;

• запобігання split-brain.

Active-active не є автоматично кращою стратегією. Вона виправдана лише тоді, коли вимоги до RTO та доступності не можна виконати простішими підходами.

Резервні копії

Правило 3-2-1

Практичне правило резервування:

• щонайменше 3 копії даних;

• на щонайменше 2 різних типах носіїв або системах зберігання;

• щонайменше 1 копія в іншому фізичному розташуванні.

Для захисту від ransomware варто додатково мати:

• незмінні копії;

• окремі облікові дані для backup;

• обмежені права на видалення;

• ізольований обліковий запис або середовище;

• періодичну перевірку можливості відновлення без доступу до production.

Резервна копія в тому самому кластері не захищає від втрати кластера. Snapshot диска в тому самому регіоні не захищає від проблем у регіоні.

Що потрібно резервувати

План повинен охоплювати не лише основну базу даних:

• дані бази;

• структуру бази та міграції;

• великі об’єкти та файли користувачів;

• конфігурацію інфраструктури;

• секрети або контрольований механізм їх відновлення;

• черги та події, якщо вони не можуть бути повторно створені;

• доменні та мережеві налаштування;

• версії контейнерних образів;

• службові облікові записи та права доступу.

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

Повні, інкрементальні та логічні копії

Повна копія містить весь набір даних. Вона проста для відновлення, але може бути дорогою та довгою.

Інкрементальна копія містить зміни після попередньої копії. Вона економить місце, але відновлення може вимагати ланцюжка кількох копій.

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

Для баз даних із жорсткими вимогами до RPO часто використовують комбінацію:

• періодичних повних або фізичних копій;

• архівування журналів транзакцій;

• реплікації;

• логічних копій для окремих сценаріїв.

Приклад резервування PostgreSQL

Нижче наведено приклад скрипту, який створює логічну копію PostgreSQL у custom-форматі, зберігає глобальні об’єкти, обчислює контрольні суми та видаляє старі локальні копії.

Цей приклад не замінює повноцінний план для PostgreSQL із point-in-time recovery. Якщо потрібне відновлення до конкретного моменту, необхідно окремо проєктувати збереження WAL, базових фізичних копій і процедуру вибору точки відновлення.

Після копіювання в інше сховище потрібно перевірити:

• чи завершилася передача без помилок;

• чи збігаються контрольні суми;

• чи можна розпакувати або відновити дані;

• чи доступний ключ шифрування;

• чи не закінчився термін зберігання копії раніше запланованого.

Реплікація

Реплікація зменшує RPO та RTO, але не є заміною резервним копіям.

Якщо помилково виконати DELETE або шкідливе оновлення, реплікація може швидко передати ту саму помилку на всі репліки. Резервна копія або журнал змін потрібні для відновлення до стану до інциденту.

Синхронна реплікація

Підтвердження запису відбувається після доставки даних на резервну систему.

Переваги:

• мінімальна або нульова втрата підтверджених даних;

• кращий захист від відмови основного вузла.

Недоліки:

• більша затримка запису;

• залежність доступності від мережі та репліки;

• можливе блокування записів при недоступності резервного вузла.

Асинхронна реплікація

Основна система підтверджує запис раніше, ніж резервний вузол гарантовано отримує його.

Переваги:

• менший вплив на затримку;

• система може продовжувати роботу при тимчасовій проблемі з реплікою.

Недоліки:

• існує replication lag;

• під час аварії можна втратити останні записи;

• потрібно моніторити відставання репліки.

Рішення про синхронну чи асинхронну реплікацію приймають на основі RPO, допустимої затримки та вартості простою.

Проєктування плану DR

План варто будувати як послідовність перевірюваних рішень.

1. Інвентаризація компонентів

Для кожного сервісу зафіксуйте:

• власника;

• залежності;

• джерело конфігурації;

• спосіб резервування;

• RPO;

• RTO;

• спосіб перевірки працездатності;

• процедуру відновлення;

• критерії успішного завершення.

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

2. Визначення порядку запуску

Типова послідовність:

1. мережа, доступи та секрети;

2. сховище даних;

3. міграції або сумісна версія схеми;

4. черги та фонові обробники;

5. backend-сервіси;

6. кеші та пошукові індекси;

7. frontend і маршрутизація;

8. інтеграційні перевірки;

9. поступове повернення трафіку.

Кеш або індекс часто можна відновити після основної бази. Критичні дані — навпаки, потрібно відновити до запуску сервісів, які можуть виконувати записи.

3. Визначення режиму аварії

План повинен розрізняти щонайменше:

• відмову одного вузла;

• відмову всього майданчика;

• пошкодження даних;

• помилкове розгортання;

• компрометацію системи;

• втрату доступу до основного облікового запису.

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

Runbook

Runbook — це операційна інструкція для конкретного сценарію.

Він має містити:

• назву та умови застосування;

• критерії оголошення аварії;

• відповідального за прийняття рішення;

• перелік команд або дій;

• очікуваний результат кожного кроку;

• спосіб перевірки;

• процедуру відкату;

• правила комунікації;

• умови завершення аварійного режиму.

Приклад структури runbook для відмови основного майданчика:

1. Підтвердити, що проблема не є локальною помилкою моніторингу.

2. Оголосити інцидент і призначити Incident Commander.

3. Заборонити небезпечні автоматичні зміни в основному середовищі.

4. Оцінити останній доступний момент даних і фактичний RPO.

5. Перевірити стан резервної репліки або вибрати резервну копію.

6. Відновити базу та перевірити її цілісність.

7. Запустити залежні сервіси у визначеній послідовності.

8. Виконати smoke-тести читання та запису.

9. Перемкнути трафік поступово.

10. Перевірити помилки, затримки, черги та бізнес-метрики.

11. Зафіксувати час відновлення і фактичну втрату даних.

12. Після стабілізації спланувати повернення до основного майданчика.

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

Failover і failback

Failover

Failover — перемикання з основного середовища на резервне.

До перемикання потрібно встановити:

• який майданчик є джерелом істини;

• хто має право виконати перемикання;

• як запобігти одночасному запису в обидва майданчики;

• як оновити DNS, балансувальник або service discovery;

• як перевірити, що резервне середовище готове.

Найнебезпечніша ситуація — split-brain, коли два вузли вважають себе основними та приймають незалежні записи. Запобігання split-brain важливіше за швидкість перемикання.

Failback

Failback — повернення роботи на основне середовище після усунення аварії.

Failback не повинен бути автоматичним продовженням failover. Перед ним потрібно:

1. перевірити стан відновленого майданчика;

2. синхронізувати нові дані;

3. визначити коротке вікно перемикання;

4. перевірити маршрутизацію;

5. виконати контрольний тест;

6. мати план повернення на резервний майданчик.

Тестування плану

План, який ніколи не тестували, є припущенням, а не планом.

Типи тестів

Перевірка резервних копій

• перевірка успішного завершення jobs;

• перевірка контрольних сум;

• перевірка терміну зберігання;

• перевірка доступності копій.

Тест відновлення

• розгортання ізольованого середовища;

• відновлення бази;

• запуск застосунку;

• виконання функціональних перевірок.

Tabletop exercise

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

Тест failover

Трафік перемикається на резервне середовище за контрольованим сценарієм.

Chaos або fault injection

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

Що вимірювати

Після кожного тесту зафіксуйте:

• фактичний RTO;

• фактичний RPO;

• час виявлення проблеми;

• час прийняття рішення;

• час відновлення бази;

• час запуску сервісів;

• кількість ручних кроків;

• помилки та неочікувані залежності.

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

Моніторинг готовності до DR

Моніторити потрібно не лише production-доступність, а й готовність до відновлення:

• кількість успішних і невдалих backup jobs;

• вік найновішої резервної копії;

• replication lag;

• доступність резервного сховища;

• результат останнього restore-тесту;

• термін дії сертифікатів;

• доступність ключів шифрування;

• відповідність версій резервного середовища;

• наявність актуального runbook;

• перевірку доступів відповідальних інженерів.

Важливий сигнал — успішний job резервного копіювання сам по собі не доводить, що дані можна відновити. Потрібні незалежні тести відновлення.

Типові помилки

Вважати реплікацію резервною копією

Репліка поширює і коректні, і помилкові зміни. Вона доповнює backup, але не замінює його.

Зберігати всі копії в одному місці

Втрата регіону, облікового запису або ключа доступу може зробити недоступними всі копії одразу.

Не резервувати конфігурацію та секрети

Дані без можливості запустити застосунок не забезпечують відновлення сервісу.

Не перевіряти restore

Копія може бути пошкоджена, неповною, несумісною з поточною версією або зашифрованою ключем, до якого вже немає доступу.

Автоматично перемикати трафік

Автоматичний failover без перевірки стану даних може спричинити split-brain або перевести користувачів на пошкоджену репліку.

Не враховувати людський фактор

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

Не планувати failback

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

Summary

• Disaster Recovery охоплює дані, інфраструктуру, конфігурацію, доступи та операційні процедури.

• RPO визначає допустиму втрату даних, а RTO — допустимий час недоступності.

• Backup and restore дешевший, але повільніший; pilot light, warm standby і hot standby зменшують RTO ціною складності та ресурсів.

• Реплікація не замінює резервні копії, оскільки може поширити помилкові або шкідливі зміни.

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

• Runbook має містити конкретні кроки, відповідальних, перевірки, умови відкату та процедуру комунікації.

• Failover і failback потрібно проєктувати окремо, особливо з урахуванням ризику split-brain.

• Реальна готовність до катастрофи підтверджується лише регулярними тестами відновлення та вимірюванням фактичних RPO і RTO.