백업과 복구 (Backup and Recovery)

백업과 복구란

백업(Backup) 은 데이터의 특정 시점 상태를 보존해 두는 작업이고,
복구(Recovery) 는 장애나 실수 이후 원하는 시점으로 데이터를 되돌리거나 재구성하는 작업입니다.

백엔드 면접에서 이 주제는 단순히 “dump를 뜬다” 수준으로 끝나지 않습니다.
보통 다음 질문으로 이어집니다.

장애가 나면 어디까지 데이터를 잃을 수 있는가
복구에 얼마나 시간이 걸리는가
replica가 있는데도 왜 백업이 필요한가
복구 절차를 실제로 검증해 봤는가

즉, 이 문서의 핵심은
데이터를 어떻게 보관할지보다, 장애 시 어떤 시점까지 어떤 시간 안에 복구할 수 있는지를 설명하는 것입니다.

복제와 장애 전환의 일반론은 PostgreSQL / MySQL, 읽기 확장과 replica lag는 데이터베이스 스케일링 문서와 함께 보면 좋습니다.

왜 백업이 필요한가

운영 중 데이터는 생각보다 다양한 이유로 손상되거나 유실될 수 있습니다.

사용자 실수: 잘못된 DELETE, 잘못된 배치 실행
애플리케이션 버그: 잘못된 migration, 잘못된 update 쿼리
운영 실수: 스키마 변경 오류, 잘못된 failover
인프라 장애: 스토리지 장애, 리전 장애, 계정 사고
보안 사고: 랜섬웨어, 자격 증명 유출

중요한 점은 고가용성과 백업이 같은 문제가 아니라는 것입니다.

고가용성은 서비스를 계속 띄우는 문제
백업은 데이터를 되돌릴 수 있는가의 문제

예를 들어 primary가 죽었을 때 replica로 failover는 할 수 있어도,
애플리케이션 버그가 잘못된 데이터를 replica까지 복제해 버렸다면 백업 없이는 되돌리기 어렵습니다.

즉, 백업은 장애 복구뿐 아니라
사람과 소프트웨어가 만든 잘못된 상태를 되돌리는 마지막 안전장치입니다.

논리 백업과 물리 백업

백업은 크게 논리 백업(Logical Backup) 과 물리 백업(Physical Backup) 으로 나눠 설명하는 편이 좋습니다.¹²

구분	논리 백업	물리 백업
대상	SQL dump, 테이블/스키마 단위 데이터	데이터 파일, WAL/binlog, 스토리지 스냅샷
장점	일부 테이블 선택, 이식성, 사람이 읽기 쉬움	대용량/빠른 복구, PITR과 연결하기 좋음
단점	대용량에서 느릴 수 있음	엔진/버전/환경 의존성이 큼
잘 맞는 경우	소규모 DB, 일부 데이터 이동, 스키마 검토	운영 DB 전체 복구, DR, 대용량 시스템

논리 백업

논리 백업은 보통 SQL 또는 엔진이 읽을 수 있는 덤프 형태입니다.

장점: 특정 DB나 테이블만 선택해 백업하기 쉬움
장점: 다른 환경으로 옮기거나 일부 데이터만 복원하기 쉬움
주의점: 데이터가 크면 백업/복구 시간이 오래 걸릴 수 있음
주의점: 복원 중 인덱스 재생성, 제약 복구 비용이 커질 수 있음

물리 백업

물리 백업은 데이터 파일과 로그 파일 수준의 백업입니다.

장점: 대용량 데이터베이스를 빠르게 복구하기 좋음
장점: PITR과 결합하기 쉬움
주의점: DB 엔진과 버전, 스토리지 환경에 더 강하게 묶임
주의점: 운영 자동화와 절차 검증이 필요함

좋은 답변은 “어느 쪽이 더 좋다”가 아니라
복구 목표와 데이터 크기에 따라 조합해서 쓴다고 설명하는 편이 좋습니다.

전체 백업, 증분 백업, 스냅샷

백업 빈도와 비용을 설명할 때 자주 나오는 구분입니다.

전체 백업 (Full Backup)

특정 시점의 전체 데이터를 모두 백업합니다.

장점: 구조가 단순하고 복구 절차를 이해하기 쉬움
단점: 시간과 저장 공간 비용이 큼

증분 백업 (Incremental Backup)

이전 백업 이후 바뀐 부분만 저장합니다.

장점: 저장 공간과 백업 시간 절감
단점: 복구 경로가 길어지고, 체인 일부가 손상되면 복구가 복잡해질 수 있음

스냅샷 (Snapshot)

스토리지 또는 관리형 DB 서비스 수준에서 특정 시점 상태를 캡처합니다.

장점: 운영에서 빠르게 찍고 복원하기 좋음
장점: 관리형 서비스와 잘 맞음
주의점: 스냅샷만으로 PITR이 되는 것은 아님
주의점: 스냅샷의 일관성 보장 범위와 지역 복제 여부를 같이 봐야 함

실무에서는 보통 다음처럼 섞어서 갑니다.

주기적 전체 백업
트랜잭션 로그/WAL/binlog 보관
스냅샷 자동화

즉, 실제 전략은 단일 방식보다
전체 백업 + 로그 보존 + 스냅샷 조합으로 설명하는 편이 자연스럽습니다.

PITR이란

PITR(Point-in-Time Recovery) 은
원하는 시점 직전까지 데이터를 복구하는 방식입니다.³⁴

예를 들어:

오전 10시에 전체 백업이 있었고
오전 10시 37분에 잘못된 DELETE가 실행됐다면
오전 10시 36분 59초 상태까지 복구하고 싶을 수 있습니다

이때 필요한 것은 보통 다음 조합입니다.

