Резервне копіювання та відновлення після збоїв для PHP-сайтів: практичний посібник

Кожен PHP-сайт працює на стеку рухомих частин: веб-сервер, середовище виконання PHP, база даних MySQL або PostgreSQL, конфігураційні файли, завантажені ресурси та часто сотня дрібних cron-завдань. Будь-яка з цих частин може вийти з ладу — пошкоджена таблиця, необережне rm -rf, програма-вимагач — і якщо у вас є лише одна резервна копія бази даних з минулого тижня, ви в біді. У DigiForge ми відновлювали більше PHP-сайтів, ніж хотілося б згадувати, і різниця між чотиригодинним відновленням і чотириденним кошмаром завжди зводиться до одного: правильно спроєктованої стратегії резервного копіювання та аварійного відновлення.

Чому резервного копіювання недостатньо

Багато команд плутають резервне копіювання з аварійним відновленням. Резервне копіювання — це періодична копія даних. Аварійне відновлення — це весь процес повернення вашого застосунку в робочий стан: відновлення даних, переналаштування сервісів, перенаправлення трафіку та перевірка, що все працює. Як зазначається в одному звіті з ІТ-стійкості, "захисту даних за допомогою резервних копій більше недостатньо для виживання" (джерело). Резервна копія без перевіреного плану відновлення — це просто страховка, яку ви ще не читали.

У контексті PHP різниця є разючою. Ваша резервна копія бази даних може бути ідеально цілою, але якщо ви не знаєте, як вказати Apache або Nginx на відновлену базу даних, змінити облікові дані в .env або перебудувати PHP opcache, ви все одно залишаєтеся офлайн. А простої, як ми всі знаємо, коштують грошей і довіри. Комплексний план аварійного відновлення (DR) повинен охоплювати кожен рівень вашого серверного стеку, а не лише дані.

Стек резервного копіювання та відновлення для PHP-сайтів

Ми розбиваємо резервне копіювання PHP-застосунку на п'ять окремих рівнів. Відсутність будь-якого з них може зробити інші марними:

1. Код та система контролю версій (Git-репозиторії, включаючи теги та гілки).
2. Дамп бази даних (MySQL, PostgreSQL або MariaDB).
3. Конфігурація веб-сервера (віртуальні хости Nginx/Apache, SSL-сертифікати, пули PHP-FPM).
4. Конфігурація застосунку (.env, конфігураційні файли, жорстко закодовані облікові дані).
5. Вміст, завантажений користувачами (зображення, PDF, будь-які файли, що зберігаються поза базою даних).

Давайте розглянемо кожен рівень з практичними рекомендаціями.

1. Код та контроль версій

Код вашого застосунку має зберігатися в Git-репозиторії — без винятків. Але Git push — це не резервна копія. Ми бачили команди, які покладалися на єдину віддалену гілку і втрачали тижні роботи через force push або пошкоджений репозиторій. Використовуйте хостинг-провайдера Git (GitHub, GitLab, Bitbucket) і налаштуйте автоматичне дзеркалювання на другу локацію. Для продакшн-розгортань тегуйте кожен реліз. Таким чином, якщо потрібно відкотитися до відомого стабільного стану, ви не будете гадати, який коміт був активним.

2. Резервне копіювання баз даних

Резервне копіювання баз даних є найкритичнішим і найчастіше ігнорованим. Щоденний mysqldump у локальну директорію краще, ніж нічого, але ми бачили, як такі дампи заповнюють диск і непомітно припиняють роботу. Автоматизуйте дампи за допомогою скрипта, який обертає старі резервні копії, стискає їх і відправляє за межі сервера — на S3, Backblaze або окремий сервер. Використовуйте mysqldump --single-transaction для таблиць InnoDB, щоб уникнути блокувань читання, і періодично тестуйте відновлення. Резервна копія, яку не можна відновити, нічого не варта.

3. Конфігурація сервера та веб-сервера

Ваш PHP-сайт працює не лише на коді та даних. Файли конфігурації Nginx або Apache, налаштування пулу PHP-FPM, SSL-сертифікати та визначення cron-завдань є унікальними для вашого сервера. Ми зберігаємо їх в окремому Git-репозиторії (або як частину репозиторію застосунку в директорії deploy/) і резервуємо їх разом з іншим. Сервіси на кшталт Certbot автоматично поновлюють сертифікати Let’s Encrypt, але якщо ваш сервер вийде з ладу, ці сертифікати будуть втрачені. Резервуйте /etc/letsencrypt/ або переходьте на DNS-валідацію, яка переживає перебудову.

4. Конфігурація середовища та застосунку

PHP-застосунки часто мають файл .env із обліковими даними бази даних, ключами API та секретами. Вони ніколи не повинні потрапляти в систему контролю версій. Для продакшну ми використовуємо менеджер секретів (наприклад, HashiCorp Vault або envkey), але як мінімум зашифруйте та зберігайте копію .env у вашій системі резервного копіювання. Якщо ви втратите цей файл, ви не відновлюєте сайт — ви перебудовуєте його.

5. Завантаження користувачів і медіафайли

Зображення, PDF та інші завантаження часто зберігаються в каталозі public/uploads. Вони швидко зростають і можуть роздувати резервні копії бази даних, якщо зберігати їх як BLOB. Найкраща практика: зберігайте завантаження на окремому томі або в об'єктному сховищі (S3, DigitalOcean Spaces). Якщо вони знаходяться на файловій системі сервера, включайте цей каталог у ваше зовнішнє резервне копіювання. Використовуйте rsync або rclone для щоденної синхронізації з хмарним сховищем.

