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