Резервне копіювання та відновлення UBD

Бекап, який не тестувався, — це не бекап, а файл. Половина організацій виявляє це у найгірший момент: під час реальної аварії. Стаття описує, як проектувати backup strategy для UBD так, щоб у момент потреби відновлення працювало, а не падало з помилкою «archived log file missing».

RTO і RPO: основні визначення

• RTO (Recovery Time Objective): скільки часу може бути система недоступна. RTO = 4 години означає: від моменту аварії до повного відновлення — не більше 4 годин.
• RPO (Recovery Point Objective): скільки даних можна втратити. RPO = 1 година означає: можна втратити максимум останню годину змін.

Ці два параметри визначають усю backup strategy. Чим менші RTO і RPO — тим дорожча інфраструктура.

Типи бекапів

Full backup

Повний знімок системи на момент створення. Простий у відновленні (один файл), але великий за розміром і довгий за часом створення. Зазвичай — раз на тиждень або раз на день для невеликих систем.

Differential backup

Зміни з моменту останнього full backup. Менший, ніж full, але росте з часом. Зазвичай — щоденно між full backup’ами.

Incremental backup

Зміни з моменту останнього будь-якого бекапа (full або incremental). Найменші файли, але відновлення вимагає всього ланцюжка: full + всі incrementals.

Log shipping (continuous)

Transaction log БД безперервно передається на резервний сервер. RPO = секунди. Стандарт для критичних систем.

Що бекапиться у UBD

UBD — система з кількох компонентів, кожен потребує власної стратегії:

• База даних: основне сховище. Full + log shipping.
• Файлове сховище: документи, аватари, attachment’и. Залежить від обсягу — від щоденного incremental до synchronous replication на S3.
• Конфігурація: файли конфігурації UBD-сервера. Невеликі, бекапляться разом з системою.
• WORM-журнал: окремо, з особливою стратегією — журнал не повинен пропадати під час інциденту, який потрібно розслідувати.
• Ключі шифрування: найкритичніше. Без ключів — БД марна. Зберігаються окремо, у HSM або у захищеному key vault, з кількома незалежними копіями.

Стратегія для АС-2

• Full backup щонеділі у 2:00 ранку.
• Differential щодня у 2:00.
• Log shipping кожні 15 хвилин.
• Зберігання: 4 тижні онлайн, 6 місяців у архіві, 5 років у cold storage.
• Файлове сховище: щоденний incremental + щотижневий full.

Стратегія для АС-3

• Full backup щодня.
• Log shipping кожні 1-5 хвилин.
• Active-passive replication на резервний майданчик з RPO <5 хв.
• Зберігання: 8 тижнів онлайн, 1 рік у архіві, 7-10 років у cold storage (залежно від регуляторики).
• Файлове сховище: synchronous replication.

Геопросторове розміщення

Правило 3-2-1: 3 копії даних, на 2 різних типах носіїв, 1 з них в іншій локації.

Для держсектору з вимогами щодо суверенітету даних — обидві локації у межах України. Для багатонаціональних організацій — допускається регіональний бекап (наприклад, EU-локація для GDPR-compliant даних).

Відстань між локаціями — від 50 км для звичайних аварій (пожежа, повінь) до 500+ км для масштабних подій (землетруси, регіональні відключення електроенергії).

Шифрування бекапів

Бекапи завжди зашифровані at-rest, навіть на локальному сховищі. Алгоритм — той самий, що для основної БД (ДСТУ 7624 або AES-256). Ключі — НЕ зберігаються разом з бекапами.

Окремий випадок: cold storage (стрічки, S3 Glacier, архівне сховище). Тут крім шифрування — окремий ключ, що зберігається у HSM, з процедурою rotation раз на 1-2 роки.

Тестування DR

Бекап без тестування — фікція. Регулярне тестування — обов’язкове за НД ТЗІ 2.5-004-99 (Б.10) і ISO 22301.

Table-top exercise (раз на квартал)

Команда збирається і теоретично проходить процедуру: «припустимо, основний дата-центр зник, що робимо першим?». Дешеве, виявляє проблеми у процесі (контакти неактуальні, документація не оновлена).

Partial test (раз на півроку)

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

Full failover (раз на рік)

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

Складно, дорого, але виявляє реальні проблеми (мережева конфігурація, помилки у документації, забуті залежності).

Регуляторні вимоги

• НД ТЗІ 2.5-004-99 (Б.10) — резервне копіювання як обов’язкова функція безпеки.
• NIST 800-34 — Contingency Planning Guide.
• ISO 22301 — Business Continuity Management.
• GDPR Art. 32 — відновлюваність даних як технічна міра безпеки.
• Для деяких категорій (наприклад, медичні записи) — мінімальний термін зберігання визначається окремими галузевими нормами.