Zum Hauptinhalt springen

Sicherung · Wiederherstellung

Die Sicherung der Datenlake erfolgt in zwei Arten. Sie wählen je nachdem, was Sie verloren haben.

Logisches DumpPhysische Sicherung
Befehlpd backup (ohne Argumente)pd backup run … und täglicher systemd-Timer
WasPostgreSQL-Benutzer-DB als SQL-Datei(pg_dump)PostgreSQL via pgBackRest, Cassandra via Medusa sichert die Datendateien selbst
Wohin/data1/pp-data/postgres/dump/<db>-YYYYmmdd_HHMMSS.sql/data1/pp-backup/ (pgbackrest/ · medusa/) + Protokoll history.jsonl
Wiederherstellenpd recover <파일> — pp eine einzelne DBpd backup restore … — gesamtes Datenverzeichnis
Full / Diff · Point-in-TimeNein (immer vollständig)Ja. PostgreSQL unterstützt Point-in-Time-Recovery (PITR) via --target

Die nächtliche Sicherung des Timers und die vom Operator via pd backup run ausgelöste Sicherung durchlaufen dasselbe Toolkit(plantpulse-backup) und landen im selben history.jsonl. Der Sicherungsbildschirm der Verwaltungskonsole ruft denselben Befehl auf.

Automatische Sicherung — bereits aktiviert​

JobWannWas
postgres-diffTäglich 01:30PostgreSQL differenziell
postgres-fullSonntag 01:00PostgreSQL vollständig
cassandra-diffTäglich 01:20Cassandra differenziell
cassandra-fullSonntag 00:10Cassandra vollständig
purgeSonntag 03:00Aufräumen nach Aufbewahrungsrichtlinie
docker exec plantpulse-datalake pd backup schedule     # 일정 · 마지막 결과 · 다음 실행
docker exec plantpulse-datalake pd backup list         # 세트 목록
docker exec plantpulse-datalake pd backup status       # 지금 도는 것이 있나

Wenn die Spalte LAST von pd backup schedule den Wert never hat, ist dies normal (noch nie ausgeführt); bei fail (…) liegt ein Fehler der letzten Ausführung vor. Cassandra-Sets mit SIZE = - haben keine Größeninformation, sind aber nicht 0. Sets, bei denen STATUS error oder incomplete ist, werden nicht wiederhergestellt.

Zeitplan ändern​

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                         # 전부 기본으로

Der Kalender verwendet systemd-Syntax — *-*-* 02:45:00 (täglich 02:45), Sun *-*-* 01:00:00 (Sonntag 01:00), Mon..Fri *-*-* 23:30:00 (Wochentage). Ungültige Ausdrücke werden bei der Validierung abgelehnt und nichts gespeichert. Die Auswahl wird in /data1/pp-data/backup/schedule.json beibehalten und beim Container-Rebuild bei jedem Start erneut angewendet.

Der globale Schalter gewinnt. Wenn Sie PP_BACKUP_SCHEDULE_ENABLED=false in der Sidecar setzen, protokollieren Timer jobübergreifend nur als «skipped» und beenden sich.

Vor großen Operationen — einen zusätzlichen Zeitpunkt jetzt​

Vor großen Operationen wie Upgrade, Wiederherstellung oder Konfigurationsänderung erstellen Sie einen zusätzlichen Snapshot «in diesem Moment».

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

Immer nur eine gleichzeitig — wenn eine läuft, wird sie mit Exit-Code 3 abgelehnt. Auch wenn das Werkzeug mit 0 beendet wird: Wenn das Repository nicht gewachsen ist, wird es als fail eingestuft.

Wiederherstellung — aus physischer Sicherung​

Das ist das letzte Mittel. Alle Schreibvorgänge nach diesem Snapshot gehen verloren. Dieses Verb erzwingt ein Verfahren — wenn Sie es ohne --yes aufrufen, wird es abgelehnt und Sie werden aufgefordert, --dry-run zu tun.

# 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
  • Point-in-Time-Recovery (PITR) — nur PostgreSQL akzeptiert einen Zeitstempel wie in --target "2026-09-04 12:00:00". Der Snapshot wird wiederhergestellt, dann werden die WAL-Dateien bis zu diesem Zeitpunkt wiedergegeben. Wenn Sie --target für Cassandra angeben, ist das Exit-Code 2.
  • Bei der Cassandra-Wiederherstellung stoppt und startet Medusa Cassandra selbst; wenn Sie einen Diff-Set auswählen, wird auch sein referenziertes Full-Set installiert.
  • Läuft nicht auf Workern. Wiederherstellung ist eine Master-Aufgabe; Worker folgen ihr nach.

Wiederherstellung — aus logischem Dump​

pp stellt eine einzelne Datenbank auf den logischen Dump-Zeitpunkt zurück. Kein Rollback und kein Dry-Run — sobald Sie den Dateinamen übergeben, wird DROP DATABASE "pp" ausgeführt.

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

Das Verfahren entspricht den Schritten 3–6 der physischen Wiederherstellung (Dienst zuerst stoppen, dann starten). Wenn Sie Dumps anderer Datenbanken (temporal, hive, kestra) einfügen, landen sie in pp — diese DBs erfordern physische Sicherung.

Was Sie nicht tun sollten​

  • Rufen Sie --yes nicht ohne --dry-run auf. Eine Wiederherstellung ohne visuellen Plan ist eine Wiederherstellung, bei der Sie nicht wissen, zu welchem Zeitpunkt Sie zurückgehen.
  • Stellen Sie nicht über einen laufenden Dienst wieder her. Verbundene Dienste halten an fehlgeschlagenen Sitzungen fest und werfen Fehler aus.
  • Löschen Sie Lock-Dateien(/data1/pp-backup/pd-backup.lock) nicht von Hand. pd liest Dead-PID-Locks als free.
  • Kopieren Sie Dumps nicht in /data1/pp-temp. pd clean löscht sie.

Zugehörige Dokumentation​