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

Що це таке

Аварійне відновлення (disaster recovery) — частина планування на випадок надзвичайних ситуацій, що охоплює найгірший сценарій: місце, де працює система, втрачено або воно надовго недосяжне, і систему доводиться відбудовувати деінде з копій. Посібник NIST з планування на випадок надзвичайних ситуацій для федеральних інформаційних систем США, SP 800-34 Revision 1 від 2010 року, визначає план аварійного відновлення як письмовий план відновлення однієї чи кількох інформаційних систем на альтернативному об’єкті після серйозного збою обладнання чи програмного забезпечення або знищення приміщень. Сфера в нього вузька. Посібник залишає такий план для великих, зазвичай фізичних, порушень, які надовго відрізають доступ до основного об’єкта, і охоплює ним лише ті порушення, що вимагають переїзду.

Саме ця вузькість відрізняє його від сусідніх понять. План на випадок надзвичайних ситуацій для інформаційної системи, у термінах посібника information system contingency plan, відновлює одну систему там, де вона стоїть, скажімо, після відмови диска чи пошкодження бази даних. План аварійного відновлення прив’язаний до місця: він переносить роботу на альтернативний майданчик, а вже там кожну систему піднімають за її власним планом. План для однієї бази даних і план на випадок втрати цілого дата-центру, хмарного регіону чи облікового запису в провайдера — це різні документи з різними власниками, і хто їх плутає, той зазвичай лишається без жодного з них.

Три показники перетворюють план із наміру на те, що можна перевірити. Максимально допустимий час простою (maximum tolerable downtime, MTD) — загальна тривалість збою, яку власник системи готовий прийняти. Цільовий час відновлення (recovery time objective, RTO) — найдовший час, протягом якого системний ресурс може бути недоступний, перш ніж шкода для інших систем і для бізнесу стане неприйнятною; а оскільки перервану роботу потім ще треба обробити заново, посібник зазначає, що RTO зазвичай має бути коротшим за MTD. Цільова точка відновлення (recovery point objective, RPO) дивиться назад: це момент до збою, на який можна відновити дані з найсвіжішої резервної копії, і вона показує, скільки втрачених даних бізнес може пережити. Простіше кажучи, RTO — це скільки ви лежите, а RPO — скільки роботи втрачаєте.

Альтернативний майданчик буває різного ступеня готовності. Холодний (cold site) дає лише приміщення та інфраструктуру, теплий (warm site) обладнаний частково, а гарячий (hot site) обладнаний повністю й має персонал. Посібник додає мобільні майданчики, які в багатьох випадках можна доставити протягом 24 годин, перш ніж почнеться розгортання, і дзеркальні — найдорожчий варіант, якому посібник приписує практично 100% доступності. Холодний майданчик найдешевше утримувати, але на його оснащення може піти чимало часу. Сьогодні для більшості програмного забезпечення ту саму роль відіграє другий хмарний регіон або другий провайдер, а компроміс між тим, що стоїть напоготові, і тим, скільки коштує тримати його напоготові, лишається тим самим.

Чому це важливо

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

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

План теж старіє. Люди звільняються, сервери замінюють, провайдери переробляють свої консолі, а паролі в інструкції з відновлення втрачають чинність. Із семи кроків, які NIST описує для планування на випадок надзвичайних ситуацій, останні два — тестування, навчання й тренування та підтримка плану; посібник хоче, щоб план був живим документом, який переглядають щонайменше раз на рік і щоразу, коли система чи ресурси для відновлення суттєво змінюються. План, який ніколи не відпрацьовували, зазвичай ламається на дрібницях, які нікому не спало на думку записати: порядок запуску сервісів, DNS-запис із TTL у добу, той єдиний ключ доступу, що зберігався на машині, якої більше немає.

Для команд, що пишуть програмне забезпечення, катастрофа — це часто обліковий запис, а не будівля. Видалений хмарний проєкт, зламаний вхід адміністратора, заблокований акаунт у провайдера чи руйнівна команда, виконана на продакшені, відрізають доступ до системи не гірше за повінь. Сервери в режимі очікування (standby) від останнього не захищають: такий сервер застосує помилковий DROP TABLE за лічені миті — так само, як застосовує будь-яку іншу зміну.

Як це виглядає на практиці

