План аварійного відновлення часто з’являється лише після першої серйозної втрати. До цього резервне копіювання сприймають як фонову функцію хостингу. Насправді відновлюваність потрібно проєктувати разом із сайтом: визначити склад даних, місця зберігання, доступи, відповідальних і порядок перевірки копій.
Добре створений сайт теж може постраждати від помилки оновлення, збою сервера, вірусної атаки або втрати облікового запису. Відмінність підготовленої системи в тому, що команда знає, що саме повертати, з якої копії та в якій послідовності.
Чому резервної копії файлів недостатньо
Файли містять ядро системи, тему, плагіни, завантаження й конфігурацію. Але тексти, налаштування сторінок, користувачі, замовлення та багато інтеграцій зберігаються в базі даних. Архів без бази може дати знайомі папки, але не повернути робочий сайт.
Зворотна ситуація теж проблемна. База без медіафайлів і коду містить записи, але сторінки можуть втратити зображення, шаблони та функції. Тому копіювання повинно охоплювати компоненти, які разом утворюють одну версію.
До технічного завдання варто додати вимоги до резервування, строку зберігання й перевірки. Загальні принципи підготовки вимог описано в матеріалі про складання технічного завдання на сайт.
Як документувати доступи, домен і налаштування хостингу
Бізнес повинен контролювати домен, хостинг, DNS, адміністративний обліковий запис, пошту й сервіси резервного копіювання. Реєстрація всього на особисту адресу тимчасового підрядника створює окрему точку відмови.
Документ доступів не означає таблицю з відкритими паролями. У ньому фіксують власника облікового запису, адресу входу, спосіб відновлення, двофакторну автентифікацію та відповідальну особу. Самі секрети зберігають у менеджері паролів.
Окремо записують версію PHP, DNS-записи, завдання cron, правила кешування, зовнішні API та нестандартні налаштування. Після аварії ці деталі можуть визначити, чому копія не працює на новому сервері.
Окремі копії бази даних, медіафайлів і конфігурації
Різні частини сайту змінюються з різною швидкістю. Інтернет-магазину може бути потрібна часта копія бази через нові замовлення, тоді як тема змінюється рідко. Медіафайли займають багато місця, але їх можна копіювати інкрементально.
Копії бажано зберігати поза тим самим сервером. Якщо архів лежить лише поруч із сайтом, збій диска, блокування акаунта або атака можуть знищити обидві версії. Потрібне незалежне сховище з обмеженим доступом і зрозумілим строком зберігання.
Кожна копія повинна мати дату, склад і зв’язок між компонентами. Файли за понеділок і база за четвер можуть бути несумісними. Для критичних систем корисно зберігати кілька точок у часі, а не лише останній архів.
Тестове середовище для безпечних оновлень
Оновлення теми, плагінів або версії PHP спочатку перевіряють на копії. Тестове середовище має відтворювати ключові налаштування робочого сайту, але не надсилати реальні листи, не приймати платежі та не індексуватися.
Після оновлення проходять контрольні сценарії: головна, послуги, форми, пошук, кошик, кабінет, інтеграції та мобільна версія. Лише відсутності повідомлення про помилку недостатньо. Потрібно переконатися, що бізнес-функції працюють.
Критерії приймання можна сформувати ще під час розробки. Стаття про оцінювання якості готового сайту допомагає перетворити перевірку на повторюваний список, а не суб’єктивний огляд.
Яким має бути план відновлення після критичного збою
План починається з діагностики: що недоступне, коли з’явилася проблема, чи зберігаються нові дані та чи є ознаки атаки. Потім фіксують поточний стан і лише після цього вибирають точку відновлення.
У документі зазначають відповідальних, канали зв’язку, порядок зупинки реклами, резервний прийом заявок, місця зберігання копій і пріоритетні функції. Для одного сайту спочатку важлива форма, для іншого — каталог, оплата або особистий кабінет.
Навіть правильно розроблений ресурс потребує перевіреного сценарію відновлення сайтів із резервної копії. Тестове розгортання до аварії показує, чи архів повний, скільки триває повернення і яких даних бракує.
Після запуску сайт не переходить у стан, де підтримка більше не потрібна. Регулярні оновлення, моніторинг і контроль копій є частиною життєвого циклу; це розкрито в матеріалі навіщо бізнесу технічна підтримка після створення сайту.
Готовність до аварії не означає очікування проблем. Вона зменшує час простою й кількість невідомих. Коли доступи задокументовані, копії розділені та перевірені, а команда знає послідовність дій, критичний збій стає керованою процедурою.