バックアップ・復元

データレイクのバックアップは2つの種類です。何を失ったかで選びます。

	論理ダンプ	物理バックアップ
コマンド	`pd backup`（引数なし）	`pd backup run …`、および毎日実行される systemd タイマー
何を	PostgreSQL ユーザー DB を SQL ファイルで（`pg_dump`）	PostgreSQL は pgBackRest、Cassandra は 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 に保存されます。管理コンソールのバックアップ画面も同じコマンドを実行します。

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

ジョブ	実行時刻	内容
`postgres-diff`	毎日 01:30	PostgreSQL 差分
`postgres-full`	日曜日 01:00	PostgreSQL 全体
`cassandra-diff`	毎日 01:20	Cassandra 差分
`cassandra-full`	日曜日 00:10	Cassandra 全体
`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 なら、まだ1度も実行されていない状態です（正常）。fail (…) なら最後の実行時のエラーです。SIZE が - である Cassandra セットはサイズ情報がないだけで 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 を再生します。Cassandra に --target を指定すると exit 2。
Cassandra の復元は Medusa が Cassandra を自動的に停止・起動し、差分セットを選択すると、それが参照する全体セットも一緒にインストールされます。
**ワーカーでは実行しません。**復元はマスターの役割で、ワーカーはそれに従います。

復元—論理ダンプから

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）を手動で削除しないでください。**デッドプロセスのロックは pd が free で読み込みます。
ダンプを /data1/pp-temp にコピーしておかないでください。pd clean が削除します。

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

スケジュールの変更​

大きな作業前に—現在時点をもう1つ​

復元—物理バックアップから​

復元—論理ダンプから​

しないでください​

関連ドキュメント​