DB 백업은 평소엔 아무도 신경 안 쓰다가, 사고가 터지고 나서야 "백업 어디 있어?"라고 외치게 되는 영역입니다. 저도 프로젝트 DB를 실수로 날려보고 나서야 그 무게를 실감했어요. 그래서 이 글은 교과서 같은 이야기 말고, 직접 데이터를 날려보고 살려본 경험과 현장에서 검증된 사례를 바탕으로 DB 백업과 복구 전략을 정리했습니다.
목차
- 1. DB 백업이 왜 그렇게 중요한가
- 2. 백업 방식별 비교와 선택 기준
- 3. 실전 복구 전략과 재해 복구(DR)
- 4. 현장에서 쓰는 실전 팁
1. DB 백업이 왜 그렇게 중요한가
데이터는 한 번 날아가면 끝입니다
서버는 다시 띄우면 되고 코드는 git에서 받으면 되지만, 데이터는 한 번 사라지면 복구할 방법이 없습니다. 저는 예전에 운영 DB에서 WHERE 절을 빼고 DELETE를 날린 동료를 본 적이 있는데, 그날 우리를 살린 건 오직 전날 새벽의 DB 백업뿐이었어요. 백업이 없었다면 회사가 흔들릴 수준의 사고였습니다.
RPO와 RTO부터 정하세요
복구 전략을 세우기 전에 두 가지 숫자를 먼저 정해야 합니다. RPO(목표 복구 시점)는 "데이터를 얼마나 잃어도 되는가", RTO(목표 복구 시간)는 "얼마나 빨리 살려야 하는가"입니다. 쇼핑몰 주문 DB라면 RPO를 분 단위로 잡아야 하고, 단순 로그성 DB라면 하루치 손실도 감수할 수 있죠. 이 두 숫자가 백업 주기와 방식을 전부 결정합니다.
2. 백업 방식별 비교와 선택 기준
전체 / 증분 / 차등 백업
가장 흔한 세 가지 방식입니다. 전체 백업은 통째로 복사하니 복구는 편하지만 용량과 시간이 큽니다. 증분 백업은 마지막 백업 이후 바뀐 것만 저장해 빠르지만, 복구할 때 여러 단계를 순서대로 적용해야 해서 까다롭습니다. 차등 백업은 그 중간쯤이라고 보시면 됩니다.
한눈에 보는 장단점 비교표
| 백업 방식 | 장점 | 단점 | 추천 상황 |
|---|---|---|---|
| 전체 백업 | 복구가 단순하고 빠름 | 용량 크고 시간 오래 걸림 | 주 1회 기준점용 |
| 증분 백업 | 용량 작고 백업이 빠름 | 복구 절차가 복잡함 | 변경 적은 대용량 DB |
| 차등 백업 | 복구·속도 균형이 좋음 | 날짜 지날수록 용량 증가 | 일반적인 운영 환경 |
현실적인 조합
제가 추천하는 건 "주 1회 전체 + 매일 증분 + 실시간 트랜잭션 로그" 조합입니다. 이렇게 하면 DB 백업 용량은 줄이면서도 거의 사고 직전 시점까지 복구가 가능해요. 한 가지 방식만 고집하면 반드시 어딘가에서 발목이 잡힙니다.
3. 실전 복구 전략과 재해 복구(DR)
복구 훈련을 안 하면 백업은 없는 것과 같다
가장 솔직하게 말씀드리면, 백업 파일이 있다고 안심하는 게 가장 위험합니다. 막상 복구를 시도했더니 파일이 깨져 있거나, 복구 절차를 아무도 모르거나, 권한이 없어서 손도 못 대는 경우를 정말 많이 봤어요. 복구는 평소에 연습해두지 않으면 실전에서 절대 제대로 못 합니다.
재해 복구(DR)는 물리적 거리를 둬라
같은 서버실, 같은 리전에만 백업을 두면 화재나 침수 한 번에 원본과 백업이 동시에 사라집니다. 재해 복구의 핵심은 지리적으로 떨어진 곳에 사본을 두는 것입니다. 클라우드라면 다른 리전, 온프레미스라면 다른 건물이나 외부 스토리지로 한 부를 더 보내세요.
3-2-1 규칙
업계 표준인 3-2-1 규칙은 단순하지만 강력합니다. 데이터 사본 3개, 서로 다른 매체 2종류, 그중 1개는 외부에 보관. 재해 복구를 고민한다면 이 규칙 하나만 지켜도 절반은 성공입니다.
4. 현장에서 쓰는 실전 팁
팁 1 — 백업 성공 알림보다 실패 알림에 집중하라
매일 "백업 성공" 메일이 오면 사람은 금방 무뎌집니다. 차라리 실패했을 때만 강하게 알람이 울리도록 설정하고, 주기적으로 백업 파일 크기가 0바이트가 아닌지 자동 점검하는 스크립트를 걸어두세요.
팁 2 — 복구 시간을 실제로 측정해 문서화하라
"복구하면 됩니다"가 아니라 "전체 복구에 47분 걸립니다"처럼 숫자로 알고 있어야 합니다. 한 번이라도 실제 복구를 돌려서 시간을 재두면, 장애 상황에서 윗선에 보고할 때도 훨씬 든든합니다.
팁 3 — 백업본도 암호화하고 권한을 나눠라
백업 파일은 운영 DB 전체가 담긴 보물상자입니다. 유출되면 그 자체로 보안 사고예요. 반드시 암호화하고, 백업 삭제 권한과 복구 권한을 다른 사람에게 분리해두는 것이 좋습니다. 랜섬웨어가 백업까지 노리는 시대라 이 부분은 절대 타협하면 안 됩니다.
마무리 — 이런 분께 추천합니다
지금까지 DB 백업과 복구, 그리고 재해 복구 전략을 실전 경험 위주로 풀어봤습니다. 핵심만 다시 정리하면, RPO/RTO를 먼저 정하고, 전체·증분·차등을 조합하며, 무엇보다 복구 훈련을 반드시 해보라는 것입니다.
이 글은 이제 막 운영 DB를 책임지게 된 주니어 개발자, 백업은 돌고 있지만 복구는 한 번도 안 해본 소규모 팀, 재해 복구 체계를 처음 세우는 스타트업 인프라 담당자에게 특히 도움이 될 거예요. 솔직히 백업은 들이는 시간 대비 티가 안 나는 일이지만, 사고가 터지는 그 단 하루를 위해 존재합니다. 오늘 당장 여러분의 백업이 진짜 복구되는지 한 번만 확인해보시길 진심으로 권합니다.
