Backup und Wiederherstellung
Container-Modus (2026.05+, empfohlen)
sudo bash /opt/kopens/install/bin/backup.sh
# 산출: /data1/pp-backups/pe-backup-<ts>.tar.zst + .sha256
# 포함: cassandra (flush 후), redis (AOF), hivemq, node-userdir, grafana, opcua, opcua-client, profiling, /data1/csv, /etc/kopens, /var/security
opcua-client enthält die OPC-UA-Client-Zertifikate des Edge sowie die vom Operator vertrauenswürdigen DCS- und Controller-Server-Zertifikate. Ohne diese würde nach jeder Wiederherstellung für jede sichere Verbindung ein neues Edge-Zertifikat erstellt, sodass jedes DCS und jeder Controller erneut vertraut werden müsste — OPC-UA Sicherheitsverbindung.
OTA upgrade.sh nutzt dasselbe Tool für automatische Pre-Snapshots (Datenwiederherstellung bei Rollback).
Wiederherstellung:
sudo bash /opt/kopens/install/bin/restore.sh /data1/pp-backups/pe-backup-20260517-153000.tar.zst
Der aktuelle Zustand wird automatisch als pre-restore-*.tar.zst gesichert → Wiederherstellung → Automatischer Neustart der Container. Automatische sha256-Verifizierung.
Wiederherstellung per CQL-Dump
Bei Backups vor einem Upgrade wird ein engine-unabhängiger CQL-Dump (<아카이브>.cql/ — Schema + CSV pro Tabelle) mitgespeichert. Dieser kann auch manuellen Backups hinzugefügt werden.
sudo pe backup run --cql # 수동 백업에 덤프를 붙인다
sudo pe restore --yes --cql /data1/pp-backups/pe-backup-pre-upgrade-<시각>.cql
Dies ist eine logische Wiederherstellung, die verwendet wird, wenn Engine-Dateien (SSTable) in einer neuen Engine nicht gelesen werden können. Ohne Unterbrechung des Dienstes wird das Schema in der laufenden DB erstellt (IF NOT EXISTS) und anschließend Zeilen in jede Tabelle eingefügt.
- Wenn
SHA256SUMSdes Dumps nicht übereinstimmen, wird nichts ausgeführt. - Zeilen mit demselben Schlüssel werden überschrieben, andere bleiben erhalten — für eine exakte Kopie nutzen Sie einen leeren Keyspace.
- Zeitreihen- und Monitoring-Tabellen kehren leer zurück, da der Dump keine Zeilen enthält. WRITETIME und TTL der Zellen werden nicht übertragen.
- Bei Angabe von
--cql-authwerden auch DB-Rollen (system_auth) eingefügt.
Periodisches Backup (cron):
echo "0 3 * * * root /opt/kopens/install/bin/backup.sh > /dev/null 2>&1" \
> /etc/cron.d/plantpulse-edge-backup
echo "0 4 * * 0 root find /data1/pp-backups -name 'pe-backup-*.tar.zst' -mtime +30 -delete" \
>> /etc/cron.d/plantpulse-edge-backup
Ausführlicher Leitfaden: Container-Modus Betrieb.
2. Nach Abschluss des Backups — Zwingend auf externe Medien
Wenn /data1/pp-backup/ auf derselben physischen Disk wie das Gateway liegen, gibt es keinen Effekt für die Katastrophenwiederherstellung. Eine Spiegelung auf ein externes NAS / S3 / einen anderen Server ist zwingend erforderlich.
# 마지막 백업 디렉토리 이름
LATEST=$(ls -t /data1/pp-backup | head -1)
# 외부 NAS / S3 / 다른 서버로 미러
rsync -av /data1/pp-backup/$LATEST nas:/backup/edge/
3. Regelmäßige Automatisierung (cron Beispiel)
# /etc/cron.d/plantpulse-backup
# 매일 새벽 1시에 백업, 30일 이상은 자동 삭제
0 1 * * * root /opt/kopens/plantpulse-edge/bin/backup.sh >>/var/log/pp-backup.log 2>&1
30 1 * * * root find /data1/pp-backup -maxdepth 1 -type d -mtime +30 -exec rm -rf {} +
Überprüfen Sie nach der Anwendung von cron am nächsten Tag um 01:00 Uhr morgens, ob /data1/pp-backup/<date>/ neu erstellt wurden.
Es ist sicherer, am Ende der 0 1 * * *-Zeile in cron && rsync ... anzuhängen, um das Backup unmittelbar nach der Erstellung automatisch extern zu spiegeln.
4. Wiederherstellung aus einem Backup (Katastrophenwiederherstellung — Standardverfahren)
Das Folgende ist ein grober Überblick über die vollständige Wiederherstellung. Kopieren und führen Sie diese Schritte in einer Produktionsumgebung nicht eigenständig aus, sondern gemeinsam mit dem Betriebsteam.
# 1. 게이트웨이 정지
$PE_HOME/bin/stop.sh
# 2. 복원 대상 백업 디렉토리 결정
LATEST=/data1/pp-backup/<YYYYMMDD-HHMMSS>
# 3. 설정 복구
cp $LATEST/app.properties $PE_HOME/server/webapps/plantpulse-edge-web/WEB-INF/classes/
# 4. 도구 데이터 복구
rsync -av --delete $LATEST/sparkplugb/ /data1/pp-data/sparkplugb/
rsync -av --delete $LATEST/grafana/ /data1/pp-data/grafana/
rsync -av --delete $LATEST/node-red/ /data1/pp-data/node-red/
rsync -av --delete $LATEST/hivemq/ /data1/pp-data/hivemq/
# 5. Cassandra 복구 (snapshot sstable 복사 → restart)
# 상세 절차는 Cassandra 운영 문서 / Apache 가이드 참조
# (단순화하면: $LATEST/cassandra/<keyspace>/<table>/snapshot/<id>/ 의 sstable 들을
# 실제 data 디렉토리로 cp 하고 nodetool refresh)
# 6. 게이트웨이 시작
$PE_HOME/bin/start.sh
# 7. 검증
$PE_HOME/bin/ps.sh
curl -s http://127.0.0.1/ui/opcua/tree | jq '.data.tree | length'
5. Häufige Fehlerquellen
| Symptom | Ursache / Lösung |
|---|---|
backup.sh überschreibt jedes Mal im selben Verzeichnis | (Nicht normal) BUILD_DATE Format geändert / Zeitabweichung. date Ergebnis + backup.sh Zeile prüfen |
| Stoppt beim Cassandra-Snapshot-Schritt | I/O / Platzmangel auf der Disk. df -h /data1 |
| Backup-Verzeichnisgröße abnormal (wenige KB) | Einige Schritte fehlgeschlagen. Ausgabeprotokolle prüfen |
Weiterführende Informationen
- Upgrades rufen automatisch ein Backup auf → Upgrade (
upgrade.sh) - Bereinigung / Disk-Rückgewinnung → Bereinigung und Reinigung
- Betriebsszenarien — Bereitstellungsverfahren für neue Versionen → Betriebsszenarien