Восстановление сайта после сбоя: runbook, бекапы, сроки

Восстановление сайта после сбоя

Вы обнаружили, что сайт не открывается, а 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, тестирование — обязательная часть плана.

Рекомендуем комбинацию: еженедельный полный + ежедневный инкрементальный. Восстановление из инкрементального бекапа занимает в 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:

Что входит в услугу восстановления

• Аудит текущей схемы бекапов — проверяем, что сохраняется и восстанавливается.
• Подготовка runbook — подробная инструкция под ваш стек.
• Тестирование восстановления на стенде — доказываем, что процесс работает.
• Оптимизация бекапов — инкрементальные, off-site, шифрованные.
• Обучение команды — проводим сессию по отработке сценария отказа.
• Сопровождение после восстановления — гарантируем стабильность в течение 30 дней.

Сроки и стоимость

Восстановление сайта с готовым runbook — от 1 до 3 дней в зависимости от сложности. Полный аудит и настройка Disaster Recovery Plan — от 5 до 10 рабочих дней. Стоимость рассчитывается индивидуально после аудита.

Уверены в качестве — гарантируем результат. Оцените ваш recovery-план сейчас: свяжитесь с нами для бесплатного аудита. Получите чек-лист готовности и рекомендации. Закажите восстановление сегодня — наши инженеры свяжутся с вами в течение часа.

Наши цифры: 10+ лет опыта, 50+ восстановленных проектов, средний срок восстановления 45 минут. Восстановление из тестированного бекапа в 5 раз быстрее, чем из непроверенного.

Техническая поддержка сайта: обновления, мониторинг, SLA

Сайт на Laravel 8 с PHP 7.4. PHP 7.4 больше не поддерживается, Laravel 8 — тоже не получает обновлений безопасности. Хостинг-провайдер предупредил об обязательном обновлении PHP до 8.1 — после обновления два плагина и одна библиотека сломались, сайт упал. Мы регулярно сталкиваемся с такими сценариями: проект без регулярного ТО превращает каждое обновление окружения в аварию.

Этот кейс — не исключение, а правило. Коммерческие сайты теряют конверсию из-за медленной загрузки, уязвимостей, недоступности. Мы берем на себя мониторинг, обновление зависимостей, бэкапы и SLA — чтобы вы занимались бизнесом, а не сервером.

Без системной поддержки каждое обновление окружения становится сюрпризом: ломаются зависимости, падает производительность, появляются дыры безопасности. Техническая поддержка сайта — это страховка от таких сюрпризов и гарантия стабильной работы.

Что реально входит в техническую поддержку сайта?

Поддержка — не «ответить на звонок, когда что-то сломалось». Это систематическое предотвращение поломок.

Обновление зависимостей. Composer packages, npm packages, CMS или фреймворк. composer audit и npm audit показывают известные уязвимости. Dependabot или Renovate создают автоматические PR — задача поддержки проверить, что обновление не сломало staging, и смержить.

Обновления бывают: patch (1.2.3 → 1.2.4, только bugfix, безопасно), minor (1.2.0 → 1.3.0, новые фичи с обратной совместимостью, обычно безопасно), major (1.x → 2.x, ломающие изменения, требуют тестирования). Игнорировать обновления 6+ месяцев — накопить техдолг: разрыв больше, работы больше.

WordPress — отдельный разговор. Популярность платформы делает её главной целью атак. Устаревшие плагины — вектор №1 взломов. Регулярные обновления ядра, плагинов, тем + правильные разрешения файловой системы + WAF — необходимый минимум. Наш опыт показывает, что автоматические обновления WordPress Core без тестового окружения — риск, который мы не допускаем.

Как мониторинг предотвращает простои?

Uptime мониторинг. Базовый HTTP-чек раз в минуту. Better Uptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Алерт в Telegram или Slack при падении — и оповещение при восстановлении. Если сайт недоступен 10 минут в рабочее время — прямой ущерб.

Производительность. TTFB, LCP, INP — отслеживаем через Google Search Console (реальные пользователи, CrUX) и синтетический мониторинг (Lighthouse CI, SpeedCurve). Деградация часто постепенная — без мониторинга вы замечаете через месяц, когда LCP уже 5s.

Ошибки приложения. Sentry — стандарт для отслеживания JavaScript и PHP/Python ошибок в реальном времени. Каждая необработанная исключение с трассировкой стека, контекстом запроса, версией браузера. Особенно важно для ошибок, которые пользователи не сообщают — они просто уходят.

