Backup / Restore
Container mode (2026.05+, recommended)
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 also performs an automatic pre-snapshot with the same tool (for data recovery on rollback).
Restore:
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 → restored → containers restart automatically. sha256 is verified automatically.
Scheduled backups (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 operations guide.
(legacy) Native mode
$PE_HOME/bin/backup.sh
Output location (<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/
Normal output:
[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)
Duration is proportional to the data volume (typically a few minutes).
2. After the backup completes — always copy to external media
If /data1/pp-backup/ sits on the same physical disk as the gateway, it provides no disaster recovery benefit. Mirroring to an external NAS / S3 / another server is mandatory.
# 마지막 백업 디렉토리 이름
LATEST=$(ls -t /data1/pp-backup | head -1)
# 외부 NAS / S3 / 다른 서버로 미러
rsync -av /data1/pp-backup/$LATEST nas:/backup/edge/
3. Scheduled 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 the cron entry, check the next day at 01:00 that a new /data1/pp-backup/<date>/ has been created.
It is safer to append && rsync ... to the end of the 0 1 * * * line in cron so the backup is mirrored off-box immediately after it is taken.
4. Restoring from a backup (disaster recovery — basic procedure)
The following is the big picture of a full restore. Do not copy and run it as-is in production; carry it out together with your 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 overwrites the same directory every time | (Not normal) BUILD_DATE format change / clock issue. Check the date output and the backup.sh lines |
| Stalls at the Cassandra snapshot stage | I/O / insufficient disk space. df -h /data1 |
| Backup directory size is abnormal (a few KB) | Some stage failed. Check the output log |
6. Learn more
- Upgrades invoke a backup automatically → Upgrade (
upgrade.sh) - Cleanup / disk reclamation → Cleanup
- Operational scenarios — new version rollout procedure → Operational scenarios