동블

그래프 뷰

01. Backup 종류와 복구 목표 상세

11 min read

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

  • 백업 종류는 RPO/RTO와 어떻게 연결되는가?
  • Spring 백엔드 개발자는 백업 정책에서 무엇을 확인해야 하는가?
  • 백업이 있어도 복구할 수 없게 되는 대표 원인은 무엇인가?

개요

백업은 장애 후 데이터를 되돌릴 수 있게 만드는 운영 장치다.

하지만 운영에서 중요한 것은 “백업 파일이 있다”가 아니라 “어느 시점까지, 얼마 안에, 어떤 검증을 거쳐 복구할 수 있는가”이다.

백엔드 개발자는 백업 솔루션을 직접 운영하지 않더라도 데이터 의미를 설명해야 한다.

어떤 테이블이 핵심 거래 데이터인지, 어떤 데이터는 재생성 가능한 캐시인지, 어떤 파일은 DB row와 함께 움직이는지 알아야 복구 우선순위를 정할 수 있다.

복구 목표

백업 정책은 RPO와 RTO 없이 설명하면 실무 판단으로 이어지지 않는다.

  • RPO는 데이터 손실을 허용할 수 있는 최대 시간이다.
  • RTO는 서비스 복구까지 허용할 수 있는 최대 시간이다.
  • 주문/결제 데이터는 RPO가 매우 짧아야 한다.
  • 통계 집계나 검색 인덱스는 재생성 가능하면 RPO가 길어질 수 있다.
  • RTO가 짧은 서비스는 백업 방식보다 복구 자동화와 권한 준비가 더 중요해질 수 있다.

RPO/RTO는 팀의 희망 사항이 아니라 비용, 장애 영향, 규제, 고객 약속을 반영한 운영 기준이다.

백업 종류

백업 방식은 복구 목표와 맞아야 한다.

  • Logical dump는 테이블 구조와 데이터를 SQL 또는 전용 포맷으로 내보내는 방식이다.
  • Physical backup은 데이터베이스 파일 단위로 복사해 큰 DB 복구에 유리하다.
  • Snapshot은 특정 시점의 디스크 상태를 빠르게 잡지만 애플리케이션 검증을 대신하지 않는다.
  • WAL archiving과 PITR은 특정 시각으로 복구할 수 있게 해 RPO를 줄인다.
  • Incremental backup은 저장 비용을 줄이지만 복구 체인이 깨지면 전체 복구가 실패할 수 있다.
  • Object Storage versioning은 사용자 업로드 파일의 삭제나 덮어쓰기를 되돌리는 데 필요하다.

하나의 서비스에도 DB 백업과 파일 백업, 설정 백업, 암호화 키 보관이 함께 필요할 수 있다.

Spring 백엔드 관점

Spring 애플리케이션은 데이터베이스를 단순 저장소로만 쓰지 않는다.

도메인 규칙, 트랜잭션 경계, 외부 API 호출 결과, 파일 업로드 상태가 DB row에 녹아 있다.

백업 정책을 검토할 때 백엔드 개발자는 다음을 설명해야 한다.

  • 핵심 테이블과 재생성 가능한 테이블의 차이
  • created_at, updated_at, 상태 값이 복구 판단에 쓰이는 방식
  • 배치 작업을 재실행해도 안전한지 여부
  • 외부 결제, 알림, 포인트 지급처럼 DB 밖 부작용이 있는 흐름
  • 파일 업로드가 DB row 생성과 같은 트랜잭션으로 보장되지 않는 지점

이 설명이 없으면 인프라 담당자는 백업 파일을 복원해도 어떤 데이터가 정상인지 판단하기 어렵다.

설정 예시

PostgreSQL logical dump는 작은 서비스나 특정 스키마 검증에 유용하다.

export BACKUP_DATE=2026-07-01
pg_dump \
  --format=custom \
  --file "order-service-${BACKUP_DATE}.dump" \
  "$DATABASE_URL"
 
pg_restore --list "order-service-${BACKUP_DATE}.dump" | head

PITR을 쓰는 환경에서는 백업 파일뿐 아니라 WAL 보관 상태도 확인해야 한다.

select now() as checked_at;
select pg_is_in_recovery();
select pg_current_wal_lsn();

중요한 것은 명령 자체가 아니라 백업 시각, 대상 DB, 보관 위치, 암호화 키, 복구 담당자를 같이 남기는 것이다.

