拓冰网站定制 
CloudNativePG 备份完全指南物理备份、定时与按需备份、对象存储与卷快照实战【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pgCloudNativePG 是 Kubernetes 上最流行的 PostgreSQL Operator其备份体系围绕 PostgreSQL 原生文件系统级物理备份构建由WAL 归档与物理基础备份两大支柱组成。本文以仓库 docs/src/backup.md 为骨架结合 API 定义与控制器源码系统讲解 WAL 归档与热/冷备份概念、对象存储备份与卷快照备份的取舍、ScheduledBackup定时备份与Backup按需备份的完整用法、从备机standby执行备份的目标选择策略以及 v1.26 之后向 CNPG-I 插件化、备份无关backup-agnostic架构迁移的演进方向帮助你为生产 PostgreSQL 集群设计并落地一套可验证的容灾恢复方案。:::info 适用范围 本文所有版本、字段与默认值均以当前仓库CloudNativePG v1.30 分支中的代码与文档为准。 :::备份策略的两条主线从原生集成到 CNPG-I 插件CloudNativePG 目前通过两条途径支持 PostgreSQL 集群的物理备份physical backupCNPG-I 插件CloudNativePG 社区官方维护的Barman Cloud Plugin用于对接各类对象存储服务是当前推荐的备份方式原生Natively支持通过 Barman Cloud 对接对象存储——自 1.26 起已弃用deprecated推荐迁移到 Barman Cloud PluginKubernetes 卷快照Volume Snapshots——前提是底层存储类支持 CSI 卷快照。:::info 重要演进 自 v1.26 起核心 Operator 中的原生备份与恢复能力正被逐步淘汰并迁移至官方 CNPG-I 插件。这一转变契合 CloudNativePG 迈向备份无关架构的目标通过可扩展接口CNPG-I统一规范WAL 归档、物理基础备份及对应的恢复流程让第三方能够构建并集成自己的备份插件未来受支持的备份方案生态将不断壮大。 :::从源码角度看这一演进已体现在 API 定义中。在 api/v1/backup_types.go 中BackupMethod枚举了三种方法其中plugin正是面向 CNPG-I 插件的新方式const ( // BackupMethodVolumeSnapshot means using the volume snapshot // Kubernetes feature BackupMethodVolumeSnapshot BackupMethod volumeSnapshot // BackupMethodBarmanObjectStore means using barman to backup the // PostgreSQL cluster BackupMethodBarmanObjectStore BackupMethod barmanObjectStore // BackupMethodPlugin means that this backup should be handled by // a plugin BackupMethodPlugin BackupMethod plugin )在动手选择备份策略之前请先理解下面“主要概念”一节中的基础原理——WAL 归档、热/冷备份、从备机执行备份等。主要概念PostgreSQL 原生提供一流的数据备份与恢复能力基于文件系统级物理拷贝实现已成功用于生产环境关键数据库长达 15 年以上。在 CloudNativePG 中每个 PostgreSQL 集群的备份基础设施由以下资源构成WAL 归档WAL archive存放 WAL 文件事务日志的位置WAL 由 Postgres 持续写入并被归档用于保障数据持久性物理基础备份Physical base backupPostgreSQL 用于存储数据的全部文件的副本主要是PGDATA以及所有表空间。CNPG-I 为 WAL 归档归档与恢复操作、基础备份及对应恢复流程提供了一套通用、可扩展的接口。WAL 归档WAL 归档是 PostgreSQL连续备份continuous backup的核心其作用体现在两个关键能力上热备份Hot backups可以在 Postgres 集群中任意实例主库或备库上执行物理基础备份而无需关闭服务器因此也称为在线备份时间点恢复Point in Time RecoveryPITR可以从系统中第一个可用的基础备份开始恢复到任意时间点。:::warning 仅有 WAL 归档是无用的——没有物理基础备份就无法恢复 PostgreSQL 集群。 :::一般来说WAL 归档的存在增强了 PostgreSQL 集群的韧性每个实例在需要时都可以从归档中获取任意 WAL 文件通常归档的保留周期远长于任何会循环回收这些文件的 Postgres 实例。这一用途还可扩展到副本集群replica clusters——它们可以单纯依赖 WAL 归档实现跨长距离的同步将容灾目标扩展到不同区域。当你配置 WAL 归档后CloudNativePG 开箱即用地为容灾恢复提供RPO ≤ 5 分钟即使跨区域也是如此RPO 定义见 before_you_start.md 的 PostgreSQL 术语表。:::info 重要建议 生产环境始终建议配置 WAL 归档。但存在一些已知用例——通常是预发staging和开发development环境——既不需要上述任何收益也不需要 WAL 归档。此时 RPO 可以是任意值例如 24 小时每日备份乃至无限大完全不备份。 :::关于archive_timeout的默认值在 docs/src/wal_archiving.md 中明确CloudNativePG 默认将archive_timeout设置为5min保证即使在低负载下WAL 文件也至少每 5 分钟被关闭并归档一次从而为你的 RPO 提供一个确定性的时间基准。即便你修改了 PostgreSQL 配置中的archive_timeout官方经验仍建议保持 operator 设置的默认值它适用于绝大多数场景。冷备份与热备份热备份已在上一节定义它要求存在 WAL 归档是现代数据库管理系统的标配。冷备份Cold backups也叫离线备份offline backups是在 PostgreSQL 实例备库或主库关闭状态下拍摄的物理基础备份。它们天然是一致的consistent per definition代表数据库在关闭那一刻的快照。因此PostgreSQL 实例可以在无需 WAL 归档的情况下从冷备份重启——当然如果归档可用它们依然可以利用它获得上一节提到的恢复侧全部收益。在 RPO 较高例如 1 小时或 24 小时、保留周期较短的场景下冷备份是容灾计划中值得考虑的可选项。备份方案对比对象存储 vs 卷快照CloudNativePG 目前支持两种主要的物理备份途径对象存储备份通过Barman Cloud Plugin或已弃用的原生集成backup_barmanobjectstore.md实现卷快照Volume Snapshots利用 Kubernetes CSI 接口与受支持的存储类详见 backup_volumesnapshot.md。对象存储备份备份到对象存储如 AWS S3、Azure Blob、GCS的特点始终要求 WAL 归档仅支持热备份不支持增量或差异拷贝incremental/differential支持保留策略retention policies卷快照原生卷快照的特点不要求 WAL 归档但生产环境仍强烈建议使用根据底层存储类的能力支持增量与差异拷贝同时支持热备份与冷备份不支持保留策略。如何选择最佳方案取决于你的环境与运维需求可参考以下考量因素对象存储可用性确保 Kubernetes 集群能够访问可靠的对象存储方案包括稳定的网络层存储类能力确认你的存储类支持带增量/差异特性的 CSI 卷快照数据库规模对于超大型数据库VLDB通常更推荐卷快照——其写时复制copy-on-write技术可显著缩短恢复时间从而大幅改善你的 RTORecovery Time Objective数据移动性对象存储备份在跨区域复制或存放备份方面可能更灵活运维熟悉度选择与你团队经验与存储管理信心最匹配的方式。对比汇总表FeatureObject StoreVolume SnapshotsWAL archivingRequiredRecommended¹Cold backup❌✅Hot backup✅✅Incremental copy❌✅²Differential copy❌✅²Backup from a standby✅✅Snapshot recovery❌³✅Retention policies✅❌Point-in-Time Recovery (PITR)✅Requires WAL archiveUnderlying technologyBarman CloudKubernetes API注WAL 归档当前必须通过插件或已弃用的原生方式使用对象存储。增量/差异拷贝的可用性取决于 PostgreSQL 卷所用存储类的能力。快照恢复可通过bootstrap.recovery.recoveryTarget.targetImmediate选项模拟。定时备份Scheduled Backups定时备份是在 CloudNativePG 中实施可靠备份策略的推荐方式通过ScheduledBackup自定义资源定义。完整的配置项清单见 API 参考中的ScheduledBackupSpec。Cron 表达式schedule字段定义备份的触发时机使用包含秒的六段式 cron 表达式遵循 Gocron包规范。:::warning 该格式与传统的 Unix/Linuxcrontab不同——它在首位多了一个秒字段。 :::每日定时备份示例apiVersion: postgresql.cnpg.io/v1 kind: ScheduledBackup metadata: name: backup-example spec: schedule: 0 0 0 * * * # At midnight every day backupOwnerReference: self cluster: name: pg-backup # method: plugin, volumeSnapshot, or barmanObjectStore (default)0 0 0 * * *表示每天午夜00:00:00触发一次备份。在 Kubernetes CronJob 中等价表达式是0 0 * * *因为 CronJob 不支持秒。:::warningspec.cluster字段在创建后不可变更immutable。若想为不同的Cluster调度备份请新建一个ScheduledBackup资源而不是修改现有资源。这一约束在 api/v1/scheduledbackup_types.go 中有对应校验规则cluster reference is immutable after creation。 :::从源码看ScheduledBackupSpec还包含schedule、suspend、immediate、method、target、pluginConfiguration、online、onlineConfiguration等字段见 api/v1/scheduledbackup_types.go控制器在 internal/controller/scheduledbackup_controller.go 中使用github.com/robfig/cron的cron.Parse解析表达式并通过schedule.Next(now)计算下一次执行时间。备份频率与 RTO:::tip 提示 备份频率直接影响你的RTORecovery Time Objective定义见 before_you_start.md。 :::要基于连续备份优化容灾策略应做到定期演练从备份恢复测量一次完整恢复所需的时间计入基础备份的大小以及需要取回并重放的 WAL 文件数量。在大多数场景下每周一次基础备份就已足够每日一次以上的全量备份极为罕见。立即备份Immediate Backup希望在ScheduledBackup创建时立即触发一次备份spec: immediate: true暂停定时备份需要临时停止定时备份时spec: suspend: true备份属主引用.spec.backupOwnerReference控制哪个 Kubernetes 对象被设置为备份资源的属主ownernone不设置属主引用旧行为self由ScheduledBackup对象充当属主cluster由 PostgreSQL 集群充当属主。该字段的枚举定义同样见 api/v1/scheduledbackup_types.gonone;self;cluster且默认值为none。按需备份On-Demand Backups按需备份允许你随时手动触发备份操作方式是创建一个Backup资源。完整选项见 API 参考中的BackupSpec。示例发起一次按需备份要开始一次按需备份应用类似下面的Backup请求自定义资源apiVersion: postgresql.cnpg.io/v1 kind: Backup metadata: name: backup-example spec: method: barmanObjectStore cluster: name: pg-backup在这个例子中operator 将使用barman-cloud-backup工具编排备份过程并把备份存放到已配置的对象存储中。BackupSpec在 api/v1/backup_types.go 中定义其中method字段的取值枚举为barmanObjectStore;volumeSnapshot;plugin默认值为barmanObjectStoretarget字段可选primary;prefer-standby。同时BackupSpec带有一条 OpenAPI 校验规则BackupSpec is immutable once set创建后不可变。监控备份进度使用以下命令查看备份状态kubectl describe backup backup-example备份进行中时输出类似Name: backup-example Namespace: default ... Spec: Cluster: Name: pg-backup Status: Phase: running Started At: 2020-10-26T13:57:40Z Events: none备份成功后phase变为completed输出会附带更多元数据Name: backup-example Namespace: default ... Status: Backup Id: 20201026T135740 Destination Path: s3://backups/ Endpoint URL: http://minio:9000 Phase: completed S3 Credentials: Access Key Id: Name: minio Key: ACCESS_KEY_ID Secret Access Key: Name: minio Key: ACCESS_SECRET_KEY Server Name: pg-backup Started At: 2020-10-26T13:57:40Z Stopped At: 2020-10-26T13:57:44Z从源码看备份生命周期由 api/v1/backup_types.go 中定义的BackupPhase枚举驱动包括pending、started、running、finalizing卷快照场景下已生成VolumeSnapshotContent但仍在等待readyToUse标志、completed、failed、walArchivingFailing与invalid backup definition。备份控制器的核心入口位于 internal/controller/backup_controller.go它根据status.phase判断是否终结completed/failed。:::info 重要提示 按需备份不包含PostgreSQL 超级用户或应用用户的 Kubernetes Secrets。你应在更广的 Kubernetes 集群备份策略中纳入这些 Secret。 :::备份方法Backup MethodsCloudNativePG 当前支持以下备份方法可用于定时与按需备份plugin—— 使用 CNPG-I 插件需要.spec.pluginConfigurationvolumeSnapshot—— 使用原生 Kubernetes 卷快照barmanObjectStore—— 使用 Barman Cloud 对接对象存储自 v1.26 起弃用推荐迁移到 Barman Cloud Plugin但为向后兼容仍是默认值。通过.spec.method字段指定方法默认barmanObjectStore。该默认值在 api/v1/backup_types.go 与 api/v1/scheduledbackup_types.go 中均以kubebuilder:default:barmanObjectStore声明。如果你的集群配置了卷快照能力可以这样启用定时快照备份spec: method: volumeSnapshot若要使用 Barman Cloud Plugin 作为备份方法需设置method: plugin并相应配置插件可参考插件文档中“Performing a Base Backup”一节的示例。对于plugin方法你还可以在pluginConfiguration中传入插件名name与键值对parameters见 api/v1/backup_types.go 的BackupPluginConfiguration。从备机执行备份Backup from a Standby执行基础备份需要读取 PostgreSQL 实例的整个磁盘数据集这可能引发 I/O 争用影响活跃工作负载的性能。为降低这种影响CloudNativePG 支持从备机standby实例执行备份充分利用 PostgreSQL 内置的从只读副本执行备份的能力。默认情况下备份在集群中数据最新的副本most up-to-date replica上执行如果没有可用副本则回退到主实例primary。:::note 本节示例聚焦于备份目标选择未考虑备份方法spec.method因为它与当前讨论的范围无关。 :::工作原理当目标为prefer-standby默认行为时CloudNativePG 会尝试识别同步程度最高的备节点在该备节点上运行备份流程若无可用备库则回退到主库。该策略最大程度地减少了对主库工作负载的干扰。:::warning 尽管备库可能并不总是与主库完全同步但从首个可用备份到最近归档 WAL 之间的时间连续体上看这通常无关紧要——基础备份本质上代表恢复操作包括 PITR的起点。与pg_basebackup的行为一致从在线备库备份时我们不会强制在主库上切换 WAL。在写入活动较低的部署中这可能在短期内archive_timeout生效之前产生意外结果。 :::源码佐证备份目标的选择逻辑实现在 internal/controller/backup_controller.go 的getBackupTargetPod函数中。该函数首先基于集群级cluster.Spec.Backup.Target与备份级backup.Spec.Target后者优先级更高确定目标策略随后遍历受管实例只挑选已就绪且镜像与大版本升级状态匹配podHasLatestMajorImage即备份不应在大版本升级期间执行的 Pod当策略为BackupTargetPrimary时选择主实例 Pod为BackupTargetStandby或空串时选择非主实例 Pod若没有合适的就绪实例则回退到主实例targetPod nil时直接获取cluster.Status.TargetPrimary对应的 Pod。强制在主库执行备份要始终在主实例上执行备份在集群配置中显式将备份目标设为primaryapiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: [...] spec: backup: target: primary:::warning 使用primary作为目标时需格外谨慎尤其是使用卷快照的冷备份——这需要临时关闭主实例将中断所有写操作。单实例集群也要注意同样的问题即使你未显式设置目标。 :::覆盖集群级目标你可以在每次备份时覆盖集群级目标使用Backup或ScheduledBackup资源均可。以下是一次按需备份的示例apiVersion: postgresql.cnpg.io/v1 kind: Backup metadata: [...] spec: cluster: name: [...] target: primary在此示例中即使集群默认目标为prefer-standby备份也会从主实例执行。保留策略Retention PoliciesCloudNativePG 正朝着备份无关架构演进备份职责被委托给外部CNPG-I 插件。这些插件预期提供更高级、可定制的数据保护特性包括比 CloudNativePG 内置能力更复杂的保留管理。作为这一过渡的一部分Cluster资源中的spec.backup.retentionPolicy字段已弃用并将在未来版本中移除。更多保留特性细节请参考所选插件的文档例如 Barman Cloud Plugin 的 Retention Policies 章节。:::info 重要提示 建议用户依赖所用备份插件提供的保留机制这能带来更好的灵活性与所用备份方法的一致性。 :::历史背景在原生 Barman Cloud 集成中详见 docs/src/appendixes/backup_barmanobjectstore.md保留策略基于**恢复窗口recovery window**概念它聚焦于可恢复点Point of RecoverabilityPoR——一个由当前时间 - 恢复窗口决定的移动时间点。第一个有效备份是按时间逆序排列的、早于 PoR 的第一个可用备份。CloudNativePG 必须保证能从第一个有效备份出发恢复到 PoR 与最近成功归档 WAL 文件之间的任意时间点。早于第一个有效备份的基础备份会被标记为obsolete过期并在下一次备份完成后永久删除。内部实现上该功能调用barman-cloud-backup-delete --retention-policy RECOVERY WINDOW OF {{ 保留值 }} {{ 保留单位 }}。附对象存储备份与卷快照备份的深入实践为帮助你进一步落地这里补充两份附录文档中的关键实操细节。对象存储备份要点原生 Barman Cloud 集成依赖镜像内置barman-cli-cloud仓库推荐使用ghcr.io/cloudnative-pg/postgresql社区镜像并通过barman-cloud-wal-archive、barman-cloud-check-wal-archive、barman-cloud-backup、barman-cloud-backup-list、barman-cloud-backup-delete等工具编排连续备份基础备份产物为tarball详见 docs/src/appendixes/backup_barmanobjectstore.md。需要注意的关键点桶必须预先创建自 Barman Cloud 3.16 起多数命令不再自动创建目标桶只有barman-cloud-check-wal-archive会创建。请在创建引用桶的Cluster资源之前先创建并配置好对象存储桶以保证未来可靠运行。WAL 压缩与加密可在.spec.backup.barmanObjectStore.wal中配置compression与encryption也可在桶上直接配置加密operator 会优先采用桶配置。并行 WAL 归档当带宽允许时可通过wal.maxParallel例如maxParallel: 8让实例管理器并行归档最多 8 个就绪 WAL提升吞吐。支持的压缩算法bzip2、gzip、lz4、snappy、xz、zstd备份与 WAL 的压缩设置相互独立不同算法在归档时间、恢复时间与体积上差异明显需按场景选择文档提供了一份基于本地 MinIO 的实测表例如不压缩 395MB 数据gzip后约 91MB、比约 4.3:1。对象标签若镜像内 Barman ≥ 2.18可通过tags作用于基础备份与归档 WAL与historyTags作用于归档历史文件为备份对象打标签。附加命令参数data.additionalCommandArgs备份、data.restoreAdditionalCommandArgs恢复、wal.archiveAdditionalCommandArgs、wal.restoreAdditionalCommandArgs可向barman-cloud-*命令追加参数恢复侧参数取自externalClusters中对应barmanObjectStore而非.spec.backup。卷快照备份要点CloudNativePG 是首批直接以声明式方式利用 Kubernetes 原生 Volume Snapshot API 进行备份与恢复的数据库 Operator 之一详见 docs/src/appendixes/backup_volumesnapshot.md。要点包括前置条件用于动态供应 PostgreSQL 卷的每个存储类storage、walStorage都必须支持卷快照且通常需要配套的VolumeSnapshotClass。配置方式在Cluster的backup.volumeSnapshot节区设置className若PGDATA与 WAL 使用不同存储类可用walClassName单独指定默认与className相同。热/冷备份控制默认请求在线/热备份online: true并遵循 PostgreSQL 低层基础备份 API 的默认行为启动时不立即请求检查点、结束时等待WAL 归档器处理最后一段。可通过onlineConfiguration.immediateCheckpoint对应pg_backup_start/pg_start_backup()的fast参数默认true与onlineConfiguration.waitForArchive对应pg_backup_stop/pg_stop_backup()的wait_for_archive参数默认true调整。设置online: false即默认改为冷备份Backup/ScheduledBackup对象还可通过online与onlineConfiguration字段覆盖集群默认行为例如spec.online: false发起一次按需冷备份。对象持久化backup.volumeSnapshot.snapshotOwnerReference控制VolumeSnapshot对象的属主与生命周期none保留、backup随Backup删除、cluster随集群删除VolumeSnapshotContent的最终去留由VolumeSnapshotClass的deletionPolicyRetain/Delete决定。快照超时重试backup.cnpg.io/volumeSnapshotDeadline注解控制卷快照错误的重试截止时间默认10 分钟每10 秒重试一次该注解可加在Backup或ScheduledBackup上定时备份创建的Backup会自动继承。关于逻辑备份pg_dump的边界CloudNativePG 的备份体系专注于物理备份。虽然 PostgreSQL 也支持使用pg_dump工具进行逻辑备份但逻辑备份不适合业务连续性business continuity场景也不受 CloudNativePG 管理。如果你仍需要使用pg_dump请参考 Troubleshooting / Emergency backup 一节的指导。该节的紧急备份示例仅限紧急情况使用临时文件必须按组织的数据保护策略保存且 dump 文件存于执行kubectl的客户端机器上# 从 cluster-example-1 pod 对 app 数据库做自定义格式逻辑备份 kubectl exec cluster-example-1 -c postgres \ -- pg_dump -Fc -d app app.dump # 恢复到 new-cluster-example-1主实例的 app 数据库 kubectl exec -i new-cluster-example-1 -c postgres \ -- pg_restore --no-owner --roleapp -d app --verbose app.dump若有多个角色或数据库还需使用pg_dumpall -g备份全局对象并逐个数据库执行恢复操作。结语从本文走向可落地的容灾方案总结 CloudNativePG 备份体系的设计主线概念层WAL 归档连续备份、RPO ≤ 5 分钟 物理基础备份恢复起点缺一不可冷/热备份按 RPO 需求取舍方案层对象存储备份需 WAL 归档、仅热备、支持保留策略与卷快照备份可选 WAL、支持冷热备、增量差异、无保留策略按存储能力与 VLDB 规模权衡见上文的对比汇总表操作层日常备份优先使用ScheduledBackup六段 cron、immediate、suspend、backupOwnerReference临时备份使用Backup并通过kubectl describe backup观察phase从running到completed的完整生命周期目标层默认prefer-standby把备份负载导向最新备机降低主库 I/O 争用必要时可逐备份覆盖为primary演进层自 v1.26 起原生 Barman Cloud 与retentionPolicy均进入弃用通道新部署应迁移到 Barman Cloud Plugin 与更广义的 CNPG-I 插件生态。建议你在生产环境遵循以下清单始终配置 WAL 归档使用volumeSnapshot或plugin方法建立每周一次的基础备份定期演练从备份恢复并计量 RTO将超级用户/应用用户 Secret 纳入集群级备份策略迁移到插件化备份方案以获得可定制的保留管理。【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CloudNativePG 备份完全指南：物理备份、定时与按需备份、对象存储与卷快照实战
CloudNativePG 备份完全指南物理备份、定时与按需备份、对象存储与卷快照实战【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pgCloudNativePG 是 Kubernetes 上最流行的 PostgreSQL Operator其备份体系围绕 PostgreSQL 原生文件系统级物理备份构建由WAL 归档与物理基础备份两大支柱组成。本文以仓库 docs/src/backup.md 为骨架结合 API 定义与控制器源码系统讲解 WAL 归档与热/冷备份概念、对象存储备份与卷快照备份的取舍、ScheduledBackup定时备份与Backup按需备份的完整用法、从备机standby执行备份的目标选择策略以及 v1.26 之后向 CNPG-I 插件化、备份无关backup-agnostic架构迁移的演进方向帮助你为生产 PostgreSQL 集群设计并落地一套可验证的容灾恢复方案。:::info 适用范围 本文所有版本、字段与默认值均以当前仓库CloudNativePG v1.30 分支中的代码与文档为准。 :::备份策略的两条主线从原生集成到 CNPG-I 插件CloudNativePG 目前通过两条途径支持 PostgreSQL 集群的物理备份physical backupCNPG-I 插件CloudNativePG 社区官方维护的Barman Cloud Plugin用于对接各类对象存储服务是当前推荐的备份方式原生Natively支持通过 Barman Cloud 对接对象存储——自 1.26 起已弃用deprecated推荐迁移到 Barman Cloud PluginKubernetes 卷快照Volume Snapshots——前提是底层存储类支持 CSI 卷快照。:::info 重要演进 自 v1.26 起核心 Operator 中的原生备份与恢复能力正被逐步淘汰并迁移至官方 CNPG-I 插件。这一转变契合 CloudNativePG 迈向备份无关架构的目标通过可扩展接口CNPG-I统一规范WAL 归档、物理基础备份及对应的恢复流程让第三方能够构建并集成自己的备份插件未来受支持的备份方案生态将不断壮大。 :::从源码角度看这一演进已体现在 API 定义中。在 api/v1/backup_types.go 中BackupMethod枚举了三种方法其中plugin正是面向 CNPG-I 插件的新方式const ( // BackupMethodVolumeSnapshot means using the volume snapshot // Kubernetes feature BackupMethodVolumeSnapshot BackupMethod volumeSnapshot // BackupMethodBarmanObjectStore means using barman to backup the // PostgreSQL cluster BackupMethodBarmanObjectStore BackupMethod barmanObjectStore // BackupMethodPlugin means that this backup should be handled by // a plugin BackupMethodPlugin BackupMethod plugin )在动手选择备份策略之前请先理解下面“主要概念”一节中的基础原理——WAL 归档、热/冷备份、从备机执行备份等。主要概念PostgreSQL 原生提供一流的数据备份与恢复能力基于文件系统级物理拷贝实现已成功用于生产环境关键数据库长达 15 年以上。在 CloudNativePG 中每个 PostgreSQL 集群的备份基础设施由以下资源构成WAL 归档WAL archive存放 WAL 文件事务日志的位置WAL 由 Postgres 持续写入并被归档用于保障数据持久性物理基础备份Physical base backupPostgreSQL 用于存储数据的全部文件的副本主要是PGDATA以及所有表空间。CNPG-I 为 WAL 归档归档与恢复操作、基础备份及对应恢复流程提供了一套通用、可扩展的接口。WAL 归档WAL 归档是 PostgreSQL连续备份continuous backup的核心其作用体现在两个关键能力上热备份Hot backups可以在 Postgres 集群中任意实例主库或备库上执行物理基础备份而无需关闭服务器因此也称为在线备份时间点恢复Point in Time RecoveryPITR可以从系统中第一个可用的基础备份开始恢复到任意时间点。:::warning 仅有 WAL 归档是无用的——没有物理基础备份就无法恢复 PostgreSQL 集群。 :::一般来说WAL 归档的存在增强了 PostgreSQL 集群的韧性每个实例在需要时都可以从归档中获取任意 WAL 文件通常归档的保留周期远长于任何会循环回收这些文件的 Postgres 实例。这一用途还可扩展到副本集群replica clusters——它们可以单纯依赖 WAL 归档实现跨长距离的同步将容灾目标扩展到不同区域。当你配置 WAL 归档后CloudNativePG 开箱即用地为容灾恢复提供RPO ≤ 5 分钟即使跨区域也是如此RPO 定义见 before_you_start.md 的 PostgreSQL 术语表。:::info 重要建议 生产环境始终建议配置 WAL 归档。但存在一些已知用例——通常是预发staging和开发development环境——既不需要上述任何收益也不需要 WAL 归档。此时 RPO 可以是任意值例如 24 小时每日备份乃至无限大完全不备份。 :::关于archive_timeout的默认值在 docs/src/wal_archiving.md 中明确CloudNativePG 默认将archive_timeout设置为5min保证即使在低负载下WAL 文件也至少每 5 分钟被关闭并归档一次从而为你的 RPO 提供一个确定性的时间基准。即便你修改了 PostgreSQL 配置中的archive_timeout官方经验仍建议保持 operator 设置的默认值它适用于绝大多数场景。冷备份与热备份热备份已在上一节定义它要求存在 WAL 归档是现代数据库管理系统的标配。冷备份Cold backups也叫离线备份offline backups是在 PostgreSQL 实例备库或主库关闭状态下拍摄的物理基础备份。它们天然是一致的consistent per definition代表数据库在关闭那一刻的快照。因此PostgreSQL 实例可以在无需 WAL 归档的情况下从冷备份重启——当然如果归档可用它们依然可以利用它获得上一节提到的恢复侧全部收益。在 RPO 较高例如 1 小时或 24 小时、保留周期较短的场景下冷备份是容灾计划中值得考虑的可选项。备份方案对比对象存储 vs 卷快照CloudNativePG 目前支持两种主要的物理备份途径对象存储备份通过Barman Cloud Plugin或已弃用的原生集成backup_barmanobjectstore.md实现卷快照Volume Snapshots利用 Kubernetes CSI 接口与受支持的存储类详见 backup_volumesnapshot.md。对象存储备份备份到对象存储如 AWS S3、Azure Blob、GCS的特点始终要求 WAL 归档仅支持热备份不支持增量或差异拷贝incremental/differential支持保留策略retention policies卷快照原生卷快照的特点不要求 WAL 归档但生产环境仍强烈建议使用根据底层存储类的能力支持增量与差异拷贝同时支持热备份与冷备份不支持保留策略。如何选择最佳方案取决于你的环境与运维需求可参考以下考量因素对象存储可用性确保 Kubernetes 集群能够访问可靠的对象存储方案包括稳定的网络层存储类能力确认你的存储类支持带增量/差异特性的 CSI 卷快照数据库规模对于超大型数据库VLDB通常更推荐卷快照——其写时复制copy-on-write技术可显著缩短恢复时间从而大幅改善你的 RTORecovery Time Objective数据移动性对象存储备份在跨区域复制或存放备份方面可能更灵活运维熟悉度选择与你团队经验与存储管理信心最匹配的方式。对比汇总表FeatureObject StoreVolume SnapshotsWAL archivingRequiredRecommended¹Cold backup❌✅Hot backup✅✅Incremental copy❌✅²Differential copy❌✅²Backup from a standby✅✅Snapshot recovery❌³✅Retention policies✅❌Point-in-Time Recovery (PITR)✅Requires WAL archiveUnderlying technologyBarman CloudKubernetes API注WAL 归档当前必须通过插件或已弃用的原生方式使用对象存储。增量/差异拷贝的可用性取决于 PostgreSQL 卷所用存储类的能力。快照恢复可通过bootstrap.recovery.recoveryTarget.targetImmediate选项模拟。定时备份Scheduled Backups定时备份是在 CloudNativePG 中实施可靠备份策略的推荐方式通过ScheduledBackup自定义资源定义。完整的配置项清单见 API 参考中的ScheduledBackupSpec。Cron 表达式schedule字段定义备份的触发时机使用包含秒的六段式 cron 表达式遵循 Gocron包规范。:::warning 该格式与传统的 Unix/Linuxcrontab不同——它在首位多了一个秒字段。 :::每日定时备份示例apiVersion: postgresql.cnpg.io/v1 kind: ScheduledBackup metadata: name: backup-example spec: schedule: 0 0 0 * * * # At midnight every day backupOwnerReference: self cluster: name: pg-backup # method: plugin, volumeSnapshot, or barmanObjectStore (default)0 0 0 * * *表示每天午夜00:00:00触发一次备份。在 Kubernetes CronJob 中等价表达式是0 0 * * *因为 CronJob 不支持秒。:::warningspec.cluster字段在创建后不可变更immutable。若想为不同的Cluster调度备份请新建一个ScheduledBackup资源而不是修改现有资源。这一约束在 api/v1/scheduledbackup_types.go 中有对应校验规则cluster reference is immutable after creation。 :::从源码看ScheduledBackupSpec还包含schedule、suspend、immediate、method、target、pluginConfiguration、online、onlineConfiguration等字段见 api/v1/scheduledbackup_types.go控制器在 internal/controller/scheduledbackup_controller.go 中使用github.com/robfig/cron的cron.Parse解析表达式并通过schedule.Next(now)计算下一次执行时间。备份频率与 RTO:::tip 提示 备份频率直接影响你的RTORecovery Time Objective定义见 before_you_start.md。 :::要基于连续备份优化容灾策略应做到定期演练从备份恢复测量一次完整恢复所需的时间计入基础备份的大小以及需要取回并重放的 WAL 文件数量。在大多数场景下每周一次基础备份就已足够每日一次以上的全量备份极为罕见。立即备份Immediate Backup希望在ScheduledBackup创建时立即触发一次备份spec: immediate: true暂停定时备份需要临时停止定时备份时spec: suspend: true备份属主引用.spec.backupOwnerReference控制哪个 Kubernetes 对象被设置为备份资源的属主ownernone不设置属主引用旧行为self由ScheduledBackup对象充当属主cluster由 PostgreSQL 集群充当属主。该字段的枚举定义同样见 api/v1/scheduledbackup_types.gonone;self;cluster且默认值为none。按需备份On-Demand Backups按需备份允许你随时手动触发备份操作方式是创建一个Backup资源。完整选项见 API 参考中的BackupSpec。示例发起一次按需备份要开始一次按需备份应用类似下面的Backup请求自定义资源apiVersion: postgresql.cnpg.io/v1 kind: Backup metadata: name: backup-example spec: method: barmanObjectStore cluster: name: pg-backup在这个例子中operator 将使用barman-cloud-backup工具编排备份过程并把备份存放到已配置的对象存储中。BackupSpec在 api/v1/backup_types.go 中定义其中method字段的取值枚举为barmanObjectStore;volumeSnapshot;plugin默认值为barmanObjectStoretarget字段可选primary;prefer-standby。同时BackupSpec带有一条 OpenAPI 校验规则BackupSpec is immutable once set创建后不可变。监控备份进度使用以下命令查看备份状态kubectl describe backup backup-example备份进行中时输出类似Name: backup-example Namespace: default ... Spec: Cluster: Name: pg-backup Status: Phase: running Started At: 2020-10-26T13:57:40Z Events: none备份成功后phase变为completed输出会附带更多元数据Name: backup-example Namespace: default ... Status: Backup Id: 20201026T135740 Destination Path: s3://backups/ Endpoint URL: http://minio:9000 Phase: completed S3 Credentials: Access Key Id: Name: minio Key: ACCESS_KEY_ID Secret Access Key: Name: minio Key: ACCESS_SECRET_KEY Server Name: pg-backup Started At: 2020-10-26T13:57:40Z Stopped At: 2020-10-26T13:57:44Z从源码看备份生命周期由 api/v1/backup_types.go 中定义的BackupPhase枚举驱动包括pending、started、running、finalizing卷快照场景下已生成VolumeSnapshotContent但仍在等待readyToUse标志、completed、failed、walArchivingFailing与invalid backup definition。备份控制器的核心入口位于 internal/controller/backup_controller.go它根据status.phase判断是否终结completed/failed。:::info 重要提示 按需备份不包含PostgreSQL 超级用户或应用用户的 Kubernetes Secrets。你应在更广的 Kubernetes 集群备份策略中纳入这些 Secret。 :::备份方法Backup MethodsCloudNativePG 当前支持以下备份方法可用于定时与按需备份plugin—— 使用 CNPG-I 插件需要.spec.pluginConfigurationvolumeSnapshot—— 使用原生 Kubernetes 卷快照barmanObjectStore—— 使用 Barman Cloud 对接对象存储自 v1.26 起弃用推荐迁移到 Barman Cloud Plugin但为向后兼容仍是默认值。通过.spec.method字段指定方法默认barmanObjectStore。该默认值在 api/v1/backup_types.go 与 api/v1/scheduledbackup_types.go 中均以kubebuilder:default:barmanObjectStore声明。如果你的集群配置了卷快照能力可以这样启用定时快照备份spec: method: volumeSnapshot若要使用 Barman Cloud Plugin 作为备份方法需设置method: plugin并相应配置插件可参考插件文档中“Performing a Base Backup”一节的示例。对于plugin方法你还可以在pluginConfiguration中传入插件名name与键值对parameters见 api/v1/backup_types.go 的BackupPluginConfiguration。从备机执行备份Backup from a Standby执行基础备份需要读取 PostgreSQL 实例的整个磁盘数据集这可能引发 I/O 争用影响活跃工作负载的性能。为降低这种影响CloudNativePG 支持从备机standby实例执行备份充分利用 PostgreSQL 内置的从只读副本执行备份的能力。默认情况下备份在集群中数据最新的副本most up-to-date replica上执行如果没有可用副本则回退到主实例primary。:::note 本节示例聚焦于备份目标选择未考虑备份方法spec.method因为它与当前讨论的范围无关。 :::工作原理当目标为prefer-standby默认行为时CloudNativePG 会尝试识别同步程度最高的备节点在该备节点上运行备份流程若无可用备库则回退到主库。该策略最大程度地减少了对主库工作负载的干扰。:::warning 尽管备库可能并不总是与主库完全同步但从首个可用备份到最近归档 WAL 之间的时间连续体上看这通常无关紧要——基础备份本质上代表恢复操作包括 PITR的起点。与pg_basebackup的行为一致从在线备库备份时我们不会强制在主库上切换 WAL。在写入活动较低的部署中这可能在短期内archive_timeout生效之前产生意外结果。 :::源码佐证备份目标的选择逻辑实现在 internal/controller/backup_controller.go 的getBackupTargetPod函数中。该函数首先基于集群级cluster.Spec.Backup.Target与备份级backup.Spec.Target后者优先级更高确定目标策略随后遍历受管实例只挑选已就绪且镜像与大版本升级状态匹配podHasLatestMajorImage即备份不应在大版本升级期间执行的 Pod当策略为BackupTargetPrimary时选择主实例 Pod为BackupTargetStandby或空串时选择非主实例 Pod若没有合适的就绪实例则回退到主实例targetPod nil时直接获取cluster.Status.TargetPrimary对应的 Pod。强制在主库执行备份要始终在主实例上执行备份在集群配置中显式将备份目标设为primaryapiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: [...] spec: backup: target: primary:::warning 使用primary作为目标时需格外谨慎尤其是使用卷快照的冷备份——这需要临时关闭主实例将中断所有写操作。单实例集群也要注意同样的问题即使你未显式设置目标。 :::覆盖集群级目标你可以在每次备份时覆盖集群级目标使用Backup或ScheduledBackup资源均可。以下是一次按需备份的示例apiVersion: postgresql.cnpg.io/v1 kind: Backup metadata: [...] spec: cluster: name: [...] target: primary在此示例中即使集群默认目标为prefer-standby备份也会从主实例执行。保留策略Retention PoliciesCloudNativePG 正朝着备份无关架构演进备份职责被委托给外部CNPG-I 插件。这些插件预期提供更高级、可定制的数据保护特性包括比 CloudNativePG 内置能力更复杂的保留管理。作为这一过渡的一部分Cluster资源中的spec.backup.retentionPolicy字段已弃用并将在未来版本中移除。更多保留特性细节请参考所选插件的文档例如 Barman Cloud Plugin 的 Retention Policies 章节。:::info 重要提示 建议用户依赖所用备份插件提供的保留机制这能带来更好的灵活性与所用备份方法的一致性。 :::历史背景在原生 Barman Cloud 集成中详见 docs/src/appendixes/backup_barmanobjectstore.md保留策略基于**恢复窗口recovery window**概念它聚焦于可恢复点Point of RecoverabilityPoR——一个由当前时间 - 恢复窗口决定的移动时间点。第一个有效备份是按时间逆序排列的、早于 PoR 的第一个可用备份。CloudNativePG 必须保证能从第一个有效备份出发恢复到 PoR 与最近成功归档 WAL 文件之间的任意时间点。早于第一个有效备份的基础备份会被标记为obsolete过期并在下一次备份完成后永久删除。内部实现上该功能调用barman-cloud-backup-delete --retention-policy RECOVERY WINDOW OF {{ 保留值 }} {{ 保留单位 }}。附对象存储备份与卷快照备份的深入实践为帮助你进一步落地这里补充两份附录文档中的关键实操细节。对象存储备份要点原生 Barman Cloud 集成依赖镜像内置barman-cli-cloud仓库推荐使用ghcr.io/cloudnative-pg/postgresql社区镜像并通过barman-cloud-wal-archive、barman-cloud-check-wal-archive、barman-cloud-backup、barman-cloud-backup-list、barman-cloud-backup-delete等工具编排连续备份基础备份产物为tarball详见 docs/src/appendixes/backup_barmanobjectstore.md。需要注意的关键点桶必须预先创建自 Barman Cloud 3.16 起多数命令不再自动创建目标桶只有barman-cloud-check-wal-archive会创建。请在创建引用桶的Cluster资源之前先创建并配置好对象存储桶以保证未来可靠运行。WAL 压缩与加密可在.spec.backup.barmanObjectStore.wal中配置compression与encryption也可在桶上直接配置加密operator 会优先采用桶配置。并行 WAL 归档当带宽允许时可通过wal.maxParallel例如maxParallel: 8让实例管理器并行归档最多 8 个就绪 WAL提升吞吐。支持的压缩算法bzip2、gzip、lz4、snappy、xz、zstd备份与 WAL 的压缩设置相互独立不同算法在归档时间、恢复时间与体积上差异明显需按场景选择文档提供了一份基于本地 MinIO 的实测表例如不压缩 395MB 数据gzip后约 91MB、比约 4.3:1。对象标签若镜像内 Barman ≥ 2.18可通过tags作用于基础备份与归档 WAL与historyTags作用于归档历史文件为备份对象打标签。附加命令参数data.additionalCommandArgs备份、data.restoreAdditionalCommandArgs恢复、wal.archiveAdditionalCommandArgs、wal.restoreAdditionalCommandArgs可向barman-cloud-*命令追加参数恢复侧参数取自externalClusters中对应barmanObjectStore而非.spec.backup。卷快照备份要点CloudNativePG 是首批直接以声明式方式利用 Kubernetes 原生 Volume Snapshot API 进行备份与恢复的数据库 Operator 之一详见 docs/src/appendixes/backup_volumesnapshot.md。要点包括前置条件用于动态供应 PostgreSQL 卷的每个存储类storage、walStorage都必须支持卷快照且通常需要配套的VolumeSnapshotClass。配置方式在Cluster的backup.volumeSnapshot节区设置className若PGDATA与 WAL 使用不同存储类可用walClassName单独指定默认与className相同。热/冷备份控制默认请求在线/热备份online: true并遵循 PostgreSQL 低层基础备份 API 的默认行为启动时不立即请求检查点、结束时等待WAL 归档器处理最后一段。可通过onlineConfiguration.immediateCheckpoint对应pg_backup_start/pg_start_backup()的fast参数默认true与onlineConfiguration.waitForArchive对应pg_backup_stop/pg_stop_backup()的wait_for_archive参数默认true调整。设置online: false即默认改为冷备份Backup/ScheduledBackup对象还可通过online与onlineConfiguration字段覆盖集群默认行为例如spec.online: false发起一次按需冷备份。对象持久化backup.volumeSnapshot.snapshotOwnerReference控制VolumeSnapshot对象的属主与生命周期none保留、backup随Backup删除、cluster随集群删除VolumeSnapshotContent的最终去留由VolumeSnapshotClass的deletionPolicyRetain/Delete决定。快照超时重试backup.cnpg.io/volumeSnapshotDeadline注解控制卷快照错误的重试截止时间默认10 分钟每10 秒重试一次该注解可加在Backup或ScheduledBackup上定时备份创建的Backup会自动继承。关于逻辑备份pg_dump的边界CloudNativePG 的备份体系专注于物理备份。虽然 PostgreSQL 也支持使用pg_dump工具进行逻辑备份但逻辑备份不适合业务连续性business continuity场景也不受 CloudNativePG 管理。如果你仍需要使用pg_dump请参考 Troubleshooting / Emergency backup 一节的指导。该节的紧急备份示例仅限紧急情况使用临时文件必须按组织的数据保护策略保存且 dump 文件存于执行kubectl的客户端机器上# 从 cluster-example-1 pod 对 app 数据库做自定义格式逻辑备份 kubectl exec cluster-example-1 -c postgres \ -- pg_dump -Fc -d app app.dump # 恢复到 new-cluster-example-1主实例的 app 数据库 kubectl exec -i new-cluster-example-1 -c postgres \ -- pg_restore --no-owner --roleapp -d app --verbose app.dump若有多个角色或数据库还需使用pg_dumpall -g备份全局对象并逐个数据库执行恢复操作。结语从本文走向可落地的容灾方案总结 CloudNativePG 备份体系的设计主线概念层WAL 归档连续备份、RPO ≤ 5 分钟 物理基础备份恢复起点缺一不可冷/热备份按 RPO 需求取舍方案层对象存储备份需 WAL 归档、仅热备、支持保留策略与卷快照备份可选 WAL、支持冷热备、增量差异、无保留策略按存储能力与 VLDB 规模权衡见上文的对比汇总表操作层日常备份优先使用ScheduledBackup六段 cron、immediate、suspend、backupOwnerReference临时备份使用Backup并通过kubectl describe backup观察phase从running到completed的完整生命周期目标层默认prefer-standby把备份负载导向最新备机降低主库 I/O 争用必要时可逐备份覆盖为primary演进层自 v1.26 起原生 Barman Cloud 与retentionPolicy均进入弃用通道新部署应迁移到 Barman Cloud Plugin 与更广义的 CNPG-I 插件生态。建议你在生产环境遵循以下清单始终配置 WAL 归档使用volumeSnapshot或plugin方法建立每周一次的基础备份定期演练从备份恢复并计量 RTO将超级用户/应用用户 Secret 纳入集群级备份策略迁移到插件化备份方案以获得可定制的保留管理。【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考