이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 백업이 있다는 말과 복구 가능하다는 말은 왜 다른가?
- RTO, RPO, PITR은 백엔드 개발자에게 어떤 의미인가?
- 개인 프로젝트에서도 어떤 백업 기준을 가져야 하는가?
개요
백업은 장애 복구의 마지막 방어선이다. 그러나 백업 파일이 있다는 것과 실제로 복구할 수 있다는 것은 다르다. 복구 시간, 데이터 손실 범위, 권한, 절차, 리허설이 있어야 한다.
백엔드 개발자는 백업을 인프라의 일로만 넘기면 안 된다. 데이터 삭제 기능, 마이그레이션, 대량 작업, 운영 쿼리를 작성하는 사람이 복구 가능성을 알아야 한다.
원리
백업 전략의 핵심은 파일 보관이 아니라 복구 가능한 시간선을 유지하는 것이다. 백업본, WAL/binlog, 권한, 암호화 키, 복구 절차, 애플리케이션 검증이 함께 있어야 실제 장애에서 데이터를 되살릴 수 있다.
백엔드 개발자는 복구를 인프라 작업으로만 보지 않는다. 자신이 만든 삭제 기능, 배치, migration, 운영 쿼리가 어떤 복구 시나리오를 요구하는지 알아야 하고, 위험 작업 전에는 RTO/RPO와 PITR 가능 범위를 확인해야 한다.
핵심 용어
- RTO: 복구에 허용되는 시간이다.
- RPO: 잃어도 되는 데이터 시간 범위다.
- PITR: Point-in-Time Recovery, 특정 시점으로 복구하는 기능이다.
예를 들어 운영자가 실수로 13:05에 대량 DELETE를 실행했다면, PITR로 13:04:59 시점으로 복구할 수 있는지가 중요하다.
백업과 복구의 차이
나쁜 상태:
백업은 매일 된다고 들었습니다.
복구는 해본 적 없습니다.
복구 시간은 모릅니다.
어느 시점까지 되돌릴 수 있는지 모릅니다.좋은 상태:
매일 full backup + WAL/binlog 기반 PITR 가능
RPO 5분, RTO 1시간 목표
분기별 복구 리허설 수행
복구 DB에서 애플리케이션 smoke test 수행백엔드와 연결되는 지점
백엔드 개발자는 다음 작업 전 백업과 복구를 확인해야 한다.
- 대량 DELETE/UPDATE
- destructive migration
- 개인정보 삭제
- 결제/포인트 데이터 변경
- 운영 DB 직접 쿼리
- 데이터 정정 작업
작업 전 “백업 있나요?”가 아니라 “어느 시점으로 얼마나 빨리 복구할 수 있나요?”를 물어야 한다.
개인 프로젝트 기준
개인 프로젝트에서도 최소한 다음을 챙긴다.
- 주기적 dump 또는 클라우드 자동 백업
- migration 전 수동 백업
- 복구 명령 문서화
- 로컬에 복구 리허설
- 민감정보가 포함된 백업 파일 관리
예를 들어 PostgreSQL dump는 다음처럼 만들 수 있다.
pg_dump "$DATABASE_URL" > backup-2026-06-30.sql복구는 별도 DB에서 시험한다.
psql "$RESTORE_DATABASE_URL" < backup-2026-06-30.sql운영에서는 관리형 백업과 PITR을 우선 검토한다.
복구 리허설
복구 리허설은 “백업 파일을 다운로드했다”가 아니라 서비스가 다시 읽을 수 있는지 확인하는 절차다.
1. 복구 대상 시점 결정
2. 별도 DB 인스턴스 또는 별도 데이터베이스에 복구
3. 애플리케이션을 복구 DB에 연결
4. 핵심 API smoke test
5. 데이터 정합성 샘플 검증
6. 실제 소요 시간과 막힌 권한 기록리허설을 해보면 예상 밖의 문제가 나온다.
- 백업 파일 접근 권한이 없다.
- 암호화 키 접근 절차를 모른다.
- 복구 DB 보안 그룹이 애플리케이션에서 접근 불가다.
- 마이그레이션 버전과 백업 시점이 맞지 않는다.
- 복구는 됐지만 검색 인덱스나 캐시 재생성이 필요하다.
그래서 RTO는 문서에 적은 숫자가 아니라 실제 리허설에서 측정한 시간이어야 한다.
PITR 판단 기준
PITR은 실수 직전으로 되돌릴 수 있다는 점에서 강력하지만, 운영에서는 간단하지 않다. 전체 DB를 과거로 되돌리면 정상 사용자 작업까지 함께 사라질 수 있다.
예를 들어 13:05에 운영자가 잘못된 DELETE를 실행했고, 13:06~13:20 사이 정상 주문이 계속 들어왔다면 선택지는 여러 개다.
- 전체 DB를 13:04:59로 복구하고 이후 정상 주문을 재처리한다.
- 별도 복구 DB를 13:04:59로 띄운 뒤 삭제된 데이터만 추출해 현재 DB에 복원한다.
- 애플리케이션 이벤트 로그나 원장으로 forward fix 한다.
- 영향 범위가 작으면 수동 보정과 감사 로그를 남긴다.
백엔드 개발자는 어떤 데이터가 재처리 가능한지, 어떤 이벤트 로그가 있는지, 어떤 상태 변경이 외부 시스템과 연결되는지 설명해야 한다.
실전 팁
- 복구 리허설 없는 백업은 신뢰하지 않는다.
- destructive 작업 전 복구 지점을 확인한다.
- 백업 파일의 개인정보와 접근 권한을 관리한다.
- PITR 복구 후 애플리케이션이 정상 동작하는지 smoke test 한다.
- 복구 절차는 장애 중 처음 읽어도 따라 할 수 있어야 한다.
- PITR은 전체 되돌리기와 부분 복원 중 어느 쪽이 비즈니스 손실이 작은지 판단해야 한다.
- 백업 성공 알림뿐 아니라 백업 실패, WAL/binlog 아카이브 지연, 저장소 용량도 모니터링한다.
- 복구 리허설 결과에는 실제 소요 시간, 실패한 권한, 애플리케이션 검증 결과를 남긴다.
위험 신호!
- 백업은 있는데 복구해본 사람이 없다.
- RTO/RPO를 아무도 모른다.
- 운영 DB 대량 변경 전 백업 상태를 확인하지 않는다.
- 백업 파일이 개인 노트북에 암호화 없이 저장된다.
- 복구 DB에서 애플리케이션 검증을 하지 않는다.
- PITR로 되돌리면 그 사이의 정상 거래도 사라진다는 점을 고려하지 않는다.
- 백업은 성공하지만 WAL/binlog 아카이브 지연이나 저장소 포화 알림이 없다.
- 복구 권한과 암호화 키 접근 절차를 장애 중에 처음 찾는다.
확인 질문
- 백업이 있다는 것과 복구 가능하다는 것은 왜 다른가?
- 백업 파일이 있어도 복구 시간, 데이터 손실 범위, 절차, 권한, 검증이 없으면 실제 장애에서 사용할 수 없기 때문이다.
- PITR이 중요한 상황은 언제인가?
- 특정 시점의 실수나 장애 직전 상태로 되돌려야 할 때 중요하다.
- 대량 데이터 변경 전 확인해야 할 복구 정보는 무엇인가?
- 마지막 백업 시점, PITR 가능 여부, RTO/RPO, 복구 리허설 여부, rollback 또는 forward fix 계획이다.
- PITR 복구를 별도 DB에 먼저 수행하는 이유는 무엇인가?
- 현재 운영 데이터를 바로 덮어쓰지 않고 삭제된 데이터 추출, 정상 거래 보존, 애플리케이션 검증을 안전하게 수행하기 위해서다.