Правило 3-2-1: как никогда не терять данные сервера

Серверы падают. Диски выходят из строя. Кто-то набирает не ту команду. Прилетает ransomware. Ни одно из этих событий не имеет нулевой вероятности — вопрос только когда. Правильный вопрос про сервер не «делать ли бэкапы», а «по какой стратегии». В этой статье — правило 3-2-1, золотой стандарт корпоративного мира, и как его применять.

Что такое 3-2-1?

Правило 3-2-1 — рекомендованная US-CERT стратегия резервного копирования, базовый ориентир для миллионов организаций по всему миру. Три цифры означают:

• 3: Всего 3 копии — оригинал + 2 бэкапа
• 2: На 2 разных типах носителей (например, SSD + HDD, или диск + облачное object storage)
• 1: Минимум 1 копия off-site (в другом физическом месте)

Логика проста: данные, собранные в одном месте, исчезают от одной поломки. 3-2-1 строит устойчивость ко всем сценариям потери.

Почему это настолько критично?

Угроза	Без 3-2-1	С 3-2-1
Сбой диска	Все данные потеряны	Восстановление из другой копии
Ransomware	Шифруется, вы платите	Восстановление из off-site бэкапа
Человеческая ошибка (DROP TABLE)	Данные стёрты	Восстановление из более раннего снимка
Пожар в дата-центре	Всё кончено	Восстановление из off-site локации
Банкротство хостинга	Услуга отключена	Локальная копия цела

По отчёту IBM 2024 года, средняя стоимость утечки данных — 4,88 млн $. Большинство бизнесов это не переживает — 60 % компаний, потерявших данные без бэкапов, закрываются за 6 месяцев.

Как применить 3-2-1 на практике?

Сценарий: e-commerce на WordPress + MySQL

Копия 1 — рабочий сервер (оригинал)

• Файлы WordPress + MySQL-БД на NVMe SSD
• Это не бэкап, а рабочая копия

Копия 2 — тот же сервер, отдельный диск / RAID

• Зеркалирование на уровне диска через RAID 1 или RAID 10
• Мгновенный фейловер при отказе диска
• Ежедневный автоматический снимок

Копия 3 — off-site (другая локация, другой носитель)

• Облачное object storage (Backblaze B2, AWS S3, Wasabi)
• Или резервный сервер в другом дата-центре
• Зашифрованная передача (rsync over SSH, restic или borgbackup)
• Еженедельный полный + ежедневный инкрементальный

Автоматизация бэкапа — простой пример cron

Минимальный скрипт бэкапа для WordPress + MySQL:

#!/bin/bash
DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/backup"
DB_NAME="wordpress"
DB_USER="root"
SITE_DIR="/var/www/html"
REMOTE="user@backup-server:/backups/wp/"

# 1. Дамп БД
mysqldump -u $DB_USER --single-transaction $DB_NAME | gzip > $BACKUP_DIR/db-$DATE.sql.gz

# 2. Файловый бэкап (инкрементальный tar)
tar --listed-incremental=$BACKUP_DIR/snapshot.snar -czf $BACKUP_DIR/files-$DATE.tar.gz $SITE_DIR

# 3. Off-site sync (зашифрованный rsync)
rsync -az --delete $BACKUP_DIR/ $REMOTE

# 4. Удалить бэкапы старше 30 дней
find $BACKUP_DIR -name "*.gz" -mtime +30 -delete

Запускать каждую ночь в 03:00 через /etc/cron.d/backup:

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

Профессиональные инструменты

В продакшене корпоративные инструменты лучше самописных скриптов:

• Veeam Backup — отраслевой стандарт, используется KavesNET
• restic — open source, дедупликация + шифрование «из коробки»
• BorgBackup — инкрементальный, зашифрованный, дедуплицированный
• Duplicati — удобный, с GUI

Самый критичный шаг: тест восстановления

Бэкап, который нельзя восстановить, стоит ноль. Этот шаг чаще всего пропускают в 3-2-1.

• Раз в месяц восстанавливайте бэкап в тестовое окружение
• Замеряйте время восстановления (RTO — Recovery Time Objective)
• Проверяйте целостность данных

Непроверенный бэкап — миф. Тех, кто в продакшене говорит «бэкапы были, но восстановить не смогли», не меньше, чем тех, у кого их вовсе не было.

Инфраструктура бэкапов KavesNET

В серверы KavesNET по умолчанию бесплатно включено:

• RAID10 — мгновенная защита на уровне дисков
• Ежедневные автоматические бэкапы через Veeam на внешние backup-серверы
• Хранение 7 дней
• Восстановление в один клик через тикет
• Backup-серверы в отдельной сети с резервированными 10 Гбит/с линками

Это покрывает пункты 2 и 3 правила 3-2-1 «из коробки». Для S3-совместимых off-site облачных бэкапов — напишите нам.

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

1. Бэкап на том же диске — диск умер, бэкап тоже
2. Только ручные бэкапы — забывается, последний — 6 месяцев назад
3. Передача без шифрования — backup-сервер взломан = все данные открыты
4. Не тестировать восстановление — отказывает в важный день
5. Слишком долгая ретенция — пустая трата хранилища; ротация 7-30-90 дней
6. Бэкапить только БД — uploads/, .htaccess, конфиги забыты

Итог

3-2-1-бэкап — не техническое предпочтение, а необходимость для непрерывности бизнеса. Компании, потерявшие данные и закрывшиеся, — не те, что слышали о правиле, а те, что не применяли.

Проверьте сегодня:

• Сколько у вас копий? (Должно быть 3)
• На скольких разных носителях? (Должно быть 2)
• Есть off-site копия? (Должна быть 1)
• Когда последний тест восстановления? (Не больше 1 месяца назад)

Серверы KavesNET уже покрывают две ноги 3-2-1: RAID10 + Veeam + внешние backup-серверы. Посмотреть тарифы серверов → или написать нам о схеме off-site бэкапа.

По теме: Различие VDS и VPS · Руководство по WordPress-хостингу