Velero 灾难恢复实战Schedules 计划备份与 Restore-Only 恢复模式详解【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/veleroVelero 支持通过周期性备份Schedule与服务器端的 Restore-Only仅恢复模式在集群遭遇服务中断、数据损坏等意外事故时将 Kubernetes 资源恢复到历史状态。本文以 site/content/docs/v0.11.0/disaster-case.md 的官方灾难恢复流程为主线结合仓库源码中restore-only标志的实际实现完整讲解从制定备份计划、切换到仅恢复模式到执行还原的端到端操作并说明该模式在 Velero 内部究竟禁用了哪些控制器、以及新版中该标志为何被标记为弃用。灾难恢复的核心思路先备份再恢复Velero 灾难恢复的前提是定期把集群资源备份到对象存储。只要备份一直在按计划生成当集群出现意外如服务大规模中断、误删除命名空间、配置被破坏时就能把集群倒回到某个历史备份对应的状态。官方给出的灾难恢复整体流程分为四步首次在集群上运行 Velero server 后创建一个每日备份计划Schedule灾难发生需要重建资源更新 Velero server 的 Deployment为server命令追加restore-onlytrue参数使恢复期间不会产生或删除任何 Backup 对象基于最近一次 Velero Backup 创建 Restore把资源还原回集群。下面逐步骤展开并补充源码层面的实现细节。步骤一通过 Schedule 建立周期性备份执行以下命令创建一个每日定时备份SCHEDULE NAME按需替换例如daily-backupvelero schedule create SCHEDULE NAME --schedule 0 7 * * *其中--schedule使用标准的 cron 表达式0 7 * * *表示每天 07:00 触发一次备份。Velero 的 Schedule 控制器会监听该计划对象并在每个触发时间点自动创建一个 Backup 对象其命名规则为SCHEDULE NAME-TIMESTAMP例如计划名为daily-backup则会生成类似daily-backup-20260107070000的 Backup 对象。之后每次查看备份时都应当选择时间戳最新的那个。从源码结构看velero schedule create属于 pkg/cmd/cli 下的 CLI 命令族它与手动执行velero backup create的区别在于手动备份是一次性动作而 Schedule 会让 schedule_controller.go 持续按 cron 节奏自动触发适合作为持续打点的灾难恢复底座。需要说明的是周期性备份保存的是 Kubernetes 资源对象以及通过卷快照/文件系统备份保存的持久卷数据具体卷数据的备份方式可参阅同版本文档 restic.md。步骤二灾难发生准备重建当灾难发生时集群中已有最近一次或多个备份可用。此时不要急于在故障集群上创建新的备份而是进入恢复流程把 Velero 服务器切换到只允许恢复的状态确保恢复期间没有任何后台控制器去新建或删除 Backup 对象避免恢复操作与备份控制器相互干扰。步骤三为 Velero server 启用 Restore-Only 模式编辑 Velero 服务器的 Deployment通常位于velero命名空间在server命令的 args 中加入--restore-onlytrue# velero Deployment 中 server 容器的命令片段 args: - server - --restore-onlytrue保存并应用后Velero server 会以仅恢复模式重新启动。Restore-Only 模式在源码中做了什么在 pkg/cmd/server/config/config.go 中定义了服务器配置项RestoreOnly对应的标志注册在 config.go--restore-only: Run in a mode where only restores are allowed; backups, schedules, and garbage-collection are all disabled. DEPRECATED: this flag will be removed in v2.0. Use read-only backup storage locations instead.真正起作用的逻辑位于 pkg/cmd/server/server.go当s.config.RestoreOnly为真时服务器启动日志会打印 Restore only mode - not starting the backup, schedule, delete-backup, or GC controllers并向禁用列表追加以下控制器ControllerBackup备份控制器ControllerBackupDeletion备份删除控制器ControllerBackupFinalizer备份 Finalizer 控制器ControllerBackupOperations备份操作控制器ControllerGarbageCollection垃圾回收控制器ControllerSchedule计划控制器随后这些控制器会从enabledRuntimeControllers映射中被移除从而不会被初始化启动见 server.go。也就是说Restore-Only 模式并不是把恢复功能之外的代码全部停掉而是精确地禁用了会产生或清理备份的那几条控制链路同时保留 Restore 控制器以及 BackupStorageLocation 等基础控制器正常工作保证 Restore 依然能读取对象存储中的备份数据。通过 install 命令直接部署仅恢复模式除了手工改 Deployment官方 CLI 也提供了对应的安装参数。在 pkg/cmd/cli/install/install.go 中注册了--restore-only: Run the server in restore-only mode. Optional.即可以在初始安装时就指定velero install --restore-onlytrue该值最终会被写入生成的 Deployment spec见 install.go 与 pkg/install/deployment.go效果与手动改 YAML 一致。对灾难恢复场景而言更常见的做法是先以普通模式运行并持续备份灾难发生后临时切换为仅恢复模式恢复完成后再按需切回。步骤四基于最近一次备份创建恢复在确认服务器已以仅恢复模式运行后用步骤一中记录的最新 Backup 名称执行velero restore create --from-backup SCHEDULE NAME-TIMESTAMP例如velero restore create --from-backup daily-backup-20260107070000该命令会读取对象存储中对应 Backup 的数据将资源重新创建到集群中。恢复完成后可以通过以下命令核验状态velero restore get velero restore describe RESTORE-NAME由于此时服务器处于 Restore-Only 模式恢复过程中不会触发新的备份、计划或垃圾回收数据源是稳定的只读快照整个还原过程更可控。配套机制备份从对象存储同步回集群灾难恢复场景中还有一个值得注意的细节如果你重建的是一个全新的集群那么对象存储里的备份并不会自动出现在新集群中。Velero 通过backup-sync-period机制周期性地把对象存储中的备份文件同步为集群内的 Backup API 对象。在 pkg/cmd/server/config/config.go 中定义了默认值defaultBackupSyncPeriod time.Minute即默认每 1 分钟同步一次config.go对应标志为--backup-sync-period: How often to ensure all Velero backups in object storage exist as Backup API objects in the cluster. (默认 1 分钟)因此在全新集群上执行恢复前通常先等待一个同步周期再通过velero backup get确认目标 Backup 已可见。同一主题的姊妹篇文档 migration-case.md集群迁移场景中详细演示了这一流程先velero backup create备份再在新集群启用--restore-only、确认BackupStorageLocation与VolumeSnapshotLocation指向同一存储桶等待velero backup describe能看到备份对象后执行恢复。注意事项与版本演进恢复期间不要创建新备份Restore-Only 模式的核心价值在于恢复过程中屏蔽掉备份创建/删除与 GC 控制器的副作用让对象存储中的备份集合保持稳定。该标志在新版本中已弃用从仓库源码可见--restore-only已标注 DEPRECATED: this flag will be removed in v2.0官方推荐的替代方案是使用只读的备份存储位置read-only backup storage locations。如果你使用较新版本的 Velero应优先查阅当前版本文档site/content/docs确认替代配置方式本文章节描述的是 v0.11.0 文档对应的行为。恢复前确认存储位置一致跨集群恢复时需保证新旧集群的BackupStorageLocation、VolumeSnapshotLocation指向同一个对象存储桶否则 Velero 无法读取备份。卷数据迁移限制Velero 不支持跨云厂商迁移持久卷涉及持久卷的跨环境恢复需结合快照或文件系统备份方案如 restic.md一并规划。总结Velero 的灾难恢复路径可以概括为Schedule 持续备份 → 灾难发生 → 启用 Restore-Only → 从最近备份恢复。其中restore-only标志通过在服务器启动阶段剔除 Backup、Schedule、GC 等控制器源码见 pkg/cmd/server/server.go为恢复操作提供了干净、稳定的数据环境。理解这一机制有助于你在真实故障场景中安全、快速地完成集群重建。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考