Є лише резервна копія бази WordPress: що можна відновити

Резервна копія бази даних WordPress — це важлива частина сайту, але не повний його архів. У базі зберігаються записи, сторінки, налаштування та інша структурована інформація, тоді як файли теми, плагінів і медіа зазвичай розміщені окремо, у каталозі wp-content. Тому відновлення лише з бази може повернути значну частину вмісту, але не завжди дозволяє одразу запустити сайт у попередньому вигляді.

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

Що містить база даних

У типовій базі WordPress зберігаються дані, необхідні для формування основного вмісту сайту:

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

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

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

Чого немає без wp-content

Каталог wp-content містить файли, без яких база даних не є повною копією сайту. Найчастіше втрачаються:

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

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

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

Повернення сторінок і налаштувань

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

Під час відновлення потрібно врахувати:

• правильний префікс таблиць у файлі wp-config.php;
• коректні назви бази, користувача та параметри підключення;
• кодування таблиць і з’єднання, щоб не зіпсувати кириличний текст;
• адреси siteurl і home;
• абсолютні URL у текстах, меню, налаштуваннях і даних конструкторів;
• сумісність версій WordPress, PHP, теми та плагінів.

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

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

Пошук медіафайлів

Медіафайли не відновлюються з одного лише запису в базі. Спочатку потрібно перевірити всі доступні джерела:

1. старий хостинг або сервер, де сайт працював раніше;
2. резервні копії файлів у панелі хостингу;
3. архіви на локальному комп’ютері чи зовнішньому диску;
4. сховища CDN, об’єктні сховища та сервіси оптимізації зображень;
5. копії сайту в системах розгортання або на тестових піддоменах;
6. кеш пошукових систем чи вебархіви — лише як джерело для ручного пошуку, а не як повноцінний резерв.

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

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

Збирання сайту заново

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

Безпечна послідовність може виглядати так:

1. зберегти оригінальний дамп і не змінювати його під час експериментів;
2. створити окреме тестове середовище;
3. перевірити структуру та імпортувати базу;
4. налаштувати адресу сайту й підключення до бази;
5. встановити сумісні версії WordPress, теми та плагінів;
6. повернути медіафайли та перевірити биті посилання;
7. переглянути сторінки, форми, меню, пошук, авторизацію та інтеграції;
8. провести перевірку безпеки перед перенесенням результату на основний домен.

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

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

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