Backup: что действительно бэкапится, а что нет

Что нужно знать перед уроком

M10 урок 7 — типы StorageClass. M6 урок 7 — reclaimPolicy: Retain. Этот урок — одно из ключевых архитектурных разграничений курса: что защищает d8 backup etcd, а что остаётся полностью ответственностью разработчика Application.

Теория

d8 backup etcd — бэкапит объекты кластера, а НЕ данные внутри PVC

1

d8 backup etcd etcd-backup.snapshot

Ключевое, часто неверно понимаемое разграничение курса: d8 backup etcd создаёт снапшот etcd — распределённого хранилища ключ-значение, в котором Kubernetes хранит описания объектов (манифесты Deployment, Service, ConfigMap, PersistentVolumeClaim как объект метаданных, Application, и так далее). Снапшот etcd восстанавливает конфигурацию кластера — какие объекты существовали, с какими параметрами. Он не содержит и не восстанавливает содержимое файлов внутри PersistentVolume, на которые ссылаются PersistentVolumeClaim — реальные данные приложения (файлы БД, загруженные пользователями файлы) физически хранятся вне etcd, на подключённых томах, и снапшот etcd их не затрагивает вообще.

Внутренний механизм автоматического бэкапа etcd иллюстрирует именно это разграничение:

1
2
3

etcdctl snapshot save etcd-backup.snapshot
tar -czvf etcd-backup.tar.gz etcd-backup.snapshot
mv etcd-backup.tar.gz /var/lib/etcd/etcd-backup.tar.gz

Это операция исключительно над данными etcd — никакого взаимодействия с содержимым PVC приложений в этом процессе нет.

Backup данных Application — ответственность разработчика

Поскольку d8 backup etcd не покрывает данные внутри PVC, разработчик Application должен спроектировать собственную стратегию защиты данных из следующих составляющих:

Volume snapshot через CSI-драйвер:

1
2
3
4
5
6
7
8

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: {{.Application.Instance.Name}}-snapshot
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: {{.Application.Instance.Name}}-data

Восстановление из снапшота — созданием нового PVC со ссылкой на существующий VolumeSnapshot:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-pvc
spec:
  dataSource:
    name: {{.Application.Instance.Name}}-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  storageClassName: <storage-class-name>
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Важная оговорка: не все CSI-драйверы поддерживают восстановление из снапшота — это нужно явно проверить для конкретного StorageClass, используемого в целевом кластере, прежде чем полагаться на этот механизм как на часть стратегии backup.

VolumeGroupSnapshot — расширение того же механизма для приложений с несколькими PVC, данные в которых логически связаны (например, БД с отдельными томами под данные и WAL/журнал) и должны попасть в снапшот одновременно, в согласованный (crash-consistent) момент времени — снимать каждый PVC отдельным VolumeSnapshot в таком случае недостаточно, т. к. между двумя последовательными снапшотами данные могут разойтись. VolumeGroupSnapshot graduated в GA (stable) в Kubernetes 1.36, после нескольких циклов в beta — при использовании нескольких взаимосвязанных томов стоит проверить, поддерживает ли CSI-драйвер именно групповые снапшоты, а не только одиночные.

Периодический дамп БД как CronJob (M1 урок 10) — для приложений с базой данных дополнительная, часто более гранулярная и переносимая стратегия — регулярный логический дамп (pg_dump, mysqldump) в отдельное, независимое от исходного хранилище (объектное хранилище S3-совместимого типа), не привязанная к конкретному CSI-драйверу и переносимая между разными инфраструктурами.

reclaimPolicy: Retain (M6 урок 7) — последняя линия защиты, а не полноценная backup-стратегия: она предотвращает немедленную потерю данных при случайном удалении PersistentVolumeClaim, но не создаёт восстанавливаемую точку в прошлом (нет версионирования, нет возможности откатиться на состояние данных недельной давности).

Disaster Recovery Plan — «бэкап проверен восстановлением», а не просто «есть бэкап»

Ключевой практический принцип: наличие настроенного механизма создания резервных копий — необходимое, но недостаточное условие реальной защищённости данных. План аварийного восстановления (Disaster Recovery Plan) обязательной практикой включает: (а) регулярную, не одноразовую проверку того, что снапшоты/дампы вообще создаются успешно (мониторинг статуса backup-джобов, а не только их наличие в конфигурации); (б) периодическое, реальное тестирование восстановления из резервной копии в изолированное тестовое окружение — многие организации обнаруживают, что их backup нерабочий (повреждён, неполон, несовместим с текущей версией приложения) только в момент реальной аварии, когда проверять уже поздно.

Частые ошибки и подводные камни

• Полагать, что d8 backup etcd защищает данные внутри PVC. Это самое частое и самое опасное заблуждение этого урока — etcd-бэкап восстанавливает только конфигурацию кластера, не содержимое файлов приложения.
• Настроить backup, но никогда не проверять его реальным восстановлением. «Бэкап, который никогда не тестировался восстановлением» с практической точки зрения неотличим от отсутствия бэкапа вообще — до момента реальной аварии.
• Полагаться только на reclaimPolicy: Retain как на полноценную backup-стратегию. Это защита от одного конкретного класса рисков (случайное удаление PVC) без версионирования и без защиты от повреждения данных на уровне файловой системы/СУБД.
• Не проверять поддержку восстановления из снапшота конкретным CSI-драйвером заранее. Обнаружение того, что CSI-драйвер не поддерживает восстановление, в момент реальной необходимости восстановления — критическая, но полностью предотвратимая ошибка планирования.

Практика в кластере

1
2

d8 k get volumesnapshotclass
d8 k get cronjob -n course-m10-umami

Проверьте наличие VolumeSnapshotClass в практическом кластере, и, если она есть, выполните полный цикл: создать снапшот PVC пакета Umami, удалить исходные данные (в тестовом сценарии), восстановить из снапшота, убедиться в целостности данных.

Практика разработки

Добавьте в пакет Umami CronJob для периодического логического дампа базы данных в S3-совместимое объектное хранилище, и задокументируйте (в docs/) полный Disaster Recovery Plan пакета: что бэкапится, с какой периодичностью, как проверяется работоспособность бэкапа, как выполняется восстановление.

Шпаргалка команд урока

1
2

d8 backup etcd etcd-backup.snapshot
d8 k get volumesnapshot,volumesnapshotclass -A

Вопросы для самопроверки

Рекомендуемая литература

Официальная документация

• Deckhouse — Backup и restore
• Deckhouse — Snapshot Controller
• kubernetes.io — Kubernetes v1.36: Haru (VolumeGroupSnapshot — GA, KEP-3476).

Статьи и блоги

• Deckhouse Prom++: оптимизация Prometheus — Flant на Habr.
• Deckhouse Prom++: как мы посадили Prometheus на RAM-диету — Flant на Habr.
• Kubernetes на базе Deckhouse: встроенный мониторинг и логирование — обзор возможностей DKP на Habr.

Книги

• Brendan Burns, David Oppenheimer. Designing Distributed Systems. 2018. ISBN 978-1491983645.
• Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.

Связанные материалы

• Предыдущий урок: M10.07 — Storage и данные.
• Следующий урок: M10.09 — Security для Application.

✓ Урок пройден — все вопросы самопроверки отвечены верно