Резервное копирование под управлением платформы при использовании Cozystack

Резервное копирование — ответственность каждого, и слишком часто — ничья работа. На мультитенантной платформе проблема острее: арендаторы хотят защищать собственные базы данных и виртуальные машины, но им не стоит передавать S3-учётные данные или просить самостоятельно настраивать хранилище. Cozystack закрывает этот пробел с помощью резервного копирования под управлением платформы — чёткого API, где арендаторы объявляют что защищать, а платформа берёт на себя где и как.

Модель за одну минуту

Есть пять объектов, чётко разделённых между двумя аудиториями.

Для арендаторов:

  • BackupJob — разовое резервное копирование.
  • Plan — резервное копирование по расписанию (cron).
  • Backup — представляет артефакт, созданный BackupJob.
  • RestoreJob — восстанавливает резервную копию в целевое приложение.
Диаграмма пяти объектов backup API и их взаимосвязей

Для администраторов:

  • BackupClass — связывает Kind приложения со стратегией резервного копирования и хранилищем, а также настраивает нужные параметры.

Арендаторы ссылаются на BackupClass по имени и никогда не видят S3-эндпоинты, учётные данные, пути или базовые ресурсы — они доступны только администраторам кластера. Платформа выполняет резервное копирование управляемым способом и гарантирует надёжность и стабильность.

Cozystack поставляется с предустановленным классом cozy-default и бакетом хранилища cozy-backups — никакой настройки для старта не требуется.

Объект BackupClass, показывающий управляемую администратором привязку между Kind приложения, стратегией и хранилищем

Для арендаторов: резервное копирование и восстановление приложений

BackupClass cozy-default предоставляется автоматически и уже охватывает Postgres, MariaDB, ClickHouse, Etcd и виртуальные машины KubeVirt (VMInstance, VMDisk). Вам нужно лишь выбрать своё приложение — никакой настройки или подготовки хранилища не требуется.

Панель управления Cozystack с формой создания BackupJob для приложения Postgres
Статус BackupJob с фазой Succeeded и деталями артефакта резервной копии

Рекомендуем начать с разового BackupJob, чтобы проверить корректную работу перед настройкой планового расписания.

apiVersion: backups.cozystack.io/v1alpha1
kind: BackupJob
metadata:
  name: oneshot-mariadb
  namespace: tenant-user1
spec:
  applicationRef:
    apiGroup: apps.cozystack.io
    kind: MariaDB
    name: mariadbinstance
  backupClassName: cozy-default

Используйте Plan для регулярного резервного копирования:

Панель управления Cozystack с формой создания Plan и настройкой расписания cron
Список Plan с активными плановыми заданиями резервного копирования и статусом последнего запуска
apiVersion: backups.cozystack.io/v1alpha1
kind: Plan
metadata:
  name: maria-nightly-backups
  namespace: tenant-user1
spec:
  applicationRef:
    apiGroup: apps.cozystack.io
    kind: MariaDB
    name: mariadbinstance
  backupClassName: cozy-default
  schedule:
    type: cron
    cron: "0 2 * * *"  # в 02:00

Когда BackupJob достигает состояния phase: Succeeded, можно выполнить восстановление из него:

Форма создания RestoreJob с настроенной исходной резервной копией и целевым приложением

Восстановление бывает двух видов. RestoreJob либо воспроизводит данные в то же приложение (на месте — быстрый откат, но деструктивный), либо в новую подготовленную копию того же Kind (в копию — безопасно для учений по аварийному восстановлению и валидации). Выбор определяется тем, задаёте ли вы targetApplicationRef.

Для администраторов кластера: настройки по умолчанию, тонкая настройка и подключение

Для большинства платформ cozy-default поставляется готовым к работе, и арендаторы могут сразу приступать к резервному копированию без какой-либо настройки.

Манифест BackupClass с настройкой стратегии, привязки хранилища и конфигурацией хранения

Создайте собственный BackupClass, если нужно:

  • настроить срок хранения для конкретного приложения или арендатора;
  • включить новый Kind, не охваченный по умолчанию;
  • использовать выделенный бакет — раздельное хранилище для упрощённого обслуживания.

Идём дальше: пользовательские стратегии

API резервного копирования расширяемо. Если нужного драйвера ещё не существует, есть два пути:

  • Без кода: универсальная стратегия на основе Job. Переиспользуйте обычный Kubernetes Job в качестве механизма резервного копирования — полезно для нестандартных или самоуправляемых рабочих нагрузок. Смотрите пример с NATS.
  • Пользовательский контроллер стратегии, созданный на основе backups API и встроенный в Cozystack, для полноценного управления жизненным циклом.

Узнать больше

Присоединяйтесь к сообществу