Prometheus 备份需兼顾一致性、时效性与可恢复性，推荐快照备份（分钟级、运行时执行）、文件系统级备份（需停机或 rsync）及远程存储组合方案；恢复须停机清空 data 目录并校验版本兼容性。
Prometheus 本身不支持内置集群或自动高可用，备份与恢复必须依赖外部机制。核心数据指 TSDB 中的时间序列样本、元数据和 WAL 日志，丢失会导致监控断档、告警失效、历史分析不可用。关键是要兼顾一致性、时效性和可恢复性，不能只拷文件了事。
快照备份：推荐的原生分钟级方案
这是最安全、最轻量的备份方式，Prometheus 运行时即可执行，不影响采集。
- 启动 Prometheus 时必须加参数：
--web.enable-admin-api，否则无法调用快照接口 - 调用命令示例（保留内存中未刷盘数据）：
curl -XPOST 'http://localhost:9090/api/v1/admin/tsdb/snapshot?skip_head=false'
注意：skip_head=false 是默认值，但显式写出更稳妥，确保最近约 2 小时的活跃数据也被包含 - 快照生成后自动存入
data/snapshots/<时间戳>目录，结构与原始data/完全一致，可直接用于恢复 - 建议用 CronJob 或 systemd timer 每日触发，并配合脚本自动清理超过 7–30 天的旧快照，避免磁盘撑满
文件系统级备份：适合离线归档或迁移场景
直接打包整个 TSDB 数据目录（默认是 --storage.tsdb.path 指定路径），能获得完整副本，但风险更高。
- 目录内关键子项包括：
wal/（最新未持久化日志）、chunks_head/和index_head/（内存映射活跃数据）、以及多个以时间命名的01G.../块目录（已压缩的历史数据） - 若 Prometheus 正在运行，禁止直接 tar 或 cp 整个 data 目录，可能因 WAL 与块不同步导致数据损坏
- 安全做法有两种：一是先静默停机再备份；二是使用
rsync --delete-during增量同步，降低写入冲突风险 - 不建议在 NFS、EFS 等非 POSIX 兼容存储上直接备份，易引发元数据不一致
远程存储 + 快照组合：面向生产环境的灾备架构
单靠本地备份无法应对节点级故障或磁盘损坏，必须引入远程存储实现跨实例、跨区域冗余。
- 通过
remote_write配置将指标实时推送到 Thanos、VictoriaMetrics 或 InfluxDB 等长期存储，天然支持多副本与异地容灾 - Prometheus 实例宕机后，可通过
remote_read从远端读取历史数据，Grafana 查询不受影响 - Thanos Sidecar 是当前最成熟的选择：自动上传新生成的数据块、提供统一查询网关、支持对象存储（如 S3、MinIO）归档
- 实际部署建议分层：本地快照用于 5 分钟内快速回滚；远程存储支撑小时级以上回溯与主备切换
恢复操作要点：不是复制粘贴就完事
恢复失败往往源于细节疏忽，尤其在多实例或 Operator 管理环境中。
- 用快照恢复：停止 Prometheus → 清空原
data/目录 → 将data/snapshots/<name>/下全部内容复制到data/→ 启动服务 - 用文件备份恢复：同样需停机，且要确认目标 Prometheus 版本与备份时一致，TSDB 格式不兼容会导致启动失败
- 若使用 Prometheus Operator，必须同步备份 CRD 配置（如 Prometheus、Alertmanager、ServiceMonitor 资源），否则恢复后规则、抓取目标、告警路由全部丢失
- K8s 环境下，PVC 的 reclaimPolicy 若为 Delete，删除 Pod 时会连带清空数据，务必设为 Retain 并手动管理 PV 生命周期
