云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载本指南基于 Longhorn 仓库中的增强设计文档 enhancements/20210525-async-pull-backups.md讲解 Longhorn 如何将与远程备份目标S3/NFS的同步阻塞式通信重构为异步拉取 集群 CRD 缓存的最终一致模型。你将掌握三个核心 CRDBackupTarget、BackupVolume、Backup的字段语义、backup命令行list / inspect-volume / head的职责拆分、四个控制器setting / backup_target / backup_volume / backup的协作循环以及相关 HTTP API 的前后行为变化可用于排查或二次开发 Longhorn 备份链路。背景与问题阻塞式通信带来的备份列表超时在 Longhorn 引入异步拉取机制之前Longhorn manager 与远程备份目标S3/NFS之间的通信是阻塞式的列出备份卷、列出备份等操作需要实时访问远端备份目标并读取其配置文件volume.cfg、backup_backup_backup-hash.cfg。这种设计在以下场景会产生明显的可靠性问题远程备份目标中积累了大量备份卷或备份Longhorn 集群与远程备份目标之间的网络延迟较高例如跨地域 S3备份目标操作引发的级联故障如 NFS 短暂不可用会影响依赖远程备份目标的功能。其中最直接的痛点是当用户在 Longhorn GUI 上点击Backup页面时列表请求的默认超时时间为1 分钟。若备份目标数据量大或延迟高用户会直接遭遇列表超时。设计文档特别说明之所以不提供增大列表超时时间的设置项是因为浏览器本身也有超时限制例如 Google Chrome 不允许用户修改默认超时值——即使 Longhorn manager 侧放宽超时浏览器侧依然会中断请求因此从架构上消除同步阻塞才是正解。该设计对应的原始问题包括 issue #1761、#1955、#2536、#2543最终在 Longhorn 1.4 及后续版本中落地CHANGELOG 中亦有相关后续修复记录例如 CHANGELOG/CHANGELOG-1.4.0.md 中关于无法从远程备份目标拉取由另一 Longhorn 系统创建的备份#4637的修复即属于该机制落地后的边界问题。目标与边界Goals / Non-goals目标降低列出备份卷或列出备份时的查询延迟覆盖三种典型场景——备份卷数量庞大、备份数量庞大、集群到远程备份目标的网络延迟高。非目标明确不做的事不自动调整备份目标轮询间隔不支持多个备份目标后续由独立的增强 enhancements/20240926-multiple-backup-targets-support.md 演进不支持备份卷/备份列表的 API 分页。总体方案异步拉取并把结果持久化为集群 CR核心思路是同步阻塞查询 → 后台轮询同步 CRD 缓存后台按轮询间隔异步查询远程备份目标将备份卷、备份的元数据以 Kubernetes 自定义资源CR的形式持久化保存到集群内用户的列表请求不再直连远程备份目标而是读取集群内的 CR集群内 CR 与远程备份目标之间通过spec.syncRequestAt/status.lastSyncedAt的时间戳比较驱动增量同步实现最终一致删除操作同样异步化HTTP 端点只负责打标/删除 CR由控制器在后台真正删除远端备份数据。方案的五个组成部分修改longhorn/backupstore的list命令行为新增inspect-volume与head命令把列名与读配置分离新增BackupTargetCRD保存备份目标 URL、凭证 Secret、轮询间隔新增BackupVolumeCRD保存备份卷配置新增BackupCRD保存单个备份配置改造既有setting_controller并新增backup_target_controller、backup_volume_controller、backup_controller三个控制器备份卷/备份相关的 HTTP 端点改为与 CR 交互不再直连远端。backupstore 命令行改造把 list、read、head 彻底分离原设计中backup ls在列出的同时会读取配置这正是一次列出大量备份时延迟高的根源。改造后三条命令职责分明改造前阻塞式 读取配置backup ls --volume-only列出所有备份卷并读取其配置volume.cfg$ backup ls s3://backupbucketminio/ --volume-only { pvc-004d8edb-3a8c-4596-a659-3d00122d3f07: { Name: pvc-004d8edb-3a8c-4596-a659-3d00122d3f07, Size: 2147483648, Labels: {}, Created: 2021-05-12T00:52:01Z, LastBackupName: backup-c5f548b7e86b4b56, LastBackupAt: 2021-05-17T05:31:01Z, DataStored: 121634816, Messages: {} }, pvc-7a8ded68-862d-4abb-a08c-8cf9664dab10: { Name: pvc-7a8ded68-862d-4abb-a08c-8cf9664dab10, Size: 10737418240, Labels: {}, Created: 2021-05-10T02:43:02Z, LastBackupName: backup-432f4d6afa31481f, LastBackupAt: 2021-05-10T06:04:02Z, DataStored: 140509184, Messages: {} } }backup ls --volume volume-name列出指定卷下所有备份并读取每个备份的配置$ backup ls s3://backupbucketminio/ --volume pvc-004d8edb-3a8c-4596-a659-3d00122d3f07 { pvc-004d8edb-3a8c-4596-a659-3d00122d3f07: { Name: pvc-004d8edb-3a8c-4596-a659-3d00122d3f07, Size: 2147483648, Labels: {}, Created: 2021-05-12T00:52:01Z, LastBackupName: backup-c5f548b7e86b4b56, LastBackupAt: 2021-05-17T05:31:01Z, DataStored: 121634816, Messages: {}, Backups: { s3://backupbucketminio/?backupbackup-02224cb26b794e73volumepvc-004d8edb-3a8c-4596-a659-3d00122d3f07: { Name: backup-02224cb26b794e73, URL: s3://backupbucketminio/?backupbackup-02224cb26b794e73volumepvc-004d8edb-3a8c-4596-a659-3d00122d3f07, SnapshotName: backup-23c4fd9a, SnapshotCreated: 2021-05-17T05:23:01Z, Created: 2021-05-17T05:23:04Z, Size: 115343360, Labels: {}, IsIncremental: true, Messages: null }, ... s3://backupbucketminio/?backupbackup-fa78d89827664840volumepvc-004d8edb-3a8c-4596-a659-3d00122d3f07: { Name: backup-fa78d89827664840, URL: s3://backupbucketminio/?backupbackup-fa78d89827664840volumepvc-004d8edb-3a8c-4596-a659-3d00122d3f07, SnapshotName: backup-ac364071, SnapshotCreated: 2021-05-17T04:42:01Z, Created: 2021-05-17T04:42:03Z, Size: 115343360, Labels: {}, IsIncremental: true, Messages: null } } } }backup inspect backup读取单个备份配置backup_backup_backup-hash.cfg$ backup inspect s3://backupbucketminio/?backupbackup-fa78d89827664840volumepvc-004d8edb-3a8c-4596-a659-3d00122d3f07 { Name: backup-fa78d89827664840, URL: s3://backupbucketminio/?backupbackup-fa78d89827664840volumepvc-004d8edb-3a8c-4596-a659-3d00122d3f07, SnapshotName: backup-ac364071, SnapshotCreated: 2021-05-17T04:42:01Z, Created: 2021-05-17T04:42:03Z, Size: 115343360, Labels: {}, IsIncremental: true, VolumeName: pvc-004d8edb-3a8c-4596-a659-3d00122d3f07, VolumeSize: 2147483648, VolumeCreated: 2021-05-12T00:52:01Z, Messages: null }改造后只列名配置单独读取backup ls --volume-only仅列出备份卷名$ backup ls s3://backupbucketminio/ --volume-only { pvc-004d8edb-3a8c-4596-a659-3d00122d3f07: {}, pvc-7a8ded68-862d-4abb-a08c-8cf9664dab10: {} }backup ls --volume volume-name仅列出备份名$ backup ls s3://backupbucketminio/ --volume pvc-004d8edb-3a8c-4596-a659-3d00122d3f07 { pvc-004d8edb-3a8c-4596-a659-3d00122d3f07: { Backups: { backup-02224cb26b794e73: {}, ... backup-fa78d89827664840: {} } } }backup inspect-volume volume读取单个备份卷配置volume.cfg$ backup inspect-volume s3://backupbucketminio/?volumepvc-004d8edb-3a8c-4596-a659-3d00122d3f07 { Name: pvc-004d8edb-3a8c-4596-a659-3d00122d3f07, Size: 2147483648, Labels: {}, Created: 2021-05-12T00:52:01Z, LastBackupName: backup-c5f548b7e86b4b56, LastBackupAt: 2021-05-17T05:31:01Z, DataStored: 121634816, Messages: {} }backup inspect backup语义不变仍读取单个备份配置$ backup inspect s3://backupbucketminio/?backupbackup-fa78d89827664840volumepvc-004d8edb-3a8c-4596-a659-3d00122d3f07 { Name: backup-fa78d89827664840, URL: s3://backupbucketminio/?backupbackup-fa78d89827664840volumepvc-004d8edb-3a8c-4596-a659-3d00122d3f07, SnapshotName: backup-ac364071, SnapshotCreated: 2021-05-17T04:42:01Z, Created: 2021-05-17T04:42:03Z, Size: 115343360, Labels: {}, IsIncremental: true, VolumeName: pvc-004d8edb-3a8c-4596-a659-3d00122d3f07, VolumeSize: 2147483648, VolumeCreated: 2021-05-12T00:52:01Z, Messages: null }新增backup head config只获取配置元数据修改时间用于判断配置是否变化{ ModificationTime: 2021-05-17T04:42:03Z }三个核心 CRD把远端状态缓存进集群设计文档规划了三个 CRD当前仓库的 Helm Chart 中已将它们落地为longhorn.io组、v1beta2版本的正式 CRD见 chart/templates/crds.yaml并提供了 CLI 短名lhbtBackupTarget、lhbvBackupVolume、lhbBackup。BackupTarget CRDbackuptargets.longhorn.io短名lhbt保存备份目标的连接信息与轮询状态对应 CRD 定义位于 chart/templates/crds.yaml当前 CRD 中backupTargetName已被移除说明该 CRD 落地时已随多备份目标演进调整。设计文档中的核心结构metadata: name: default # 备份目标名最初仅支持单一备份目标 spec: backupTargetURL: # 备份目标 URLstring credentialSecret: # 备份目标凭证 Secretstring pollInterval: 0s # 备份目标轮询间隔metav1.Duration syncRequestAt: null # 请求同步远端备份目标的时间*metav1.Time status: ownerID: # 负责运行备份目标控制器操作的节点 ID available: false # 远端备份目标是否可用 lastSyncedAt: null # 备份目标最近一次执行 reconcile 的时间当前 CRD 中保留了spec.backupTargetURL、spec.credentialSecret、spec.pollInterval、spec.syncRequestedAt状态中除available、lastSyncedAt、ownerID外还扩展了conditions记录备份目标不可用的原因并在additionalPrinterColumns中暴露 URL、Credential、Available、LastSyncedAt 等列便于kubectl get lhbt直接观察。BackupVolume CRDbackupvolumes.longhorn.io短名lhbv缓存单个备份卷的配置对应 CRD 定义位于 chart/templates/crds.yaml。设计文档结构metadata: name: backup-volume-name # 备份卷名称 spec: syncRequestAt: null # 请求同步远端备份卷的时间*metav1.Time fileCleanupRequired: false # 是否删除远端备份卷配置bool status: ownerID: # 负责运行备份卷控制器操作的节点 ID lastModificationTime: null # 备份卷配置的最后修改时间Time size: # 备份卷大小string labels: {} # 备份卷标签map[string]string createAt: # 备份卷创建时间string lastBackupName: # 最新备份名string lastBackupAt: # 最新备份时间string dataStored: # 备份卷已存块数string messages: {} # 调用 longhorn engine 列/查备份卷时的错误信息map[string]string lastSyncedAt: null # 备份卷最近一次同步进集群的时间*metav1.Time当前 CRD 的状态字段基本沿用此设计createdAt、dataStored、lastBackupAt、lastBackupName、lastModificationTime、lastSyncedAt、messages、ownerID、size、labels并随功能演进补充了backingImageName、backingImageChecksum、storageClassName、linkedCloneSourceVolume、linkedCloneSourceSnapshot等字段后者用于快速克隆场景。kubectl get lhbv可看到 BackupTarget、CreatedAt、LastBackupName、LastBackupAt、LastSyncedAt 等列。Backup CRDbackups.longhorn.io短名lhb缓存单个备份的配置并通过标签关联所属备份卷对应 CRD 定义位于 chart/templates/crds.yaml。设计文档结构metadata: name: backup-name labels: longhornvolume: backup-volume-name # 标记该备份所属的备份卷 spec: fileCleanupRequired: false # 是否删除远端备份配置及关联块文件bool snapshotName: # 快照名string labels: {} # 快照备份标签map[string]string backingImage: # 备份映像string backingImageURL: # 备份映像 URLstring status: ownerID: # 负责运行备份控制器操作的节点 ID backupCreationIsStart: false # 快照备份创建是否已开始bool url: # 快照备份 URLstring snapshotName: # 快照名string snapshotCreateAt: # 快照创建时间string backupCreateAt: # 快照备份创建时间string size: # 快照大小string labels: {} # 快照备份标签map[string]string messages: {} # 调用 longhorn engine 列/查备份时的错误信息map[string]string lastSyncedAt: null # 备份最近一次同步进集群的时间*metav1.Time当前 CRD 中spec保留了snapshotName、labels、backupModefull/incremental、backupBlockSize0表示沿用默认 2MiB-1表示无效2097152/16777216为可选块大小、syncRequestedAtstatus保留了backupCreatedAt、labels、backupTargetName、compressionMethod、error、lastSyncedAt等并在additionalPrinterColumns中暴露 SnapshotName、SnapshotSize、SnapshotCreatedAt、BackupTarget、State、LastSyncedAt 列。控制器架构四级协调实现最终一致1. setting_controller既有控制器改造监听 Setting CRsettings.longhorn.io的backup-target、backup-target-credential-secret、backupstore-poll-interval三个字段负责创建/更新默认的 BackupTarget CR同时按backupstore-poll-interval启动一个定时器 goroutine定时把 BackupTarget CR 的spec.syncRequestAt更新为time.Now()。若轮询间隔为0则不更新spec.syncRequestAt即关闭自动轮询。2. backup_target_controller新增监听 BackupTarget CR 的变化负责创建/更新/删除 BackupVolume CR 的 metadata 与 spec。Reconcile 步骤若当前节点 ID ≠ BackupTarget CR 的spec.responsibleNodeID跳过若status.lastSyncedAt ≥ spec.syncRequestAt跳过无需同步调用 longhorn engine 执行backup ls --volume-only列出远端备份卷backupStoreBackupVolumes若远端不可用置status.availablefalse、status.lastSyncedAttime.Now()跳过本次 reconcile列出集群内 BackupVolume CRclusterBackupVolumes计算差集backupVolumesToPull backupStoreBackupVolumes - clusterBackupVolumes为缺失的备份卷创建 BackupVolume CRmetadata.name计算差集backupVolumesToDelete clusterBackupVolumes - backupStoreBackupVolumes删除多余的 BackupVolume CR重新列出集群内 BackupVolume CR更新其spec.syncRequestAt time.Now()触发下一层同步更新 BackupTarget CR 状态status.availabletrue、status.lastSyncedAttime.Now()。3. backup_volume_controller新增监听 BackupVolume CR负责删除场景远端清理、状态更新与 Backup CR 的创建/删除。Reconcile 步骤校验当前节点 ID同前若收到删除 BackupVolume CR 事件若 BackupVolume CRspec.fileCleanupRequiredtrue则把所有 Backup CR 的spec.fileCleanupRequired置为true删除对应 Backup CR若spec.fileCleanupRequiredtrue执行backup rm --volume volume-name url删除远端备份卷移除 finalizer若status.lastSyncedAt ≥ spec.syncRequestAt跳过执行backup ls --volume volume-name列出远端备份backupStoreBackups列出集群内 Backup CRclusterBackups差集backupsToPull backupStoreBackups - clusterBackups创建 Backup CRmetadata.namemetadata.labels[longhornvolume]backup-volume-name差集backupsToDelete clusterBackups - backupStoreBackups删除 Backup CR执行backup head volume-config获取备份卷配置的最后修改时间与status.lastModificationTime比较若未变化仅更新status.lastSyncedAt并返回避免无谓重读执行backup inspect-volume volume-name读取备份卷配置依据配置更新 BackupVolume CR 状态并更新status.lastModificationTime与status.lastSyncedAt同步更新 Volume CR 的status.lastBackup与status.lastBackupAt。4. backup_controller新增监听 Backup CR负责向远端备份目标创建/删除备份并更新状态。Reconcile 步骤校验当前节点 ID同前若收到删除 Backup CR 事件若spec.fileCleanupRequiredtrue执行backup rm url删除远端备份更新对应 BackupVolume CR 的spec.syncRequestAttime.Now()移除 finalizer若spec.snapshotName ! 且status.backupCreationIsStart false调用 longhorn engine/replica 执行备份创建置status.backupCreationIsStart true派生 goroutine 监控创建进度当进度达到 100% 时若 BackupVolume CR 存在则更新其spec.syncRequestAt time.Now()否则创建该 BackupVolume CRmetadata.name若status.lastSyncedAt ! nil说明备份配置已同步过跳过执行backup inspect backup-url读取备份配置按配置更新 Backup CR 状态更新status.lastSyncedAt。从实现上看差集同步是三个新控制器的共同模式pull差集远端有、集群没有 → 创建 CR、delete差集集群有、远端没有 → 删除 CR从而保证集群内 CR 集合与远端备份目标最终一致。HTTP API 前后行为对照设计文档给出了完整的端点行为对照表改造后所有备份卷/备份相关的读操作都变成读集群内 CR写/删操作则转为打标 控制器异步执行HTTP EndpointBefore直连远端AfterCR 驱动GET/v1/backupvolumes从远端备份目标读取所有备份卷读取所有 BackupVolume CRGET/v1/backupvolumes/{volName}从远端读取单个备份卷按卷名读取 BackupVolume CRDELETE/v1/backupvolumes/{volName}从远端删除备份卷删除 BackupVolume CR由backup_volume_controller协调删除远端备份卷POST/v1/volumes/{volName}?actionsnapshotBackup直接向远端创建备份创建新 Backup CR由backup_controller协调创建远端备份GET/v1/backupvolumes/{volName}?actionbackupList从远端读取备份列表按标签过滤volumebackup-volume-name读取 Backup CR 列表GET/v1/backupvolumes/{volName}?actionbackupGet从远端读取单个备份按备份名读取 Backup CRDELETE/v1/backupvolumes/{volName}?actionbackupDelete从远端删除备份删除 Backup CR由backup_controller协调删除远端备份两个删除端点的具体流程DELETE /v1/backupvolumes/{volName}先将 BackupVolume CR 的spec.fileCleanupRequired置为true再删除该 CR最终由控制器执行远端清理并移除 finalizerDELETE /v1/backupvolumes/{volName}?actionbackupDelete先将 Backup CR 的spec.fileCleanupRequired置为true再删除该 CR最终由backup_controller执行backup rm url。POST /v1/volumes/{volName}?actionsnapshotBackup会先生成备份名再创建如下 Backup CRmetadata: name: backup-name labels: longhornvolume: backup-volume-name spec: snapshotName: snapshot-name labels: snapshot-backup-labels backingImage: backing-image backingImageURL: backing-image-URL用户故事与体验提升设计文档给出了三个典型用户故事用于验证改造效果Story 1远端备份目标有大量备份卷且延迟高 → 用户仍能在 GUI 上列出全部备份卷Story 2远端备份目标有大量备份且延迟高 → 用户仍能在 GUI 上列出全部备份Story 3用户在 GUI 上创建备份 → 系统先创建 Backup CRbackup_controller再协调 longhorn engine/replica 真正执行远端备份。改造后GUI 的列表请求不再受远端查询耗时的直接影响超时问题从架构上消除。配置与部署轮询间隔与默认备份存储异步拉取的轮询行为由设置backupstore-poll-interval控制。在 Helm Chart 中可通过 chart/values.yaml 的defaultBackupStore段配置默认值defaultBackupStore: # 默认备份存储端点可选NFS、CIFS、AWS、GCP、AZURE backupTarget: ~ # 与默认备份目标关联的 Kubernetes Secret 名称 backupTargetCredentialSecret: ~ # Longhorn 等待多久再检查默认备份存储是否有新备份秒。 # 默认值为 300值为 0 时禁用轮询。 pollInterval: ~这些配置经 chart/templates/default-resource.yaml 写入默认 Setting CRbackup-target: {{ .Values.defaultBackupStore.backupTarget }} backup-target-credential-secret: {{ .Values.defaultBackupStore.backupTargetCredentialSecret }} backupstore-poll-interval: {{ .Values.defaultBackupStore.pollInterval }}setting_controller正是监听这三个 Setting 字段来创建/更新默认 BackupTarget CR并按backupstore-poll-interval默认 300 秒即 5 分钟设为 0 则完全禁用自动轮询触发spec.syncRequestAt更新。设计文档还建议提供立即同步的能力可在 Backup 页面提供按钮更新 BackupTarget CR 的spec.syncRequestAt time.Now()或在 Backup → Backup Volume 页面提供按钮更新 BackupVolume CR 的spec.syncRequestAt time.Now()让用户在配置变更后不必等待整个轮询周期。测试计划与验证要点设计文档给出的测试围绕高负载、高延迟场景超过 1000 个备份卷、超过 1000 个备份且从 longhorn manager 到远端备份目标每次操作延迟 700–800ms基础备份/恢复配置备份目标与 5 分钟轮询 → 在 vol-A、vol-B 各创建两个备份 → GUI 可见对应 BackupVolume 与备份 → 删除单个备份后远端数据随之删除 → 删除 vol-A 备份卷后远端备份卷与其全部备份被删除 → 切换到另一备份目标后看不到 vol-B → 将backupstore-poll-interval改为 1 分钟并切回原目标1 分钟后恢复可见 → 从 vol-B 备份创建卷。DR 卷操作双集群共享同一备份目标集群 A 创建卷并周期性备份 → 集群 B 在轮询周期后能列出备份卷/备份 → 从备份卷创建 DR 卷 → 校验 DR 卷status.LastBackup/status.LastBackupAt周期性更新 → 集群 A 删除备份卷 → 集群 B 在轮询周期后该备份卷消失且 DR 卷状态不再更新。备份目标 URL 清空配置目标并创建备份 → 将备份目标设置置空 → 轮询触发后默认 BackupTarget CRstatus.availablefalse、status.lastSyncedAt更新、所有 BackupVolume/Backup CR 被删除、vol-A CR 的status.lastBackup/status.lastBackupAt被清理、GUI 显示目标不可用。切换备份目标 URLS3 备份 → 切到 NFS 备份 → 再切回 S3 → 轮询触发后 BackupVolume/Backup CR 与 vol-A 状态按 S3 数据重新同步。凭证 Secret 变更将备份目标凭证 Secret 置空 → 轮询触发后status.availablefalseGUI 显示目标不可用。后续演进与现状对照该设计落地后 Longhorn 持续演进仓库中可看到与本主题直接相关的后续增强enhancements/20241003-improve-pulling-backups-from-the-backup-target.md针对 NFS 短时宕机恢复后空响应导致备份数据被误删的问题引入DeleteCustomResourceOnly标签——当远端已无对应备份数据时只删除集群内的BackupVolume/Backup/BackupBackingImage/SystemBackup资源不再删除远端数据enhancements/20240926-multiple-backup-targets-support.md解除仅支持单一备份目标的限制支撑多备份目标这也是当前 CRD 中 BackupVolume/Backup 增加backupTargetName字段的原因当前 CRD 的Backup还扩展了backupModefull/incremental、backupBlockSize对应 enhancements/20250701-configurable-backup-block-size.md 的可配置备份块大小等字段CHANGELOG/CHANGELOG-1.8.0.md 记录有使备份删除异步化并强制备份创建等待直到没有备份正在删除的改进issue #8746。由此可见异步拉取架构从 2021 年的增强提案起步逐步成为 Longhorn 备份链路的基础设施并围绕可靠性误删防护、多目标支持、备份模式等方向持续完善。小结本增强的核心价值可以概括为三点列表与读配置分离backupstore 命令职责拆分、远端状态集群化三个 CRD 缓存备份目标/备份卷/备份元数据、控制器异步协调差集同步 时间戳驱动 finalizer 清理最终让备份列表超时从架构层面消失并为后续的多备份目标、备份块大小可配置等能力打下基础。若需深入源码可重点研读 chart/templates/crds.yaml 中三个 CRD 的字段定义以及 chart/values.yaml 的默认备份存储配置结合本文的 reconcile 步骤理解数据流。赞分享云原生存储高可用容器编排【免费下载链接】longhornCloud-Native distributed storage built on and for Kubernetes项目地址https://gitcode.com/gh_mirrors/lo/longhorn点击查看免费下载相关推荐Longhorn 备份目标拉取增强用 DeleteCustomResourceOnly 标签守护远端备份数据安全Longhorn 备份目标拉取增强用 DeleteCustomResourceOnly 标签守护远端备份数据安全 在 Longhorn 中备份目标Back云原生存储高可用容器编排Velero Backup API 类型详解从 Backup CRD 配置到备份生命周期控制Velero Backup API 类型详解从 Backup CRD 配置到备份生命周期控制 本文以 Velero 官方 API 类型文档 site/con云原生灾备存储后端Longhorn 多备份目标Multiple Backup Targets支持架构设计、配置实践与灾备指南Longhorn 多备份目标Multiple Backup Targets支持架构设计、配置实践与灾备指南 Longhorn 从 v1.8.0 起引入多备云原生存储高可用容器编排创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考