备份 · 恢复
数据湖的备份有两种类型。根据您丢失的内容来选择。
| 逻辑转储 | 物理备份 | |
|---|---|---|
| 命令 | pd backup（不带参数） | pd backup run …，以及调度器每天运行的作业 |
| 备份内容 | 将 PostgreSQL 用户数据库导出为 SQL 文件(pg_dump) | PostgreSQL 使用 pgBackRest，Aster TSDB 使用 Medusa 来备份数据文件本身 |
| 存储位置 | /data1/pp-data/postgres/dump/<db>-YYYYmmdd_HHMMSS.sql | /data1/pp-backup/（pgbackrest/ · medusa/）+ 记录 history.jsonl |
| 恢复方式 | pd recover <파일> — pp 一个数据库 | pd backup restore … — 整个数据目录 |
| 全量/差异 · 时间点恢复 | 无（始终全量） | 有。PostgreSQL 可通过 --target 进行时间点恢复(PITR) |
调度器在夜间执行的备份与操作员通过 pd backup run 执行的备份使用相同的工具集（plantpulse-backup），并输出到相同的 history.jsonl 位置。管理控制台的备份界面也调用相同的命令。
备份计划的权威来源是 datalake 数据库中的 backup_schedule 表，而读取并执行该表内容的是
plantpulse-datalake-admin-api 中的 Quartz 调度器（仅在主节点上运行）。
系统单元文件已包含在镜像中，但实际上并未安装任何单元 — 因为容器的 PID 1 不是
systemd，而是 bash，因此根本无法运行。尝试通过 systemctl list-timers 检查
只会看到“System has not been booted with systemd”消息。
docker exec plantpulse-datalake pd backup schedule --json | head -c 400
# "manager":"quartz","systemctl_present":false,"unit_dir":null,
# "scheduler":{"name":"plantpulse-datalake-admin-api","kind":"quartz","runs_on":"MASTER"}
更改设置的位置是 pd backup schedule set --job <잡> --cron "<Quartz cron>" 或管理控制台的备份界面。
cron 采用 Quartz 格式（秒 分 时 日 月 周），因此有六个字段。
自动备份 — 已启用
| 作业 | 时间 | 内容 |
|---|---|---|
postgres-diff | 每天 01:30 | PostgreSQL 差异备份 |
postgres-full | 周日 01:00 | PostgreSQL 全量备份 |
cassandra-diff | 每天 01:20 | Aster TSDB 差异备份 |
cassandra-full | 周日 00:10 | Aster TSDB 全量备份 |
purge | 周日 03:00 | 按保留策略清理 |
docker exec plantpulse-datalake pd backup schedule # 일정 · 마지막 결과 · 다음 실행
docker exec plantpulse-datalake pd backup list # 세트 목록
docker exec plantpulse-datalake pd backup status # 지금 도는 것이 있나
如果 pd backup schedule 的 LAST 列为 never，表示尚未执行过一次（正常），如果是 fail (…) 则表示上次执行出错。当 SIZE 为 - 的 Aster TSDB 集合，没有大小信息，但并不为 0。我们不会使用 STATUS 为 error · incomplete 的集合进行恢复。
修改计划
docker exec plantpulse-datalake pd backup schedule set --job postgres-diff --calendar "*-*-* 02:45:00"
docker exec plantpulse-datalake pd backup schedule set --job purge --enabled false
docker exec plantpulse-datalake pd backup schedule reset --job postgres-diff # 그 잡만 기본으로
docker exec plantpulse-datalake pd backup schedule reset # 전부 기본으로
日历采用 systemd 语法 — *-*-* 02:45:00（每天 02:45）、Sun *-*-* 01:00:00（周日 01:00）、Mon..Fri *-*-* 23:30:00（工作日）。错误的表达式会在验证阶段被拒绝，不会写入任何内容。所选内容会保留在 /data1/pp-data/backup/schedule.json 中，因此即使重新创建容器也会在每次启动时重新应用。
全局开关优先。 如果在 sidecar 中写入 PP_BACKUP_SCHEDULE_ENABLED=false，则无论各作业如何启用，调度器都只会记录“skipped”并结束。
重大操作前 — 再增加一个时间点
在升级、恢复、配置更改等重大操作之前，需要再创建一个“当前时刻”的备份。
docker exec plantpulse-datalake pd backup run --engine postgres --type diff
docker exec plantpulse-datalake pd backup run --engine cassandra --type full
docker exec plantpulse-datalake pd backup # 그리고 SQL 사본 하나
一次只能进行一个操作 — 如果正在进行，则返回退出代码 3 拒绝。即使工具以 0 结束，如果存储库没有增长，则判定为 fail。
恢复 — 使用物理备份
这是最后的手段。 该集合之后的所有写入操作都会丢失。此命令强制遵循流程 — 如果未加上 --yes 就执行，则会拒绝并要求您先执行 --dry-run。
# 1. 세트 고르기 — STATUS 가 ok 인 것만
docker exec plantpulse-datalake pd backup list
# 2. 드라이런 — 전제조건 일곱과 «정확히 무슨 명령이 무엇을 덮어쓸지». 아무것도 안 건드린다
docker exec plantpulse-datalake pd backup restore --engine postgres --set 20260903-013040F_20260904-135107D --dry-run
# preconditions (all pass - ready) 가 나올 때까지 실행하지 않는다
# 3. pp 를 쓰는 서비스를 역순으로 내린다 — storage 는 둔다 (PostgreSQL 은 이 동사가 스스로 멈추고 띄운다)
docker exec plantpulse-datalake pd stop admin-api
docker exec plantpulse-datalake pd stop data-gateway
docker exec plantpulse-datalake pd stop workflow
docker exec plantpulse-datalake pd stop cep
docker exec plantpulse-datalake pd stop timeseries
# 4. 실행
docker exec plantpulse-datalake pd backup restore --engine postgres --set 20260903-013040F_20260904-135107D --yes
# 5. 끝 줄 "done in NNs - restart the dependent services" 를 보고
docker exec plantpulse-datalake pd restart
# 6. 확인
docker exec plantpulse-datalake pd status # 0 STOPPED
docker exec plantpulse-datalake pd backup status # 락이 free
- 时间点恢复(PITR) — 仅 PostgreSQL 可以像
--target "2026-09-04 12:00:00"那样指定时间。在该集合恢复后，将 WAL 重放到指定时间。如果对 Aster TSDB 指定--target，则退出代码 2。 - Aster TSDB 的恢复由 Medusa 自行停止并启动 Aster TSDB，如果选择差异集，则其引用的全量备份也会一并部署。
- 不会在工作节点上运行。 恢复是主节点的工作，工作节点会跟随其进行。
恢复 — 使用逻辑转储
将 pp 数据库一个恢复到逻辑转储的时间点。此操作不可逆且无试运行 — 一旦传入文件名，DROP DATABASE "pp" 就会执行。
ls -l /data1/pp-data/postgres/dump/ # 날짜와 크기를 먼저 눈으로
docker exec -it plantpulse-datalake pd recover # 목록을 찍고 파일 이름을 묻는다 (Ctrl+C 취소)
docker exec plantpulse-datalake pd recover pp-20260904_131500.sql
流程与物理恢复的步骤 3 至 6 相同（先停止服务，完成后启动服务）。即使导入其他数据库（temporal · hive · kestra）的转储，也会进入 pp — 这些数据库应使用物理备份。
请勿操作
- 在未执行
--dry-run的情况下，请勿执行--yes。 未查看计划的恢复，就是不知道“恢复到哪个时间点”的恢复。 - 不要在运行中的服务上执行恢复。 已连接的服务会挂住已断开的会话并不断报错。
- 不要手动删除锁文件（
/data1/pp-backup/pd-backup.lock）。 死进程的锁会被pd读取为 free。 - 不要将转储复制到
/data1/pp-temp。pd clean会将其删除。
相关文档
- 备份与恢复 — 卷备份、异地复制、灾难恢复场景
pdCLI- 管理控制台 — 备份界面