Настройка бэкапирования Kubernetes через Velero — опыт и сроки

Настройка бэкапирования Kubernetes через Velero — опыт и сроки

Потеря данных в StatefulSet после неудачного деплоя — стандартная ситуация в боевых кластерах. Без бэкапа на уровне namespace восстановление занимает часы: пересоздавать StatefulSet, искать последний снапшот etcd, поднимать PV вручную. Мы сталкивались с этим десятки раз и знаем, как избежать таких сценариев. Velero закрывает этот gap: namespace-level и resource-level backup с поддержкой PV через CSI snapshot или Kopia (бывший Restic). При тестовом restore в изолированном namespace данные восстанавливаются за 5–15 минут — это в 10 раз быстрее ручного поднятия, которое занимает 2–3 часа.

Почему Velero лучше etcd-снапшотов?

etcd хранит состояние кластера, но восстановление из него — это возврат всего кластера целиком. Если нужно откатить один namespace или один PersistentVolume после ошибочного деплоя — etcd не подойдёт. Velero даёт гранулярность на уровне ресурсов и поддерживает гибкие политики хранения.

Кроме того, Velero интегрируется с облачными объектными хранилищами (S3, GCS, Azure Blob), что позволяет хранить бэкапы в другом регионе или аккаунте — ключевой элемент disaster recovery. По нашим замерам, время восстановления отдельного приложения снижается в 10 раз по сравнению с ручным процессом. При типичном кластере с 100 PVC и 50 workloads полный бэкап занимает около 20 минут.

Как избежать типичных ошибок при настройке Velero?

Первая проблема: CSI-драйвер без поддержки VolumeSnapshot API. Если такой драйвер не зарегистрировал VolumeSnapshotClass, Velero молча пропустит данные томов. В логах — Included Volumes: 0. Решение: включите Node Agent (Kopia) для файлового бэкапа или добавьте аннотацию velero.io/csi-volumesnapshot-class к PVC.

Вторая ошибка — IAM-политика для object storage без прав на запись объектов. На AWS типично: у service account есть доступ к bucket, но не к пути /*. Бэкап метаданных проходит, а данные нет. Ошибка в логах: AccessDenied на s3:PutObject для backups/*. Исправляется добавлением отдельного statement на arn:aws:s3:::velero-bucket/*.

Третья — restore в кластер с другим StorageClass. Velero не переименует StorageClass автоматически. Нужен --namespace-mappings или ConfigMap с resource modifier для маппинга имён. Без этого PVC зависнут в Pending.

Правильная архитектура бэкапа

Для production-кластера схема выглядит так: Object storage: отдельный S3-bucket (или GCS/Azure Blob) в другом регионе или аккаунте. Политика бэкапов: два расписания через Schedule CR:

• Ежедневный полный бэкап всего кластера с TTL 30 дней
• Почасовой бэкап критичных namespace'ов (базы данных, stateful workloads) с TTL 7 дней

---
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: hourly-databases
  namespace: velero
spec:
  schedule: "0 * * * *"
  template:
    includedNamespaces:
      - postgres
      - redis
    storageLocation: default
    volumeSnapshotLocations:
      - default
    ttl: 168h0m0s
---