기준 시점의 백업
그 이후의 변경 로그
- PostgreSQL의 WAL
- MySQL의 binlog

면접에서는 PITR을 “세밀한 복구” 정도로만 말하지 말고,
백업 한 장으로는 안 되고 로그 보존 정책이 같이 있어야 한다고 설명하는 편이 좋습니다.

PITR의 주의점도 분명합니다.

로그 보존 기간을 짧게 잡으면 원하는 시점까지 못 돌아감
복구 시점 선택을 잘못하면 잘못된 상태를 다시 포함할 수 있음
실제 복구 시간을 줄이려면 정기적인 기준 백업도 중요함

RPO와 RTO

백업과 복구를 면접에서 설명할 때는 RPO 와 RTO 를 같이 말해야 합니다.

지표	의미	질문으로 바꾸면
RPO (Recovery Point Objective)	얼마나 최근 데이터까지 보장할 것인가	최대 얼마만큼의 데이터 유실을 허용하는가
RTO (Recovery Time Objective)	얼마 안에 서비스/데이터를 복구할 것인가	장애 후 얼마 안에 돌아와야 하는가

예를 들어:

결제 시스템은 RPO를 매우 낮게 잡아야 할 수 있음
내부 통계 시스템은 약간의 유실을 감수할 수 있음
고객-facing 서비스는 RTO가 특히 중요할 수 있음

좋은 답변은 “백업을 자주 한다”보다
우리 시스템이 감당 가능한 데이터 유실과 다운타임을 먼저 정의하고, 거기에 맞춰 백업 전략을 고른다는 흐름입니다.

Replica가 Backup을 대체하지 못하는 이유

이 질문은 면접에서 자주 나옵니다.

답은 분명합니다. replica는 고가용성/읽기 확장 도구이지, 백업의 완전한 대체제가 아닙니다.

이유는 다음과 같습니다.

잘못된 데이터도 복제됨: 버그나 실수로 잘못 쓴 데이터가 replica에도 그대로 전파될 수 있음
삭제도 복제됨: 잘못된 DROP TABLE, DELETE도 같이 반영될 수 있음
시간을 되돌리지 못함: replica는 보통 현재 상태를 따라가는 장치이지, 과거 시점 복원 장치가 아님
같은 장애 영역일 수 있음: 같은 리전, 같은 계정, 같은 스토리지 계층이면 함께 영향을 받을 수 있음

즉, replica는 서비스를 빨리 다시 띄우는 용도,
backup은 원하는 시점의 데이터를 되돌리는 용도라고 구분하는 편이 좋습니다.

관련 복제 운영은 PostgreSQL / MySQL, replica lag와 읽기 확장은 데이터베이스 스케일링 문서와 직접 연결됩니다.

복구 절차와 복구 훈련

백업 전략에서 가장 자주 빠지는 부분이 복구 훈련입니다.

백업 파일이 있다고 해서 복구가 되는 것은 아닙니다.

파일이 실제로 읽히는가
필요한 로그가 모두 보존됐는가
복구 순서를 팀이 알고 있는가
애플리케이션 연결 전환과 검증 절차가 준비됐는가

좋은 운영팀은 보통 다음을 같이 준비합니다.

복구 절차 문서화
정기적인 restore drill 수행
샌드박스 환경에서 복구 시간 측정
데이터 검증 체크리스트 준비

면접에서는 “백업을 자동화합니다”보다
정기적으로 복원 훈련을 해서 실제 RTO/RPO를 검증한다고 말하는 편이 훨씬 실무적으로 들립니다.

대표 복구 순서는 다음과 같습니다.

장애 범위 확인
복구 목표 시점 결정
기준 백업 복원
필요한 로그/WAL/binlog 재적용
데이터 무결성 검증
애플리케이션 트래픽 전환
사후 검토와 재발 방지

운영 시 자주 보는 포인트

백업과 복구를 운영 관점에서 볼 때는 다음을 같이 확인하는 편이 좋습니다.

백업 성공률: 스케줄은 돌았지만 실제 파일이 깨져 있을 수 있음
백업 크기 증가율: 평소보다 급증하면 데이터 이상이나 설정 변경을 의심
로그 보존 기간: PITR 목표를 만족하는지 확인
복구 시간 측정: 문서상 RTO가 아니라 실제 restore drill 기준으로 확인
오프사이트/교차 리전 보관: 같은 장애 영역에 함께 묶이지 않는지 확인
암호화와 접근 제어: 백업 파일도 민감 데이터임
보존 정책: 무한 보관은 비용 문제, 너무 짧은 보존은 복구 실패 위험

관리형 DB를 쓰더라도 이 질문은 사라지지 않습니다.

자동 스냅샷이 실제 요구 RPO/RTO를 만족하는가
cross-region backup이 필요한가
수동 검증과 복구 훈련을 했는가

즉, 면접에서는 “관리형이 알아서 해준다”보다
관리형 기능의 한계를 알고, 실제 복구 가능성을 검증한다고 설명하는 편이 좋습니다.

면접 포인트

백업은 고가용성과 다른 문제이며, 장애뿐 아니라 실수와 버그로부터 데이터를 되돌리는 장치입니다.
논리 백업과 물리 백업은 장단점이 다르므로 데이터 크기와 복구 목표에 따라 조합해서 써야 합니다.
PITR은 기준 백업과 로그 보존이 함께 있어야 가능한 복구 전략입니다.
RPO와 RTO를 먼저 정의하고, 그 목표에 맞춰 백업 주기와 복구 절차를 설계해야 합니다.
replica는 backup을 대체하지 못하며, restore drill 없이는 백업 전략이 완성됐다고 보기 어렵습니다.