백업과 복구 · 복구 리허설 · 이론
복구 절차를 설계하기
한 줄 요약
복구는 순서와 검증이 전부다. 그리고 그 순서를 실제로 밟아 시간을 재기 전까지 RTO 는 숫자가 아니라 희망사항이다.
왜 이게 필요했나
백업을 잘 만들어 두고도 복구에서 실패하는 이유는 대개 절차 문제다.
- 어떤 백업을 써야 하는지 모른다 (전체? 증분? 어느 세대?)
- 복원 순서를 틀린다 (증분을 먼저 풀거나 순서를 뒤집는다)
- 복원 위치를 잘못 잡아 현재 시스템을 덮어쓴다
- 복원은 됐는데 서비스가 안 뜬다 (권한, SELinux, UID 매핑)
어떻게 동작하나
안전한 복원 순서
# 1. 임시 경로로 먼저 푼다 — 절대 바로 덮어쓰지 않는다mkdir -p /restore/checktar -xzf /backup/full-2026-08-20.tar.gz -C /restore/check# 2. 내용을 확인한다find /restore/check -type f | wc -ldiff -r /restore/check/etc/nginx /etc/nginx | head -40# 3. 필요한 것만 옮긴다rsync -aHAX --numeric-ids /restore/check/etc/nginx/ /etc/nginx/임시 경로를 거치는 것이 핵심이다. -C / 로 바로 푸는 것은 되돌릴 수 없는 작업이다.
증분 복원의 순서
전체 → 증분 0 → 증분 1 → ... 순서를 반드시 지켜야 한다. tar 의 --listed-incremental 로 만든 증분은 삭제 정보까지 담고 있어서, 순서를 어기면 있어야 할 파일이 사라진다.
tar --listed-incremental=/dev/null -xzf full.tar.gz -C /restore/tar --listed-incremental=/dev/null -xzf inc0.tar.gz -C /restore/tar --listed-incremental=/dev/null -xzf inc1.tar.gz -C /restore/복원 시 --listed-incremental=/dev/null 을 쓰는 것이 관례다. 스냅샷 파일을 갱신하지 않겠다는 뜻이다.
선택 복원
전체를 풀 필요 없이 특정 파일만 꺼낼 수 있다.
tar -tzf backup.tar.gz | grep nginx.conftar -xzf backup.tar.gz -C /restore/ src/conf/nginx.conftar -xzf backup.tar.gz -C /restore/ --strip-components=1 src/conf/--strip-components=N 은 앞쪽 경로 요소 N 개를 제거하고 푼다. 아카이브 구조와 복원 위치가 다를 때 쓴다.
시간 재기
RTO 를 확인하려면 실제로 재야 한다.
START=$(date +%s)# ... 복구 절차 전체 ...END=$(date +%s)echo "복구 소요: $((END - START))초"여기에 포함되어야 하는 것은 아카이브 추출 시간만이 아니다. 백업 저장소에서 파일을 가져오는 시간, 검증 시간, 서비스 기동 시간, 정합성 확인 시간이 전부 들어가야 실제 RTO 다. 실무에서 RTO 를 못 지키는 원인 1위는 추출이 느려서가 아니라 네트워크로 백업을 가져오는 시간이다.
복원 후 검증
- 파일 개수와 총 크기가 기대와 맞는가
- 권한과 소유자가 맞는가 (
--numeric-ids를 썼는가) - 서비스가 기동하는가
- 애플리케이션의 정합성 검사를 통과하는가
현장에서 만나는 모습
"복원은 됐는데 서비스가 안 뜬다." 원인 후보가 정해져 있다. UID/GID 매핑, SELinux 컨텍스트, 파일시스템 기능 차이(ACL 미지원), 커널/라이브러리 버전 차이. --numeric-ids 와 --selinux 가 앞의 둘에 대한 대비다.
복원 문서가 복원 담당자의 노트북에만 있다. 그 노트북이 없는 상황이 곧 복구가 필요한 상황일 수 있다.
다음 실습에서 할 것
앞에서 만든 백업 세트로 복구 리허설을 수행한다. 안전한 순서로 복원하고, 원본과 비교하고, 선택 복원과 증분 순서 복원까지 하고, 시간을 재서 RTO 충족 여부를 판정한다.