Невдала спроба відновити сайт із резервної копії не завжди означає, що всі дані втрачено. Причина може бути у пошкодженому архіві, неповному дампі бази даних, несумісності версій PHP або системи керування сайтом, а також у помилці під час розпакування чи імпорту.
Перш ніж повторно запускати відновлення, не перезаписуйте наявні файли та базу даних. Зробіть копію самого архіву, поточного стану сайту й усіх доступних дампів. Навіть невдала спроба імпорту може змінити структуру бази або видалити частину даних.
Перевірка цілісності файлу
Спочатку потрібно визначити, чи є резервна копія повною та технічно придатною для читання. Якщо архів не відкривається, розпакування переривається або хостинг повідомляє про помилку контрольної суми, файл міг пошкодитися під час створення, завантаження чи копіювання.
- Перевірте розмір файлу та порівняйте його з інформацією в панелі резервного копіювання.
- Спробуйте відкрити архів локально за допомогою іншої програми, не змінюючи оригінал.
- Для файлів, що мають контрольну суму, порівняйте значення
MD5абоSHA-256із даними джерела. - Перевірте, чи не обірвалося завантаження через обмеження браузера, FTP-клієнта або дискового простору.
Якщо архів частково читається, не видаляйте його. Іноді з нього можна вилучити окремі каталоги, зображення або конфігураційні файли, навіть коли повне розпакування неможливе. Для відновлення краще працювати з копією, адже повторна спроба ремонту архіву може ускладнити подальший аналіз.
Неповний SQL-дамп
Коли файли сайту відновлюються, але WordPress показує помилки підключення до бази даних, порожні сторінки або відсутній контент, проблема може бути в неповному SQL-дампі. Дамп іноді обривається посеред таблиці, містить лише частину записів або не включає службові таблиці, необхідні для роботи сайту.
Ознаками неповного дампа можуть бути різке завершення файлу без коректного кінця SQL-команд, відсутність частини таблиць, помилки імпорту на конкретному рядку або невідповідність розміру бази очікуваному значенню. Також варто перевірити, чи не перевищує файл ліміти імпортера в панелі хостингу або phpMyAdmin.
- Створіть окрему порожню базу даних для тестового імпорту.
- Не імпортуйте дамп безпосередньо в робочу базу, якщо не маєте її копії.
- Подивіться журнал помилок і номер рядка, на якому зупинився імпорт.
- Порівняйте перелік таблиць із типовою структурою WordPress, зокрема таблиці постів, користувачів, налаштувань і метаданих.
- Якщо дамп великий, використовуйте імпорт через командний рядок або спеціалізований інструмент лише після перевірки параметрів сервера.
Механічне видалення проблемного фрагмента з SQL-файлу може призвести до втрати пов’язаних записів і порушення структури бази. Такий спосіб допустимий лише для копії дампа та після розуміння залежностей між таблицями.
Несумісність версій
Резервна копія може бути справною, але не запускатися в іншому середовищі. Наприклад, сайт створено на PHP 7.4, а відновлюється на PHP 8.3; використовується інша версія MySQL або MariaDB; старий WordPress несумісний із новою версією плагіна чи теми.
Перевірте версії PHP, бази даних, WordPress, активної теми та критично важливих плагінів, які були встановлені на момент створення копії. Помилки на кшталт Parse error, Call to undefined function, повідомлення про несумісний синтаксис або помилки під час підключення розширень часто вказують саме на різницю між середовищами.
Безпечніше спершу розгорнути копію на тестовому піддомені або локальному сервері. Не оновлюйте одразу всі компоненти: якщо змінити кілька версій одночасно, буде складно встановити, що саме спричинило збій. Після створення додаткової резервної копії можна поетапно підібрати сумісну версію PHP, відключити проблемні розширення та перевірити журнал помилок.
Окрему увагу приділіть файлу конфігурації, параметрам підключення до бази, правам доступу та шляхам до директорій. Після перенесення вони можуть відрізнятися від попереднього сервера, навіть якщо всі файли відновлено без помилок.
Ручне вилучення даних
Якщо повне відновлення архіву неможливе, іноді вдається окремо отримати цінні дані: завантаження, зображення, записи, сторінки, користувачів або налаштування. Це не тотожне повному відновленню сайту, оскільки зв’язки між даними, шаблони, плагіни та службові параметри можуть залишитися пошкодженими або відсутніми.
Із файлового архіву можна спробувати вилучити каталог wp-content/uploads, тему та плагіни. Із SQL-дампа — імпортувати окремі таблиці в тимчасову базу, а потім експортувати потрібні записи. Для WordPress особливо важливо враховувати префікс таблиць і serialized-дані в параметрах та метаполях: звичайна заміна URL або масове редагування тексту може пошкодити довжину таких структур.
Перед ручними змінами:
- збережіть незмінні копії архіву та дампа;
- працюйте у тимчасовій базі, а не в робочій;
- перевірте доступність дискового простору;
- зафіксуйте початкові назви таблиць і структуру каталогів;
- після імпорту перевірте кодування, URL, права користувачів і зв’язки між записами.
Якщо потрібно відновити дані з пошкодженого носія, фрагментованого архіву або складного SQL-файлу, краще зупинитися після створення копій і звернутися до спеціаліста. Неправильне редагування може зменшити кількість даних, які ще можна вилучити.
Альтернативні джерела копій
Коли основна резервна копія не відновлюється, перевірте всі місця, де могли зберегтися інші версії: автоматичні копії хостингу, snapshots сервера, віддалене сховище, локальний комп’ютер розробника, Git-репозиторій, копії в панелі CDN або архіви від попереднього підрядника.
Зверніться до хостинг-провайдера та уточніть, чи доступні щоденні або тижневі snapshot-копії. Важливо з’ясувати дату їх створення, склад даних і строк зберігання. Такі копії також не варто відновлювати поверх поточного сайту без попереднього збереження його файлів і бази даних.
Якщо резервних копій більше немає, частину публічного контенту іноді можна знайти у веб-архівах. Наприклад, окремі сторінки, тексти або зображення можуть залишитися в Відновлення сайту з Web Archive: коли резервних копій більше немає. Однак архівна копія зазвичай не містить базу даних, адміністративну частину, форми, замовлення чи актуальні файли плагінів, тому її слід розглядати як джерело окремих матеріалів, а не як повноцінний backup.
Якщо самостійна перевірка не дає результату, спеціаліст може проаналізувати структуру архіву, журнали сервера, SQL-дамп і доступні джерела копій без ризикового перезапису даних. Остаточний обсяг відновлення залежить від стану файлів, повноти бази, сумісності середовища та наявності альтернативних версій.
Пошкоджений архів ще не завжди означає остаточну втрату даних: відновлення сайтів із пошкодженої резервної копії може передбачати вилучення справних файлів, окреме відновлення бази та збирання робочої версії з кількох доступних джерел. Головне — не перезаписувати єдину копію новими спробами розпакування.