メインコンテンツまでスキップ

バックアップ・リストア

データレイクのバックアップは2種類です。失ったものに応じて選びます。

論理ダンプ物理バックアップ
コマンドpd backup（引数なし）pd backup run …、およびスケジューラが毎日実行するジョブ
対象PostgreSQL ユーザー DB を 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 DB 1つpd backup restore … — データディレクトリ全体
full / diff・時点復元なし（常に全体）あり。PostgreSQL は --target で時点復元（PITR）

スケジューラが夜間に取得するバックアップと、オペレータが pd backup run で取得するバックアップは同じツールキット（plantpulse-backup）を通り、同じ history.jsonl に残ります。管理コンソールのバックアップ画面も同じコマンドを呼び出します。

systemd タイマーではありません

バックアップスケジュールの正本は datalake DB の 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 形式（秒 分 時 日 月 曜日）なので6つのフィールドです。

自動バックアップ — すでに有効です​

ジョブいつ何を
postgres-diff毎日 01:30PostgreSQL 差分
postgres-full日曜日 01:00PostgreSQL 全体
cassandra-diff毎日 01:20Aster TSDB 差分
cassandra-full日曜日 00:10Aster 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 に残り、コンテナを再作成しても毎回起動時に再適用されます。

グローバルスイッチが優先されます。 サイドカーに PP_BACKUP_SCHEDULE_ENABLED=false を書くと、ジョブ単位で何を有効にしてもスケジューラは «skipped» と記録するだけで終わります。

大規模作業の前に — 今の時点をもう1つ​

アップグレード・リストア・設定変更などの大規模作業の直前に、「今この瞬間」をもう1つ残します。

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 사본 하나

一度に1つだけ実行されます — 実行中なら exit 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 を与えると exit 2。
  • Aster TSDB のリストアは Medusa が Aster TSDB を自ら停止・起動し、diff セットを選ぶとそれが参照する full も一緒に展開されます。
  • ワーカーでは動作しません。 リストアはマスターの仕事で、ワーカーはそれに追従します。

リストア — 論理ダンプから​

pp データベース1つだけを論理ダンプ時点に戻します。元に戻せずドライランもありません — ファイル名を渡した瞬間 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 に入ります — それらの DB は物理バックアップが適切です。

しないでください​

  • --dry-run なしで --yes を実行しないでください。 計画を目で確認していないリストアは「どの時点に戻るか」を知らないリストアです。
  • 稼働中のサービスの上でリストアしないでください。 接続していたサービスは切断されたセッションを掴んだままエラーを吐き続けます。
  • ロックファイル（/data1/pp-backup/pd-backup.lock）を手で削除しないでください。 死んだ pid のロックは pd が free として読み取ります。
  • ダンプを /data1/pp-temp にコピーして置かないでください。 pd clean が削除します。

関連文書​