홈페이지는 잘 돌아갈 때는 있는 줄도 모르다가, 어느 날 접속이 안 되는 순간 비로소 그 무게가 보입니다. 서버 하드가 고장 나고, 업데이트 한 번이 꼬이고, 해킹 한 방에 데이터가 암호화되는 일은 대기업이 아니라 오히려 관리가 느슨한 작은 회사에서 더 자주 일어납니다. 문제는 사고 자체가 아니라, 사고가 났을 때 돌아갈 어제가 없다는 것입니다. 백업이 없으면 복구도 없습니다.
1. 백업은 '언젠가'가 아니라 '자동으로' 돌아야 한다
사람이 기억해서 손으로 받는 백업은 결국 안 받게 됩니다. 바쁘면 미루고, 미루면 잊습니다. 서버나 호스팅의 예약 백업 기능을 켜서 매일 정해진 시각에 저절로 돌게 만들어야 합니다. 사람의 의지가 아니라 스케줄러가 백업을 책임지게 하는 것, 그것이 첫 단추입니다.
2. 3-2-1 규칙 — 사본 3개, 저장매체 2종, 원격 1곳
백업 데이터는 최소 3벌을 두되, 서로 다른 2종의 저장매체에 나눠 담고, 그중 1벌은 물리적으로 떨어진 원격지에 둡니다. 같은 서버 안에만 백업을 두면 그 서버가 죽는 순간 백업도 함께 사라집니다. 클라우드 스토리지 한 곳을 원격 사본으로 잡아 두는 것만으로도 최악은 피합니다.
3. 파일만 받지 말고 데이터베이스도 함께 받아라
홈페이지는 눈에 보이는 파일(이미지·문서)과 눈에 안 보이는 데이터베이스(문의 내역·회원·게시글)로 이뤄집니다. 파일만 백업하고 DB를 빠뜨리면, 복구해도 껍데기만 돌아오고 손님이 남긴 문의와 주문 기록은 영영 사라집니다. 두 가지를 한 세트로 묶어 같은 주기로 받아야 완전한 백업입니다.
4. 복구를 안 해 본 백업은 백업이 아니다
가장 흔한 사고는, 몇 년치 백업 파일이 알고 보니 전부 깨져 있었다는 뒤늦은 발견입니다. 백업은 받는 순간이 아니라 되살리는 순간에 진짜 값을 합니다. 분기에 한 번쯤은 백업본으로 실제 복구가 되는지 시험해 보고, 걸리는 시간과 절차를 기록해 두세요. 검증하지 않은 백업은 안심이 아니라 착각입니다.
5. 백업 보관에도 개인정보 책임이 따라온다
백업 파일 안에는 손님의 이름·연락처·주문 정보가 그대로 들어 있습니다. 아무 데나 방치된 백업은 그 자체가 유출 사고의 뇌관입니다. 백업본은 접근 권한을 건 안전한 저장소에 두고, 보관 기간이 지난 오래된 백업은 규칙에 따라 정리해야 합니다. 지키는 데이터일수록 지키는 방식도 안전해야 합니다.
백업과 복구는 평소엔 티도 안 나다가, 사고 한 번에 회사의 몇 년을 통째로 살리거나 잃게 만드는 영역입니다. CYAN은 작은 회사의 홈페이지를 만들 때 자동 백업 스케줄과 원격 사본, 그리고 복구 절차까지 처음부터 함께 설계합니다. 지금 우리 홈페이지에 '어제로 돌아갈 방법'이 있는지 한 번 점검해 보시길 권합니다.
