Аварія сервера не завжди означає остаточну втрату сайту. Результат залежить від характеру несправності, стану дисків, доступності резервних копій і того, чи встигли дані пошкодитися після збою. У деяких випадках можна повернути сайт із повної копії, в інших — відновити окремі файли або базу даних. Водночас будь-які самостійні дії на несправному сервері можуть погіршити ситуацію, тому спочатку важливо зафіксувати стан системи та не запускати ризиковані операції без копіювання доступних даних.
Якщо проблема супроводжується втратою доступу до панелі хостингу, домену чи серверних файлів, окремо варто розглянути Відновлення сайту після втрати хостингу.
Наслідки серверної аварії
Після аварії сайт може повністю не відкриватися, показувати помилки сервера або завантажувати лише окремі сторінки. Типові прояви — повідомлення 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, помилки підключення до бази даних або нескінченне перенаправлення.
Наслідки залежать від того, що саме вийшло з ладу:
- пошкодження файлової системи або окремих файлів сайту;
- відмова накопичувача чи проблеми з RAID-масивом;
- пошкодження таблиць бази даних;
- втрата конфігурацій вебсервера, PHP або доступів;
- помилки після аварійного завершення запису даних;
- видалення файлів через шкідливе програмне забезпечення або помилкову дію адміністратора.
На першому етапі слід перевірити повідомлення провайдера, стан сервера, доступ до панелі керування, наявність SSH або FTP-доступу та час останньої працездатності сайту. Не варто без резервної копії перевстановлювати CMS, очищати диски, запускати автоматичні скрипти відновлення чи багаторазово перезапускати сервер: такі дії можуть перезаписати ще доступні фрагменти даних.
Копії на сторонніх сховищах
Найбезпечніший шлях відновлення — використати копію, яка зберігалася окремо від аварійного сервера. Це можуть бути резерви хостинг-провайдера, копії в панелі керування, архіви на локальному комп’ютері, зовнішньому диску, FTP-сховищі або хмарному сервісі.
Потрібно встановити не лише факт наявності копії, а й її склад:
- чи містить архів файли WordPress, завантаження, теми та плагіни;
- чи є окремий дамп бази даних;
- за яку дату створено копію;
- чи можна розпакувати архів без помилок;
- чи не пошкоджені файли резерву під час самої аварії;
- чи є кілька версій копій, щоб не відновлювати вже пошкоджений стан.
Перед використанням резерву бажано створити його додаткову копію й працювати не з єдиним оригіналом. Якщо архів доступний частково, не слід одразу видаляти неповні файли: навіть окремі зображення, конфігурації або дамп бази можуть бути корисними для подальшого відновлення.
Відновлення файлів і бази
Файли сайту та база даних відновлюються окремо, хоча для повноцінної роботи вони мають відповідати одне одному за версією та датою. У WordPress файли містять ядро системи, теми, плагіни й медіа, а база — сторінки, записи, налаштування, користувачів і частину службової інформації.
Якщо доступна резервна копія, зазвичай спочатку готують чисте середовище з сумісною версією PHP, вебсервера та бази даних. Після цього відновлюють файли, імпортують дамп бази та перевіряють параметри підключення у файлі wp-config.php. Важливо не замінювати робочі дані без попереднього збереження поточного стану нового середовища.
За відсутності повного резерву можливе часткове відновлення: окремо зберігають каталог wp-content/uploads, доступні теми та плагіни, а з бази даних намагаються витягнути неушкоджені таблиці. Однак пошкоджений дамп може містити неповні записи, помилки кодування або порушені зв’язки між таблицями. У такій ситуації результат неможливо визначити без аналізу структури бази.
Якщо є підозра на фізичну несправність диска, краще припинити роботу з оригінальним носієм і звернутися до спеціаліста. Повторні спроби запуску, перевірки або копіювання можуть прискорити деградацію диска та зменшити обсяг даних, які ще можна отримати.
Перевірка цілісності
Після відновлення не можна обмежуватися перевіркою головної сторінки. Сайт може відкриватися, але мати пошкоджені зображення, відсутні сторінки, помилки в адмінпанелі або некоректні посилання на старий сервер.
Перевірка має охоплювати:
- вхід до адміністративної панелі та роботу основних ролей користувачів;
- завантаження сторінок, записів, категорій і меню;
- відображення зображень, документів та інших медіафайлів;
- роботу форм зворотного зв’язку, пошти та інтеграцій;
- підключення до бази даних і відсутність критичних помилок у журналах;
- коректність домену, SSL-сертифіката та внутрішніх URL;
- наявність підозрілих файлів, невідомих користувачів і змінених конфігурацій.
Якщо сайт відновлюється після аварії, одночасно варто перевірити його на ознаки зараження. Перенесення шкідливих файлів із резерву може повернути проблему разом із даними. Після діагностики бажано змінити паролі до хостингу, CMS, бази даних і пошти, але лише після того, як буде зрозуміло, що доступи не перехоплюються зараженим середовищем.
Повернення сайту в роботу
Після технічної перевірки сайт можна повертати в роботу поетапно. Спочатку тестують його на тимчасовому домені або окремому сервері, потім налаштовують DNS, SSL, вебсервер, кешування та фонові завдання. Це дає змогу виявити помилки до того, як сайт знову стане доступним для всіх відвідувачів.
- Зберегти всі доступні файли, архіви та журнали аварійної системи.
- Підготувати окреме чисте середовище для відновлення.
- Відновити файли й базу даних із перевіреної копії або доступних фрагментів.
- Перевірити роботу сайту, пошти, форм, платежів та інтеграцій.
- Оновити CMS, плагіни й серверне програмне забезпечення після створення робочої копії.
- Налаштувати регулярні резервні копії зберіганням щонайменше в одному незалежному від сервера місці.
- Перемкнути домен на відновлений сервер і контролювати помилки після запуску.
Спеціаліст потрібен, якщо немає доступу до сервера, резервна копія пошкоджена, база даних не імпортується, диск має ознаки фізичної несправності або після відновлення з’являються помилки, яких не було раніше. Діагностика допоможе визначити, які дані реально збереглися, не погіршити стан носія та вибрати безпечний спосіб повернення сайту до роботи.