홈 서버 백업 및 복구 - 간단한 복원 실습

백업 종료 코드가 성공했다고 해서 저장된 데이터로 서비스를 재시작할 수 있다는 것을 보장하는 것은 아닙니다. 파일 복원, 데이터베이스 읽기 가능성, 애플리케이션 작업 등을 각각 별도로 정의해야 합니다. 프로덕션 데이터에 접근하지 않는 실습부터 시작하세요.

성공적인 복구 정의

Diagram 1 · Use the button to switch views

사진 서비스는 이미지와 데이터베이스 레코드 간의 관계를 필요로 합니다. 인증은 구성 및 암호화 키에 따라 달라질 수도 있습니다. 허용 가능한 데이터 손실 시간(RPO)과 허용 가능한 복구 시간(RTO)을 별도로 정의하세요. 백업 빈도와 복원 시간은 서로 다른 측정 기준입니다.

독립적인 실습 실행

restore_lab.py 파일을 저장하고 python3 restore_lab.py를 실행하세요. 이 파일은 Python 3.12.3 표준 라이브러리를 사용합니다. 실행할 때마다 새로운 임시 디렉터리, 텍스트 파일 하나, SQLite 레코드 하나가 생성됩니다. 기존 서비스나 데이터셋은 중지하거나 삭제하지 않습니다.

이 스크립트는 SQLite의 백업 API를 사용하여 데이터베이스를 복사하고, 텍스트 파일과 함께 ZIP으로 압축한 후, 비어 있는 다른 디렉터리에 복원합니다. SHA-256 해시, PRAGMA integrity_check 및 알려진 SQL 레코드를 확인합니다. SQLite의 공식 백업 API 설명을 참조하십시오.

file_hashes: pass
sqlite_integrity: pass
application_read: pass
scope: synthetic fixture only

2026년 9월 7일에 세 가지 검사가 모두 통과되었습니다. 여기서 애플리케이션 읽기란 알려진 SQL 쿼리를 의미하며, Immich 또는 Nextcloud를 시작하는 것을 의미하지 않습니다. 출력된 directory에는 보존된 증거가 포함되어 있습니다. 해당 임시 디렉터리의 ZIP 파일은 테스트용 아티팩트이며, 저장 장치 분실에 대한 보호책이 아닙니다.

실제 서비스의 일관성 유지

실시간 데이터베이스 파일을 일반적인 방식으로 복사하는 것은 복구에 필요한 일관성을 유지하지 못할 수 있습니다. PostgreSQL의 경우 SQL 덤프와 같은 방법의 요구 사항을 검토하십시오. 데이터베이스 스냅샷과 참조된 외부 파일 간의 일관성은 별개의 문제입니다.

일치하는 해시는 캡처된 복사본과의 동일성을 입증합니다. 하지만 캡처 시점에 전체 애플리케이션이 일관성을 유지했음을 증명하는 것은 아닙니다.

restic을 사용한 추가 검사

다음은 restic이 이미 설치된 환경에 대한 절차입니다. 이 실습에서는 restic을 실행하지 않았습니다. 저장소와 자격 증명을 별도로 구성하고 restic version을 기록합니다. 스냅샷을 선택하고 비어 있는 대상으로 복원합니다.

restic snapshots
restic check --read-data
restic restore SNAPSHOT_ID --target /path/to/empty-restore

환경에 맞게 ID와 경로를 변경하십시오. 복원 및 저장소 검사는 서로 다른 질문에 대한 답을 제공합니다. --read-data를 사용하여 저장된 데이터를 읽을 때 런타임 및 전송 비용을 고려하십시오.

복구 기록 유지

복구 시작 및 종료 시간, 데이터 용량, 버전, 파일 검사 결과 및 애플리케이션 작업을 기록하십시오. 프로덕션 데이터를 교체하기 전에 발신 이메일 및 웹훅을 비활성화한 격리된 환경에서 검증하십시오. 인증 및 파일 읽기 검사를 통해 이 간단한 연습을 홈 서버 플랫폼에 대한 서비스별 절차로 만들 수 있습니다.