Sicherung und Wiederherstellung

Datenschutz ist eine der wichtigsten Verantwortungen des Betriebs. PlantPulse sichert PostgreSQL, Cassandra, Dateien und Container-Volumen über das plantpulse-backup-Modul integriert.

Sicherungsbefehle werden «innerhalb» des Datalake-Containers ausgeführt

plantpulse-backup ist im plantpulse-datalake-Image enthalten. Weil alle Datenbanken in diesem Container laufen.

cd /opt/kopens/plantpulse-platform-docker/bin
./shell.sh                                              # 데이터레이크 진입
cd /opt/kopens/plantpulse-platform/plantpulse-backup/bin

Docker-Volumen-Sicherungen führen Sie nur auf dem Host aus (siehe §3 unten).

Schutzmaßnahmen auf einen Blick

Sicherungswerkzeug-Matrix

Werkzeug	Ziel	Methode	Kompression	Deduplizierung
pgBackRest	PostgreSQL	Vollsicherung / Differenziell / Inkrementell	gzip / zstd	✓
Medusa	Cassandra	Vollsicherung / Differenziell (Snapshots)	gzip	-
Restic	Dateien / Verzeichnisse	Inkrementell	zstd	✓
mc mirror	MinIO	Inkrementelle Synchronisierung	-	-
backup-volume.sh	Docker-Volumen	tar.gz-Snapshot	gzip	-

RPO / RTO – Empfohlene Ziele

Daten	RPO (Wiederherstellungspunkt)	RTO (Wiederherstellungszeit)	Empfohlene Sicherungshäufigkeit
PostgreSQL-Metadaten	1 Stunde	30 Minuten	1 x täglich Vollsicherung + stündliches WAL
Cassandra-Zeitreihen	24 Stunden	2 Stunden	1 x täglich Differenziell + 1 x wöchentlich Vollsicherung
MinIO-Objekte	24 Stunden	4 Stunden	Externer S3-Spiegel + 1 x täglich
Konfiguration / Zertifikate	Bei Änderung	15 Minuten	Sofort bei Änderung + 1 x monatlich

Rechenzentren in Produktionsqualität: Die obigen Ziele orientieren sich an einem einzelnen Standort mit einfachem Betrieb. Für Multi-AZ oder Geo-Redundanz planen Sie bitte zusätzlich externe Standortreplikation (rsync, mc mirror, Kafka MirrorMaker) ein.

Sicherungsspeicherstruktur

/data1/pp-backup/
├── pgbackrest/postgres/         # PostgreSQL 백업 (pgBackRest)
│   ├── archive/                  # WAL archive
│   └── backup/                   # Full / Diff / Incr
├── medusa/                       # Cassandra 백업 (Medusa)
│   └── <hostname>/<backup-name>/
├── restic/                       # 파일 백업 (Restic)
│   ├── data/
│   ├── index/
│   └── snapshots/
└── docker-volume/                # Docker 볼륨 (tar.gz)
    ├── pp-data-YYYYMMDD.tar.gz
    ├── pp-security-YYYYMMDD.tar.gz
    └── ...

1. Integrierter Befehl plantpulse-backup

Das plantpulse-backup-Modul umfasst alle Sicherungswerkzeuge.

Initialinstallation (einmalig)

cd /opt/kopens/plantpulse-platform/plantpulse-backup/bin
./backup.sh --install

Führt automatisch aus:

• pgBackRest-Konfiguration (/etc/pgbackrest/pgbackrest.conf)
• Medusa-Konfiguration (/etc/medusa/medusa.ini)
• Verzeichnis- / Berechtigungserstellung
• pgBackRest-Stanza-Erstellung

PostgreSQL-Sicherung

cd /opt/kopens/plantpulse-platform/plantpulse-backup/bin

./backup.sh --postgres            # Differential (기본, 빠름)
./backup.sh --postgres full       # Full (전체)
./backup.sh --postgres incr       # Incremental (가장 빠름)

Cassandra-Sicherung

./backup.sh --cassandra           # Differential
./backup.sh --cassandra full      # Full

Dateisicherung (Restic)

/opt/kopens/plantpulse-platform/plantpulse-backup/etc/run_restic.sh

• /data1/pp-data Inkrementelle Sicherung
• Aufbewahrungsdauer: letzte 7 Tage + monatlich 1 Datensatz
• Automatische Integritätsprüfung

Sicherungen bereinigen

./backup.sh --purge

• pgBackRest: repo1-retention-full (Standard 2 Sätze)
• Medusa: CASS_PURGE_KEEP_DAYS (Standard 10 Tage)
• Restic: automatisch nach Richtlinie

2. Automatische Sicherung – bereits aktiviert

Nichts zu installieren

Automatische Sicherung ist bereits mit fünf systemd-Timern ins Image eingebacken und standardmäßig aktiviert. Sie müssen --cron-install nicht ausführen.

Timer	Aufgabe
plantpulse-backup-postgres-diff	PostgreSQL Differenziell
plantpulse-backup-postgres-full	PostgreSQL Vollsicherung
plantpulse-backup-cassandra-diff	Cassandra Differenziell
plantpulse-backup-cassandra-full	Cassandra Vollsicherung
plantpulse-backup-purge	Aufbewahrungsrichtlinie bereinigen

