Стратегия облачного резервного копирования: руководство

Работающая стратегия облачного резервного копирования следует правилу 3-2-1: три копии данных, на двух разных типах носителей, одна из которых хранится вне офиса — на практике это означает основное хранилище (продакшен), локальный бэкап (NAS или внешний диск) и минимум один облачный уровень (Backblaze B2, AWS S3 Glacier Deep Archive или Wasabi). Добавьте иммутабельность через object lock, шифруйте на стороне клиента с AES-256 перед загрузкой, автоматизируйте ночные бэкапы через restic или Borg, и — этот шаг большинство команд пропускает — тестируйте полное восстановление ежеквартально. Без проверенного восстановления у вас есть надежда, а не резервная копия.

Почему правило 3-2-1 актуально и сегодня

Правило 3-2-1 пришло из плёночной фотографии, но математика не изменилась. Три копии дают достаточную избыточность, чтобы любой единичный сбой (падение диска, шифровальщик, случайный rm -rf) оставил две копии нетронутыми. Два типа носителей защищают от системных сбоев — плохой прошивки, убившей целую линейку SSD, или аварии в регионе облачного провайдера. Хранение вне офиса защищает от событий на уровне здания: пожара, потопа, кражи или падения стеллажа.

Существуют современные вариации. 3-2-1-1-0 добавляет иммутабельную копию и требует нулевых ошибок в тестах восстановления. 4-3-2 (используется многими MSP) предполагает четыре копии и двух облачных вендоров. Выберите один вариант, задокументируйте и придерживайтесь его. Конкретные числа важны меньше, чем дисциплина исполнения.

Выбор уровней хранения: цена против скорости восстановления

Облачные провайдеры предлагают классы хранилища по кардинально разным ценам:

| Уровень | Цена за ГБ/мес | Задержка первого байта | Исходящий трафик | |---|---|---|---| | S3 Standard | $0,023 | миллисекунды | $0,09/ГБ | | S3 Glacier Instant | $0,004 | миллисекунды | $0,03/ГБ | | S3 Glacier Flexible | $0,0036 | 3–5 минут | $0,02/ГБ | | S3 Glacier Deep Archive | $0,00099 | 12 часов | $0,02/ГБ | | Backblaze B2 | $0,006 | миллисекунды | $0,01/ГБ | | Wasabi | $0,0069 | миллисекунды | бесплатно (до 1x объёма/мес) | | Cloudflare R2 | $0,015 | миллисекунды | бесплатно |

Для бэкапов Glacier Deep Archive даёт примерно $1 за ТБ в месяц, но задержка восстановления исключает его использование для «ой, я удалил вчерашний файл». Лучший подход — двухуровневый: свежие бэкапы на горячем уровне (B2 или R2), старше 30 дней — переход в Glacier Deep Archive по lifecycle-политике.

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

Пример стека для рабочего набора в 2 ТБ:

Продакшен: ноутбуки, серверы, SaaS-данные (первичная копия)
Локальный: NAS на ZFS со снапшотами, 4 ТБ полезного объёма, еженедельное зеркалирование на внешний USB-диск в огнеупорном сейфе
Облако горячее: бакет Backblaze B2 с restic, ночные инкременты, хранение 90 дней за ~$12/мес для 2 ТБ
Облако холодное: S3 Glacier Deep Archive через lifecycle-политику, ежегодные снапшоты, хранение 7 лет за ~$24/год для 2 ТБ

Общая ежемесячная стоимость: менее $20 за полное покрытие 3-2-1 с семилетней историей. Это дешевле одного нового ноутбука.

Автоматизация бэкапов надёжными инструментами

Restic — стандарт де-факто для зашифрованных инкрементных бэкапов в объектное хранилище. Дедуплицирует, сжимает, шифрует (AES-256-CTR + Poly1305), нативно поддерживает B2, S3, Azure, GCS и SFTP:

restic -r b2:hexa-backups:production init
restic -r b2:hexa-backups:production backup /var/data \
  --exclude-file=/etc/restic/exclude.txt \
  --tag nightly
restic -r b2:hexa-backups:production forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Запускайте ночью через systemd timer или cron, с паролем репозитория в файле, доступном только root. Borg Backup — отличная альтернатива, особенно при необходимости локального репозитория; Kopia новее и имеет более дружелюбный UI.

Для Windows-машин Duplicati или встроенная Windows File History с облачной целью покрывают базовые нужды. Для Mac — Time Machine на локальный NAS плюс Arq Backup на Backblaze B2 — проверенная связка. Для российских компаний с требованиями 152-ФЗ о хранении данных граждан РФ на территории России self-hosted MinIO или Яндекс Object Storage заменяют зарубежные B2/S3.