База данных. Рост объёма, медленные запросы (MySQL slow query log, pg_stat_statements для PostgreSQL), размер индексов. Таблица без VACUUM в PostgreSQL разрастается до гигабайт из-за dead tuples. Рутинное обслуживание БД — часть поддержки.

Дисковое пространство и логи. logrotate настроен? /var/log/nginx растёт без ограничений и заполняет диск — классика. Автоматическая ротация + алерт при disk > 80%.

Почему бэкапы без проверки — иллюзия?

Бэкап без проверки восстановления — не бэкап, а иллюзия безопасности. Видели случаи, когда mysqldump создавал файл 0 байт из-за ошибки прав, а никто не проверял содержимое месяцами. Мы гарантируем, что все копии работоспособны.

Схема бэкапов:

• Ежедневный инкрементальный бэкап базы данных + медиафайлы
• Еженедельный полный бэкап
• Хранение: минимум 3 копии, 2 разных медиа, 1 offsite (S3, Backblaze B2)
• Автоматическая проверка целостности (pg_restore --list, mysqldump verify)
• Тестовое восстановление раз в квартал в изолированное окружение

Retention политика: 7 ежедневных, 4 еженедельных, 3 ежемесячных. S3 Lifecycle rules автоматизируют удаление.

SLA: что это значит на практике

SLA (Service-Level Agreement) Wikipedia — конкретные обязательства по времени реакции и восстановления:

SLA имеет смысл только при наличии мониторинга — иначе о проблемах узнают от пользователей, а не от систем. Нерабочая кнопка в форме может незаметно убивать конверсию неделями.

Процесс обновления контента

Разработчик не должен быть в цепочке для правки текста на странице. CMS с удобным редактором, разграничение прав (редактор правит контент, не трогает код), история изменений. Для Laravel-проектов — Nova, Filament, или headless CMS (Strapi, Contentful) в зависимости от сложности.

Preview перед публикацией, staged rollout для важных изменений. Если редакторы работают напрямую с prod — это риск.

Типичные ситуации, которые решаем

Взлом сайта: анализ вектора атаки, очистка, усиление безопасности (WAF, fail2ban, ограничение прав файловой системы). Восстановление из бэкапа занимает часы, а не дни — если бэкапы настроены правильно. Средние затраты на ликвидацию последствий взлома — 150 000–300 000 ₽, включая аудит и закрытие уязвимостей. Регулярная поддержка обходится значительно дешевле и предотвращает такие инциденты.

Падение производительности после обновления: feature flag + возможность быстрого rollback. Canary деплой — обновляем 5% трафика, смотрим метрики, потом 100%.

Что входит в пакет поддержки (deliverables)

При заключении договора вы получаете:

• Документация: схема инфраструктуры, доступы, процедуры восстановления
• Мониторинг: uptime, производительность, ошибки, логи — настроенный с первого дня
• Резервное копирование: ежедневные/еженедельные копии с проверкой
• Обновление зависимостей: ежемесячный аудит и обновление с тестированием
• SLA-реагирование: по приоритетам из таблицы выше
• Отчёты: еженедельные дашборды, ежемесячный обзор, квартальный техплан
• Поддержка редактирования контента: обучение редакторов, настройка прав

Свяжитесь с нами, чтобы подобрать подходящий план и получить первичный аудит состояния вашего проекта.

Как мы работаем: этапы

1. Онбординг (3–5 дней): аудит текущего состояния, настройка мониторинга и бэкапов, документирование инфраструктуры.
2. Регулярный ритм: еженедельный отчёт по метрикам, ежемесячный обзор обновлений, квартальный технический аудит.
3. Реагирование: по SLA, с фиксацией причины и времени решения.
4. Развитие: по вашему запросу — новый функционал, оптимизация, рефакторинг.

Мы работаем с 2016 года, поддерживаем более 50 проектов от лендингов до маркетплейсов. Наши клиенты экономят от 50 000 ₽ в месяц за счёт превентивных мер.

Сроки и стоимость

Настройка мониторинга и бэкапов: 3–5 дней. Регулярная поддержка — ongoing контракт с фиксированным объёмом часов в месяц или абонемент. Стоимость рассчитывается индивидуально после аудита. Получите консультацию — оценим ваш проект за 1–2 дня.

Сравнение: мониторинг с автоматическим алертингом vs ручная проверка

Автоматический мониторинг Better Uptime в 10 раз быстрее реагирует на сбои, чем ручная проверка.