Снимки EBS и резервное копирование в AWS

Быстрые ссылки

• «Fault-Tolerant» не значит безопасно
• Как работают снимки EBS?

«Fault-Tolerant» не значит безопасно

EBS — это блочное хранилище от AWS, используемое как диск для EC2-инстансов. На уровне реализации AWS предусмотрела устойчивость к отказам аппаратуры: одиночный сбой диска обычно не приводит к потере тома. Тем не менее сбои EBS случаются — в исходном материале указывалась оценка годового уровня отказов (AFR) для томов EBS в диапазоне 0.1–0.2%. Это гораздо лучше, чем у одного физического диска, но всё равно означает вероятность отказа при большом количестве томов.

Избежать потерь помогает регулярное резервное копирование. Снимки EBS (snapshots) являются удобным инструментом: они хранятся в S3 и более надёжны. AWS рекомендует регулярно создавать снимки; для автоматизации можно использовать EBS Lifecycle Manager (он не включён по умолчанию). Хранение снимков в S3 увеличит ваши затраты на хранение, но обычно это дешевле, чем держать массивы EBS как основной источник защиты.

Крайний пример риска — инцидент в США (us-east-1) в сентябре 2019 года: сбои питания и проблемы с генераторами привели к повреждению EBS-инфраструктуры и потере данных у некоторых клиентов. Такие события подчёркивают, что архитектура высокой доступности должна учитывать локальные отказы и предусматривать восстановление из резервных копий.

S3 обеспечивает очень высокую долговечность — 99.999999999% (11 девяток). На практике это означает, что при хранении миллионов объектов вероятность утраты одного объекта ожидается очень редко. S3 реплицирует данные по как минимум трём зонам доступности и постоянно проверяет состояния носителей.

Важно: высокая отказоустойчивость инфраструктуры не заменяет стратегию резервного копирования. Резервные копии — это страховой полис против аппаратных сбоев, человеческих ошибок и регрессионных изменений.

Как работают снимки EBS

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

Короткая последовательность действий для включения автоматизированных снимков:

1. В консоли EC2 откройте «Elastic Block Store» → «Lifecycle Manager». Создайте новую политику.
2. Укажите тег, к которому будет привязана политика. Это может быть тег конкретного тома или общий тег для группы томов.

3. Конфигурируйте расписание создания снимков и правила хранения (retention). Оставляйте столько снимков, сколько требуется для ваших RPO/RTO и соответствия.

4. При необходимости включите Fast Snapshot Restore (FSR) для мгновенного восстановления томов из снимка — но учтите повышенные затраты.

Что именно хранится и как восстановить

• Снимок хранит данные блоков тома и метаданные; при восстановлении вы создаёте новый том из снимка и подключаете его к инстансу.
• Поскольку снимки инкрементные, удаление более старого снимка может быть оптимизировано AWS так, чтобы не нарушить целостность цепочки данных; однако планирование политики хранения должно учитывать зависимости между снимками.

Рекомендации по стратегии снимков (мини‑методология)

1. Определите RPO (допустимая потеря данных) и RTO (приемлемое время восстановления).
2. Назначьте теги на тома: приложение, окружение (prod/staging/dev), владелец, SLA.
3. Создайте политики Lifecycle Manager по тегам с расписанием и retention на основе RPO/RTO.
4. Тестируйте восстановление раз в цикл (например, ежеквартально) и документируйте шаги.
5. Оптимизируйте хранение: сочетайте частые инкрементные снимки с периодическими полными образами при необходимости.

Пример простой политики для продакшена: ежедневный снимок, хранение 14 дней + еженедельный снимок с хранением 90 дней.

Контрольный список по ролям

• DevOps / SRE:
  • Настроить Lifecycle Manager и теги.
  • Мониторить выполнение политик и ошибки создания снимков.
  • Регулярно тестировать восстановление.
• Разработчики:
  • Убедиться, что приложения корректно работают после восстановления томов.
  • Спланировать миграции схем/миграций БД с учётом точек восстановления.
