1. DB 백업과 복구 리허설

사고 시나리오

콘솔에서 쿼리를 직접 치다가 WHERE 절을 빼먹는다. UPDATE 한 줄이 전체 행을 덮는다. 마이그레이션 스크립트가 테이블을 지운다. 되돌릴 방법을 찾는 순간 깨닫는다 — 백업이 없다. 혹은 백업은 있는데, 복구를 한 번도 해본 적이 없어서 그 백업이 실제로 살아나는지 아무도 모른다.

원칙

백업의 완성 조건은 “백업이 있다”가 아니라 “복구에 성공해봤다”이다. 복구를 리허설해보지 않은 백업은 심리적 안정감일 뿐, 운영 수단이 아니다.

실무 처방

• 자동 백업을 켠다. 요즘 관리형 DB는 대부분 시점 복구(point-in-time recovery)를 기본 제공한다 — 켜져 있는지, 보존 기간이 며칠인지 확인부터.
• 복구 리허설은 운영 DB가 아니라 일회용 DB에서 한다. 만들고 → 데이터 넣고 → 시점 기록하고 → 더 쓰고 → 그 시점으로 복구해서 이후 데이터가 사라지는지 확인하고 → 버린다.
• 복구 절차를 5줄짜리 runbook으로 남긴다. 사고 당일의 나는 침착하지 않다. 명령어를 그대로 복사해 쓸 수 있어야 한다.
• 시점 복구의 보존 기간(대개 7~30일)을 넘는 장기 보존이 필요하면 주기적 덤프(export)를 따로 둔다.
• 복구는 대개 그 DB 전체를 되돌린다. 한 서비스만 되돌리고 싶어도 같은 DB를 쓰는 다른 서비스 데이터까지 함께 돌아간다 — DB를 공유하고 있다면 복구 영향 범위를 미리 적어둔다.

체크리스트

• 자동 백업(또는 시점 복구)이 켜져 있고 보존 기간을 알고 있다
• 일회용 DB에서 복구 리허설을 1회 이상 성공했다
• 복구 명령어가 runbook에 복사 가능한 형태로 적혀 있다
• 복구 시 함께 되돌아가는 데이터 범위(공유 DB 여부)를 알고 있다