Бекап WordPress є, але невідомої дати: як обрати безпечну копію

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

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

Як визначити дату та склад резервної копії

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

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

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

Перевірка архіву на цілісність і віруси

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

Не завантажуйте підозрілу копію одразу на робочий сайт. Розпакуйте її в ізольованому середовищі та перевірте файли антивірусом або спеціалізованими засобами аналізу WordPress. Особливу увагу зверніть на:

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

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

Як порівняти бази та файли

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

Окремо зіставте:

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

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

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

Коли відновлювати на тестовому домені

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

Після розгортання перевірте:

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

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

Про безпечне відновлення сайту з бекапу особливо важливо подбати, коли немає впевненості в походженні архіву або сайт уже демонструє ознаки злому. У складних випадках потрібне поетапне відновлення з журналюванням змін.

Що зберегти з поточної версії

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

• файл wp-config.php у захищеному місці;
• поточну папку wp-content/uploads;
• активну тему та власні зміни в її коді;
• список встановлених плагінів і їхні налаштування;
• експорт критичних таблиць і записів;
• логи сервера, PHP та WordPress;
• дані про DNS, SSL, cron-завдання та поштові налаштування;
• скріншоти або перелік поточних помилок і симптомів.

Не публікуйте резервні копії, дампи бази та wp-config.php у відкритому доступі: вони можуть містити паролі, ключі та персональні дані. Якщо невідомо, який бекап є безпечним, відсутній доступ до бази або після тестового розгортання з’являються помилки чи ознаки зараження, краще зупинити самостійне відновлення й залучити спеціаліста. Спочатку потрібно зберегти поточний стан і провести діагностику, а вже потім обирати сценарій ремонту.