백업은 다들 돌리고 있습니다. 문제는 정작 필요할 때 열어보니 복구가 안 되는 경우예요. 며칠째 백업이 실패하고 있었거나, 파일은 있는데 DB가 빠져 있거나, 압축은 풀리는데 데이터가 깨져 있거나. 사고가 난 뒤에 알게 되면 손쓸 방법이 없습니다.
스냅샷과 백업은 다릅니다
가장 흔한 오해입니다. 스냅샷은 같은 스토리지 안에 특정 시점을 표시해두는 것이에요. 실수로 파일을 지웠거나 업데이트가 잘못됐을 때 몇 분 만에 되돌릴 수 있어 아주 유용합니다.
하지만 스토리지 자체에 장애가 나면 원본과 스냅샷이 함께 사라집니다. 같은 곳에 있으니까요. 랜섬웨어도 마찬가지예요. 서버 권한을 잡은 공격자는 스냅샷부터 지웁니다. 그래서 다른 저장소에 따로 보관하는 백업이 반드시 별도로 있어야 합니다. 스냅샷은 빠른 되돌리기용, 백업은 최후의 보루로 역할이 다릅니다.
얼마나 잃어도 되는지부터 정하세요
백업 주기를 정할 때 기준이 되는 질문 두 가지가 있습니다. 하나는 데이터를 얼마나 잃어도 감당할 수 있는가이고, 다른 하나는 복구에 몇 시간까지 쓸 수 있는가입니다.
하루 한 번 백업한다면 최악의 경우 하루치가 날아갑니다. 쇼핑몰이라면 하루치 주문이 사라지는 셈이라 감당하기 어렵죠. 이런 경우 DB만이라도 훨씬 자주 백업하거나 실시간 복제를 함께 씁니다. 반대로 자료실 성격의 사이트라면 하루 한 번으로 충분할 수 있어요. 모든 데이터에 같은 기준을 적용할 필요는 없습니다.
보관 기간도 중요합니다. 최근 것만 며칠 갖고 있으면, 문제가 생긴 지 한참 뒤에 발견했을 때 이미 정상 시점 백업이 없습니다. 일별과 주별, 월별을 섞어 보관하면 이런 상황에 대응할 수 있어요.
백업을 지울 권한까지 분리하세요
백업을 다른 저장소로 옮겼더라도 누가 지울 수 있는지는 따로 확인해야 해요. 미국 사이버보안·인프라보안청(CISA)은 랜섬웨어 대응 지침에서 중요 데이터를 오프라인으로, 암호화해서 보관하도록 권고합니다. 공격자가 접근할 수 있는 백업은 삭제하거나 암호화할 수 있기 때문이에요. 여기서 오프라인은 저장 장소가 멀다는 뜻이 아니라 감염된 시스템에서 접근할 수 없도록 연결을 끊어두는 쪽으로 이해하면 됩니다. 원격 저장소에 올려두었다는 사실만으로 이런 보호가 생기지는 않아요.
온라인 저장소를 계속 써야 한다면 일정 기간 변경과 삭제를 막는 불변 보관 기능을 검토할 수 있어요. AWS S3의 Object Lock은 파일의 특정 버전을 보호하는 기능입니다. 거버넌스 모드는 우회 권한을 가진 사용자가 잠금을 풀 수 있지만, 컴플라이언스 모드는 보관 기간 동안 루트 사용자를 포함해 누구도 보호된 버전을 덮어쓰거나 삭제할 수 없어요. 이름이 비슷해도 관리자에게 허용하는 행동이 다르니, 기능을 켰다는 표시보다 적용 모드와 실제 권한을 확인하는 게 좋습니다.
잠금에는 운영상의 제약도 있어요. S3의 컴플라이언스 모드는 이미 설정한 보관 기간을 줄일 수 없고, Object Lock으로 파일을 지켜도 암호화 키가 사라지면 읽을 수 없습니다. 그래서 도입 전에는 잘못 올린 파일도 만료일까지 남을 수 있다는 점을 고려하고, 백업 삭제 권한과 암호화 키 관리 권한을 함께 점검해보세요. 서버에서 사용하는 계정이 보관 설정을 바꾸거나 키를 삭제할 수 있는지도 확인할 항목이에요. 파일 보호와 읽을 수 있는 상태의 유지는 함께 챙겨야 합니다.
DB를 사고 직전으로 되돌리는 방법
DB 백업을 이해할 때는 전체 데이터를 담은 사본과 그 뒤에 일어난 변경 기록을 구분하면 좋아요. PostgreSQL은 데이터 파일의 변경 내용을 WAL이라는 로그에 기록합니다. 기준이 되는 물리 백업을 복원한 뒤 보관된 WAL을 순서대로 적용하면, 백업 이후의 변경을 다시 반영할 수 있어요. 로그 적용을 원하는 시점에서 멈추는 방식이 시점 복구, 즉 PITR입니다. 실수로 데이터를 지운 상황이라면 삭제가 일어나기 전을 복구 목표로 잡는 식이에요.
다만 DB 덤프 파일에 로그만 붙이면 되는 것은 아닙니다. PostgreSQL 공식 문서는 pg_dump와 pg_dumpall로 만든 논리 백업을 WAL 재생에 사용할 수 없다고 명시해요. 이 방식에는 물리 백업과, 적어도 그 백업이 시작된 시점부터 복구 목표까지 이어지는 WAL이 필요합니다. 중간 기록이 빠진 상태에서는 그 이후 시점까지 복구할 수 있다고 기대하면 안 돼요. 백업 상품이나 관리 도구를 고를 때도 덤프 보관인지, 시점 복구에 필요한 기반과 로그까지 관리하는지 구분해서 물어보세요. 로그만 오래 보관하고 기준이 되는 물리 백업을 먼저 지워버리지 않도록, 두 자료의 보관 정책도 함께 맞춰두는 게 좋습니다.
복구 범위도 확인해야 합니다. PostgreSQL의 이 방식은 DB 클러스터 전체를 되돌리는 방식이라 테이블 하나만 골라 복원하는 기능과는 달라요. 특정 테이블만 되살려야 한다면 별도 환경에 전체를 복구한 다음 필요한 데이터를 가져오는 절차를 검토해야 합니다. 또 WAL 보관이 뒤처지면 장애 때 잃을 수 있는 변경도 늘어납니다. 서비스에서 안내하는 복구 가능 시점이 실제로 어디까지인지, 목표 시점 이전의 물리 백업과 필요한 로그가 모두 남아 있는지 함께 확인해두세요.
복구 연습을 해두세요
이 글에서 딱 하나만 가져가신다면 이겁니다. 복구를 한 번도 해보지 않은 백업은 있다고 말할 수 없습니다.
실제로 해보면 예상 못한 것들이 나옵니다. 백업에 설정 파일이 빠져 있거나, DB 덤프는 있는데 사용자 권한 정보가 없거나, 복구에 생각보다 오래 걸려서 목표 시간을 못 맞추거나. 이런 건 미리 해봐야만 알 수 있어요.
분기에 한 번이라도 좋으니 테스트 서버에 복구해보시길 권합니다. 그러면서 복구 절차를 문서로 남겨두세요. 사고는 대개 담당자가 자리에 없을 때 납니다. 그때 다른 사람이 보고 따라 할 수 있는 문서가 있느냐가 복구 시간을 좌우합니다.
백업 실패를 알아채는 장치
백업 스크립트는 조용히 실패합니다. 디스크가 가득 차서, 권한이 바뀌어서, 원격 저장소 인증이 만료돼서. 로그를 매일 들여다보지 않는 이상 몇 달째 실패 중인 걸 모를 수 있어요.
그래서 성공했을 때가 아니라 실패했을 때 알림이 오도록 걸어두는 게 좋습니다. 여기에 백업 파일 크기를 함께 확인하면 더 확실해요. 평소 수 기가바이트이던 파일이 갑자기 몇 킬로바이트로 줄었다면 내용이 비었다는 뜻이니까요.
TIDC는 서버 요금제에 정기 백업 운영을 포함하고 있습니다. 어떤 주기와 보관 정책이 서비스에 맞을지 함께 잡아드리니 편하게 문의해주세요.
백업용 외장 하드, 쿠팡에서 찾아보기
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다. 가격·재고는 쿠팡에서 확인하세요.
