Потеря данных — это не вопрос «случится ли», а вопрос «когда». Диски ломаются, серверы падают, люди случайно удаляют файлы, хостинги закрываются. И вот тут выясняется, был ли у вас нормальный бэкап или просто иллюзия.

Стратегия 3-2-1 — это минимальный стандарт, который реально защищает. Не на 80%, не «в целом», а конкретно. Разберём её до деталей и сразу на практике.

Что такое стратегия 3-2-1

Правило простое:

  • 3 копии данных
  • 2 разных типа носителя
  • 1 копия хранится вне основного места (offsite)

Откуда взялась эта формула? Придумал её фотограф Питер Крог ещё в 2000-х — и она прижилась в DevOps, потому что работает. Логика железная: при соблюдении всех трёх условий вероятность потерять данные стремится к нулю.

Давайте разберём каждый пункт.

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

Два типа носителя — значит не два жёстких диска в одном сервере. Разные носители: локальный диск и облако, NAS и лента, SSD и объектное хранилище. Суть в том, что одна физическая авария (пожар, затопление серверной, скачок напряжения) не уничтожит оба носителя.

Одна копия offsite — за пределами вашего датацентра или офиса. Если горит серверная — облачная копия цела. Если облако падает — локальная копия цела.

Что именно нужно бэкапить

Прежде чем настраивать инструменты — разберитесь, что у вас вообще есть.

Базы данных — приоритет номер один. PostgreSQL, MySQL, MongoDB, Redis — всё, что хранит пользовательские данные, заказы, контент. Базы меняются постоянно, поэтому бэкапить их нужно чаще всего.

Файлы приложения — код, конфиги, загруженные пользователями файлы (медиа, документы). Код обычно хранится в git, но конфиги с секретами — нет. Про них часто забывают.

Конфигурация сервера — nginx.conf, настройки systemd, crontab, SSL-сертификаты, переменные окружения. Это то, что позволит поднять сервер с нуля за час, а не за день.

Системные данные — логи (если они важны для аудита), сертификаты, ключи доступа.

Сделайте список всего критичного прямо сейчас. Буквально файл backup_plan.md с перечнем директорий и баз данных. Без этого список «что бэкапить» будет жить только в голове — а там он обязательно окажется неполным в самый неподходящий момент.

Как выбрать инструменты

Инструментов много, вот самые проверенные.

Для баз данных

pg_dump / pg_dumpall — для PostgreSQL. Встроенный, надёжный, простой.

pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%Y%m%d_%H%M).dump

Флаг -Fc создаёт бинарный формат — он сжатый и восстанавливается через pg_restore. Удобнее, чем чистый SQL.

mysqldump — для MySQL/MariaDB:

mysqldump -u root -p mydb | gzip > /backups/mydb_$(date +%Y%m%d_%H%M).sql.gz

mongodump — для MongoDB, аналогично.

Для файлов

rsync — классика для инкрементальных бэкапов. Копирует только изменившиеся файлы, экономит трафик и время.

rsync -avz --delete /var/www/ /backups/www/

tar — для создания архивов перед отправкой в облако:

tar -czf /backups/www_$(date +%Y%m%d).tar.gz /var/www/

Restic — современный инструмент с дедупликацией, шифрованием и поддержкой множества хранилищ (S3, B2, SFTP, локальный диск). Рекомендую его для серьёзных проектов.

restic -r s3:s3.amazonaws.com/mybucket backup /var/www

Restic автоматически дедублицирует данные — то есть одинаковые блоки не хранятся дважды. На больших объёмах это экономит деньги.

Куда складывать (offsite)

S3-совместимые хранилища — AWS S3, Yandex Object Storage, Selectel, Timeweb Cloud. Это самый распространённый offsite-вариант. Yandex Object Storage стоит около 1,5–2 ₽ за гигабайт в месяц — для большинства проектов это копейки.

Backblaze B2 — дешевле AWS, есть бесплатный уровень до 10 ГБ. Хорошо работает с Restic.

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

Настраиваем бэкапы: пошагово

Шаг 1: локальный бэкап

Создаём скрипт, который каждую ночь делает дамп базы и архив файлов:

#!/bin/bash
BACKUP_DIR="/backups"
DATE=$(date +%Y%m%d_%H%M)
DB_NAME="mydb"

# Бэкап базы данных
pg_dump -U postgres -Fc $DB_NAME > $BACKUP_DIR/db_$DATE.dump

# Бэкап файлов
tar -czf $BACKUP_DIR/files_$DATE.tar.gz /var/www/

# Удаляем бэкапы старше 7 дней
find $BACKUP_DIR -name "*.dump" -mtime +7 -delete
find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete

echo "Backup completed: $DATE"

Добавляем в crontab:

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Каждую ночь в 2:00 — тихо, автоматически.

Шаг 2: второй носитель

Локальный бэкап — это хорошо, но недостаточно. Если диск с бэкапами в том же сервере, что и основные данные — это не два носителя, это один сервер.

Варианты:

  • Отдельный диск в сервере (NVMe + HDD)
  • NAS в офисе
  • Другой сервер в той же локации

Шаг 3: offsite через облако

Отправляем бэкапы в объектное хранилище. Пример с Restic и Yandex Object Storage:

