Модуль резервного копирования и восстановления (shturval-backup)

О сервисе #

При выборе сервиса на шаге создания кластера зависимые сервисы подключаются автоматически.

Назначение #

shturval-backup разворачивает Velero в кластере: объекты Backup, Schedule, Restore, хранилище бэкапов в S3-совместимом backend и (при необходимости) механизмы копирования томов.

Пользовательские сценарии — подключение хранилища, создание бэкапов, restore, траблшутинг — собраны в разделе Резервное копирование в кластере.

Установка сервиса #

Сервис состоит из двух чартов: shturval-backup-crds с CRD Velero и основного чарта shturval-backup.

При ручной установке из Доступных чартов сначала установите shturval-backup-crds и дождитесь статуса готовности сервиса на странице Установленные сервисы. После этого установите основной чарт shturval-backup. Если установить основной чарт до готовности CRD, Kubernetes не сможет создать кастомные ресурсы Velero.

Где управлять сервисом #

Сервисы и репозитории → Установленные сервисы → shturval-backup → Управлять. Режим Авто включает автоматическое применение манифестов сервиса (обзор).

Если чарт не установлен, его можно поставить из Доступных чартов (чарт shturval-backup), см. как развернуть новый сервис. При необходимости переопределения параметров чарта, примените изменения через ShturvalServicePatch.

Период удаления бэкапов после истечения TTL #

Удаление объектов бэкапа из хранилища после истечения TTL по умолчанию выполняется в пределах 1 часа. Период задаётся через defaultRepoMaintainFrequency в ShturvalServicePatch для shturval-backup.

apiVersion: ops.shturval.tech/v1beta2
kind: ShturvalServicePatch
metadata:
  name: <имя ресурса>
spec:
  shturvalServiceConfigName: shturval-backup
  customvalues:
    configuration:
       defaultRepoMaintainFrequency: "<ваше значение параметра>"

Начиная с Velero 1.16 частоту quick maintenance для конкретного репозитория можно уточнять на ресурсе BackupRepository (поле вроде maintenanceFrequency, по умолчанию 1 час), см. также Backup Repository Configuration (v1.17).

Автоматическое исключение промежуточных CSI-ресурсов #

Начиная с Velero v1.17.0 (в платформе — с релиза 2.13.1) контроллер автоматически исключает из сбора ресурсов Kubernetes объекты CSI-снэпшотов:

• volumesnapshots.snapshot.storage.k8s.io — неймспейсный ресурс VolumeSnapshot;
• volumesnapshotcontents.snapshot.storage.k8s.io — кластерный ресурс VolumeSnapshotContent.

Эти объекты считаются промежуточными CSI-ресурсами, а также среди них могут быть старые или созданные другим резервным копированием. Velero не собирает все существующие в кластере VolumeSnapshot и VolumeSnapshotContent обычным resource collection: в обработку попадают только объекты, относящиеся к текущему backup flow.

Отображение в манифесте резервного копирования #

После создания резервной копии в YAML-манифесте Backup вы увидите, даже если указывали ресурсы только в included:

excludedClusterScopedResources:
  - volumesnapshotcontents.snapshot.storage.k8s.io
excludedNamespaceScopedResources:
  - volumesnapshots.snapshot.storage.k8s.io

Типовые сообщения об ошибках #

Кратко (подробности и команды — траблшутинг):

Error checking repository for stale locks #

Данные в бакете (restic/kopia) удалены или не согласованы с BackupRepository в кластере. Не удаляйте каталоги репозитория вручную без удаления соответствующих CR.

error checking if volume is a hostPath volume #

Tom hostPath не участвует в file system backup; сообщение не останавливает весь процесс. При необходимости задайте backup.velero.io/backup-volumes-excludes.

pod volume backup failed: getting pod trivy-system/scan-vulnerabilityreport-* #

Краткоживущий под сканера; при гонке с бэкапом сообщение допустимо.