Сайт не відкривається, сервер не відповідає, а остання резервна копія начебто «десь є». У такій ситуації найбільше часу забирає не сама несправність, а невизначеність: що саме зламалося, які дані залишилися цілими, де лежить придатна копія і в якій послідовності повертати сервіси. Готовність до аварії перевіряється до того, як вона сталася. Для цього заздалегідь визначають RPO — скільки даних допустимо втратити, і RTO — скільки часу сервіс може бути недоступним. Далі вже налаштовують резервне копіювання, моніторинг і процедуру відновлення. Один production-сервер не повинен одночасно бути єдиним місцем роботи застосунку, єдиним сховищем даних і єдиним місцем зберігання його backup. Спочатку визначте, що саме для вас означає «сервер упав» Недоступний сайт ще не означає, що сам сервер вийшов із ладу. Причиною може бути Nginx або Apache, PHP-FPM, MySQL, DNS, переповнений диск, вичерпані inode, прострочений TLS-сертифікат чи помилка застосунку. Перед відновленням із копії треба локалізувати рівень відмови. Починати зручно із зовнішньої перевірки. Командаcurl -I https://example.comпокаже, чи відповідає вебсервер і який HTTP-код повертає. Якщо SSH доступний, перевірте ключові служби черезsystemctl status nginx,systemctl status php-fpmтаsystemctl status mysqlабо відповідні команди для вашого стеку. Далі — ресурси:df -hдля дискового простору,df -iдля inode,free -mдля пам’яті,uptimeабоtopдля навантаження. Типовий приклад: SSH працює, Nginx запущений, а сайт повертає 502. Відновлювати весь VPS тут немає сенсу — спочатку перевіряють PHP-FPM або upstream застосунку. Якщо процес формально запущений, але поводиться нестабільно, дивлятьсяjournalctl, логи вебсервера, PHP і самого застосунку. DNS теж перевіряють окремо черезdig. Сервер може працювати нормально, але домен уже вказує не туди або частина резолверів бачить іншу адресу. У перші хвилини достатньо відповісти на три питання: чи доступний вузол по мережі, який компонент перестав працювати і чи є ознаки пошкодження даних. «Вузол живий, але сервіс лежить» — цілком реальний сценарій. Резервна копія корисна лише тоді, коли її можна відновити Файл із назвою backup і статус Success у панелі ще не доводять, що після аварії сайт вдасться повернути. Придатність копії підтверджує відновлення в окремому середовищі. Якщо архів не розпаковується, дамп БД неповний або потрібні конфігураційні файли не потрапили до копії, формально успішне резервування не вирішує завдання. Snapshot і backup — не одне й те саме Snapshot зберігає стан віртуальної машини або диска на певний момент і зручний перед оновленням чи ризикованою зміною конфігурації. Але snapshot не варто автоматично вважати незалежною резервною копією. Якщо він залежить від того самого сховища або тієї самої інфраструктури, серйозна відмова може зробити недоступними і production, і snapshot. Тобто snapshot добре відповідає на питання «як швидко відкотитися», але не завжди — на питання «що залишиться, якщо ми втратимо саме сховище». Копія на тому самому сервері не рятує від усіх аварій Архів у каталозі/backupна тому самому VPS захищає від випадкового видалення окремого файла, але не від втрати всього вузла. Базовим орієнтиром залишається правило 3-2-1: мати щонайменше три копії даних, використовувати два різні місця або типи зберігання та тримати одну копію поза основною точкою відмови. Для вебзастосунку резервування має охоплювати не лише файли. Зазвичай потрібні база даних, завантажені користувачами файли, конфігурація вебсервера, параметри PHP, cron-завдання або systemd timers, а також інформація, необхідна для відновлення роботи інтеграцій. Секрети та ключі слід зберігати безпечно й окремо, а не просто додавати до відкритого Git-репозиторію. Дампи MySQL або MariaDB можна створювати черезmysqldumpчиmariadb-dump, PostgreSQL — черезpg_dump; файли часто копіюютьrsyncабо архівують черезtar. Для великих систем треба враховувати консистентність: копія файлів і БД повинна відповідати одному логічному стану застосунку. Тут є проста перевірка. Візьміть останню копію і спробуйте підняти з неї сайт на окремому сервері. Дамп БД варто не лише знайти на диску, а й імпортувати в порожню тестову базу. Розмір архіву, дата створення та checksum черезsha256sumдопомагають виявити очевидні проблеми, але restore вони не замінюють. Неперевірений backup — це лише припущення, що backup у вас є. Частоту backup визначає не календар, а допустима втрата даних Частоту резервного копіювання визначає RPO, а не універсальне правило «раз на добу». Для статичного сайту втрата кількох годин змін може бути неістотною, а для магазину, CRM або особистого кабінету ті самі кілька годин можуть означати втрату замовлень, звернень чи інших записів. RPO, або Recovery Point Objective, відповідає на питання: до якого моменту ми повинні мати змогу повернути дані. RTO, або Recovery Time Objective, визначає допустимий час від початку аварії до відновлення працездатності сервісу. Це не технічні константи, а вимоги конкретного проєкту. Тип сервісуЩо змінюєтьсяЛогіка RPOЩо копіюватиСтатичний сайтФайли змінюються рідкоГодини або доба можуть бути прийнятнимиФайли та конфігураціяКонтентний сайтПублікації, коментарі, завантажені файлиЗалежить від частоти оновленьБД і файлиІнтернет-магазинЗамовлення, оплати, залишкиЗазвичай потрібне коротше вікно втратиБД, файли, конфігураціяCRM або онлайн-сервісЗаписи створюються постійноВизначається бізнес-процесомБД, вкладення, ключові конфіги Поставте собі конкретне питання: якщо сервер зникне о 17:00, до якого часу сьогоднішні дані ми зможемо повернути? Якщо відповідь «до опівночі минулої доби», а допустима втрата становить одну годину, розклад backup не відповідає реальному RPO. Окремо вимірюють тривалість створення копії та відновлення. Немає сенсу декларувати RTO в одну годину, якщо завантаження архіву, імпорт бази й підготовка середовища фізично займають довше. Моніторинг має виявляти проблему раніше за користувачів Мінімальний моніторинг повинен одночасно дивитися на сайт ззовні та на стан ресурсів усередині сервера. CPU і RAM можуть бути «зеленими», коли користувач уже отримує 502 або взагалі не може встановити з’єднання. Зовнішні та внутрішні перевірки Зовнішній uptime-monitor перевіряє сервіс із позиції користувача: чи відкривається потрібний URL, який код відповіді повертається, скільки часу триває запит. Для важливих систем краще перевіряти не лише головну сторінку, а й окремий health endpoint або сторінку, яка справді залежить від застосунку та БД. Внутрішній моніторинг відповідає на інше питання — чому сервіс почав деградувати. Тут корисні вільне місце на диску, inode, RAM і swap, CPU/load, стан MySQL або PostgreSQL, Nginx/Apache, PHP-FPM, черг і фонових задач. Окремими алертами варто контролювати строк дії TLS-сертифіката та успішність останнього backup. За якими метриками справді варто ставити сповіщення доступність HTTP/HTTPS і код відповіді; час відповіді та різке зростання затримки; вільне місце на файловій системі; кількість вільних inode; RAM, swap, CPU та load average; стан БД і ключових процесів; помилки застосунку та черг; строк TLS-сертифіката; час і результат останньої резервної копії. Uptime Kuma, Zabbix, Prometheus із Grafana або зовнішній сервіс моніторингу — лише інструменти. Наприклад, сервер може продовжувати відповідати на ping, але через заповнений диск MySQL уже не може записувати нові дані. Зелений CPU ще не означає, що користувач може оформити замовлення. Є ще один практичний нюанс: dashboard не дорівнює оповіщенню. Графік, на який ніхто не дивиться вночі, не повідомить про аварію. На staging-середовищі можна зупинити тестовий сервіс і засікти час від відмови до отримання алерту. Так перевіряють не красиву панель, а весь ланцюжок сповіщення. Коли одного сервера вже недостатньо: прибираємо єдині точки відмови Single Point of Failure, або SPOF, — це компонент, втрата якого робить недоступною всю систему або унеможливлює її відновлення. Ним може бути не тільки один VPS: єдине сховище резервних копій, одна база, одна DNS-зона без контрольованого доступу або навіть єдина людина, яка знає всі паролі. Намалюйте просту схему своєї системи. Позначте production-вузол, базу даних, файлове сховище, DNS, резервні копії, секрети та місце зберігання конфігурації. Потім для кожного елемента поставте одне питання: що залишиться доступним, якщо саме цей компонент повністю зникне? Якщо проєкт уже не вкладається в модель одного вузла, одним із варіантів інфраструктури може бути хмарний VDS, де при виборі середовища оцінюють не лише CPU та RAM, а й резервування, зберігання копій і сценарій відновлення. Але сама хмарна інфраструктура не скасовує незалежних backup і перевіреного плану disaster recovery. Реплікація теж не замінює резервну копію. Якщо застосунок видалив дані помилковим запитом, наприклад некоректнимDELETE, ця зміна може швидко повторитися на репліці. Репліка допомагає пережити відмову вузла; backup потрібен, щоб повернути попередній стан даних. Конфігурацію вебсервера, deployment-файли та опис середовища зручно зберігати у version control, наприклад Git, але без відкритих паролів і секретів. Для зріліших систем корисний Infrastructure as Code: він скорочує кількість ручних кроків під час розгортання нового вузла. Та навіть найкращий код розгортання не допоможе, якщо єдина актуальна копія БД залишилася на недоступному production-диску. План відновлення потрібен до аварії, а не під час неї Disaster recovery plan — це не список телефонів і не фраза «розгорнути backup». Він повинен описувати перевірену послідовність повернення сервісу: звідки взяти копії, яку версію середовища підготувати, у якому порядку відновити БД і файли, як повернути DNS та як переконатися, що бізнес-функції справді працюють. У якій послідовності повертати сервіси Визначити масштаб аварії та не починати руйнівних дій до первинної діагностики. Зафіксувати час останньої придатної резервної копії. Не перезаписувати наявні backup новими неперевіреними копіями. Підготувати чисте серверне середовище з потрібними версіями пакетів. Повернути конфігурацію вебсервера, PHP та інших служб. Відновити базу даних і файлові дані. Перевірити власників і права доступу. Повернути cron-завдання, systemd timers, черги та фонові процеси. Запустити сервіси й перевірити конфігурацію, наприклад черезnginx -tабоapachectl configtest. Перевірити сайт через тимчасовий hostname або локальну зміну файлаhostsдо перемикання DNS. Переключити трафік і продовжити посилений моніторинг. Runbook має бути достатньо зрозумілим, щоб ним зміг скористатися не лише адміністратор, який колись налаштовував сервер. Корисно зафіксувати версію PHP черезphp -v, список потрібних модулів, розташування конфігів, команди керування службами, джерело backup, порядок імпорту БД і контакти відповідальних людей. Що перевіряти після restore 200 OK на головній сторінці ще не означає, що сервіс відновлений. Після запуску треба пройти ключові користувацькі сценарії: авторизацію, форму зворотного зв’язку, пошук, оформлення замовлення, завантаження файлів, відправлення пошти, API-інтеграції, webhooks, cron та черги — залежно від функцій конкретного проєкту. Окремо перегляньте логи застосунку й системні журнали. Частина помилок з’являється лише після першого реального запиту: неправильний шлях до каталогу, відсутній PHP-модуль, невірні права, старий пароль до БД або забутий фоновий процес. Тому запуск Nginx — ще не фініш; фініш настає після перевірки реальних функцій сервісу. Тестове відновлення — єдиний спосіб дізнатися реальний RTO Працездатність плану аварійного відновлення підтверджує лише повний тестовий restore в окремому середовищі. Якщо в документації написано «повернемо сайт за годину», але ніхто ніколи не проходив процес від початку до кінця, це поки що лише оцінка. Під час recovery drill варто засікати час отримання backup, підготовки чистого сервера, відновлення бази, повернення файлів, запуску застосунку, першої успішної HTTP-відповіді та повної перевірки функцій. Саме остання точка найближча до реального RTO: користувачеві не допомагає факт, що Nginx уже запущений, якщо авторизація чи оформлення замовлення ще не працюють. Не тестуйте тільки ідеальний сценарій. Спробуйте відновити окремий файл, базу даних і цілий сервер; перевірте, що робитимете, якщо останній backup пошкоджений або основне сховище копій тимчасово недоступне. Після великих змін інфраструктури — оновлення ОС, зміни стеку, перенесення БД чи нового способу deployment — процедуру варто пройти знову. Короткий чек-лист готовності до збою Визначено RPO і зрозуміло, скільки даних допустимо втратити. Визначено RTO і перевірено, чи відповідає йому реальний час restore. Хоча б одна резервна копія зберігається поза production-вузлом. Копіюються база, файли та потрібна для запуску конфігурація. Є ротація копій і контроль результату останнього backup. Налаштований зовнішній HTTP/HTTPS-моніторинг. Контролюються диск, inode, пам’ять, навантаження, БД і ключові процеси. Сповіщення перевірені, а не просто налаштовані. Є короткий runbook із послідовністю аварійного відновлення. Критичні доступи не залежать від однієї людини або одного пристрою. Проведено повне тестове відновлення. Після restore перевіряються реальні функції сервісу, а не лише головна сторінка. Найслабше місце аварійного плану часто видно саме під час тесту: копія завантажується надто довго, загублена версія пакета, забутий cron, немає доступу до DNS або інструкція зрозуміла тільки її автору. Disaster recovery plan, який ніколи не запускали, — це поки що гіпотеза. Після реального тестового відновлення вже можна говорити про робочу процедуру.