Резервное копирование по правилу 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. Гарантируем восстановление из бэкапа. Закажите консультацию — мы подберём оптимальную стратегию для вашего проекта. Хотите обезопасить свой проект? Свяжитесь с нами — оценим инфраструктуру за один день и предложим оптимальную стратегию.