운영 체크리스트

  • 마지막 성공 백업 시각이 RPO 안에 있는지 확인한다.
  • 백업 파일 크기가 평소와 비슷한지 확인한다.
  • 백업 작업이 실패했을 때 운영자가 알 수 있는 경로가 있는지 확인한다.
  • 백업 파일을 읽을 권한과 복호화 키가 분리 보관되는지 확인한다.
  • 백업 보관 기간이 데이터 보존 정책과 맞는지 확인한다.
  • DB 백업과 Object Storage 백업의 기준 시각이 크게 어긋나지 않는지 확인한다.
  • 복구 절차가 특정 개인의 로컬 환경에 의존하지 않는지 확인한다.

장애 신호

  • 백업 성공 로그는 있는데 복원 테스트 기록이 없다.
  • 백업 파일 크기가 갑자기 작아졌지만 원인을 설명할 수 없다.
  • WAL 보관이 끊겼는데 운영 알림이 발생하지 않았다.
  • 백업 계정 권한이 만료되어도 정기 작업이 조용히 실패한다.
  • 암호화 키 위치를 아는 사람이 한 명뿐이다.
  • 사용자 파일은 삭제되었는데 DB 백업만 남아 있다.

이 신호들은 서비스 장애가 아니더라도 복구 실패의 선행 징후다.

안전한 완화 조치

  • 백업 실패가 확인되면 대량 삭제, 스키마 변경, 데이터 보정 배치를 잠시 멈춘다.
  • 최신 백업이 불완전하면 이전 정상 백업과 손실 가능 시간대를 먼저 계산한다.
  • 운영 DB에 바로 복원하지 말고 별도 DB에 복원해 데이터 상태를 확인한다.
  • 복구 지연이 예상되면 쓰기 기능을 제한하고 읽기 기능만 유지하는 방안을 검토한다.
  • 파일 백업 누락이 의심되면 lifecycle 삭제 정책을 즉시 확인하고 보존 가능한 버전을 잠근다.

복구 가능성을 확인하기 전에 운영 데이터를 덮어쓰면 사고 범위를 키울 수 있다.

하지 말아야 할 대응

  • 백업 파일 이름만 보고 복구 가능하다고 선언하지 않는다.
  • 운영 DB에 오래된 dump를 바로 restore하지 않는다.
  • 실패한 백업 작업을 원인 분석 없이 재실행만 반복하지 않는다.
  • RPO를 초과한 상태를 숨기고 정상 운영이라고 보고하지 않는다.
  • 암호화 키, DB 비밀번호, 백업 URL을 공개 채널에 붙여 넣지 않는다.

인프라 담당자와 공유할 자료

  • 서비스명, DB명, 환경, 백업 기준 시각
  • 요구 RPO/RTO와 현재 달성 가능 여부
  • 마지막 성공 백업, 마지막 복원 테스트, WAL 보관 상태
  • 핵심 테이블 목록과 데이터 우선순위
  • Object Storage 버킷, prefix, versioning 여부
  • 복구 검증에 사용할 API, 배치, SQL 목록

자료는 “백업이 필요하다”가 아니라 “어느 데이터가 어느 시점으로 복구되어야 한다”는 형태여야 한다.

확인 질문

확인 질문

  • RPO가 5분인 서비스에서 하루 1회 logical dump만으로 충분하지 않은 이유는 무엇인가?
    • 장애 직전 하루 가까운 데이터를 잃을 수 있어 RPO를 만족하지 못하기 때문이다.
  • 백업 종류를 정할 때 백엔드 개발자가 설명해야 할 데이터는 무엇인가?
    • 핵심 테이블, 재생성 가능한 데이터, 외부 부작용이 있는 데이터, 파일과 연결된 DB row다.
  • 백업이 있어도 복구할 수 없는 상황은 무엇인가?
    • 권한, 암호화 키, WAL, 복원 절차, 애플리케이션 검증 중 하나가 빠진 상황이다.

리뷰 체크포인트

  • 문서에 RPO/RTO가 숫자로 적혀 있는가?
  • 마지막 성공 백업과 마지막 복원 테스트가 구분되어 있는가?
  • DB와 파일 백업 범위가 따로 설명되어 있는가?
  • 복구 담당자와 승인자가 명확한가?
  • 운영 DB에 복원하기 전 검증 환경이 준비되어 있는가?

관련 문서

백링크