Ubuntu: 백업을 ‘돌려보기’ 전까지 믿지 않는 이유

대상 OS: Ubuntu Server 24.04 LTS

백업이 실패하는 가장 흔한 이유는 “백업 파일이 없다”가 아니라 복구가 실제로 안 된다는 것입니다. 운영 환경에서 백업은 파일이 쌓이는 순간 끝나는 게 아니라, 복구 절차가 검증된 상태가 되어야 비로소 가치가 생깁니다.

특히 랜섬웨어/계정 탈취/삭제 사고의 본질은 “데이터가 사라졌다”가 아니라 “제 시간 안에 정상 상태로 돌아갈 수 없다”입니다. 그래서 백업은 반드시 “돌려보기(복구 리허설)”가 포함되어야 합니다.

1) ‘백업 성공 로그’만 보면 안 되는 핵심 포인트

• 권한/소유자/ACL/xattr가 복구되지 않아 서비스가 기동 실패
• DB 일관성이 깨져 애플리케이션이 오류(특히 파일백업만 했을 때)
• 암호화 키/패스프레이즈 분실(암호화 백업의 역설)
• 복구 순서가 문서화되지 않아 장애 시 우왕좌왕

2) 먼저 목표를 정하자: RPO/RTO(보안/운영의 합의점)

복구 테스트를 하려면 기준이 필요합니다.

• RPO(Recovery Point Objective): “최대 얼마만큼 과거 시점까지 데이터 유실을 허용할 것인가”
• RTO(Recovery Time Objective): “최대 몇 분/시간 안에 복구되어야 하는가”

RPO/RTO가 정해지면 백업 주기/보관 정책/복구 방식(스냅샷, 스트리밍 복제, 오브젝트 스토리지 등)이 결정됩니다.

3) 최소 복구 테스트 체크리스트(현실적으로 가능한 ‘작은’ 테스트)

매번 전체 복구를 하기는 어렵습니다. 대신 작고 반복 가능한 복구 테스트를 정례화하세요.

3-1) 백업 존재/용량/최근성 점검

# 백업 경로는 환경별로 다릅니다. 예시: /var/backups
df -h
sudo ls -alh /var/backups 2>/dev/null

3-2) “골든 파일” 1~2개 복구 테스트(권한 포함)

서비스 운영에 필수인 파일(예: 설정 파일, 인증서, 중요 업로드 파일)을 골든 파일로 지정하고 복구 연습을 합니다.

# 예시: tar 백업을 특정 경로로 복구(원본 덮어쓰기 금지)
mkdir -p /tmp/restore-test
sudo tar -xvf /var/backups/myapp-etc.tar -C /tmp/restore-test

# 권한/소유자 확인
sudo ls -al /tmp/restore-test | head

3-3) DB는 ‘파일 백업’ 말고 restore를 실제로 해보기(PostgreSQL 예시)

DB는 “덤프가 있다”가 아니라 “복원이 된다”가 중요합니다. 샌드박스(별도 VM/컨테이너)에서 최소 주 1회는 restore를 수행하세요.

# (예시) PostgreSQL 덤프 파일 복구
# 준비: 테스트용 DB 생성
sudo -u postgres createdb restore_test

# 복구 실행(덤프 형식에 맞게 pg_restore/psql 사용)
sudo -u postgres pg_restore -d restore_test /var/backups/pg/mydb.dump

# 간단 검증: 테이블 수/대표 쿼리
sudo -u postgres psql -d restore_test -c "\dt"

4) 복구 절차(runbook)를 ‘명령어 단위’로 문서화

복구는 장애 시 사람이 하는 작업입니다. 따라서 문서가 “설명”이 아니라 실행 가능한 커맨드여야 합니다.

• 어디서(서버/계정) 어떤 순서로 실행하는지
• 서비스 중지/시작 순서(예: DB → 앱 → 워커 → 프록시)
• 필요한 시크릿/키(위치, 접근 방식, 담당자)
• 검증 체크(헬스체크 URL, 주요 쿼리, 에러 로그 확인)

5) 백업 보안(무결성/접근통제/오프사이트)

백업은 공격자가 가장 먼저 노리는 자산입니다.

• 오프사이트/오프라인: 동일 계정/동일 스토리지에만 있으면 랜섬웨어에 같이 암호화될 수 있음
• 권한 최소화: 백업 저장소는 “쓰기 전용(append-only)” 또는 별도 자격증명 사용
• 무결성: 백업 파일 해시/서명(또는 스토리지의 Object Lock/WORM) 고려

사례(현장에서 자주 겪는 상황)

• 백업은 매일 돌았는데, 막상 복구하려니 권한/소유자 누락으로 서비스가 계속 500을 뱉는다.
• DB를 파일로만 백업해두고 “복구 완료”라고 생각했다가, 실제 복구 시 트랜잭션 일관성 문제로 데이터가 깨진다.
• 암호화 백업을 도입했지만, 키를 담당자 개인 PC에만 저장해두어 담당자 부재 시 복구 불가가 된다.

트러블슈팅(증상→원인→해결)

• 증상: 복구 후 서비스가 “Permission denied”로 기동 실패
  원인: tar/rsync 옵션 미흡으로 소유자/권한/ACL이 복원되지 않음
  해결: 백업/복구 시 권한 보존 옵션을 명시하고(도구별 상이), 복구 테스트에 ls -al 및 서비스 계정 접근 검증을 포함
• 증상: DB 복구는 됐는데 애플리케이션이 데이터 불일치/외래키 오류
  원인: 온라인 상태에서 파일 단위 백업을 떠 일관성이 깨짐
  해결: DB 덤프/스냅샷 등 일관성 있는 백업 방법으로 전환하고, 샌드박스 restore를 정례화
• 증상: 백업 파일은 있는데 복구 시간이 RTO를 초과
  원인: 네트워크/스토리지 대역폭, 압축/암호화 비용, 복구 절차 미숙
  해결: 복구 리허설로 병목을 측정하고(다운로드/복호화/전개 시간), 스냅샷/증분 백업/복구 자동화로 개선
• 증상: 랜섬웨어 후 백업까지 삭제/암호화됨
  원인: 운영 계정이 백업 저장소까지 같은 권한을 가짐
  해결: 오프사이트 + 별도 자격증명 + Object Lock/WORM/append-only 같은 보호장치 적용

- 이 글은 ai가 random적으로 만들어 올리는 글입니다. -