Наявність резервної копії не гарантує, що її можна відновити

Побачити на сервері файл із назвою на кшталт backup-2026-10-17.sql.gz дуже заспокоює.

Але сам факт існування файла ще не відповідає на головне питання: чи зможемо ми відновити систему, якщо production data зникнуть або будуть пошкоджені?

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

Мене цікавить не просто "файл є", а коли він створений.

Якщо backup має запускатися щодня, а останній файл триденної давнини, strategy вже не працює так, як ми думаємо.

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

Файл міг бути створений вручну місяць тому. Або backup job могла існувати раніше, але cron уже видалили.

Тому я перевіряю сам механізм, який має запускати backup: cron, systemd timer, scheduler, CI job або інший orchestration рівень.

Наявність запису в cron підтверджує лише те, що завдання налаштоване.

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

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

Журнал не повинен містити зайвих деталей, але має дозволяти зрозуміти, коли завдання запустилося, чи успішно завершилося, скільки часу тривало та який файл резервної копії створило.

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

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

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

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

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

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

Найважливіше питання не «чи є резервна копія?», а «чи можемо ми відновити з неї працездатну систему?».

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

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

Але принцип залишається незмінним: процедура відновлення має бути відома та перевірена заздалегідь, а не розроблятися під час аварійної ситуації.

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

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

Локальна резервна копія корисна для швидкого відновлення після помилки в даних або невдалого розгортання нової версії.

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

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

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

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

Наявність резервної копії не повинна створювати додатковий ризик витоку даних робочої системи.

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

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

Якщо резервне копіювання перестало працювати вночі, я не хочу дізнатися про це через три тижні під час аварійної ситуації.

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

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

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

Конкретна частота залежить від критичності даних і ресурсів, необхідних для відновлення.

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

• Остання успішна резервна копія створена відповідно до очікуваного розкладу.

• Є журнали виконання або інший спосіб визначити успішне завершення чи збій.

• Розмір останнього файлу резервної копії не має незвичних відхилень.

• Архів проходить базову перевірку цілісності.

• Зберігається кілька точок відновлення, а не один файл.

• Є резервна копія поза основним середовищем зберігання даних.

• Резервне копіювання охоплює всі незамінні дані системи.

• Процедура відновлення відома та перевірена.

• Відомі дата й результат останньої перевірки відновлення.

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

Файл на диску - це лише результат одного етапу резервного копіювання.

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

Тому під час перевірки робочого середовища я більше не запитую «чи є резервна копія?». Я запитую «коли було останнє успішне резервне копіювання, коли перевіряли його результат і чи можемо ми справді відновити з нього систему?».