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