Zum Hauptinhalt springen

Sichern & Wiederherstellen

Die Sicherung des Data Lake gibt es in zwei Arten. Je nachdem, was verloren wurde, wird die passende gewählt.

Logischer DumpPhysische Sicherung
Befehlpd backup (ohne Argumente)pd backup run … sowie der täglich vom Scheduler gestartete Job
WasPostgreSQL-Benutzerdatenbank als SQL-Datei (pg_dump)Bei PostgreSQL pgBackRest, bei Aster TSDB Medusa – die Datendateien selbst
Wohin/data1/pp-data/postgres/dump/<db>-YYYYmmdd_HHMMSS.sql/data1/pp-backup/ (pgbackrest/ · medusa/) + Protokoll history.jsonl
Wiederherstellenpd recover <파일> — eine pp-DBpd backup restore … — das gesamte Datenverzeichnis
Voll / diff · Point-in-Time-RecoveryNein (immer vollständig)Ja. Bei PostgreSQL --target für Point-in-Time-Recovery (PITR)

Die Backups, die der Scheduler nachts erstellt, und die, die der Bediener über pd backup run auslöst, verwenden dasselbe Toolkit (plantpulse-backup) und landen im selben history.jsonl. Auch der Sicherungsbildschirm in der Verwaltungskonsole ruft dieselben Befehle auf.

Kein systemd-Timer

Die maßgebliche Quelle für den Sicherungszeitplan ist die Tabelle backup_schedule der datalake-DB; gelesen und ausgeführt wird sie vom Quartz-Scheduler in plantpulse-datalake-admin-api (läuft nur auf dem Master).

Unit-Dateien liegen zwar im Image bei, aber keine einzige ist installiert — PID 1 im Container ist nicht systemd, sondern bash, daher können sie von vornherein nicht laufen. Der Versuch, sie über systemctl list-timers zu prüfen, liefert nur «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"}

Änderungen nimmt man über pd backup schedule set --job <잡> --cron "<Quartz cron>" oder den Sicherungsbildschirm der Verwaltungskonsole vor. cron nutzt das Quartz-Format (Sekunde Minute Stunde Tag Monat Wochentag), also sechs Felder.

Automatische Sicherung — bereits aktiviert​

JobWannWas
postgres-difftäglich 01:30PostgreSQL-Differenz
postgres-fullSonntag 01:00PostgreSQL-Vollsicherung
cassandra-difftäglich 01:20Aster-TSDB-Differenz
cassandra-fullSonntag 00:10Aster-TSDB-Vollsicherung
purgeSonntag 03:00Bereinigung gemäß 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 in pd backup schedule den Wert never hat, wurde noch nie ausgeführt (normal); bei fail (…) liegt ein Fehler der letzten Ausführung vor. Eine Aster-TSDB-Gruppe mit - bei SIZE hat keine Größeninformation, ist aber nicht 0. Gruppen mit error bzw. incomplete bei STATUS 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 (Werktage). Falsche Ausdrücke werden bei der Validierung abgewiesen, es wird nichts geschrieben. Die Auswahl bleibt in /data1/pp-data/backup/schedule.json erhalten und wird auch nach einem Container-Neustart bei jedem Start erneut angewendet.

Der globale Schalter gewinnt. Wird in der Sidecar PP_BACKUP_SCHEDULE_ENABLED=false gesetzt, protokolliert der Scheduler für alle Jobs nur «skipped», egal was pro Job aktiviert ist.

Vor größeren Arbeiten – ein weiterer Zeitpunkt​

Vor großen Schritten wie Upgrade, Wiederherstellung oder Konfigurationsänderung wird ein zusätzlicher «jetzt»-Zeitpunkt gesichert.

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

Es läuft nur einer gleichzeitig — wenn bereits einer läuft, wird mit Exit 3 abgelehnt. Selbst wenn das Tool mit 0 endet, gilt die Sicherung als fail, wenn das Repository nicht gewachsen ist.

Wiederherstellung — mit physischer Sicherung​

Letztes Mittel. Alle Schreibvorgänge nach dieser Sicherung gehen verloren. Dieses Verb erzwingt den Ablauf — ohne --yes wird die Aufforderung ausgegeben, --dry-run auszuführen.

# 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 bei PostgreSQL kann eine Uhrzeit wie --target "2026-09-04 12:00:00" angegeben werden. Nach Einspielen der Sicherung werden die WAL-Dateien bis zu diesem Zeitpunkt repliziert. Bei Aster TSDB führt --target zu Exit 2.
  • Die Wiederherstellung von Aster TSDB stoppt und startet Aster TSDB selbst durch Medusa; wird eine Diff-Sicherung gewählt, wird auch die referenzierte Vollsicherung mit eingespielt.
  • Läuft nicht auf Workern. Wiederherstellung ist Sache des Masters; Worker folgen ihm.

Wiederherstellung — mit logischem Dump​

Eine pp-Datenbank wird auf den Zeitpunkt des logischen Dumps zurückgesetzt. Das ist nicht umkehrbar und es gibt keinen Trockenlauf — sobald der Dateiname übergeben wird, 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

Der Ablauf entspricht Schritt 3 bis 6 der physischen Wiederherstellung (Dienst zuerst stoppen, nach Abschluss wieder starten). Dumps anderer Datenbanken (temporal · hive · kestra) landen ebenfalls in pp — für diese DBs ist die physische Sicherung die richtige Wahl.

Nicht empfohlen​

  • --dry-run nicht ohne --yes ausführen. Eine Wiederherstellung, deren Plan man nicht gesehen hat, ist eine Wiederherstellung, bei der man nicht weiß, «auf welchen Zeitpunkt stellt man zurück».
  • Nicht über einem laufenden Dienst wiederherstellen. Ein Verbundener Dienst hält an einer getrennten Sitzung fest und erzeugt Fehler.
  • Sperrdatei (/data1/pp-backup/pd-backup.lock) nicht manuell löschen. Eine Sperre eines toten Prozesses wird von pd als frei gelesen.
  • Dumps nicht in /data1/pp-temp kopieren. pd clean entfernt sie.

Verwandte Dokumente​