• Владельцы данных / Compliance:
  • Установить требования по удержанию данных и шифрованию.
  • Проверять соответствие политик требованиям GDPR/регионального законодательства.

Фактбокс: ключевые числа и понятия

• AFR для EBS: около 0.1–0.2% (источник: исходный материал). Это вероятность отказа тома в год для большого пула томов.
• Долговечность S3: 99.999999999% (11 девяток).
• Снимки EBS — инкрементные: последующие снимки сохраняют только изменённые блоки.
• Fast Snapshot Restore уменьшает RTO, но повышает расходы.

Когда стратегия снимков может не сработать

• Если у вас нет политики хранения; люди удаляют теги — автоматизация не применяется.
• Если snapshots созданы, но не протестированы: возможны ошибки при восстановлении из-за несовместимости конфигураций.
• Если критичен непрерывный RPO в секундах/милисекундах — снимки EBS не заменят репликацию в реальном времени (например, асинхронную репликацию БД или кластеризацию).

Безопасность и соответствие

• Шифруйте тома и снимки (EBS поддерживает шифрование с AWS KMS). Это важно для хранения персональных данных и соблюдения GDPR.
• Контролируйте доступ к созданию/восстановлению снимков через IAM-политики.
• Логи аудита (CloudTrail) помогают отследить кто и когда делал снимки/восстановления.

Основной сценарий включения Lifecycle Manager — пошагово

1. Консоль EC2 → Elastic Block Store → Lifecycle Manager.
2. Создать политику: выбрать тип ресурса — EBS Snapshot.
3. Указать теги, к которым применять политику.
4. Настроить расписание: частота, время создания, временную зону.
5. Настроить правила хранения: сколько снимков хранить, политики удаления.
6. Включить дополнительные опции: шифрование, Fast Snapshot Restore (по необходимости).
7. Сохранить и проверить выполнение в первые сутки.

Дерево решений для выбора политики снимков (Mermaid)

flowchart TD
  A[Есть требование RPO/RTO?] -->|Нет| B[Определить RPO/RTO]
  A -->|Да| C[Нужна непрерывная репликация?]
  C -->|Да| D[Использовать реплику/кластер + слепления]
  C -->|Нет| E[Использовать EBS snapshots]
  E --> F{RTO критичен?}
  F -->|Да| G[Включить Fast Snapshot Restore]
  F -->|Нет| H[Стандартные инкрементные снимки + тест]
  G --> I[Оценить стоимость]
  I --> H

Критерии приёмки

• Политики Lifecycle Manager созданы и применяются к помеченным томам.
• Созданный снимок восстанавливается в тестовом окружении и данные целы.
• Время восстановления укладывается в допустимый RTO.
• Политика хранения не приводит к чрезмерным затратам и соответствует требованиям соответствия.

Тесты и приёмо‑сдаточные случаи

• Создать тестовую политику с частыми снимками, выполнить восстановление тома и проверить целостность данных.
• Смоделировать удаление тега и убедиться, что политика не применится к неотмеченным томам.
• Включить Fast Snapshot Restore для одного снимка и измерить время создания тома и его инициализации.

Советы по оптимизации затрат

• Инкрементные снимки экономят место; поддерживайте разумный retention.
• Удаляйте старые снапшоты, которые не потребуются для восстановления.
• Включайте FSR только для тех снимков, где время восстановления важнее стоимости.

Заключение

Снимки EBS — простой и мощный инструмент для защиты данных EC2. Они не решают все задачи: для минимального RPO потребуется репликация или архитектурные изменения, а для соответствия требованиям — шифрование и аудит. Автоматизация создания снимков через Lifecycle Manager и регулярное тестовое восстановление — основные практики, которые снижают риск потерь данных и уменьшают время простоя.

Важно: планируйте политику резервного копирования, тестируйте восстановление, управляйте доступом и контролируйте расходы.

Важно: регулярно проверяйте и обновляйте политику резервного копирования при изменении архитектуры или требований.