메인 콘텐츠로 건너뛰기
신뢰할 수 있는 백업 및 복구 절차는 노드 가용성을 유지하고 데이터 손실을 방지하는 데 필수적입니다. 이 섹션에서는 무엇을 백업할지, 얼마나 자주 백업할지, 어디에 저장할지, 그리고 장애로부터 복원하는 방법을 설명합니다.
현재 체인 데이터 크기의 1.52배에 해당하는 백업 스토리지를 계획하세요. 백업 작업은 실행 중 일반적으로 1020%의 I/O 부하를 추가합니다.

백업 대상

비검증 노드는 지속적인 운영에 필요한 중요한 상태 및 구성 데이터를 저장합니다. 주요 구성 요소는 다음과 같습니다:
  • 블록체인 데이터베이스
    전체 Plasma 체인 상태를 저장합니다. 백업은 전체 재동기화보다 훨씬 빠릅니다.
  • 구성 파일
    Docker Compose 파일, .env 변수 및 사용자 정의 스크립트를 포함합니다.
  • 키스토어 및 피어 상태
    수동 재구성 없이 깔끔한 재시작을 가능하게 합니다. 인증 토큰과 네트워킹 메타데이터가 포함될 수 있습니다.

백업 전략

빈도

사용량과 위험 프로파일에 따라 백업 간격을 설정하세요. 일일 스냅샷은 대부분의 비검증 노드에 충분합니다. 처리량이 많은 배포는 장애 시 데이터 손실을 최소화하기 위해 더 자주 백업이 필요할 수 있습니다.

스토리지 고려 사항

백업은 별도의 인프라(클라우드 버킷, 원격 호스트 또는 오프라인 디스크)에 저장하세요. 백업을 기본 노드와 같은 곳에 두지 마세요.
실행 중인 노드와 동일한 물리적 머신에 백업을 저장하지 마세요. 단일 하드웨어 장애로 전체 데이터를 잃을 수 있습니다.
특히 외부 스토리지 공급자를 사용할 때는 민감한 데이터 보호를 위해 백업 암호화를 구현하세요. 백업 스토리지가 유지 요구 사항과 증가 예측에 충분한 용량을 가지고 있는지 확인하세요.

복구 시나리오

부분 복구

특정 파일만 영향을 받은 경우 대상 복원을 사용합니다:
  • 실수로 편집한 구성 파일 복원
  • 동기화 진행 상황을 재설정하지 않고 손상된 데이터베이스 복구
  • 기존 네트워킹 설정을 유지하기 위한 피어 상태 재적용
부분 복구는 다운타임을 줄이고 전체 재동기화를 방지합니다.

전체 복구

노드 또는 호스트 시스템이 손실된 경우 필요:
  1. 새 머신 또는 VM 프로비저닝
  2. 백업에서 블록체인 데이터베이스와 구성 복원
  3. 노드를 시작하고 네트워크에 다시 연결
  4. 최신 확정 블록과의 동기화 확인
복구 시간은 데이터 크기, 대역폭 및 스토리지에 따라 달라질 수 있습니다.

검증

백업 무결성을 정기적으로 확인합니다:
  • 저장된 파일에 대해 체크섬 검증 실행
  • 비중요 인프라에서 주기적으로 테스트 복원 수행
  • 백업 성공률, 기간 및 데이터 크기 모니터링

모범 사례

  • 백업을 자동화하고 실패 시 알림 받기
  • 구성 파일에 버전 관리 사용
  • 분기별로 복원 절차 테스트
  • RTO/RPO 목표를 평가하기 위해 복구 시간 추적

문제 해결

백업 실패

  • 디스크 공간, 권한 및 스토리지 연결성 확인
  • I/O 또는 타임아웃 오류에 대한 로그 검토

손상 감지

  • 정기적으로 체크섬 검증
  • 데이터베이스 불일치 징후를 위해 동기화 로그 모니터링

복구 성능

  • 빠른 스토리지와 로컬 디스크를 사용하여 복원 최적화
  • 스토리지 백엔드에서 지원하는 경우 병렬 I/O 사용
견고한 백업 및 복구 계획은 데이터 손실을 방지하고 다운타임을 최소화합니다. 정기적으로 테스트하고, 백업을 안전하게 저장하고, 구조화된 복구 프로세스를 따라 안정적인 노드 운영을 유지하세요.