Backup and Recovery
Container Mode (2026.05+, Recommended)
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 contains the Edge OPC-UA client certificates and the DCS/controller server certificates trusted by the operator. Without these, a new Edge certificate is generated for every secure connection after restoration, requiring each DCS/controller to be trusted again — OPC-UA Secure Connection.
OTA upgrade.sh also use the same tool for automatic pre-snapshots (for data recovery during rollback).
Recovery:
sudo bash /opt/kopens/install/bin/restore.sh /data1/pp-backups/pe-backup-20260517-153000.tar.zst
The current state is automatically backed up as pre-restore-*.tar.zst → restoration → automatic container restart. sha256 is automatically verified.
Recovery via CQL Dump
Backups made before an upgrade include a CQL dump (<아카이브>.cql/ — schema + CSV per table), which is independent of the engine. This can also be attached to manual backups.
sudo pe backup run --cql # 수동 백업에 덤프를 붙인다
sudo pe restore --yes --cql /data1/pp-backups/pe-backup-pre-upgrade-<시각>.cql
This is a logical restoration used when engine files (SSTable) cannot be read by a new engine. It allows restoring data to a running DB by creating the schema (IF NOT EXISTS) and inserting rows into each table without stopping the service.
- If the
SHA256SUMSin the dump does not match, no action is taken. - Rows with the same key are overwritten while others are preserved — if an exact copy is required, insert into an empty keyspace.
- Time series and monitoring tables return empty as there are no rows in the dump. WRITETIME and TTL of cells are not migrated.
- If
--cql-authis provided, DB roles (system_auth) are also inserted.
Periodic 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
Detailed Guide: Container Mode Operation.
2. After Backup — Must Use External Media
If /data1/pp-backup/ is on the same physical disk as the gateway, there is no disaster recovery effect. Mirroring to an external NAS / S3 / different server is mandatory.
# 마지막 백업 디렉토리 이름
LATEST=$(ls -t /data1/pp-backup | head -1)
# 외부 NAS / S3 / 다른 서버로 미러
rsync -av /data1/pp-backup/$LATEST nas:/backup/edge/
3. Regular Automation (cron Example)
# /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 {} +
After applying cron, verify that /data1/pp-backup/<date>/ is newly created at 1 AM the following day.
For safety, append && rsync ... to the end of the 0 1 * * * line in cron to automatically mirror the backup externally immediately after it is created.
4. Recovery from Backup (Disaster Recovery — Basic Procedure)
The following is a high-level overview of a full restoration. Do not copy and execute this directly in a production environment; proceed with the operations team.
# 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. Common Pitfalls
| Symptom | Cause / Resolution |
|---|---|
backup.sh is overwritten in the same directory every time | (Abnormal) BUILD_DATE format change / clock anomaly. Check date results + backup.sh lines |
| Stops at Cassandra snapshot stage | I/O / insufficient disk space. df -h /data1 |
| Backup directory size is abnormal (a few KB) | Some steps failed. Check output logs |
Learn More
- Upgrades automatically trigger a backup → Upgrade (
upgrade.sh) - Cleanup / Disk Recovery → Cleanup and Purge
- Operational Scenarios — New Version Deployment Procedure → Operational Scenarios