Успішний звіт резервного копіювання ще не доводить, що бізнес повернеться до роботи після аварії. Потрібні дані, конфігурація, доступи та зрозуміла послідовність запуску. План аварійного відновлення поєднує ці складові й перевіряє їх на практиці, поки робоче середовище доступне.
Погодьте допустимі втрати й перерву
RPO описує допустиму втрату останніх даних у часі, а RTO — цільовий час відновлення. Це різні вимоги. Щоденна копія може не відповідати задачі, де важливі зміни протягом дня; швидке відновлення сервера не допоможе, якщо бракує потрібної версії бази.
Визначаємо пріоритети сервісів разом із бізнесом. Не все потрібно запускати одночасно. Умовний приклад: для доступу до обліку спочатку потрібні мережа, система ідентифікації та сховище. Послідовність відновлення має враховувати ці залежності.
| Показник |
На яке запитання відповідає |
|
RPO |
Який проміжок останніх змін допустимо втратити? |
|
RTO |
За який час потрібно повернути погоджену функцію? |
Захистіть копії від тієї самої причини втрати
Копія на тому самому пристрої не захищає від його відмови. Сховище з тими самими адміністративними доступами може постраждати разом із робочою системою. Підбираємо незалежність, розмежування прав і захист від зміни відповідно до сценаріїв ризику та можливостей продукту.
Перевіряємо не лише базу, а й файли, конфігурацію та потрібні ключі. Доступ до резервів і секретів має бути можливим навіть за недоступності основного сервісу. Водночас не залишаємо їх у відкритій папці заради зручності аварійного доступу.
Проведіть відновлення в ізольованому середовищі
Навчальне відновлення не повинно перезаписувати робочі дані чи надсилати справжні повідомлення. Готуємо ізольоване місце, перевіряємо цілісність копії та послідовно повертаємо залежності. Записуємо час кожного етапу й неочікувані ручні дії.
Після запуску потрібна прикладна перевірка: працівник відкриває потрібний документ, виконує погоджену дію та бачить правильний результат. Старт операційної системи або успішний імпорт не замінює такої перевірки. Порівнюємо фактичні строки й доступні дані з цільовими.
Оновлюйте план після змін
Документ містить відповідальних, контакти, розташування копій, порядок доступу та критерії готовності. Його зберігаємо так, щоб він був доступний під час аварії. Якщо є підозра на компрометацію, відновлення враховує перевірку чистоти середовища та зміну доступів, а не просте повернення зараженої копії.
Після зміни сервера, інтеграції або сховища переглядаємо сценарій. Висновки репетиції перетворюємо на конкретні виправлення й повторні перевірки. План корисний лише тоді, коли ним може скористатися відповідальна команда, а не тільки його автор.
Джерела та подальше читання
