Як повернути сайт, якщо збереглися файли, але втрачено базу даних

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

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

Що можна відновити з файлів

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

• каталог wp-content/uploads із зображеннями, відео та документами;
• активну тему та дочірню тему;
• встановлені плагіни й їхні конфігураційні файли;
• файл wp-config.php, у якому можуть залишатися назва бази, ім’я користувача та параметри підключення;
• файли кешу, тимчасові копії та експортовані налаштування;
• статичні HTML-файли, створені плагінами кешування або попереднім розробником.

Зображення та документи зазвичай можна повернути без бази даних, якщо вони фізично збережені на диску. Водночас їхні зв’язки зі сторінками, підписи, назви та записи медіатеки можуть бути втрачені. Файли теми допоможуть відновити зовнішній вигляд, але самі тексти сторінок і записи WordPress переважно зберігаються в таблицях MySQL.

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

Пошук дампів MySQL

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

• панель хостингу та розділ автоматичних резервних копій;
• домашній комп’ютер, сервер розробника або файлове сховище;
• поштові вкладення та службові листи від хостинг-провайдера;
• Google Drive, Dropbox, OneDrive та інші сховища;
• архіви, створені плагінами резервного копіювання WordPress;
• старі копії на іншому хостингу або тестовому домені;
• резервні знімки VPS, контейнерів чи панелей керування сервером.

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

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

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

Витяг контенту з кешу

Кеш може зберегти HTML-версії сторінок, якщо сайт раніше працював із плагіном кешування, CDN або серверним механізмом прискорення. Перевірити варто:

• каталоги кешу в wp-content/cache та подібних директоріях;
• кеш веб-сервера, наприклад Nginx або LiteSpeed;
• кеш CDN, якщо сайт використовував Cloudflare чи інший сервіс;
• збережені HTML-файли у резервних архівах;
• локальний кеш браузерів адміністратора або розробника.

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

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

Web Archive та пошукові копії

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

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

Детальніше про такий підхід можна прочитати у матеріалі Відновлення сайту з Web Archive: коли резервних копій більше немає.

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

Відбудова структури

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

1. Зберегти всі наявні файли та зафіксувати поточні налаштування сервера.
2. Перевірити файли на шкідливий код і визначити сумісні версії PHP, WordPress та розширень.
3. Розгорнути чисту копію WordPress на тестовому домені або локальному сервері.
4. Підключити медіафайли та перевірити їхні шляхи.
5. Відновити основні сторінки й записи за даними з архівів, кешу, документів компанії або пошукових копій.
6. Налаштувати меню, категорії, URL, форми, SEO-параметри та інтеграції.
7. Перевірити посилання, зображення, мобільне відображення, швидкість і журнали помилок.
8. Після перевірки створити нову резервну копію та лише тоді переносити результат у робоче середовище.

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

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