Nodes/common/backup-restore

common

백업 / 재해 복구

6분 읽기 · backup-restore

list목차(16)

백업 / 재해 복구

블록체인 노드 데이터 보호 전략입니다. 대부분의 체인은 공개 네트워크에서 재동기화할 수 있지만, **시간(수 일~수 주)**과 I/O 비용이 크므로 정책적 백업이 중요합니다.

데이터 계층 구분

계층 특징 백업 우선도
체인 데이터(blocks/state) 네트워크에서 재동기화 가능 중 (시간 절약 목적)
Validator/Baker/SP 서명 키 유일무이 · 분실 시 슬래시/권한 상실 최상
slashing protection DB Validator 중복 서명 방지 최상
RPC/API 인증 설정(.env) 복구 가능하지만 시크릿 유출 위험 상
pruning 이전 archive 데이터 재구축 시 오랜 시간 상 
flowchart LR
  subgraph Live["운영 호스트"]
    SK[(서명 키)]
    DB[(chain state)]
    Cfg[.env / config]
  end
  subgraph Offline["오프라인 · 암호화"]
    USB[USB / HSM]
    Vault[Secrets Manager]
  end
  subgraph Cloud["오프사이트"]
    S3[S3 / GCS]
    Snap[파일시스템 스냅샷]
  end
  SK -.암호화.-> USB
  SK -.암호화.-> Vault
  DB -->|주기적 rsync / snapshot| Snap
  DB -->|필요 시 tar.zst| S3
  Cfg -->|비밀 필드만| Vault

1. 서명 키 백업 (최우선)

오프라인 보관

# 예: Cosmos validator priv_validator_key.json
KEY_FILE=~/.gaia/config/priv_validator_key.json

# 암호화 후 USB/HSM에 저장
age -p "$KEY_FILE" > priv_validator_key.json.age
# (여러 사본 보관, 서로 다른 물리 위치)

체인별 핵심 키 목록

체인 경로 비고
Cosmos SDK 계열 ~/.<chain>/config/priv_validator_key.json validator 서명 키
Ethereum Validator ~/.eraydo/validator/keystores/*.json 32 ETH 키스토어
Solana (Agave) ~/validator-keypair.json, ~/vote-account-keypair.json Validator + Vote
Cardano SPO KES, VRF, Operational Certificate, Payment, Stake 키 유형 여러 개
Tezos Baker ~/.tezos-client/ (tezos-client show address) 하드웨어 월렛 권장
Filecoin SP ~/.lotusminer/keystore/ 복잡한 키 계층 구조
Kaspa wallet.dat 개인키

slashing protection DB (Ethereum Validator)

# 월 단위로 내보내기 권장
validator slashing-protection export --datadir=~/.eraydo/validator --file=slashing_backup.json

복구 시 반드시 import 후에만 validator 재기동. import 누락 시 이중 서명 슬래시 발생 가능.

2. 체인 데이터 스냅샷

파일시스템 스냅샷 (권장)

중지 후 일관된 상태에서 스냅샷을 생성해야 합니다.

# ZFS
sudo systemctl stop <node>
sudo zfs snapshot tank/chain-data@$(date +%Y%m%d)
sudo systemctl start <node>

# LVM
sudo lvcreate --size 20G --snapshot --name chain-snap-$(date +%Y%m%d) /dev/vg/chain-data

# AWS EBS (라이브 가능하지만 pending write 손실 위험 → 중지 후 권장)
aws ec2 create-snapshot --volume-id vol-xxx --description "chain-$(date +%Y%m%d)"

tar.zst 백업

sudo systemctl stop <node>

tar --zstd -cf /backup/chain-$(date +%Y%m%d).tar.zst \
  --exclude='logs' --exclude='*.log' \
  /var/lib/<node>

sudo systemctl start <node>

# 무결성 체크
zstd -t /backup/chain-$(date +%Y%m%d).tar.zst

공개 스냅샷 활용

자체 백업 대신 커뮤니티/공식 스냅샷을 주기적으로 내려받는 전략도 가능합니다.

체인 공개 스냅샷
Ethereum Erigon / Geth snapshot providers
Cosmos SDK Polkachu, Nodes.guru
Solana snapshotfinder
Arbitrum snapshot.arbitrum.foundation
Base docs.base.org snapshots
Celestia Polkachu, Nodes.guru

3. 3-2-1 규칙

  • 3 개의 사본 (원본 + 백업 2개)
  • 2 종류의 저장매체 (예: SSD + S3)
  • 1 개의 오프사이트 사본

4. 복원 리허설

백업은 복원이 가능할 때만 의미가 있습니다. 최소 분기 1회 복원 테스트를 권장합니다.

# 1. 스테이징 머신에서 백업 복원
tar --zstd -xf /backup/chain-xxx.tar.zst -C /tmp/restore

# 2. 체인 데이터 디렉토리로 이동
sudo rsync -a /tmp/restore/var/lib/<node>/ /var/lib/<node>/

# 3. 서비스 시작 후 동기화 진행 확인
sudo systemctl start <node>
journalctl -u <node> -f

5. 재해 복구 시나리오

디스크 장애

  1. 콜드 백업 서명 키 복구 → 새 호스트에 배치 (chmod 600)
  2. 최신 스냅샷 복원
  3. 서비스 기동 → 동기화 완료까지 네트워크 차단
  4. Validator 재활성화 (슬래싱 리스크 없는 상태 확인 후)

키 유출

  1. Validator라면 즉시 unjail/중지 → 새 키로 교체
  2. 쿠키·RPC 인증 모두 회전
  3. 유출 경로(레포/덤프/로그) 전수 조사

6. 자동화 예시 (systemd timer)

# /etc/systemd/system/chain-backup.service
[Unit]
Description=Chain data backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-chain.sh

# /etc/systemd/system/chain-backup.timer
[Unit]
Description=Daily chain data backup

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl enable --now chain-backup.timer

참고

common 다른 챕터