보안 이야기에서 백업이 뒤늦게 나오는 것은 이상해 보일 수 있습니다. 그런데 백업은 사고를 막는 장치가 아니라 사고를 사고로 끝내는 장치입니다. 앞의 회차들이 문을 닫는 이야기였다면, 이 회차는 문이 뚫렸을 때 무엇을 잃을 것인가에 대한 이야기입니다.
백업이 있는데도 잃는 세 가지 경우
실제 상담에서 반복되는 상황이 있습니다. “백업 있어요” 라고 답한 뒤 열어 보면 쓸 수 없는 경우입니다.
첫 줄이 특히 흔합니다. 워드프레스는 파일과 데이터베이스 두 부분으로 되어 있고 둘은 한 쌍입니다. 이미지와 테마는 파일에, 글과 설정과 문의 내역은 데이터베이스에 있습니다. 한쪽만 있으면 복구는 절반도 되지 않습니다.
세 번째 줄도 중요합니다. 서버 자체에 문제가 생기거나 계정이 잠기는 상황이라면, 그 서버 안에 있는 백업도 함께 닿을 수 없게 됩니다. 백업은 최소한 한 벌은 사이트 밖에 있어야 합니다.
창업가 예산에 맞춘 백업 구성
업계의 원칙은 “사본 3벌, 매체 2종, 그중 1벌은 다른 장소” 로 요약됩니다. 작은 사이트라면 이것을 이렇게 옮기면 충분합니다.
보관 기간이 의외로 중요합니다. 백업을 7일치만 두면, 침해를 열흘 뒤에 발견했을 때 돌아갈 깨끗한 시점이 남아 있지 않습니다. 조용히 진행되는 문제일수록 발견이 늦으므로, 여유가 되면 한 달치 이상을 두는 편이 좋습니다.
복구 연습 — 한 시간이면 됩니다
이 회차의 제목이 여기서 나옵니다. 백업 파일이 있다는 사실과 그것으로 사이트를 되살릴 수 있다는 사실은 다른 이야기이고, 확인하는 방법은 실제로 해 보는 것뿐입니다.
연습은 운영 중인 사이트에 하지 않습니다. 호스팅이 제공하는 스테이징(테스트) 환경이나 로컬 개발 환경에 백업을 복원해 봅니다. 이 한 번의 연습이 알려 주는 것이 많습니다 — 복구에 걸리는 실제 시간, 필요한 접속 정보가 어디 있는지, 그리고 무엇보다 그 백업 파일이 정말 온전한지.
연습 뒤에는 소요 시간과 절차를 짧게 적어 두세요. 실제 사고 때는 침착하기 어렵고, 그때 필요한 것은 지식이 아니라 따라 할 수 있는 목록입니다.
백업이 대신해 주지 않는 것
마지막으로 솔직하게 적어야 할 것이 있습니다. 백업은 되돌리기이지 고치기가 아닙니다. 침해의 원인이 그대로 남아 있으면 복구한 사이트도 같은 경로로 다시 뚫립니다. 그래서 복구 다음에는 반드시 원인을 찾는 단계가 붙어야 하고, 그 절차는 이 연재의 마지막 회차에서 다룹니다.
백업과 복구를 포함한 운영 절차는 개발 워크플로우 아카이브에 더 있고, 백업 구성과 복구 가능성 점검을 포함한 정비는 최적화 지원 사업에서 함께 다룹니다.
다음 회차
다음 회차는 눈에 보이는 신뢰 문제입니다. SSL 을 분명히 켰는데 주소창에 자물쇠가 뜨지 않는 경우 — 원인은 대체로 한 줄짜리이고, 찾는 방법이 정해져 있습니다.