У панелі керування можна бачити десятки щоденних резервних копій і все одно залишитися без робочого способу відновлення. Типовий сценарій виглядає просто: після збою обирають учорашній backup, запускають restore — а база даних відсутня, архів пошкоджений або сайт після відновлення відповідає помилкою 500.
Наявність backup-файлу ще не означає, що сайт можна відновити. Копія має практичну цінність лише тоді, коли відомо, що саме до неї потрапило, де вона зберігається, чи читається архів і чи проходило реальне тестове відновлення. Автоматизація тут не проблема: проблема починається тоді, коли перевіряють сам факт створення копії, але не її придатність.
Щоденний backup може бути неповним
Сайт може не відновитися, якщо в резервну копію потрапила лише частина його даних. Для WordPress, Joomla, OpenCart та інших CMS недостатньо просто мати каталог із файлами: окремо існує база даних, а медіафайли можуть зберігатися у власних каталогах. Якщо хоча б одного критичного компонента немає, після restore повернеться лише частина системи.
Файли є, а бази даних немає
Найпростіший приклад — у копію потрапив public_html, але не створився дамп MySQL або MariaDB. У такому разі на місці можуть бути тема, плагіни, PHP-файли й wp-config.php, але записи, сторінки, користувачі, замовлення та налаштування CMS не повернуться. У підтримці це часто зводиться до короткої фрази: «Файли є, база не потрапила в копію».
В архіві або поруч із ним має бути SQL-дамп, а його розмір не повинен бути нульовим чи підозріло малим. Якщо резервну копію робить панель хостингу, варто окремо подивитися, чи була база включена до завдання.
База відновилася, але зникли uploads
Зворотна ситуація теж трапляється: база на місці, сайт відкривається, але немає фотографій, документів або вкладень. Для WordPress варто перевірити wp-content/uploads; для інших CMS — їхні каталоги media, images або storage. Великий каталог могли виключити з backup через ліміт розміру або невдале правило виключень.
Перед тим як вважати копію повною, потрібно чітко знати її склад: файли сайту, база даних, медіа, конфігураційні файли та, за потреби, дані за межами основного web-каталогу. Розмір архіву сам по собі нічого не доводить: файл на кілька гігабайтів може виглядати переконливо, але не містити БД.
«Backup completed» ще не доводить, що копія справна
Зелений статус у панелі означає, що завдання завершилося, але не завжди означає, що результат придатний до відновлення. Під час створення backup могли бути warning, timeout, помилки доступу до окремих файлів або нестача місця. Якщо на ці повідомлення ніхто не дивиться, проблема накопичується непомітно.
Корисний швидкий сигнал — розмір копії. Якщо протягом тижнів архіви займали 4,8–5,1 ГБ, а сьогоднішній має 180 МБ, це вже привід відкрити журнал завдання. Те саме стосується SQL-дампа: файл у кілька кілобайт замість звичних сотень мегабайт треба перевірити до того, як він знадобиться.
Для технічної перевірки можна подивитися логи backup-системи, вільне місце через df -h, inode через df -i, список файлів TAR-архіву через tar -tf або перевірити ZIP командою unzip -t. Команди не замінюють restore, але швидко відсіюють явно пошкоджені або неповні копії.
Дивитися варто не тільки на статус job, а й на фактичний результат: розмір, склад архіву, журнал помилок і можливість прочитати дані.
Тридцять копій можуть містити одну й ту саму проблему
Кількість точок відновлення не показує, чи є серед них справний стан сайту. Якщо зараження, пошкодження таблиці або випадкове видалення сталися раніше, ніж найстаріша доступна копія, усі 30 щоденних backup уже можуть містити ту саму проблему.
Наприклад, шкідливий файл потрапив на сайт 45 днів тому, але його виявили лише сьогодні. Якщо зберігаються тільки 30 щоденних копій, повернення на будь-яку з них не прибере початкову причину. Аналогічно, якщо каталог перестав копіюватися місяць тому через зміну налаштувань, усі нові копії повторюватимуть цю помилку.
Тридцять backup — це не обов’язково тридцять шансів на відновлення. Тут важливі дві різні речі: частота backup і глибина історії. Щоденна копія добре зменшує можливу втрату нових даних, але короткий retention не допоможе, якщо проблему помітили із запізненням. Варто знати дату найстарішої доступної точки та розуміти, чи можна повернутися до стану «до інциденту».
Але навіть правильна глибина історії не допоможе, якщо всі ці копії фізично лежать поруч із самим сайтом.
Копія на тому самому сервері не захищає від аварії самого сервера
Backup у каталозі /backup корисний для швидкого повернення окремого файла, але не захищає від повної втрати або недоступності сервера. Якщо сайт і копії залежать від одного накопичувача, файлової системи або облікового запису, вони мають спільну точку відмови.
Окремий каталог — ще не окреме сховище. Навіть другий virtual disk може фізично залежати від тієї самої інфраструктури. Відмова накопичувача, пошкодження файлової системи, компрометація сервера або помилкове видалення можуть одночасно зачепити production і локальні копії.
Є простий тест: якщо цей сервер завтра повністю зникне з доступу, звідки буде взято копію? Якщо відповіді немає, резервування все ще залежить від production-середовища.
У такій схемі окремий сервер для сайту може бути основним середовищем, а резервні копії варто виносити за його межі — в інше сховище або на інший вузол. Сам по собі окремий сервер не вирішує питання резервування: хоча б одна актуальна копія має пережити втрату основного середовища, а її restore потрібно перевіряти.
На практиці це може бути off-site backup, object storage, інший сервер або окреме сховище з незалежними обліковими даними. Критерій простий: копія має залишатися доступною навіть тоді, коли production уже недоступний.
Архів може існувати, але його неможливо використати
У панелі файл є, розмір виглядає нормальним, дата свіжа. Проблема з’являється лише під час першої спроби його розпакувати. Фізична наявність backup ще не гарантує, що його можна прочитати.
Архів може бути пошкоджений, неповністю переданий у зовнішнє сховище, зашифрований утраченим ключем або створений у форматі, для якого вже немає доступного інструмента відновлення. Зашифрований backup без доступного ключа практично не відрізняється від відсутнього.
Спочатку варто відкрити архів і переглянути список файлів. Для ZIP корисний тест цілісності, для TAR — читання структури архіву. Якщо використовується шифрування, окремо перевіряють пароль або ключ. Додатковий контроль — checksum, наприклад SHA-256: він не покаже, чи сайт запуститься після restore, але допоможе зрозуміти, чи не змінився файл під час передавання або зберігання.
Для багатотомних архівів потрібно мати всі частини. Втрата одного volume може зробити непридатним увесь набір, хоча решта файлів виглядатимуть справними.
Restore пройшов успішно, а сайт усе одно не запустився
Резервна копія може коректно повернути файли та базу даних, але не відтворити середовище, у якому вони працювали. Через це панель показує «Restore completed», а сайт відповідає 500, білим екраном або помилкою підключення до БД.
Дані відновилися, середовище — ні
Стара версія сайту могла працювати на PHP 7.4, тоді як новий сервер уже використовує PHP 8.x. Може відрізнятися MySQL або MariaDB, бракувати потрібного PHP-розширення, змінитися права на файли, шлях document root чи реквізити доступу до БД. Для частини проєктів важливі також cron-завдання та конфігурація вебсервера.
Успішне повернення файлів ще не дорівнює успішному поверненню сервісу. Якщо відновлюється стара копія або сайт переноситься на іншу машину, версії PHP, СУБД і ключові модулі варто порівняти зі старим середовищем.
Що перевірити після відновлення
Після restore потрібно відкрити не лише головну сторінку. Варто перевірити авторизацію в адмінпанелі, кілька внутрішніх сторінок, зображення, форми, підключення до БД та функції, від яких залежить робота проєкту. Для інтернет-магазину це може бути кошик і оформлення замовлення, для корпоративного сайту — форми заявок і завантаження файлів.
Якщо сторінка не запускається, перші джерела фактури — error_log, журнали вебсервера, конфігураційний файл CMS і фактична версія PHP. phpinfo() теж може допомогти з діагностикою, але такий файл не варто залишати у відкритому доступі після перевірки.
Backup, restore і disaster recovery — різні рівні готовності
Backup відповідає на питання «чи є копія», restore — «чи можемо ми повернути дані», а disaster recovery — «як повернути весь сервіс у роботу після серйозного збою». Мати архів — одна задача. Підняти сайт після повної втрати сервера — вже інша.
Рівень | На яке питання відповідає | Що потрібно перевірити |
|---|---|---|
Backup | Чи є копія даних? | Склад, свіжість, місце зберігання |
Restore | Чи можна повернути дані? | Цілісність, доступ, тестове відновлення |
Disaster recovery | Чи можна повернути сервіс у роботу? | Сервер, конфігурація, DNS, доступи, час відновлення |
Backup — чи є копія
Тут перевіряють склад, свіжість і місце зберігання. Без цього наступні кроки не мають сенсу.
Restore — чи можна повернути дані
Це практична здатність розпакувати архів, імпортувати БД, повернути файли й отримати придатний для запуску набір даних.
Disaster recovery — чи можна повернути сервіс
Тут додаються сервер, конфігурація, DNS, зовнішні інтеграції, доступи та час, потрібний на повернення проєкту в роботу.
У практичному плані тут достатньо двох показників — RPO та RTO. RPO показує, скільки свіжих даних допустимо втратити. Якщо backup створюється раз на добу, у найгіршому разі можна втратити майже добу змін. RTO показує, скільки часу допускається на повернення сервісу. Навіть справний backup не гарантує, що сайт підніметься за 15 хвилин.
Тестовий restore перевіряє весь ланцюжок
Єдина перевірка, яка показує, чи працює весь процес резервування, — реальне тестове відновлення. Перегляд логів, checksum і тест архіву корисні, але вони не відповідають на головне питання: чи запуститься сайт із цієї копії.
Де безпечно проводити тест
Не потрібно щоразу відновлювати production. Копію можна розгорнути в окремому каталозі, на staging, тестовій VM/VDS або на окремій БД. Для вебсайту зручно використати тимчасовий домен або локальну прив’язку через hosts, щоб не змінювати основний DNS.
Що перевірити після запуску сайту
Мінімальний тест має показати, що сторінки відкриваються, база підключається, користувач може авторизуватися, uploads доступні, форми працюють, а в логах немає критичних помилок. Для важливого проєкту корисно ще зафіксувати час, який зайняло відновлення, і всі ручні кроки, що довелося виконати.
Такий тест не обов’язково робити щодня. Але якщо автоматичні резервні копії створюються роками і з них жодного разу не робили restore, справність системи фактично не підтверджена. У технічному середовищі це часто формулюють коротко: backup перевіряється restore’ом.
П’ять запитань до будь-якої резервної копії
Перед аварією ніхто не хоче з’ясовувати, що саме лежить у черговому архіві. Тому робочий backup має давати чітку відповідь щонайменше на п’ять запитань. Якщо хоча б на одне з них відповіді немає, резервування краще вважати неперевіреним.
- Що саме копіюється? Файли сайту, база даних, uploads, конфігурація та інші критичні дані.
- Де лежить копія? Чи залишиться вона доступною, якщо основний сервер повністю втратить доступність.
- Наскільки вона свіжа? Чи відповідає частота backup допустимій втраті даних.
- Чи можна її відкрити та прочитати? Чи цілий архів, чи читається SQL, чи доступний пароль або ключ шифрування.
- Чи перевіряли з неї реальне відновлення? Не статус backup-job, а запуск сайту після restore.
Для важливих проєктів варто додати ще три питання: скільки часу займає відновлення, хто має доступ і знає порядок дій, та чи є в історії достатньо стара копія, щоб повернутися до стану до проблеми.
Десятки щоденних архівів можуть створювати відчуття безпеки, але воно нічого не варте без перевірки складу, цілісності, місця зберігання та процедури restore. Резервна копія стає корисною не в момент її створення, а в момент успішного відновлення.
