Планирование резервного копирования и восстановления

План резервного копирования и восстановления отвечает на два числовых вопроса: RPO (сколько данных вы можете потерять, выраженное в единицах времени) и RTO (как долго вы можете позволить себе простой). Определите их для каждой рабочей нагрузки, затем проектируйте в обратном направлении. База данных с RPO 5 минут требует непрерывной архивации WAL; еженедельный маркетинговый отчёт с RPO 24 часа — одного ночного задания. Дополните правилом 3-2-1: три копии, на двух типах носителей, одна вне площадки — и тестируйте восстановления ежеквартально. Большинство историй «у нас есть резервные копии» заканчиваются плохо, потому что никто никогда не практиковал восстановление.

RPO и RTO: исходные числа

RPO (Recovery Point Objective) = максимально допустимая потеря данных во времени. RTO (Recovery Time Objective) = максимально допустимое время простоя.

Примеры по рабочим нагрузкам:

• Производственная база данных для интернет-магазина: RPO 5 мин, RTO 1 час
• Загрузки файлов клиентами: RPO 15 мин, RTO 2 часа
• Внутренний файловый сервер: RPO 24 часа, RTO 8 часов
• Архив электронной почты: RPO 24 часа, RTO 48 часов
• Маркетинговая аналитика: RPO 24 часа, RTO 72 часа

Более жёсткий RPO/RTO стоит дороже. RPO в 5 минут означает непрерывную репликацию (дорогостоящая инфраструктура); RPO в 24 часа — одно ночное задание (дёшево). Не переусердствуйте — не каждая нагрузка нуждается в горячем резерве.

Правило 3-2-1 по-прежнему работает

Три копии данных, на двух разных типах хранилищ, одна — вне площадки. Правило 3-2-1 появилось до облака и остаётся актуальным:

• Первичная: производственное хранилище (S3, EBS, диск PostgreSQL)
• Вторичная: резервная копия на другом носителе или в другом регионе (ещё один S3-бакет с репликацией, Glacier)
• Третичная: вне площадки, в идеале другой поставщик или изолированная сеть (Backblaze B2, локальная лента, физические диски в сейфе)

Диверсификация поставщиков важна. Скомпрометированный корневой аккаунт AWS может удалить все ваши резервные копии в AWS. Вторичное хранилище в Backblaze, Wasabi или на собственном оборудовании переживёт этот сценарий. Для компаний с выручкой до 50 миллионов рублей в год копия у второго поставщика обходится примерно в 5 000–15 000 ₽/месяц и страхует от катастрофических проблем с основным арендатором.

Полное, инкрементное и синтетическое полное резервное копирование

Три стратегии резервного копирования:

• Полное: каждый раз копируется всё. Просто, восстановление быстрое (один файл), требует много места.
• Инкрементное: копируется только то, что изменилось с последней резервной копии. Экономно по месту, восстановление требует полной + всех инкрементных копий.
• Синтетическое полное: объединение полной + инкрементных в новую виртуальную полную на стороне сервера. Быстрое восстановление из любой точки.

Современные инструменты резервного копирования (Veeam, Rubrik, restic с prune, BorgBackup) используют инкрементное-навсегда с синтетическими полными копиями под капотом. Паттерн: ночное инкрементное, еженедельное синтетическое полное, хранение 30 ежедневных + 12 ежемесячных + 7 ежегодных копий (ротация дедушка-отец-сын).

Для файлового сервера на 2 ТБ с дневным изменением 5% инкрементное-навсегда хранит около 3–5 ТБ для годичного хранения — против 700+ ТБ при ежедневном полном.

Шифрование перед отправкой

Резервные копии не должны передаваться или храниться в незашифрованном виде. Клиентское шифрование с AES-256-GCM (по умолчанию в restic, Borg, Duplicacy, Veeam и других) гарантирует, что хост резервных копий никогда не видит открытый текст.

Управление ключами важнее выбора алгоритма. Резервная копия, зашифрованная ключом, хранящимся в том же аккаунте AWS, что и сама копия — бутафория: злоумышленник с доступом IAM получает оба. Храните ключи в:

• AWS KMS с ключом отдельного аккаунта (кросс-аккаунтная дешифровка)
• HashiCorp Vault во внеполосной среде
• Аппаратном модуле безопасности (YubiKey, HSM) для корневого ключа
• Распечатанной и запечатанной бумажной копии для критически важных ключей

Ротируйте регулярно (ежегодно), логируйте каждое использование и тестируйте восстановление с ротированным ключом до того, как ротация вступит в силу на производстве.