Для бази даних PostgreSQL RPO, набагато коротший за інтервал між двома резервними копіями, дає безперервне архівування журналу попереднього запису (write-ahead log, WAL) поверх базової резервної копії. Сервер копіює кожен заповнений сегмент WAL у безпечне місце, а під час відновлення ці сегменти програються поверх базової копії аж до будь-якого обраного моменту після того, як її зробили:

# postgresql.conf на захищеному сервері
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/archive/%f && cp %p /mnt/archive/%f'

Щоб відновитися, базову резервну копію розпаковують у новий каталог даних, кладуть туди порожній файл recovery.signal, а параметри відновлення вказують, де лежить архів і де зупинитися:

restore_command = 'cp /mnt/archive/%f %p'
recovery_target_time = '2026-03-10 17:14:00+01'
recovery_target_action = 'pause'

Документація PostgreSQL розповідає історію, заради якої ці параметри існують: хтось видаляє критичну таблицю о 17:15 у вівторок увечері, помічає це в середу опівдні й відновлює стан на 17:14. Досягнувши цілі, сервер за замовчуванням стає на паузу, щоб запитами можна було переконатися, що момент правильний, перш ніж сервер стане основним і почне приймати з’єднання; якщо момент не той, сервер зупиняють, задають пізнішу ціль і запускають знову. Точка зупинки має лежати після завершення базової резервної копії, а документація радить налаштувати й перевірити архівування ще до того, як зроблять першу базову копію. Коли відновлення завершується, сервер видаляє recovery.signal, щоб випадково не перейти в режим відновлення знову.

Engineer ApS надає резервне копіювання та відновлення як послугу: резервні копії, перевірені на ділі, а не на віру, і письмовий план на той ранок, коли сервер не підніметься. Що це означає, показують дві сторінки портфоліо. У проєкті резервних копій і відновлення як коду 2025 року термін зберігання резервних копій налаштовано в Bicep поруч із базою даних, тож відновлення на довільний момент часу — властивість шаблону, а не налаштування, яке колись хтось виставив у порталі, а середовище навколо бази теж описано як код, бо базу, відновлену в середовище, яке відбудовували з пам’яті, навряд чи можна вважати відновленою. Потім готовність до відновлення перевірили й задокументували, чесно назвавши прогалини: географічне резервування вимкнено, а цільовий час відновлення лише запропоновано, а не виміряно, бо навчань не проводили.

У проєкті резервних копій, які справді відновлювали, виконаному у вересні 2026 року, вихідною точкою була компанія, чиї репозиторії, база даних і сайт працювали на одному хмарному інстансі, а вся можливість відновлення трималася на знімку від провайдера: він лежав у тому самому обліковому записі, що й машина, компанія його не шифрувала, і з нього ні разу не відновлювалися. Нове рішення працює на таймері systemd: дамп бази даних, якщо вона є, потім зашифрований знімок restic із дедуплікацією в сховище іншого провайдера через SFTP, далі очищення за політикою зберігання й перевірка цілісності. Сигнал для dead man’s switch надсилається лише після успішного запуску, тож тривогу здіймає саме тиша. Щомісяця тренувальне відновлення дістає з репозиторію відомий файл і звіряє його. Твердження сторінки, що компанія може втратити хост і повернути свої дані, спирається на це щомісячне відновлення, а не на резервну копію, зроблену минулої ночі.

Де виникають проблеми

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

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

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

Цілі взято зі стелі. RTO, вписаний у документ без жодного тренування, — це лише пропозиція, а RPO, який припускає, що кожна резервна копія вдалася, — оптимізм. Виміряйте обидва під час навчань. NIST розрізняє штабні навчання (tabletop), які зводяться до обговорення й не задіюють обладнання, і функціональні навчання, що імітують роботу, аж до повномасштабних, які охоплюють кожен елемент плану; цифри дають саме другі.

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

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

Що почитати далі

• SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — повний посібник: як він визначає та окреслює DRP, сім кроків планування, MTD, RTO і RPO, альтернативні майданчики та види навчань, разом із шаблонами планів.
• Continuous Archiving and Point-in-Time Recovery (PITR) — розділ документації PostgreSQL 18 про архівування WAL, базові резервні копії й відновлення на обраний момент.
• Write Ahead Log — довідник параметрів archive_command, restore_command і налаштувань того, де має зупинитися відновлення.