Справочная информация

Бэкап и снапшот #

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

Поведение бэкапа (Velero и платформа) #

• Селективный выбор — включающие или исключающие неймспейсы, типы ресурсов, лейблы; отдельные объекты можно пометить лейблом velero.io/exclude-from-backup=true (Backup Reference (v1.17)).
• Автоисключение CSI-снапшотов — начиная с Velero v1.17.0 (платформа 2.13.1) контроллер принудительно исключает volumesnapshots.snapshot.storage.k8s.io и volumesnapshotcontents.snapshot.storage.k8s.io из обычного сбора ресурсов. Подробности — shturval-backup.
• Неймспейс velero исключается автоматически.
• defaultVolumesToFsBackup — при значении по смыслу «да» тома подов копируются через file system backup (общая схема описана в File System Backup (v1.17)). При отключении для томов используются механизмы на уровне провайдера (CSI-снапшоты и т.д.), если они доступны в кластере. Для полного бэкапа кластера с томами рекомендуется отключать файловое копирование для всех томов, чтобы уменьшить риск ошибок при восстановлении.
• BackupRepository и kopia — при бэкапе с PV в объектном хранилище создаётся структура с данными бэкапа и каталог kopia. Репозитории в kopia привязаны к неймспейсам с бэкапируемыми PV, а не к отдельным объектам Backup. В неймспейсе velero создаются ресурсы BackupRepository (в т.ч. с префиксом имени неймспейса).
• Удаление бэкапа — удаление только CR Backup в Kubernetes не убирает данные из хранилища; для полного удаления данных из object/block storage используется velero backup delete (Backup Reference (v1.17)). Удаление CR не удаляет репозитории kopia сразу; фактическая очистка выполняется процедурами maintenance (частота quick для репозитория настраивается на ресурсе BackupRepository, например поле maintenanceFrequency (по умолчанию 1 час); full — автоматически; полное удаление «следов» может занимать до порядка недели после удаления бэкапа). Логи maintenance смотрят в ресурсах Job неймспейса velero (хранятся последние несколько job).
• Объектное хранилище с immutability — режимы неизменяемости объектов у разных провайдеров мешают обновлять метаданные бэкапа в хранилище; поведение зависит от типа политики и провайдера (Backup Reference (v1.17)).

Поведение restore #

• Асинхронность — статус в Restore.
• Политика существующих ресурсов — none (не перезаписывать) или update (обновлять при конфликте), см. страницу restore.
• PV в использовании — тома, смонтированные в работающие поды, не восстанавливаются (Deployment, StatefulSet, Pod).
• Порядок — ресурсы восстанавливаются в порядке, рассчитанном Velero с учётом зависимостей (Restore Reference (v1.17)).
• Ресурсы вне бэкапа не затрагиваются.

Рекомендации #

1. Подключить S3-совместимое хранилище до первых бэкапов.
2. Для регулярных копий использовать Schedule (cron).
3. Разделять бэкапы по назначению (критичные неймспейсы, «полный» кластер, DR).
4. Для полного бэкапа кластера с PV — отключить defaultVolumesToFsBackup для соответствующих бэкапов.
5. Задавать TTL, исходя из ёмкости хранилища и политики хранения.
6. Периодически проверять restore на тестовом кластере или в тестовом неймспейсе.
7. Не удалять каталоги данных бэкапа (restic/kopia) в объектном хранилище вручную без согласованного удаления BackupRepository — иначе возможны ошибки вроде Error checking repository for stale locks.
8. Для подов с hostPath при необходимости задать аннотацию backup.velero.io/backup-volumes-excludes со списком имён volume.
9. Сценарии восстановления кластера управления — см. Восстановление кластера.

Документация Velero v1.17 #

Справочник по CLI, полям CRD и ограничениям: Velero v1.17 Docs.