Автоматизація та тестування плану відновлення

Стратегія резервного копіювання настільки ж хороша, наскільки хороше відновлення. Ми не раз стикалися з пост-мортемами, де клієнт казав: «У нас є резервні копії», але ніколи не пробував їх використовувати. Аварійне відновлення — це процес, а не продукт. Вам потрібно записати — і, що важливіше, відрепетирувати — як ви будете повертати ваш PHP-сайт до життя.

• Напишіть runbook. Документуйте кожен крок: де зберігаються резервні копії, як відновити базу даних, які команди перебудовують веб-сервер, як оновити DNS, якщо зміниться ваша IP-адреса.
• Автоматизуйте відновлення. Використовуйте скрипти або інструменти оркестрації (Ansible, Puppet або навіть простий Bash-скрипт), щоб підготувати новий сервер і відновити ваш застосунок із резервних копій. Якщо ви не можете розгорнути клон менш ніж за годину, ваш план аварійного відновлення занадто повільний.
• Тестуйте щоквартально. Відновіть весь ваш PHP-стек на свіжому сервері (новий VPS або локальна віртуальна машина) і переконайтеся, що сайт працює. Перевірте розповсюдження DNS, SSL, з'єднання з базою даних, cron-завдання та всі потоки користувачів. Виправте все, що зламалося.

На наш досвід, найпоширеніші невдачі під час тренувального відновлення — це невідповідність облікових даних (жорстко закодовані паролі бази даних, які не збігаються з відновленим .env), відсутні розширення PHP та неповні завантаження. Кожна невдача — це подарунок: вона виявляє прогалину, яку можна виправити до реальної катастрофи.

«Резервна копія без перевіреного плану відновлення — це просто надія.» — Інженерний принцип DigiForge

Вибір місць зберігання та форматів

Старе правило 3-2-1 досі актуальне: три копії ваших даних, на двох різних носіях, одна з яких — поза межами сайту. Для PHP-сайтів типова конфігурація: (1) локальний скрипт резервного копіювання на живому сервері, (2) віддалене хмарне сховище та (3) холодне архівне сховище (наприклад, Glacier) для щомісячних знімків. Шифруйте резервні копії за допомогою GPG або клієнтського шифрування перед завантаженням до будь-якої сторонньої служби.

Інкрементні резервні копії економлять пропускну здатність і місце, але ускладнюють відновлення. Для сайту із середнім трафіком на PHP оптимальним є щоденний повний дамп бази даних плюс погодинні бінарні логи (якщо потрібно). Резервне копіювання файлової системи можна робити інкрементно за допомогою rsync — просто переконайтеся, що ваш інструментарій здатен відновити узгоджений стан з інкрементних копій.

Коли трапляється лихо: посібник із відновлення

Змоделюймо найгірший сценарій: атака програм-вимагачів шифрує корінь веб-сервера PHP та базу даних. Ось загальний план відновлення, який ми використовуємо в DigiForge:

1. Ізолюйте заражений сервер — заблокуйте весь зовнішній доступ, створіть знімок для криміналістики, якщо потрібно.
2. Підготуйте чистий сервер — свіжий VPS з тією ж ОС і версією PHP.
3. Відновіть код із Git — клонуйте тег релізу, який працював до атаки.
4. Відновіть конфігурацію — скопіюйте .env, конфіги веб-сервера, SSL-сертифікати (або перевипустіть їх).
5. Відновіть базу даних — імпортуйте останній чистий дамп, потім відтворіть бінарні логи до моменту зараження (якщо доступні).
6. Відновіть завантаження — синхронізуйте за допомогою rsync з резервного сховища до каталогу завантажень нового сервера.
7. Протестуйте все — запустіть перевірки працездатності, переконайтеся в з'єднанні з БД, перевірте виконання cron-завдань.
8. Перемкніть DNS — вкажіть домен на IP нової машини (попередньо зменшіть TTL).
9. Моніторте — спостерігайте за логами та аптаймом протягом 24 годин. Оголошуйте про відновлення лише після стабільної зеленої позначки.

Весь цей процес може зайняти 2–4 години, якщо ваші резервні копії добре організовані й ви практикувалися. Без практики це може розтягнутися на дні.

Формування культури відновлення

Аварійне відновлення — це не одноразовий проєкт, а постійна практика. Щоразу, коли ви оновлюєте версію PHP, додаєте новий cron-завдання або змінюєте директиву веб-сервера, оновлюйте свій runbook і проводьте повторне тестування. Ми надто часто бачили, як команди ставляться до резервного копіювання як до пункту в чеклисті. Справжня стратегія аварійного відновлення вплітається у ваш конвеєр розгортання, моніторинг і м'язову пам'ять команди.

Якщо ви відповідаєте за PHP-сайт, почніть сьогодні. Перегляньте покриття резервного копіювання для всіх п'яти рівнів, автоматизуйте те, що можна, і заплануйте перше тренування з відновлення. А якщо вам потрібен свіжий погляд на вашу стратегію, зв'яжіться з DigiForge. Ми створили й відновили достатньо PHP-сайтів, щоб знати, що працює, а що — ні.