Zum Hauptinhalt springen

Backup / Wiederherstellung

Container-Modus (2026.05+, empfohlen)​

sudo bash /opt/kopens/install/bin/backup.sh
# 산출: /data1/pp-backups/pe-backup-<ts>.tar.zst + .sha256
# 포함: cassandra (drain 후), redis (AOF), hivemq, node-userdir, /etc/kopens

OTA upgrade.sh erstellt mit demselben Werkzeug automatisch einen Pre-Snapshot (zur Datenwiederherstellung beim Rollback).

Wiederherstellung:

sudo bash /opt/kopens/install/bin/restore.sh /data1/pp-backups/pe-backup-20260517-153000.tar.zst

Auch der aktuelle Zustand wird automatisch als pre-restore-*.tar.zst gesichert → Wiederherstellung → Container startet automatisch neu. sha256 wird automatisch verifiziert.

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ührliche Anleitung: Betriebsleitfaden Container-Modus.

(legacy) Native-Modus​

$PE_HOME/bin/backup.sh

Speicherort (<DT> = YYYYMMDD-HHMMSS):

/data1/pp-backup/<DT>/
├── env.sh                  # 환경 변수 스냅샷
├── app.properties          # 게이트웨이 설정 사본
├── cassandra/              # nodetool snapshot — sstable 그대로 (TTL/메타 보존)
│   ├── pe/                 # keyspace
│   └── system_*/
├── sparkplugb/             # bdSeq 등 sparkplug 상태
├── grafana/                # 대시보드 / 데이터소스 정의
├── node-red/               # Node-RED userDir (플로우 / credentials / 패키지)
├── hivemq/                 # MQTT persistence
└── apm/

Normale Ausgabe:

[1] DUMP env.sh / app.properties ... OK
[2] CASSANDRA nodetool snapshot ... OK (snapshot=backup-20260508-040215, size=1.2 GB)
[3] COPY /data1/pp-data/{sparkplugb,grafana,node-red,hivemq,apm} ... OK
BACKUP COMPLETED — /data1/pp-backup/20260508-040215/  (총 2.1 GB, 소요 47s)

Die Dauer ist proportional zur Datenmenge (üblicherweise im Minutenbereich).

2. Nach Abschluss des Backups — unbedingt auf externe Medien​

Liegt /data1/pp-backup/ auf derselben physischen Festplatte wie das Gateway, gibt es keinen Effekt für die Disaster Recovery. 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 {} +

Prüfen Sie nach dem Einrichten von cron am nächsten Tag um 1 Uhr nachts, ob /data1/pp-backup/<date>/ neu angelegt wird.

Auch die externe Spiegelung automatisieren

Am sichersten ist es, am Ende der 0 1 * * *-Zeile in cron ein && rsync ... anzuhängen, damit direkt nach dem Backup automatisch nach extern gespiegelt wird.

4. Wiederherstellung aus einem Backup (Disaster Recovery — Grundablauf)​

Die Wiederherstellung überschreibt Daten — nur mit erfahrenem Personal

Nachfolgend das Gesamtbild einer vollständigen Wiederherstellung. Kopieren und führen Sie dies nicht unbesehen in der Produktivumgebung aus, sondern gehen Sie gemeinsam mit dem Betriebsteam vor.

# 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 Stolperfallen​

SymptomUrsache / Abhilfe
backup.sh überschreibt jedes Mal dasselbe Verzeichnis(nicht normal) Format von BUILD_DATE geändert / Uhrzeit fehlerhaft. Ergebnis von date + Zeilen in backup.sh prüfen
Hängt beim Schritt Cassandra-SnapshotI/O / zu wenig Speicherplatz. df -h /data1
Größe des Backup-Verzeichnisses unplausibel (einige KB)Einzelne Schritte fehlgeschlagen. Ausgabelog prüfen

6. Weiterführende Informationen​