복구해 본 적 없는 백업

한 줄 요약

복구해 본 적 없는 백업은 백업이 아니라 백업이라고 믿는 파일이다. 백업의 가치는 오직 복구로만 증명된다.

왜 이게 문제인가

백업이 실패하는 방식은 요란하지 않다. 스크립트가 오류를 내는데 종료 코드를 안 봐서 매일 0 바이트 파일이 쌓이거나, 대상 테이블 목록이 낡아서 새로 만든 테이블만 빠져 있거나, 백업 파일이 원본과 같은 디스크에 있어서 디스크가 죽는 날 함께 사라지거나.

이 모든 경우에 매일의 점검 보고는 "백업 정상" 이다. 그래서 문제는 백업이 필요한 바로 그날 처음 발견된다.

특히 자주 걸리는 것이 데이터 말고 나머지다. 시퀀스·권한·트리거가 빠진 백업은 복구해도 애플리케이션이 안 뜬다. 복구 리허설을 한 번이라도 해 보면 이걸 그날 알게 되고, 안 해 보면 장애 당일에 알게 된다.

백업의 가치는 복구로만 증명된다

운영 점검 회의에서 "백업은 매일 정상적으로 돌고 있습니다"라는 보고를 듣는다.
그다음 질문은 하나여야 한다.

> "마지막으로 그 백업에서 복구해 본 것이 언제입니까?"

대답이 "없습니다"라면 그건 백업이 아니라 백업이라고 믿는 파일이다.
실제로 이런 일들이 일어난다.

• 백업 스크립트가 오류를 내고 있는데 종료코드를 확인하지 않아 매일 0바이트 파일이 생김
• 백업은 되는데 대상 테이블 목록이 낡아서 새로 만든 테이블이 빠져 있음
• 백업 파일이 같은 디스크에 있어서 디스크 장애 시 함께 사라짐
• 복구에 3시간이 걸리는데 그 사실을 장애 당일에 알게 됨
• 복구는 되는데 시퀀스·권한·트리거가 빠져 애플리케이션이 안 뜸

마지막 항목이 특히 흔하다. 데이터만 있으면 복구가 되는 것이 아니다.

백업의 세 가지 축

| 축 | 질문 | 지표 |
| --- | --- | --- |
| 무엇을 | 데이터만? 스키마·권한·시퀀스도? | 백업 대상 목록 |
| 얼마나 자주 | 얼마나 잃어도 되는가 | RPO (복구 시점 목표) |
| 얼마나 빨리 | 얼마나 멈춰도 되는가 | RTO (복구 시간 목표) |

RPO 와 RTO 는 기술이 아니라 업무가 정하는 값이다.
"1시간치 데이터를 잃어도 됩니까?"를 업무 담당자에게 물어야 한다.
그 답에 따라 백업 주기와 방식이 정해진다.

• RPO 24시간 → 일 1회 전체 백업으로 충분
• RPO 1시간 → 전체 백업 + 증분/로그 백업
• RPO 0에 가깝게 → 복제(replication) + 로그 시점 복구

대부분의 SI 프로젝트가 이 대화를 하지 않는다. 그래서 "백업은 매일 새벽에
돌립니다"라는 기술적 사실만 있고, 그것이 업무 요구를 만족하는지는 아무도 모른다.

이행에서의 백업 — 시간이 곧 선택지다

이행(오픈) 작업의 백업은 성격이 다르다.
롤백 수단으로 쓸 수 있어야 하기 때문이다.

새벽 2시에 시작해 4시까지 판단해야 하는 작업에서
복구에 3시간 걸리는 백업은 선택지가 아니다.
그래서 이행 계획에는 반드시 이 두 줄이 들어가야 한다.

백업 소요 시간 : 실측 __분복구 소요 시간 : 실측 __분   ← 이 값이 롤백 판단 시한을 결정한다

복구가 오래 걸린다면 다른 수단을 준비한다.

• 스냅샷(스토리지/가상화 레벨) — 대개 훨씬 빠르다
• 변경 대상 테이블만 별도 백업 — 전체를 되돌릴 필요가 없다면
• 스키마 변경을 되돌릴 수 있게 설계 (확장-이관-축소)

백업 대상에서 자주 빠지는 것들

데이터베이스만 백업하고 끝내면 복구가 안 된다.

