メインコンテンツまでスキップ

バックアップおよび復旧

コンテナモード (2026.05+, 推奨)​

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 には Edge の OPC-UA クライアント証明書と、オペレーターが信頼した DCS・コントローラサーバー証明書が含まれています。これがない場合、復元後にセキュリティ接続ごとに新しい Edge 証明書が作成され、DCS・コントローラごとに再度信頼設定を行う必要があります — OPC-UA セキュリティ接続。

OTA upgrade.sh も同一ツールで自動 pre-snapshot (ロールバック時のデータ復旧用) が行われます。

復旧:

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

現在の状態も pre-restore-*.tar.zst として自動バックアップ → 復元 → コンテナ自動再起動。sha256 自動検証。

CQL ダンプによる復元​

アップグレード前のバックアップには、エンジンに依存しない CQL ダンプ(<아카이브>.cql/ — スキーマ + テーブル別 CSV) が同時に保存されます。手動バックアップに含めることも可能です。

sudo pe backup run --cql                       # 수동 백업에 덤프를 붙인다
sudo pe restore --yes --cql /data1/pp-backups/pe-backup-pre-upgrade-<시각>.cql

エンジンファイル(SSTable)が新しいエンジンで読み込めない場合に使用する 論理復元 です。サービスを停止せず、稼働中の DB にスキーマを作成した後(IF NOT EXISTS)、テーブルごとに行を挿入します。

  • ダンプの SHA256SUMS が一致しない場合は何も行いません
  • 同じキーの行は上書きし、それ以外は保持します — 正確なコピーが必要な場合は空のキースペースに挿入してください
  • 時系列・モニタリング表はダンプに行が含まれていないため、空の状態で戻ります。セルの WRITETIME ・ TTL も移行しません
  • --cql-auth を指定すると、DB 役割(system_auth)も挿入します

定期的バックアップ (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

詳細ガイド: コンテナモード運用。

2. バックアップ完了後 — 必ず外部メディアへ​

/data1/pp-backup/ が ゲートウェイ と 同じ物理ディスク である場合、災害復旧 の効果はありません。 外部 NAS / S3 / 別サーバーへのミラーリングは必須 です。

# 마지막 백업 디렉토리 이름
LATEST=$(ls -t /data1/pp-backup | head -1)

# 외부 NAS / S3 / 다른 서버로 미러
rsync -av /data1/pp-backup/$LATEST nas:/backup/edge/

3. 定期自動化 (cron 例)​

# /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 {} +

cron 適用後、翌日午前1時に /data1/pp-backup/<date>/ が新しく生成されているか確認してください。

外部ミラーまで自動化

cron の 0 1 * * * 行の末尾に && rsync ... を追加し、バックアップ直後に自動で外部へミラーリングさせることが安全です。

4. バックアップからの復旧 (災害復旧 — 基本手順)​

復旧はデータを上書きします — 経験者と共に実施してください

以下は 全復元 の概要です。運用環境でそのままコピーして実行せず、 運用チームと共に 進めてください。

# 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. よくある落とし穴​

症状原因 / 解決
backup.sh が同じディレクトリに毎回上書きされる(異常) BUILD_DATE 形式の変更 / 時刻異常。 date の結果 + backup.sh の行を点検
Cassandra snapshot 段階で停止するI/O / ディスク容量不足。 df -h /data1
バックアップディレクトリのサイズが異常 (数 KB)一部の段階で失敗。出力ログを確認

さらに詳しく​