Standard-Zeitplan

Aufgabe	OnCalendar	Uhrzeit
PostgreSQL Diff	*-*-* 01:30:00	täglich 01:30
PostgreSQL Vollsicherung	Sun *-*-* 01:00:00	sonntags 01:00
Cassandra Diff	*-*-* 01:20:00	täglich 01:20
Cassandra Vollsicherung	Sun *-*-* 00:10:00	sonntags 00:10
Purge	Sun *-*-* 03:00:00	sonntags 03:00

Ein- und Ausschalten

Schreiben Sie den Schalter in das Secrets-Sidecar des Hosts und starten Sie neu.

# 호스트에서
sudo vi /etc/kopens/plantpulse-platform.env
#   export PP_BACKUP_SCHEDULE_ENABLED=false

cd /opt/kopens/plantpulse-platform-docker/bin
./restart.sh

«Ausgeschaltet» ist kein Fehler – es ist der dritte Zustand

Der Timer selbst löst immer aus; das Wrapper-Skript liest den Schalter und entscheidet. Wenn ausgeschaltet, überspringt die Sicherung und protokolliert im Journal und in history.jsonl als result="skipped" – weder ok noch fail. So können Sie später zwischen «ausgeschaltet» und «gelaufen» unterscheiden.

Bearbeiten Sie die Unit-Datei nicht direkt zum Ausschalten. Der nächste Image-Build aktiviert sie stillschweigend wieder.

Der Schalter muss im Sidecar stehen

Wenn Sie export PP_BACKUP_SCHEDULE_ENABLED=false nur in bin/env.sh setzen, erreicht er den Container nicht. Der einzige Weg, wie compose den Namen an den Container übergibt, ist diese Variable, und der Wert kommt vom Sidecar (oder Shell-Export). Wenn Sie sie falsch setzen, entsteht ein «sieht ausgeschaltet aus, läuft aber weiter»-Zustand.

3. Docker-Volumen-Sicherung (Container-Umgebung)

Bei Installation / Docker-Installation ist zusätzliche Volume-basierte Sicherung möglich.

Führen Sie dies auf dem Host aus.

cd /opt/kopens/plantpulse-platform-docker/bin

# 기본 세트를 한 번에 (pp-data · pp-security)
./backup.sh

# 볼륨 하나만
./tools/backup-volume.sh pp-data 7 /data1/pp-backup/docker-volume
./tools/backup-volume.sh pp-security 30 /data1/pp-backup/docker-volume

Die beiden, die in der Standardvorgabe fehlen, sind nicht übersehen – pp-backup ist das Ziel einer Sicherung (sich selbst einzubeziehen würde die Größe jeden Durchlauf verdoppeln), und pp-temp ist für die Wiederherstellung nutzlos. Wenn nötig, können Sie diese mit Argumenten sichern.

Konfigurationsvorlage ist kein Volumen

Die Konfigurationsvorlage ist ein Bind-Mount des Host-Verzeichnisses /etc/kopens/conf und daher kein Ziel für Docker-Volumen-Sicherung. Sichern Sie sie zusammen als Host-Dateien. Das Secrets-Sidecar /etc/kopens/plantpulse-platform.env ist gleichfalls betroffen.

Argument	Beschreibung	Standard
1	Volumename	(erforderlich)
2	Aufbewahrung in Tagen	7
3	Speicherpfad	/data1/pp-backup/docker-volume

4. Umgebungsvariablen (backup.sh)

Variable	Standard	Beschreibung
BACKUP_ROOT	/data1/pp-backup	Sicherungsstammverzeichnis
PG_VER	18	PostgreSQL-Version
PG_DATA	/data1/pp-data/postgres/data	PostgreSQL-Datenverzeichnis
CASS_BASE	/opt/kopens/plantpulse-platform/plantpulse-storage/db/cassandra	Cassandra-Installationspfad
CQL_USER	${PP_CASSANDRA_USER}	CQL-Benutzer
CQL_PASS	${PP_CASSANDRA_PASSWORD}	CQL-Passwort
PG_RETENTION_FULL	2	PostgreSQL Vollsicherung Aufbewahrung
CASS_PURGE_KEEP_DAYS	10	Medusa Aufbewahrung in Tagen

5. Externe Standortreplikation (Off-site)

Nur lokale Sicherungen sind anfällig für Rechenzentrumsausfälle. Empfohlenes Muster:

# 매일 새벽 4시 — 외부 S3 로 복제
0 4 * * * rclone sync /data1/pp-backup/ s3:kopens-pp-backup/$(hostname)/ \
  --bwlimit 50M --log-file /var/log/pp-backup-sync.log

# MinIO 객체는 mc 로 별도 미러
0 5 * * * mc mirror --overwrite local/ s3-offsite/

6. Wiederherstellung

6.1 PostgreSQL-Wiederherstellung

# 1. plantpulse 중지 (PG 의존 모듈 + PG)
cd /opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin
./stop.sh

