Резервна копія сайту має цінність не сама по собі, а лише тоді, коли з неї можна відновити працездатний ресурс. Файл у панелі хостингу або архів на диску ще не означає, що в ньому є всі необхідні дані, а процес відновлення завершиться без помилок.
Перевірку краще проводити заздалегідь, у контрольованих умовах. Це допомагає виявити пошкоджені архіви, неповну базу даних, відсутні медіафайли, несумісність версій PHP або проблеми з налаштуваннями сервера до виникнення аварійної ситуації.
Чому файл backup ще не гарантує відновлення
Резервна копія може бути неповною з кількох причин. Наприклад, автоматичний backup зберігає лише файли сайту, але не базу даних. Інший варіант — копіюється база, проте не додаються завантажені зображення, документи, конфігураційні файли або поштові налаштування.
- архів створився з помилкою або має нульовий чи підозріло малий розмір;
- у копії відсутня база даних або частина таблиць;
- пошкоджені окремі файли через збій диска чи перерваний процес копіювання;
- backup зроблено для іншої версії CMS, PHP або серверного програмного забезпечення;
- збережені файли не містять конфігурації підключення до бази даних;
- копія розташована на тому самому сервері, що й робочий сайт, тому може бути втрачена разом із ним.
Не варто перевіряти резервну копію відновленням поверх робочого сайту. Така дія може призвести до втрати актуальних даних, заміни нових замовлень або видалення змін, які ще не потрапили до backup. Перед будь-якими небезпечними операціями потрібна окрема резервна копія поточного стану сайту та бази даних.
Тестове середовище
Найбезпечніший спосіб перевірки — відновити сайт у тестовому середовищі. Це може бути окремий хостинг, піддомен із закритим доступом, локальний сервер або ізольований контейнер. Важливо, щоб тестова копія не була доступною пошуковим системам і випадковим відвідувачам.
Перед відновленням бажано зафіксувати характеристики робочого сайту:
- версію CMS, тему та активні плагіни;
- версію PHP, тип бази даних і параметри сервера;
- розмір файлів і бази даних;
- структуру директорій та доменні налаштування;
- критичні інтеграції: платіжні системи, CRM, пошту, аналітику та зовнішні API.
Після розпакування файлів і імпорту бази потрібно перевірити конфігурацію підключення, права доступу до каталогів, адресу сайту та правила перенаправлень. Для WordPress особливу увагу слід звернути на файл wp-config.php, таблиці бази даних, папку wp-content/uploads і налаштування постійних посилань.
Якщо сайт не запускається, не слід бездумно змінювати файли або видаляти таблиці. Спочатку потрібно зафіксувати текст помилки, час її появи та журнали сервера. Це полегшить діагностику й зменшить ризик додаткового пошкодження копії.
Перевірка бази й медіа
Після технічного запуску тестової копії перевіряють не лише головну сторінку, а й повноту даних. База має містити записи, сторінки, товари, категорії, користувачів, налаштування та іншу інформацію, необхідну для роботи бізнесу.
- відкрийте кілька старих і нових сторінок;
- перевірте пошук по сайту, категорії, фільтри та пагінацію;
- переконайтеся, що записи в адмінпанелі відображаються коректно;
- перевірте форми зворотного зв’язку без відправлення реальних клієнтських заявок;
- перегляньте зображення, PDF-файли, відео та інші завантаження;
- перевірте кирилицю, спеціальні символи та кодування тексту;
- переконайтеся, що немає масових помилок 404, проблем із редиректами та битих посилань.
Відновлений сайт також потрібно перевірити на наявність шкідливого коду. Якщо резервна копія була створена після зараження, вона може відтворити вірус разом із файлами сайту. Ознаками проблеми можуть бути невідомі адміністратори, підозрілі PHP-файли, змінені системні файли, сторонні скрипти або автоматичні перенаправлення.
Окремо оцініть, які дані втрачаються між моментом створення backup і моментом аварії. Для інтернет-магазину це можуть бути замовлення, платежі та облікові записи клієнтів. Тому недостатньо знати лише факт існування копії — потрібно визначити її актуальність і допустимий обсяг втрати даних.
Після відновлення важливо перевірити й пошукові налаштування. Практичні рекомендації щодо цього зібрані в матеріалі Як зберегти SEO після відновлення сайту з резервної копії.
Документування процесу
Результати тесту варто зафіксувати в простій інструкції. У ній зазначають, де зберігаються копії, за який період вони створені, як їх завантажити та які облікові дані потрібні для відновлення. Паролі не слід записувати у відкритому документі — для них краще використовувати менеджер паролів або захищене сховище.
Корисно описати послідовність дій:
- створити backup поточного робочого сайту перед тестом;
- підготувати ізольоване тестове середовище;
- відновити файли та базу даних;
- налаштувати версії PHP, CMS і серверні параметри;
- перевірити роботу сайту, адмінпанелі, форм та інтеграцій;
- зафіксувати помилки й відмінності від робочої версії;
- видалити або захистити тестову копію після завершення перевірки.
У документації також варто вказати відповідальну особу та порядок дій у разі збою. Якщо відновлення залежить від підрядника або адміністратора хостингу, заздалегідь перевірте, чи має він доступ до копій і чи зрозумілий формат звернення по допомогу.
Регулярність тестів
Одноразова перевірка не гарантує, що наступна резервна копія буде придатною. Змінюються версії CMS, плагіни, структура сайту, обсяг бази та правила на хостингу. Тому тестове відновлення потрібно повторювати за графіком і після значних змін у системі.
- для активного магазину або сайту з частими замовленнями — перевіряти копії частіше;
- після оновлення CMS, PHP, теми чи критичних плагінів — виконувати окремий тест;
- після перенесення на інший хостинг — перевіряти сумісність і повноту відновлення;
- після інциденту безпеки — не використовувати старі копії без аналізу на зараження;
- періодично перевіряти, чи відкриваються віддалені сховища та чи не завершився їхній ліміт.
Надійна схема передбачає кілька копій у різних місцях, контроль їхнього створення та періодичне тестове відновлення. Якщо сайт не запускається навіть у тестовому середовищі, база має помилки, backup пошкоджений або незрозуміло, які дані можна безпечно замінювати, краще звернутися до спеціаліста з відновлення сайтів. До діагностики не варто видаляти оригінальні файли, перезаписувати базу чи запускати сумнівні скрипти: ці дії можуть ускладнити подальше відновлення.
Журнал резервних копій і результати тестів
Для кожної копії корисно фіксувати дату, розмір, місце зберігання, склад архіву та результат перевірки. Якщо система формує контрольну суму файлу, збережіть її в журналі: це допоможе виявити пошкодження або неповне копіювання ще до аварії.
Після тестового відновлення запишіть тривалість розгортання, потрібні доступи, помилки та ручні кроки. Такий журнал перетворює резервне копіювання на керований процес і показує, чи вкладається команда в допустимий час простою. Він також спрощує вибір правильної копії, якщо доступні кілька архівів із різними датами.
Тест вважається успішним не тоді, коли архів просто розпакувався, а коли працюють адмінпанель, ключові сторінки, форми й база даних. Практична послідовність дій описана в матеріалі про те, як відновити WordPress із резервної копії. Результати наступних перевірок варто порівнювати з цим базовим тестом.