Иммутабельность бэкапов против шифровальщиков

Шифровальщик, зашифровавший продакшен-данные, попытается зашифровать и бэкапы. Object lock предотвращает это. AWS S3 и Backblaze B2 поддерживают «режим соответствия», где даже root-аккаунт не может удалить объекты до истечения срока хранения:

aws s3api put-object-lock-configuration \
  --bucket backup-immutable \
  --object-lock-configuration '{
    "ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}
  }'

30 дней после загрузки никто — включая скомпрометированного администратора — не может удалить бэкап. Совмещайте с версионированием, MFA-delete и IAM-ролью, у которой есть право записи, но нет перезаписи. Это закрывает основной вектор атаки шифровальщиков.

Шифрование на клиенте перед загрузкой

Даже при серверном шифровании провайдера (SSE-KMS) облачный вендор держит ключи — что означает возможность расшифровки по запросу регулятора. Для чувствительных данных шифруйте до того, как байты покинут вашу сеть. Restic делает это автоматически; для разовых файлов хорошо подходит age:

age -r age1xyz... -o archive.tar.gz.age archive.tar.gz
aws s3 cp archive.tar.gz.age s3://backups/

Храните приватный ключ age в менеджере паролей (Bitwarden, 1Password) или аппаратном ключе. Сделайте резервную копию самого ключа на бумаге, зашифровав парольной фразой, и поместите её в банковскую ячейку. Потеря ключа шифрования так же катастрофична, как потеря данных.

Тестирование восстановления — это и есть резервная копия

Каждый квартал выбирайте случайный файл или сервер и восстанавливайте его от начала до конца в чистой среде. Измеряйте:

RTO (recovery time objective): от принятия решения до завершения восстановления
RPO (recovery point objective): сколько данных потеряно (часы, дни)
Целостность: совпадает ли хэш восстановленных байт с оригиналом?

Реальный пример: команда с ночными бэкапами в S3 Glacier Deep Archive обнаружила во время первого теста восстановления, что настройка разрешений плюс ожидание 12-часового извлечения даёт RTO 18 часов при потребности бизнеса в 4. Перевели активное хранение на Glacier Flexible (извлечение 3–5 минут), оставив Deep Archive только для compliance-истории. Этот тест уберёг их от открытия истины во время реального инцидента.

Документируйте runbook в процессе: команды, учётные данные, парольные фразы для расшифровки, кто может авторизовать восстановление. Тестируйте на чистом ноутбуке, чтобы убедиться, что runbook работает без вашей локальной среды.

Требования регуляторов к срокам хранения

В России и СНГ применяются следующие требования:

152-ФЗ о персональных данных: срок хранения — не дольше, чем необходимо для заявленной цели; при достижении цели — уничтожение
НК РФ: финансовые документы — минимум 5 лет
Архивное законодательство (Приказ Росархива): кадровые документы — 75 лет
Бухгалтерский учёт (402-ФЗ): первичные документы — минимум 5 лет
GDPR (для ЕС): хранить только в течение необходимого времени

Тегируйте бэкапы метаданными хранения и применяйте lifecycle-политики, чтобы не хранить данные дольше необходимого (проблема 152-ФЗ) и не короче требуемого (проблема налоговых проверок).

Мониторинг и алертинг

Бэкапы, которые тихо падают, хуже, чем их отсутствие. Каждый задача restic или Borg должна отправлять метрики: длительность, переданные байты, изменённые файлы, статус успеха/ошибки. Отправляйте в Prometheus, Datadog или обычный cron-лог, мониторящийся инструментом типа Dead Man's Snitch — он алертит, когда ожидаемый heartbeat не приходит. Ошибка, которую нужно поймать — «бэкапы сломаны 90 дней, и никто не заметил».

Алертируйте на: падение задачи, пропуск задачи, повреждение репозитория (restic check), необычное изменение размера (потеря данных или неожиданный рост) и неудачный тест восстановления.

HexaTransfer — не инструмент резервного копирования, он для разовых зашифрованных передач. Но те же принципы сквозного шифрования применяются при отправке архива бэкапа коллеге. Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.

От стратегии к дисциплине

Стратегия облачного резервного копирования живёт и умирает на дисциплине, а не на архитектуре. Ночные запуски, квартальные тесты восстановления, ежегодные ревью runbook, иммутабельное хранение и клиентское шифрование — не glamour-задачи, но именно они отличают «у нас был бэкап» от «мы смогли восстановиться». Запишите то, что делаете, автоматизируйте всё возможное, тестируйте то, что нельзя автоматизировать, и держите общую ежемесячную стоимость достаточно низкой, чтобы финансовый директор никогда не попросил её сократить. Дёшево плюс скучно бьёт дорого плюс умно каждый раз.