Восстановление сайта после сбоя
Вы обнаружили, что сайт не открывается, а 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 раза дольше, чем из полного, но экономит место.
Восстановление из бекапа: пошагово (наш кейс)
Разберём реальную ситуацию: клиент обновил плагин, сайт лёг, а бекап двухнедельной давности. Вот что мы сделали:
# Определяем последний рабочий бекап 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 дней в зависимости от сложности. Полный аудит и настройка Disaster Recovery Plan — от 5 до 10 рабочих дней. Стоимость рассчитывается индивидуально после аудита.
Уверены в качестве — гарантируем результат. Оцените ваш recovery-план сейчас: свяжитесь с нами для бесплатного аудита. Получите чек-лист готовности и рекомендации. Закажите восстановление сегодня — наши инженеры свяжутся с вами в течение часа.
Наши цифры: 10+ лет опыта, 50+ восстановленных проектов, средний срок восстановления 45 минут. Восстановление из тестированного бекапа в 5 раз быстрее, чем из непроверенного.