• DB 계정과 권한 — 복구한 DB 에 계정이 없으면 애플리케이션이 못 붙는다
• 시퀀스/자동증가 현재값 — 되돌아가면 PK 충돌이 난다
• 뷰·트리거·프로시저·함수
• 애플리케이션 설정 파일 — 이행 편에서도 강조한 그것
• 배치 스케줄 정의
• 인증서와 키

그래서 백업 대상 목록을 문서로 관리하고, 새 객체가 추가될 때
목록을 갱신하는 절차가 필요하다. 자동 백업이 "스키마 전체"를 잡는다면
많이 해결되지만, 그것조차 확인해 본 적이 있어야 안다.

복구 리허설 절차

리허설은 이렇게 한다. 요령은 운영 서버가 아닌 곳에서, 백업만 갖고 하는 것이다.

1. 백업 파일을 별도 서버/디렉터리로 가져온다 (운영에서 직접 복구하지 않는다)2. 빈 상태에서 복구를 수행한다 — 시작·종료 시각을 기록3. 검증   - 테이블 수, 주요 테이블 행 수   - 시퀀스 현재값   - 계정·권한·인덱스·제약   - 애플리케이션 기동과 로그인 (가능하면)4. 결과를 문서로 — 소요 시간, 발견된 누락, 조치5. 발견된 누락을 백업 대상 목록에 반영

3번의 마지막 줄이 리허설의 진짜 가치다. "복구는 됐는데
애플리케이션이 안 뜬다"를 장애 당일이 아니라 리허설에서 발견하는 것.

백업 검증 자동화

리허설을 매번 사람이 하기는 어렵다. 최소한 이 정도는 자동화한다.

# 매일 백업 직후 자동 검증1. 백업 파일이 생성됐는가 (존재 + 크기 > 최소 기준)2. 백업 명령의 종료코드가 0인가        ← 놀랍게도 이걸 안 보는 곳이 많다3. 파일이 열리는가 (압축이면 무결성 검사)4. 예상 객체가 포함돼 있는가 (테이블 목록 grep)5. 주 1회: 실제 복구 후 행 수 비교

2번을 강조하고 싶다. 백업 스크립트가 실패하는데 크론이 오류를 삼키고 있으면
아무도 모른다. 종료코드를 확인하고, 실패 시 경보를 보내야 한다.
"백업 실패 알림이 온 적이 없다"는 것은 "백업이 항상 성공한다"가 아니라
"알림 자체가 없다" 일 수 있다.

보관과 삭제

백업은 무한히 쌓인다. 정책이 필요하다.

일 백업: 14일 보관주 백업: 8주 보관월 백업: 12개월 보관

보관 개수가 곧 되돌릴 수 있는 범위다. 일 백업 14개면 2주 전으로 돌아갈 수 있다.
"3개월 전 데이터를 복원해 주세요"라는 요청이 올 수 있는 업무라면
그 기간만큼 보관해야 한다. 이것도 업무와 합의할 항목이다.

그리고 삭제도 자동화하되 안전장치를 둔다.
"오래된 것 삭제" 스크립트의 버그로 전부 지운 사례가 실제로 있다.
날짜 조건으로만 지우고, 최소 보관 개수를 하한으로 두고,
삭제 전에 목록을 로그로 남긴다.

그리고, 백업은 다른 곳에 둔다

같은 서버, 같은 디스크에 있는 백업은 그 서버가 죽으면 함께 죽는다.
최소한 다른 스토리지, 가능하면 다른 물리 위치에 사본을 둔다.

폐쇄망 환경이면 외부 클라우드가 안 되니, 사내 백업 전용 스토리지나
테이프/외장 매체를 쓴다. 그때는 매체 반출입 절차와 암호화가
함께 따라온다. 이것도 이행 전에 정리해 둘 항목이다.

현장에서 만나는 모습

이행 계획을 짤 때 백업이 곧 시간 계산이 되는 순간이 있다. 복구에 3 시간이 걸리는 백업이라면, 롤백 판단 시한은 작업 종료 3 시간 전이어야 한다. 이 산수를 안 해 두면 새벽 네 시에 "지금 되돌리면 아침 업무 시작에 못 맞춘다" 는 것을 그 자리에서 깨닫게 된다.

그래서 백업 항목에 적어야 할 것은 "백업 완료" 가 아니라 파일 경로와 복구 소요 시간이다. 실제 파일명을 이행 결과 보고서에 적게 하는 규칙도 같은 이유에서 나왔다 — 정작 필요한 순간에 어느 파일인지 찾는 데 시간을 쓰지 않기 위해서다.