Неизменность: ответ на программы-вымогатели

Атаки программ-вымогателей в 2025 году обычно сначала нацелены на резервные копии — шифруют производственные данные, затем удаляют или шифруют резервные, чтобы предотвратить восстановление. Неизменяемые резервные копии нейтрализуют это.

Реализации:

• S3 Object Lock (Compliance Mode): даже root не может удалить в течение периода хранения
• Azure Blob immutable storage: аналогично, применяется на уровне контейнера
• Veeam Hardened Linux Repository: только добавление, только SSH, нет API удаления
• Физическая лента в хранилище: абсолютная изоляция от сети

Для бизнес-критичных данных хотя бы одна копия резервного копирования должна быть неизменяемой на период хранения. Дополнительные затраты обычно нулевые — вы всё равно собирались её хранить. Ценность при атаке программ-вымогателей абсолютна.

Тестирование: обязательная часть

Резервная копия, которую вы никогда не восстанавливали — не резервная копия, а надежда. График тестирования по приоритетам:

• Уровень 1 (критически важный): полная тренировка восстановления ежеквартально, случайное восстановление файла ежемесячно
• Уровень 2 (важный для бизнеса): полная тренировка раз в полгода, случайное восстановление ежеквартально
• Уровень 3 (стандартный): полная тренировка ежегодно, случайное восстановление ежеквартально

Фиксируйте в ходе теста:

1. Сколько времени занял откат (сравните с RTO)
2. Соответствуют ли данные производственному состоянию (контрольные суммы против известной точки)
3. Не сломались ли права или конфигурации при восстановлении
4. Что пошло не так и как было исправлено

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

Резервные копии баз данных требуют отдельного плана

Файлы и базы данных резервируются по-разному. Директория .pgdata, скопированная посреди транзакции, повреждена. Используйте нативные инструменты:

• PostgreSQL: pg_basebackup + архивация WAL для PITR, pg_dump для логического
• MySQL: Percona XtraBackup для горячего физического, mysqldump для логического
• MongoDB: mongodump, наборы реплик с отложенными вторичными
• Microsoft SQL Server: нативный бэкап с BACKUP DATABASE, доставка логов для PITR

Для 500-гигабайтовой базы PostgreSQL с RPO 5 минут ночные базовые резервные копии + непрерывная архивация WAL в S3 даёт восстановление до любой секунды за последние 30 дней. Время восстановления: получение базовой копии (30 мин), воспроизведение WAL до целевого времени (5–30 мин). Жёсткий RTO означает тёплую реплику, готовую к повышению.

Снимки, согласованные с приложением

Снимки файловой системы (ZFS, Btrfs, AWS EBS, управляемые диски Azure, постоянные диски GCP) фиксируют момент времени на блочном уровне. Для баз данных сочетайте с приостановкой приложения:

1. pg_start_backup('label') (PostgreSQL) или FLUSH TABLES WITH READ LOCK (MySQL)
2. Снимок
3. pg_stop_backup() или разблокировка

Снимок согласован с приложением — пригоден для восстановления без crash recovery. AWS Backup, Azure Backup и Google Cloud Backup автоматизируют этот паттерн для распространённых баз данных.

Передача архивов резервных копий третьим сторонам

Когда резервные копии нужно передать внешним сторонам — аудиторам, регуляторам, правопреемникам — сама передача требует внимательного отношения. FTP устарел; вложения в электронную почту упираются в ограничения размера; передача USB-носителей медленна.

Сквозное зашифрованное средство передачи файлов обрабатывает ad-hoc-распределение резервных копий. HexaTransfer перемещает файлы до 10 ГБ с клиентским шифрованием AES-256-GCM и одноразовой ссылкой. Подходит для отправки снимка базы данных аудитору без предоставления доступа к вашим S3-бакетам.

Документация — часть резервного копирования

Лучшая в мире резервная копия бесполезна, если человек, умеющий её восстановить, в отпуске, а никто другой не знает как. Документируйте:

• Что резервируется и что нет (явные исключения)
• Расписание и хранение по рабочим нагрузкам
• Управление ключами и доступом
• Инструкции по восстановлению с пошаговыми командами
• Контакты (техподдержка поставщика, дежурный)
• Результаты тестов и даты

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

Определите RPO/RTO, реализуйте 3-2-1 с неизменяемостью, шифруйте на стороне клиента, тестируйте ежеквартально, документируйте дотошно. Успех резервного копирования — это 10% технологии и 90% дисциплины.

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.