Збій сайту не завжди означає безповоротну втрату даних. Але хаотичні дії після появи помилки можуть ускладнити діагностику, перезаписати потрібні файли або знищити доступні сліди атаки. У першу годину важливо не намагатися навмання «полагодити все», а зафіксувати стан системи, зберегти дані та визначити безпечний порядок подальших кроків.
Якщо сайт приносить заявки, приймає замовлення або є основним каналом комунікації з клієнтами, корисно заздалегідь ознайомитися з матеріалом про Екстрене відновлення сайту: коли кожна година має значення.
Зупинка подальших змін
Перший крок після збою — припинити дії, які можуть змінити стан сайту. Не встановлюйте нові плагіни, не оновлюйте WordPress, тему чи серверні компоненти, не видаляйте підозрілі файли та не запускайте масове очищення без розуміння наслідків.
Якщо до сайту мають доступ кілька працівників або підрядників, повідомте їм про аварію та попросіть тимчасово не входити в адміністративну панель. Паралельні зміни ускладнюють визначення причини проблеми: помилка могла виникнути через оновлення, конфлікт розширень, зміну налаштувань сервера, зараження або несправність бази даних.
- зафіксуйте приблизний час появи збою;
- запишіть, що змінювалося перед проблемою;
- не перезапускайте сервер без необхідності;
- не видаляйте журнали помилок і підозрілі об’єкти;
- якщо є ознаки злому, тимчасово обмежте доступ до адміністративної панелі.
Якщо сайт ще відкривається частково, не вважайте це доказом незначної проблеми. Помилки в окремих розділах, відсутність зображень, перенаправлення на сторонні адреси або раптове створення невідомих облікових записів можуть свідчити про пошкодження файлів чи компрометацію доступу.
Збереження поточного стану
До будь-якого ремонту потрібно зберегти копію поточного стану сайту. Навіть якщо він уже працює неправильно, у файлах, базі даних і журналах можуть залишатися важливі відомості для діагностики.
- Зробіть копію файлів сайту, включно з каталогом завантажень, конфігураційними файлами та файлами теми.
- Експортуйте базу даних окремим файлом.
- Збережіть журнали вебсервера, PHP та системи безпеки, якщо вони доступні.
- Зафіксуйте скриншоти помилок, сторінки входу, повідомлень хостингу та результатів перевірки в браузері.
- Збережіть копію в окремому сховищі, не на тому самому сервері.
Резервну копію краще створювати до спроб виправлення, але важливо розуміти її стан: пошкоджені файли або зараження могли потрапити до копії раніше. Не перезаписуйте єдину доступну резервну копію новою версією без перевірки.
Якщо через панель хостингу неможливо створити архів або експорт бази даних завершується помилкою, не повторюйте операцію безкінечно. За нестачі дискового простору, пошкодження бази чи обмежень доступу додаткові спроби можуть погіршити ситуацію. У такому випадку варто залучити спеціаліста, який спершу оцінить ризик втрати даних.
Пошук останньої справної копії
Потрібно визначити, яка резервна копія є останньою відомою справною, а не просто найновішою за датою. Перевірте автоматичні копії хостингу, резервування в панелі WordPress, копії на зовнішньому сховищі та архіви, які могли створюватися перед оновленням або перенесенням.
Для кожної копії зафіксуйте:
- дату та час створення;
- склад копії — файли, базу даних чи обидва компоненти;
- розмір архіву;
- місце зберігання;
- чи перевірялася вона раніше;
- які зміни на сайті були зроблені після її створення.
Не відновлюйте сайт одразу на робочій версії, якщо є можливість спершу перевірити копію на тестовому домені або окремому середовищі. Після відновлення потрібно перевірити вхід до адмінпанелі, роботу бази даних, сторінок, форм, медіафайлів, платежів та інтеграцій.
Якщо резервна копія містить шкідливий код або була створена вже після пошкодження, її розгортання поверне проблему. За ознак вірусу, невідомих редиректів, змінених файлів або підозрілих користувачів необхідні додатковий аналіз і перевірка безпеки.
Тимчасова сторінка для клієнтів
Якщо повне відновлення потребує часу, розмістіть просту тимчасову сторінку замість повідомлення про технічну помилку. Вона має коротко пояснювати, що сайт тимчасово недоступний, і містити альтернативні канали зв’язку.
На сторінці можна вказати:
- назву компанії та логотип;
- номер телефону й адресу електронної пошти;
- посилання на активні сторінки в соціальних мережах;
- спосіб приймання термінових замовлень;
- повідомлення про те, що технічні роботи тривають.
Не публікуйте деталі внутрішньої проблеми: версії WordPress, шляхи до файлів, повідомлення бази даних, логіни або технічні фрагменти. Такі дані можуть допомогти зловмисникам. Якщо сайт містить форми, переконайтеся, що тимчасова сторінка не приймає конфіденційні дані без захищеного каналу та зрозумілого способу їх обробки.
Тимчасова сторінка не замінює ремонт. Її завдання — зменшити втрати звернень і повідомити клієнтів, поки проводиться діагностика. Після повернення сайту обов’язково перевірте, чи не залишилися старі правила перенаправлення, кешована помилка або неправильні налаштування вебсервера.
Порядок відновлення
Після збереження поточного стану та пошуку копій можна переходити до відновлення. Послідовність залежить від симптомів, але зазвичай включає такі етапи:
- Перевірити доступність домену, DNS, SSL-сертифіката, хостингу та ресурсів сервера.
- Визначити, чи проблема пов’язана з файлами, базою даних, PHP, вебсервером або зовнішньою інтеграцією.
- Проаналізувати журнали помилок і час появи збою.
- Перевірити зміни, зроблені безпосередньо перед проблемою.
- За потреби відновити файли та базу даних із вибраної копії в контрольованому середовищі.
- Перевірити сайт після відновлення та змінити скомпрометовані паролі.
- Оновити програмне забезпечення лише після створення нової перевіреної копії та оцінки сумісності.
Не варто одночасно відновлювати архів, оновлювати всі компоненти, змінювати конфігурацію сервера й чистити вірус. Якщо після цього сайт запрацює або, навпаки, стане недоступним, буде складно встановити, яка дія вплинула на результат.
Спеціаліст потрібен уже на етапі, коли немає доступу до хостингу або адміністративної панелі, база даних не імпортується, сайт перенаправляє відвідувачів на сторонні ресурси, резервні копії відсутні чи є ризик остаточної втрати даних. До початку робіт надайте фахівцю час появи збою, опис виконаних змін, доступні копії та журнали. Це допоможе провести діагностику без зайвих експериментів і вибрати найбезпечніший варіант відновлення.