Резервное копирование по правилу 3-2-1: автоматизация и гарантия

Резервное копирование сайта: гарантия восстановления по правилу 3-2-1

Однажды клиент потерял 3 месяца данных из-за сбоя RAID-массива. Бэкап хранился на том же физическом сервере — обе копии погибли. Восстановить удалось только из полугодовой копии на ноутбуке разработчика. По статистике, 30% компаний не проверяют бэкапы, а 50% хранят их на том же хостинге, что и основной сайт. Потеря данных обходится бизнесу в среднем в 2 миллиона рублей. Это прямой путь к невосполнимым потерям, которые обходятся в десятки и сотни тысяч рублей простоя. Мы занимаемся резервным копированием 10 лет и обслужили более 200 проектов.

В отличие от многих компаний, мы не просто настраиваем скрипты — мы проектируем архитектуру бэкапов, которая выдерживает отказ оборудования, человеческую ошибку и даже целенаправленную атаку. Наши инженеры сертифицированы AWS и PostgreSQL, что гарантирует корректную настройку S3 Lifecycle и pg_dump.

Правило 3-2-1 — золотой стандарт резервного копирования, исключающий такие риски. Источник: Wikipedia Мы настраиваем автоматические бэкапы, соответствующие этому правилу, с использованием S3-хранилища и умной ротации. Результат — гарантированная возможность откатиться к любой точке за последние 90 дней. Данные в безопасности даже при отказе оборудования.

Почему резервное копирование — не опция, а необходимость?

Бэкап на том же сервере — ложная безопасность. Если упадёт RAID, сгорят обе копии. Мы переносим бэкапы в S3 и настраиваем Lifecycle — теперь данные дублируются в другом регионе. Стоимость хранения 10 ГБ на S3 — менее 5 рублей в месяц, тогда как потеря данных может обойтись в миллионы. Это вложение, которое окупается при первой же аварии. Например, ежемесячные затраты на хранение 50 ГБ бэкапов — около 25 рублей. А восстановление данных после сбоя может стоить сотни тысяч рублей. Экономия очевидна.

Какие данные бэкапим в первую очередь

База данных — главный источник изменений. Для WordPress с 10k+ посетителей в день настраиваем бэкапы БД каждые 6 часов. Файлы загрузок (uploads/, storage/) — раз в сутки. Конфигурационные файлы (.env, nginx.conf) — после каждого изменения. Код — в Git, но резервная копия репозитория на отдельном сервере не помешает.

Настройка автоматического бэкапа за 2–4 часа

Используем bash, pg_dump, rsync и S3. Ниже — типовой сценарий.

Автоматический бэкап БД на S3

#!/bin/bash
# /opt/scripts/backup-db.sh

set -euo pipefail

DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="mysite_prod"
BACKUP_DIR="/tmp/backups"
S3_BUCKET="s3://my-backups/database"

mkdir -p "$BACKUP_DIR"

# PostgreSQL
pg_dump -U postgres -d "$DB_NAME" -F custom \
  | gzip > "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz"

# Upload to S3
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz" \
  "${S3_BUCKET}/${DB_NAME}_${DATE}.dump.gz" \
  --storage-class STANDARD_IA

# Clean local
rm "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz"

# Remove old (30 days)
aws s3 ls "${S3_BUCKET}/" \
  | awk '{print $4}' \
  | while read key; do
      date=$(echo "$key" | grep -oP '\d{8}')
      if [[ $(date -d "$date" +%s) -lt $(date -d "30 days ago" +%s) ]]; then
          aws s3 rm "${S3_BUCKET}/${key}"
      fi
  done

echo "Backup completed: ${DB_NAME}_${DATE}.dump.gz"

Crontab: каждые 6 часов

0 */6 * * * /opt/scripts/backup-db.sh >> /var/log/backup.log 2>&1

S3 Lifecycle Policies для автоматической ротации

{
  "Rules": [{
    "ID": "BackupRetention",
    "Filter": { "Prefix": "database/" },
    "Status": "Enabled",
    "Transitions": [
      { "Days": 7,  "StorageClass": "STANDARD_IA" },
      { "Days": 30, "StorageClass": "GLACIER" }
    ],
    "Expiration": { "Days": 90 }
  }]
}

Бэкап файлов через rsync + S3

# Syn uploads/ to S3
aws s3 sync /var/www/mysite/storage/app/public/ \
  s3://my-backups/files/ \
  --storage-class STANDARD_IA \
  --delete

# Without --delete (safer, but grows)
aws s3 sync /var/www/mysite/uploads/ s3://my-backups/uploads/

Этапы настройки бэкапа

1. Оценка объёма данных: определяем размер БД, файлов и их темп роста.
2. Выбор стратегии: частота бэкапов, глубина хранения, классы S3.
3. Написание скриптов: pg_dump, rsync, aws cli.
4. Настройка crontab: для БД — каждые 6 часов, для файлов — раз в сутки.
5. Настройка S3 Lifecycle: автоматическая ротация и удаление старых копий.
6. Тестовое восстановление: имитация сбоя и проверка restore.

Как проверить, что бэкап работает?

Бэкап без проверки восстановления — иллюзия безопасности. Ежемесячно запускайте тестовое восстановление в изолированной среде:

# Monthly restore test
aws s3 cp s3://my-backups/database/latest.dump.gz /tmp/test-restore.dump.gz
createdb mysite_restore_test
gunzip < /tmp/test-restore.dump.gz | pg_restore -d mysite_restore_test
psql -d mysite_restore_test -c "SELECT COUNT(*) FROM users;"
dropdb mysite_restore_test

Если восстановление прошло успешно — бэкап работает. При ошибке настроен alert в Telegram. Такой подход гарантирует, что в критический момент данные будут доступны.

Состав услуги по резервному копированию

• Разработка скриптов бэкапа (БД, файлы, конфиги)
• Настройка crontab и S3 Lifecycle
• Тестовое восстановление на изолированной среде
• Мониторинг с ежедневным healthcheck и алертами
• Документация с полной схемой и инструкцией

Перед сдачей проекта проверяем, что crontab настроен для БД и файлов, создана S3 Lifecycle policy, выполнено тестовое восстановление, настроен мониторинг с алертами, и передана документация клиенту.

Самописный скрипт или готовый плагин: что выбрать?

Самописный скрипт оправдан при кастомных сценариях: ротация, несколько БД, интеграция с мониторингом. Для простых сайтов готовые плагины быстрее, но мы рекомендуем гибридный подход.

Рекомендуемая политика хранения

Наши инженеры сертифицированы AWS и PostgreSQL. Гарантируем восстановление из бэкапа. Закажите консультацию — мы подберём оптимальную стратегию для вашего проекта. Хотите обезопасить свой проект? Свяжитесь с нами — оценим инфраструктуру за один день и предложим оптимальную стратегию.

Техническая поддержка сайта: обновления, мониторинг, 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 раз быстрее реагирует на сбои, чем ручная проверка.