Резервное копирование (backup) — это создание копий данных/состояния системы с целью их сохранения и последующего восстановления в случае потери, повреждения или при миграции. Восстановление (restore) — процесс возвращения данных из этих копий в рабочее состояние.

Цели и ключевые показатели

• RPO (Recovery Point Objective) — максимальное допустимое количество данных, которое можно потерять, выраженное во времени (напр., RPO = 1 час означает, что можно потерять до 1 часа изменений).

• RTO (Recovery Time Objective) — максимальное допустимое время восстановления сервиса/данных до рабочего состояния (напр., RTO = 4 часа).

RPO определяет частоту бэкапов, RTO — требования к скорости восстановления и автоматизации.

Типы бэкапов

• Full (полный) — копируется весь набор данных. Быстро восстанавливать, дороже по объёму.

• Incremental — сохраняются только изменения после последнего бэкапа (full или инкрементального). Экономит место, но восстановление требует последовательного применения инкрементов.

• Differential — сохраняет изменения с момента последнего полного бэкапа. Быстрее восстановления, чем инкрементальный (нужно два набора), но растёт размер с течением времени.

• Snapshot — снимок состояния тома/файловой системы на момент времени (часто аппаратный или файловой системой). Быстро создаётся, может быть интегрирован с хранилищем (копия на уровне блочного устройства). Не всегда заменяет полноценный бэкап (зависит от хранения и согласованности).

• Incremental-forever / synthetic full — стратегия, при которой регулярно делаются инкременты, а периодически синтезируется «виртуальный» полный бэкап без полного копирования.

Согласованность данных

• Crash-consistent — данные в состоянии, как при внезапном отключении питания; может потребоваться восстановление журнала транзакций.

• Application-consistent — приложение приведено в согласованное состояние (например, с помощью flush/flush logs, VSS для Windows, выключение транзакций). Желательно для баз данных и критичных приложений.

• Для распределённых систем требуется координация снимков (global checkpoint) или использование инструментов, понимающих распределённые транзакции.

Бэкап баз данных

• Logical (дамп SQL) — читабельные экспортные файлы; удобны для миграций и частичных восстановлений, но медленнее.

• Physical (образы/файлы данных, WAL) — быстрые для восстановления больших БД; поддерживают PITR (Point-In-Time Recovery) через журнал транзакций (WAL shipping).

• Реплики как средство восстановления: promote replica → минимальное RTO, но реплика должна быть защищена от тех же ошибок (например, если ошибка — логическая, реплика может получить её тоже).

Хранение и безопасность

• 3-2-1 правило: минимум 3 копии, 2 разных носителя, 1 offsite (вне площадки).

• Immutable / WORM и air-gapped копии для защиты от ransomware.

• Шифрование бэкапов в покое и в transit; управление ключами (KMS).

• Ограничение доступа: отдельные учетные записи и аудит доступа к бэкапам.

Ретеншн, дедупликация, сжатие

• Политики хранения (retention) по возрасту/законодательству; tiering (горячее → холодное, архив) для оптимизации стоимости (например, Glacier).

• Дедупликация и сжатие уменьшают объём хранимых данных.

Верификация и тестирование

• Регулярно выполнять test restores (частичные и полные) — единственный надёжный способ убедиться, что бэкапы пригодны.

• Контролировать контрольные суммы (checksums) и статус задач бэкапа; мониторить успешность и время.

План восстановления (playbook)

• каталог бэкапов/метаданных (backup catalog) для поиска нужной копии;

• последовательность восстановления (full → differential/incremental → применение журналов);

• шаги валидации после восстановления (integrity checks, smoke tests), переключение DNS/балансировщиков, уведомление стейкхолдеров.

Операционные моменты

• Учитывать окно бэкапа и влияние на производительность; использовать snapshot-offload и репликацию, чтобы минимизировать нагрузку.

• Пропускная способность сети ограничивает скорость offsite-репликации; для больших объёмов используют физическую транспортировку или initial seeding.

• Логирование и алерты по сбоям бэкапов; регулярные ревью политики retention и стоимости.

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

• Не тестировать восстановление; хранить бэкапы на том же носителе/в той же сети, что и первичные данные; отсутствие шифрования; пропуск application-consistency; отсутствие immutable-копий.

Автоматизация, регулярное тестирование восстановлений, чёткие RPO/RTO и защита бэкапов (шифрование, разделение прав, immutable storage) — основа надёжной стратегии резервного копирования и восстановления.