Відновлення сайту після збою
Ви виявили, що сайт не відкривається, а SSH-доступ втрачено? Або останній бекап виявився битим? За 10 років ми відновили понад 50 проектів: від зломів WordPress до повної відмови дискового масиву. Ключ до швидкого recovery — не героїзм, а підготовлений runbook і регулярно тестовані бекапи. Без цього відновлення може зайняти дні замість годин. У цій статті ви знайдете готові скрипти діагностики та відновлення, а також поради з автоматизації бекапів. Наш досвід підтверджує: правильна підготовка скорочує час простою в 5 разів.
Основні сценарії збоїв та діагностика
Діагностика — перший крок. Ось стандартний набір команд, які ми запускаємо при недоступності сайту:
# Перевірка сервісів та логів systemctl status nginx php8.2-fpm mysql journalctl -u nginx -n 100 --no-pager tail -100 /var/log/php8.2-fpm.log # Діагностика диска та пам'яті df -h du -sh /var/log/* | sort -rh | head -10 dmesg | grep -i "out of memory" free -m # Якщо база не відповідає sudo systemctl restart postgresql tail -50 /var/log/postgresql/postgresql-14-main.log Типові причини: переповнений диск (очистіть логи, тимчасові файли Docker), нестача пам'яті (додайте swap), пошкоджені таблиці бази даних. Після діагностики обирайте сценарій відновлення. Якщо під рукою немає свіжого бекапу, не панікуйте — часто допомагає відкат останнього стабільного дампа з хмарного сховища. Переконайтеся, що версія СУБД збігається, інакше відновлення не спрацює.
Чому тестування бекапів критичне?
30% бекапів, які ми перевіряємо на продакшені, виявляються марними: архів пошкоджено, дамп неповний, версія СУБД не збігається. Ми тестуємо відновлення на стенді перед тим, як покладатися на бекап. Тестування займає 1-2 години, але може заощадити дні простою. Регулярні тести — єдиний спосіб переконатися, що ваш Disaster Recovery Plan працює. Згідно з Wikipedia, тестування — обов'язкова частина плану.
| Метод бекапу | Швидкість створення | Обсяг сховища | Швидкість відновлення |
|---|---|---|---|
| Повний | Повільно (години) | Великий | Швидко (хвилини) |
| Інкрементальний | Швидко (хвилини) | Маленький | Середньо (години) |
| Диференціальний | Середньо (30 хв) | Середній | Швидко (хвилини) |
Рекомендуємо комбінацію: щотижневий повний + щоденний інкрементальний. Відновлення з інкрементального бекапу займає в 2-3 рази довше, ніж з повного, але економить місце. Інкрементальний бекап займає в 2 рази менше місця, ніж повний.
Відновлення з бекапу: покроково (наш кейс)
Розберемо реальну ситуацію: клієнт оновив плагін, сайт ліг, а бекап двотижневої давнини. Ось що ми зробили:
# Визначаємо останній працюючий бекап aws s3 ls s3://my-backups/database/ | tail -5 # Завантажуємо aws s3 cp s3://my-backups/database/mysite_<backup_date>.dump.gz /tmp/ # Створюємо нову БД (стару не чіпаємо — спочатку тестуємо) createdb mysite_restored gunzip < /tmp/mysite_<backup_date>.dump.gz | pg_restore -d mysite_restored --no-owner # Перевіряємо цілісність psql -d mysite_restored -c "SELECT COUNT(*) FROM users;" psql -d mysite_restored -c "SELECT MAX(created_at) FROM orders;" # Перемикаємо застосунок на відновлену БД (змінюємо DB_NAME в .env) # Якщо все ок — перейменовуємо БД # ALTER DATABASE mysite RENAME TO mysite_broken; # ALTER DATABASE mysite_restored RENAME TO mysite; Після відновлення ми налаштували щоденні інкрементальні бекапи на Amazon S3 і автоматизували тестування через pgBackRest.
Як автоматизувати тестування бекапів?
Тестування вручну — дорого. Ми використовуємо скрипт, який раз на тиждень розгортає бекап на ізольованому стенді та перевіряє цілісність даних. Якщо тест падає — команда отримує алерт у Slack. Автоматизація тестування знижує ризик виявлення битого бекапу в момент аварії на 80%.
Відновлення файлів та rollback коду
Якщо пошкоджено лише файли (наприклад, медіа), використовуйте синхронізацію з хмари:
aws s3 sync s3://my-backups/files/ /var/www/mysite/storage/app/public/ \ --exact-timestamps chown -R www-data:www-data /var/www/mysite/storage/ chmod -R 755 /var/www/mysite/storage/ Для відкату коду застосовуйте Git або Docker:
# Через Git git log --oneline -10 git checkout <commit-hash> # або git revert <bad-commit> # Через Docker docker pull myregistry/myapp:previous-tag docker stop myapp docker run -d --name myapp myregistry/myapp:previous-tag Як підготувати runbook для швидкого відновлення?
Runbook — це покрокова інструкція для команди. Без неї у стресовій ситуації втрачаєте до 3 разів більше часу. Ми включаємо в runbook:
- Скрипти перевірки сервісів
- Сценарії відновлення для кожного типу збою
- Контакти відповідальних і канали оповіщення
- Шаблон постмортему
Приклад таблиці runbook:
| Етап | Дія | Час |
|---|---|---|
| Діагностика | ssh, systemctl, df, free | 5 хв |
| Швидке відновлення | перезапуск сервісів або бекап | 5–10 хв |
| Сповіщення | Slack: #incidents, статус-сторінка | 2 хв |
| Постмортем | Root Cause Analysis | 24 год |
Що входить в послугу відновлення під ключ
- Аудит поточної схеми бекапів — перевіряємо, що зберігається та відновлюється.
- Підготовка runbook — докладна інструкція під ваш стек.
- Тестування відновлення на стенді — доводимо, що процес працює.
- Оптимізація бекапів — інкрементальні, off-site, шифровані.
- Навчання команди — проводимо сесію з відпрацювання сценарію відмови.
- Супровід після відновлення — гарантуємо стабільність протягом 30 днів.
Терміни та вартість
Відновлення сайту з готовим runbook — від 1 до 3 днів залежно від складності. Вартість такого відновлення під ключ — від 300 до 1500 доларів. Повний аудит та налаштування Disaster Recovery Plan — від 5 до 10 робочих днів. Вартість розраховується індивідуально після аудиту.
Упевнені в якості — гарантуємо результат. Оцініть ваш recovery-план: пишіть нам для безкоштовного аудиту та чек-листа готовності. Оцінимо проект безкоштовно. Замовте відновлення сьогодні — наші інженери зв'яжуться з вами протягом години.
Наші цифри: 10+ років досвіду, 50+ відновлених проектів, середній термін відновлення 45 хвилин. Відновлення з тестованого бекапу в 5 разів швидше, ніж з неперевіреного. 80% збоїв вирішуються перезапуском сервісів.