export AWS_ACCESS_KEY_ID="your_key"
export AWS_SECRET_ACCESS_KEY="your_secret"
export RESTIC_PASSWORD="your_restic_password"

# Инициализируем репозиторий (один раз)
restic -r s3:storage.yandexcloud.net/mybucket init

# Делаем бэкап
restic -r s3:storage.yandexcloud.net/mybucket backup /backups/

# Чистим старые версии (оставляем последние 30)
restic -r s3:storage.yandexcloud.net/mybucket forget --keep-last 30 --prune

Restic шифрует данные перед отправкой — даже если кто-то доберётся до вашего бакета, он ничего не прочитает.

Ротация и политика хранения

Держать все бэкапы вечно — дорого и бессмысленно. Стандартная политика:

  • Ежедневные — хранить 7 дней
  • Еженедельные — хранить 4 недели
  • Ежемесячные — хранить 12 месяцев

Это даёт вам возможность откатиться на любую дату в пределах недели, на конец любой недели в пределах месяца, и на конец любого месяца в пределах года.

Restic делает это одной командой:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Тестирование бэкапов — самое важное

Бэкап, который вы не проверяли — это не бэкап. Это файл с неизвестным содержимым.

Типичная история: бэкапы делались год, всё выглядело хорошо. Когда сервер упал — оказалось, что скрипт падал с ошибкой уже три месяца, а файлы в директории — пустые архивы. Потому что никто не проверял.

Что проверять:

  1. Бэкап вообще создался и не пустой
  2. Архив открывается без ошибок
  3. База данных восстанавливается из дампа
  4. Файлы в архиве те, что нужно

Как автоматизировать проверку:

#!/bin/bash
LATEST=$(ls -t /backups/*.dump | head -1)

if [ -z "$LATEST" ]; then
  echo "ERROR: No backup found" | mail -s "Backup failed" admin@example.com
  exit 1
fi

SIZE=$(stat -c%s "$LATEST")
if [ $SIZE -lt 10000 ]; then
  echo "ERROR: Backup too small ($SIZE bytes)" | mail -s "Backup suspicious" admin@example.com
  exit 1
fi

# Проверяем восстановление в тестовую базу
pg_restore -U postgres -d test_restore_db $LATEST
if [ $? -ne 0 ]; then
  echo "ERROR: Restore failed" | mail -s "Backup restore failed" admin@example.com
fi

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

Мониторинг бэкапов

Если бэкап упал — вы должны об этом узнать немедленно, а не через неделю при следующей проверке.

Простой вариант — отправлять уведомление в Telegram при ошибке. Чуть сложнее — использовать healthcheck-сервисы вроде healthchecks.io: скрипт пингует сервис при успешном завершении, а если пинга нет — сервис присылает алерт.

# В конце скрипта бэкапа
curl -fsS -m 10 https://hc-ping.com/your-uuid > /dev/null

Если скрипт завершился с ошибкой — curl не выполнится, healthchecks.io пришлёт уведомление.

Особые случаи: Docker и Kubernetes

Если приложение в Docker — не забудьте бэкапить Docker volumes. Они живут в /var/lib/docker/volumes/ и не входят в стандартный бэкап файловой системы.

docker run --rm \
  -v myapp_data:/data \
  -v /backups:/backups \
  alpine tar -czf /backups/volume_$(date +%Y%m%d).tar.gz /data

Для Kubernetes — Velero. Это полноценный инструмент для бэкапов кластера: сохраняет состояние ресурсов и данные persistent volumes.

Сколько это стоит

Стоимость бэкапной инфраструктуры зависит от объёма данных. Типичный небольшой проект:

  • База данных 5–10 ГБ, файлы 20–30 ГБ
  • Yandex Object Storage: ~70–100 ₽/месяц за хранение
  • Время настройки: 2–4 часа один раз

Это буквально ничто по сравнению с ценой восстановления данных или репутационными потерями от даунтайма.

Если вы заказываете сайт или корпоративный ресурс — уточните у разработчика, входит ли настройка бэкапов в поддержку. В REEXY, например, поддержка сайта стартует от 10 000 ₽/мес и включает техническое обслуживание — туда как раз входит и контроль резервного копирования.

Частые ошибки

Бэкап в ту же директорию, что и данные. Если диск умрёт — умрут оба. Разные носители — это физически разные устройства.

Бэкап без проверки. Файл есть, но что внутри — неизвестно. Проверяйте восстановление.

Только ручные бэкапы. «Я делаю бэкап каждую пятницу» — это значит, что в четверг данные за неделю пропадут. Автоматизируйте.

Бэкап без ротации. Диск переполнится, новые бэкапы перестанут создаваться. Настройте удаление старых копий.

Нет offsite. Пожар, затопление, кража оборудования — локальные бэкапы исчезнут вместе с основными данными.

Секреты в открытом виде. Если бэкап уходит в облако — шифруйте. Restic делает это автоматически.

Итог

Стратегия 3-2-1 — не rocket science. Три копии, два носителя, одна offsite. Настраивается за несколько часов, стоит копейки, а в момент аварии сохраняет бизнес.

Минимальный стек для старта: pg_dump / tar для создания бэкапов, rsync или Restic для отправки в облако, cron для автоматизации, healthchecks.io для мониторинга. Этого достаточно для 95% проектов.

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