백업 및 복구
컨테이너 모드 (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 에는 엣지의 OPC UA 클라이언트 인증서와 운영자가 신뢰한 DCS·컨트롤러 서버 인증서가 들어 있습니다. 이것이 없으면 복원 뒤 보안 연결마다 새 엣지 인증서가 만들어져 DCS·컨트롤러마다 다시 신뢰해야 합니다 — OPC-UA 보안 연결.
OTA upgrade.sh 도 동일 도구로 자동 pre-snapshot (rollback 시 데이터 복구용).
복구:
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/<날짜>/ 가 새로 생기는지 확인하세요.
cron 의 0 1 * * * 라인 끝에 && rsync ... 를 붙여 백업 직후 자동으로 외부로 mirror 시키는 게 안전합니다.
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) | 일부 단계 실패. 출력 로그 확인 |
더 알아보기
- 업그레이드는 자동으로 백업을 호출합니다 → 업그레이드 (
upgrade.sh) - 정리 / 디스크 회수 → 정리 및 청소
- 운영 시나리오 — 신버전 배포 절차 → 운영 시나리오