안정적인 사이트 운영을 위한 백업과 장애 대응 준비

서버 관리 서비스를 이용할 때는 서버 운영, 사이트 기능 유지보수, 백업과 복구를 누가 맡는지 정해 두면 도움이 됩니다. 각 업무의 담당 범위를 알면 주문 오류나 접속 문제를 발견했을 때 필요한 지원을 요청하기 쉽습니다. 백업 자료를 보관하는 범위와 실제 복원 작업의 지원 범위도 함께 살펴봅니다.

계약할 때 문제가 생기면 누가 조치하는지, 자료를 잃으면 어느 시점까지 복구할 수 있는지를 알아두면 운영 중에 요청할 곳을 찾기 쉽습니다. 디딤 클라우드·호스팅을 검토할 때도 서버 구성과 백업·매니지드 지원 범위를 나누어 살펴볼 필요가 있습니다. 구체적으로 어떤 관리 업무를 맡길지는 사용할 환경에 맞춰 협의해야 합니다.

상황별로 지원받을 담당자와 연락 방법을 정합니다

사이트가 아예 열리지 않는 경우와 화면은 열리는데 문의가 저장되지 않는 경우는 확인할 대상이 다릅니다. 결제 오류라면 PG와 사이트의 연결을 함께 살펴야 할 수도 있습니다. 호스팅과 사이트 유지보수가 별도 계약이라면 담당자도 나뉠 수 있습니다.

그래서 견적의 ‘장애 대응 포함’이라는 문구만으로는 어디까지 맡길 수 있는지 알기 어렵습니다. ‘접속이 안 될 때는 어디로 연락하나요?’, ‘문의가 저장되지 않을 때도 먼저 확인해 주나요?’처럼 실제 상황을 제시하면 담당 범위가 드러납니다. 다른 업체가 고쳐야 하는 문제라면, 처음 접수한 곳에서 어떤 확인 결과를 넘겨줄 수 있는지도 알아두면 연락을 반복하는 일을 줄일 수 있습니다.

어디에 연락할지 알았다면 언제 도움을 받을 수 있는지도 이어서 살펴봅니다. 모니터링으로 이상 징후를 감지했다고 해서 담당자가 곧바로 복구 작업에 착수하는 것은 아닐 수 있습니다. 디딤의 기본 매니지드 안내에는 영업시간 기술지원이 명시돼 있습니다. 주말 행사나 야간 주문이 중요한 사이트라면 해당 시간에 신고를 받는지, 실제 조치는 언제 시작하는지까지 답을 받아 두는 편이 좋습니다.

주문이 쌓이는 속도에 맞춰 백업 주기를 정합니다

백업에는 해당 백업을 만든 시점까지의 자료가 담깁니다. 새벽에 백업한 뒤 오후에 자료를 잃은 쇼핑몰을 가정해 보겠습니다. 새벽 이후에 받은 주문은 그 백업에 없으므로, 복원해도 오후의 주문 목록과 같지 않을 수 있습니다. 이후 주문까지 되살리려면 다른 복구 수단이나 원천 기록이 필요할 수 있습니다.

변경이 드문 회사 소개 사이트라면 변경 직전 자료로 돌아가는 것으로 충분할 수 있지만, 주문과 문의가 계속 들어오는 사이트에서는 백업 이후 들어온 자료를 다른 기록과 대조해 다시 입력해야 할 수 있습니다. 하루 한 번이라는 주기가 적절한지는 이런 업무 차이로 판단해야 합니다.

표의 ‘백업 대상’은 사이트에 맞춰 구체적으로 물어볼 항목입니다. 게시글과 첨부파일을 함께 쓰는 사이트라면 복원한 글과 파일이 서로 맞는지도 확인해야 합니다. 글의 내용을 담은 데이터베이스(DB)만 복원되고 파일이 빠지면 글은 보여도 첨부를 열 수 없기 때문입니다.

복구 후 주문 처리까지 이어지도록 점검합니다

백업 파일이 있다는 것과 사이트를 다시 사용할 수 있다는 것은 다릅니다. 복구 점검을 제공받는다면 운영과 분리된 환경에서 어느 시점의 자료를 복원했고, 로그인이 되는지, 주요 자료와 첨부파일이 복원됐는지, 핵심 업무를 다시 처리할 수 있는지 결과를 받으면 됩니다.

앞의 쇼핑몰에서 새벽 백업을 복원했다면 사이트가 열려도 새벽 이후 접수된 주문을 다른 기록과 대조하는 일은 남습니다. 업체가 복원하는 데까지 맡는지, 운영자가 다른 기록과 대조해야 하는지를 구분해야 복구 후 할 일을 알 수 있습니다. 이런 과정을 시험해 보려면 사용할 환경과 작업 비용이 지원 범위에 포함되는지도 함께 협의합니다.

견적을 받을 때도 이 쇼핑몰처럼 복구가 필요한 상황 하나를 제시해 볼 수 있습니다. 어느 시점의 자료를 되살리는지, 업체가 끝내 주는 작업은 무엇인지, 그 뒤 운영자가 대조할 기록은 무엇인지 답을 받아 두는 것입니다. 두 견적의 월 요금을 비교할 때도 같은 범위의 관리 업무가 포함돼 있는지 먼저 봐야 합니다.