# 2. 백업 정보 확인
sudo -u postgres pgbackrest --stanza=pg18 info

# 3. 최신 복구
sudo -u postgres pgbackrest --stanza=pg18 restore

# 3-2. 시점 복구 (PITR)
sudo -u postgres pgbackrest --stanza=pg18 --type=time \
  --target="2026-05-30 12:00:00" restore

# 4. 재시작
./start-daemon.sh
./status.sh

6.2 Cassandra-Wiederherstellung

# 백업 목록
medusa list-backups

# 단일 노드 복구
medusa restore-node --backup-name full_20260530_0010

# 클러스터 전체 복구 (마스터에서)
medusa restore-cluster --backup-name full_20260530_0010

Vorsicht: restore-cluster überschreibt Daten auf allen Knoten. Validieren Sie dies vor der Ausführung in einer Staging-Umgebung.

6.3 Dateienwiederherstellung (Restic)

# 스냅샷 목록
restic -r /data1/pp-backup/restic snapshots

# 최신 스냅샷 → 임시 위치 복구
restic -r /data1/pp-backup/restic restore latest --target /data1/pp-data-restored

# 특정 파일만 복구
restic -r /data1/pp-backup/restic restore latest --target / --include /data1/pp-data/cassandra/data/pp/tm_tag_point

6.4 Teilweise Zeitreihen-Wiederherstellung (plantpulse-recovery)

Um nur Daten einer bestimmten Anlage für einen bestimmten Zeitraum neu zu verarbeiten:

cd /opt/kopens/plantpulse-platform/plantpulse-recovery/bin
./recovery.sh ASSET_01032 20260501 20260530

6.5 Zeitreihen-Extraktion (plantpulse-exporter)

Extrahieren Sie in CSV oder verarbeiten Sie mit dsbulk in Masse:

cd /opt/kopens/plantpulse-platform/plantpulse-exporter/bin

# 에셋 단위 CSV
./export.sh ASSET_01032 20260101 20260530 /tmp

# 테이블 벌크 언로드 → gz
./bulk-unload.sh pp tm_tag_point
# /data1/pp-backup/cassandra/bulk/tm_tag_point.gz

# 다시 로드
./bulk-load.sh pp tm_tag_point

7. Notfallwiederherstellungs-Szenarien (DR)

Szenario A: Hardware-Ausfall des Servers (Cold DR)

Erwartete RTO: 4–8 Stunden (hängt von der Datenmenge ab)

Szenario B: Datenbeschädigung (PITR)

# 1. 손상 시점 직전으로 시점 복구
./stop.sh
sudo -u postgres pgbackrest --stanza=pg18 --type=time \
  --target="2026-05-30 14:30:00" restore

# 2. Cassandra 도 동일 시점 가까운 백업으로
medusa restore-cluster --backup-name diff_20260530_0120

# 3. 재시작
./start-daemon.sh
./status.sh

Szenario C: Failover zu externem Standort (Hot DR)

Wenn Sie einen Standby-Cluster am externen Standort betreiben. Erfordert Vorplanung:

• PostgreSQL: Streaming-Replikation oder pgBackRest asynchrone Replikation
• Cassandra: Multi-DC-Cluster + automatischer Hinted Handoff
• Kafka: MirrorMaker 2 bidirektionale Replikation
• MinIO: Site-Replikation oder mc mirror --watch

8. Checkliste zur Validierung nach Wiederherstellung

cd /opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin

# 1. 전체 모듈 상태
./status.sh

# 2. 헬스 체크
./ops-check.sh

# 3. Cassandra 클러스터 정상
./pd node status

# 4. PostgreSQL 연결
./pd node psql -c "SELECT count(*) FROM site;"

# 5. Kafka 토픽 / Consumer Group
./pd node topic

Im Browser:

• Web-Konsole aufrufen (http://[HOST]/)
• Administrator-Login (admin / admin123!)
• Dashboard laden
• Alarmliste anzeigen
• OPC-Verbindungsstatus CONNECTED
• Aktuelle Daten im Zeitreihen-Trend anzeigen
• CEP-Regelausführung bestätigen

9. Best Practices für Sicherungsbetrieb

• 3-2-1-Regel: 3 Kopien der Daten, 2 Medien, 1 externer Standort
• Monatliche Wiederherstellungsübung: Echte Wiederherstellung in Staging-Umgebung versuchen
• Sicherungsintegritätsprüfung: restic check, pgbackrest verify, medusa verify
• Sicherungsüberwachung: Benachrichtigungen bei Sicherungsfehlern (Slack, Email)
• Verschlüsselung: TLS bei externem Standort-Übertrag, LUKS/SSE-S3 bei Speicherung
• Berechtigungstrennung: Sicherungslaufwerk separates Mount + read-only-Mountoption
• Dokumentation: Wiederherstellungsverfahren im gemeinsamen Betriebsteam-Wiki dokumentieren

Verwandte Dokumentation

• Modul: storage
• Modul: utilities (backup / recovery / exporter)
• Betriebsverwaltung
• Fehlerbehebung

Technischer Support

Fragen zu Sicherung / Wiederherstellung: webmaster@kopens.com