Що таке backup restore test і чому бекап без відновлення — це надія, а не план

Зачіпка

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

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

Проблема / Контекст

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

Типові сюрпризи з’являються саме під час restore. Архів може бути неповним. Дамп бази — застарілим або несумісним з новою версією сервера. Файли можуть відновитися, але без потрібних прав доступу. Секрети або encryption key можуть лежати в тому ж місці, яке зламалося. Документація може описувати стару інфраструктуру, якої вже немає.

Restore test прибирає цю ілюзію. Команда бере реальний backup, створює безпечне тестове середовище і проходить шлях від копії до робочого стану. Не обов’язково піднімати весь продакшн-клон щоразу. Але треба регулярно доводити, що критичні дані можна прочитати, сервіс стартує, а інструкції не вигадані.

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

У день аварії команда не має вивчати відновлення з нуля. Якщо база випадково видалена, сервер помер, ransomware зашифрував файли або невдалий deploy зіпсував дані, час стає дуже дорогим.

Backup restore test допомагає відповісти на практичні питання:

• скільки даних ми можемо втратити;
• за скільки часу повернемо сервіс;
• чи є у нас потрібні доступи;
• чи не зберігається backup поруч із тим, що може згоріти;
• чи розуміє інструкцію не лише одна людина;
• чи бачимо ми помилки до інциденту, а не під час нього.

Дві важливі метрики тут — RPO і RTO. RPO показує, наскільки свіжими мають бути дані після відновлення. Якщо backup робиться раз на добу, втрата останніх 24 годин може бути нормальною для блогу, але катастрофічною для магазину. RTO показує, скільки часу сервіс може бути недоступним. Для внутрішньої wiki це можуть бути години, для платіжного API — хвилини.

Схема в голові

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

З бекапами так само:

• backup job створює копію;
• storage зберігає її окремо;
• restore procedure пояснює кроки;
• test environment дає безпечне місце для перевірки;
• restore test доводить, що весь ланцюжок працює.

Якщо хоч одна ланка слабка, зелена галочка біля “backup created” мало що означає.

Як це зробити

1. Вибери найкритичніший сценарій

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

Опиши простий сценарій: “сервер недоступний, але останній backup є” або “потрібно відновити одну таблицю після помилки”. Чим конкретніший сценарій, тим легше його перевірити.

2. Підготуй безпечне місце для restore

Не відновлюй тестовий backup поверх production. Використай staging, окрему VM, тимчасовий контейнер або локальне середовище. Мета — перевірити відновлення без ризику знищити живі дані.

Для бази даних це може бути окремий контейнер PostgreSQL або MySQL. Для файлів — окрема директорія. Для повного сервісу — тимчасова машина з мінімально потрібною конфігурацією.

3. Пройди шлях як під час реальної аварії

Візьми backup зі звичайного місця зберігання, а не з красивої тестової копії. Перевір, що маєш доступ, пароль, encryption key, інструкцію і потрібні версії інструментів.

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

4. Перевір не тільки запуск, а й зміст

Сервіс може стартувати, але дані всередині можуть бути неправильними. Перевір кілька контрольних записів, кількість таблиць, наявність медіафайлів, логін тестового користувача, базові сторінки або API-запити.

Добрий restore test має закінчуватися не фразою “начебто піднялось”, а конкретним доказом: дані читаються, сервіс відповідає, критичний workflow проходить.

5. Запиши RPO, RTO і ручні кроки

Після тесту зафіксуй:

• з якого часу був backup;
• скільки даних потенційно втрачалося;
• скільки тривав restore;
• які кроки були ручними;
• хто має потрібні доступи;
• що треба автоматизувати або оновити в документації.

Це перетворює тест з разової вправи на покращення системи.

6. Повторюй після важливих змін

Restore test не треба робити щодня для всього. Але його треба повторювати після зміни схеми бази, міграції сервера, переходу на нове сховище, зміни encryption keys або появи нового критичного сервісу.

Маленький регулярний тест краще, ніж великий героїчний restore раз на два роки.

Антипатерни

• “Файл є — значить усе добре”. Файл може бути порожнім, пошкодженим, неповним або зашифрованим ключем, якого більше немає.
• Бекап у тому ж місці, що й основні дані. Якщо одна аварія знищує і сервер, і backup, це не резервна копія, а декорація.
• Restore знає тільки одна людина. Якщо процес тримається в голові одного адміністратора, аварія легко стає організаційною проблемою.
• Тест поверх production. Перевірка не має ризикувати живими даними.
• Без виміру часу. Якщо ніхто не міряв restore, RTO існує тільки в презентації.

Висновок / План дій

Backup restore test робить бекапи реальним планом, а не заспокійливою галочкою. Почни з одного критичного сервісу, віднови його в ізольованому середовищі, перевір дані, запиши час і онови інструкцію.

Мінімальний план:

1. вибери сервіс і сценарій аварії;
2. знайди останній реальний backup;
3. віднови його не в production;
4. перевір дані й базовий workflow;
5. зафіксуй RPO, RTO, помилки і наступні покращення.

Після такого тесту фраза “у нас є бекапи” починає означати щось конкретне: ми знаємо, як повернутися до роботи.