> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plasma.org/llms.txt
> Use this file to discover all available pages before exploring further.

# 백업 및 복구

> 백업 절차, 재해 복구 및 노드 마이그레이션

신뢰할 수 있는 백업 및 복구 절차는 노드 가용성을 유지하고 데이터 손실을 방지하는 데 필수적입니다. 이 섹션에서는 무엇을 백업할지, 얼마나 자주 백업할지, 어디에 저장할지, 그리고 장애로부터 복원하는 방법을 설명합니다.

<Note>
  현재 체인 데이터 크기의 1.5~~2배에 해당하는 백업 스토리지를 계획하세요. 백업 작업은 실행 중 일반적으로 10~~20%의 I/O 부하를 추가합니다.
</Note>

## 백업 대상

비검증 노드는 지속적인 운영에 필요한 중요한 상태 및 구성 데이터를 저장합니다. 주요 구성 요소는 다음과 같습니다:

* **블록체인 데이터베이스**\
  전체 Plasma 체인 상태를 저장합니다. 백업은 전체 재동기화보다 훨씬 빠릅니다.
* **구성 파일**\
  Docker Compose 파일, `.env` 변수 및 사용자 정의 스크립트를 포함합니다.
* **키스토어 및 피어 상태**\
  수동 재구성 없이 깔끔한 재시작을 가능하게 합니다. 인증 토큰과 네트워킹 메타데이터가 포함될 수 있습니다.

## 백업 전략

### 빈도

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

### 스토리지 고려 사항

백업은 별도의 인프라(클라우드 버킷, 원격 호스트 또는 오프라인 디스크)에 저장하세요. 백업을 기본 노드와 같은 곳에 두지 마세요.

<Warning>
  실행 중인 노드와 동일한 물리적 머신에 백업을 저장하지 마세요. 단일 하드웨어 장애로 전체 데이터를 잃을 수 있습니다.
</Warning>

특히 외부 스토리지 공급자를 사용할 때는 민감한 데이터 보호를 위해 백업 암호화를 구현하세요. 백업 스토리지가 유지 요구 사항과 증가 예측에 충분한 용량을 가지고 있는지 확인하세요.

## 복구 시나리오

### 부분 복구

특정 파일만 영향을 받은 경우 대상 복원을 사용합니다:

* 실수로 편집한 구성 파일 복원
* 동기화 진행 상황을 재설정하지 않고 손상된 데이터베이스 복구
* 기존 네트워킹 설정을 유지하기 위한 피어 상태 재적용

부분 복구는 다운타임을 줄이고 전체 재동기화를 방지합니다.

### 전체 복구

노드 또는 호스트 시스템이 손실된 경우 필요:

1. 새 머신 또는 VM 프로비저닝
2. 백업에서 블록체인 데이터베이스와 구성 복원
3. 노드를 시작하고 네트워크에 다시 연결
4. 최신 확정 블록과의 동기화 확인

복구 시간은 데이터 크기, 대역폭 및 스토리지에 따라 달라질 수 있습니다.

## 검증

백업 무결성을 정기적으로 확인합니다:

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

## 모범 사례

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

## 문제 해결

### 백업 실패

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

### 손상 감지

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

### 복구 성능

* 빠른 스토리지와 로컬 디스크를 사용하여 복원 최적화
* 스토리지 백엔드에서 지원하는 경우 병렬 I/O 사용

견고한 백업 및 복구 계획은 데이터 손실을 방지하고 다운타임을 최소화합니다. 정기적으로 테스트하고, 백업을 안전하게 저장하고, 구조화된 복구 프로세스를 따라 안정적인 노드 운영을 유지하세요.