백업 주기를 물으면 대개 “하루에 한 번” 이라는 답이 돌아옵니다. 틀린 답은 아니지만, 그것이 왜 맞는지 설명할 수 있는 경우는 드뭅니다. 주기는 도구의 기본값에서 오는 것이 아니라 사고가 났을 때 우리가 잃어도 되는 시간에서 나와야 합니다.
이 시간을 흔히 목표 복구 시점(RPO)이라고 부릅니다. 용어는 중요하지 않고, 질문 하나로 바꿔 쓰면 됩니다 — “지금 데이터베이스가 어젯밤 상태로 돌아간다면, 우리는 무엇을 다시 만들어야 하나?”
역산하는 순서
답은 사이트마다 완전히 다릅니다. 주 1회 글을 올리는 소개 사이트라면 하룻밤을 잃어도 다시 쓸 글 하나입니다. 반면 문의와 주문이 들어오는 사이트에서 하룻밤은 다시 만들 수 없는 기록입니다 — 고객이 남긴 문의는 우리가 복원할 수 없고, 고객이 두 번 남겨 주지도 않습니다.
그래서 판단 기준은 용량이나 비용이 아니라 되만들 수 있는가입니다. 우리가 다시 쓸 수 있는 것(글 초안 · 설정 변경)과 외부에서 들어와 사라지면 끝인 것(문의 · 주문 · 회원 가입)을 나누어 보면, 주기가 거의 저절로 정해집니다.
덩어리마다 다른 주기
1회차에서 나눈 세 덩어리는 변경 속도가 달랐습니다. 주기도 따라서 갈립니다.
마지막 줄이 흔한 이유는 이해할 만합니다. 전체 압축은 설정이 간단하고 한 번에 끝나기 때문입니다. 문제는 그 편의의 대가를 사고가 난 날에 몰아서 치른다는 점입니다.
주기를 자주 가져갈 때 실제로 드는 비용
자주 뜨는 것이 늘 좋기만 한 것은 아니므로, 대가도 정확히 알아야 합니다. 데이터베이스 덤프는 실행 중에 서버 자원을 씁니다. 방문이 많은 시간대에 큰 덤프를 뜨면 사이트가 잠깐 느려질 수 있고, 그래서 새벽 시간대에 잡는 관행이 생겼습니다.
또 하나는 보관 용량입니다. 자주 뜨면 파일이 빨리 쌓이고, 쌓인 파일은 비용이자 개인정보 위험입니다 — 이 주제는 7회차의 보관 기간 설계에서 따로 다룹니다.
정리하면, 결정해야 하는 것은 “얼마나 자주” 가 아니라 “얼마를 잃어도 되는가” 하나뿐입니다. 나머지는 그 답에서 따라옵니다. 잃어도 되는 시간을 문장으로 적어 두면, 다음에 도구를 바꾸더라도 같은 기준으로 다시 설정할 수 있습니다.
운영 기준을 문서로 만드는 방법은 개발 워크플로우 아카이브에서 더 다루고, 백업 · 모니터링을 포함한 지속 관제가 필요하다면 InfraGuard 이용권을 참고하세요.
다음 회차
주기를 아무리 촘촘히 가져가도, 백업이 원본과 같은 서버에 있으면 한 번에 함께 사라집니다. 다음 회차는 백업을 어디에 두어야 하는가입니다.