Prometheus灾备需依赖外部设计，核心方案包括：快照备份（启用admin API后调用/snapshot接口，skip_head=false确保包含内存数据）、文件系统级备份（需静默或增量同步）和远程存储（如Thanos实现多副本与故障转移），并须同步备份Operator配置。
Prometheus 本身不提供内置集群或高可用能力，灾备必须靠外部设计。核心目标是避免单点故障导致监控中断、历史数据丢失，以及保障业务连续性所需的快速恢复能力。
快照备份：最推荐的原生方案
Prometheus 提供了 `/api/v1/admin/tsdb/snapshot` 接口，在运行时创建一致性快照，不影响正常采集。 - 启动时需启用 admin API：添加 `--web.enable-admin-api` 参数 - 调用命令：`curl -XPOST 'http://localhost:9090/api/v1/admin/tsdb/snapshot?skip_head=false'` - `skip_head=false`（默认）会包含内存中未持久化的最新数据，确保不丢最近2小时样本 - 快照生成后存于 `data/snapshots/` 下，目录结构与原始数据一致，可直接用于恢复建议配合 CronJob 或 systemd timer 每日自动触发，并保留最近7–30天快照。注意快照不自动清理，需自行加删除逻辑。
文件系统级备份：简单直接，但需停机或规避写入风险
直接打包 `--storage.tsdb.path` 指定的数据目录（如 `data/`），结构包括： - `wal/`：预写日志，含最新未刷盘数据 - `chunks_head/` 和 `index_head/`：内存映射的活跃数据 - 若干以时间命名的块目录（如 `01GZXJ8ZQ8Y6T2A5K2R3F4B5C6/`）：已压缩的持久化时序块操作时务必保证 Prometheus 处于静默状态，或使用 `rsync --delete-during` 等支持增量同步的工具降低影响。不建议在 NFS/EFS 类非 POSIX 文件系统上直接备份，易引发数据损坏。
远程存储 + 故障转移：面向长期可用的架构级方案
通过 `remote_write` 将指标实时推送至长期存储（如 Thanos、VictoriaMetrics、InfluxDB），实现： - 数据多副本保存，跨区域容灾 - Prometheus 实例宕机后，可通过 `remote_read` 从远端读取历史数据继续查询 - 支持横向扩展多个 Prometheus 实例，搭配服务发现做负载分片实际部署中，推荐组合使用：本地快照用于分钟级恢复，远程存储用于小时级以上回溯和跨集群切换。Thanos Sidecar 是目前最成熟的集成方式，能自动上传块并提供统一查询入口。
Operator 环境下的配置备份不可忽略
在 Kubernetes 中使用 Prometheus Operator 时，CRD 资源本身也是关键资产： - `Prometheus`、`ServiceMonitor`、`PodMonitor`、`PrometheusRule` 等定义了采集逻辑和告警规则 - 这些 YAML 配置应纳入 GitOps 流程，版本化管理 - 可用 Velero 定时备份整个命名空间，或导出为清单：`kubectl get prometheuses, servicemonitors, prometheusrules -n monitoring -o yaml > backup-config.yaml`配置丢失比数据丢失更难修复——规则重建耗时，且容易遗漏业务关键阈值。
