대표님, 큰일났습니다!
자료실이 통째로 사라졌어요!
월요일 아침, 출근하자마자 이런 보고를 받으면 기분이 어떨까요. 몇 년간 쌓아온 제품 매뉴얼, 고객 문의 답변, 기술 자료가 순식간에 증발해버린 겁니다.
파일 몇 개 날아간 수준이 아닙니다. 회사의 지식 자산 자체가 사라진 거죠.
실제로 있었던 일입니다.
한 제조업체였는데요. 홈페이지 자료실에 제품 매뉴얼, 기술 문서, 고객 지원 자료를 올려뒀습니다. 10년 동안 쌓인 게 약 3,000개 파일이었습니다.
고객들은 제품 구매 후 자료실에서 매뉴얼을 받았고, 기술팀도 고객 응대할 때 자료실을 참고했습니다. 별 문제 없이 잘 굴러가고 있었죠.
근데 어느 월요일, 자료실이 텅 비어있었습니다. 폴더는 있는데 파일이 하나도 없는 상태.
고객들한테 "자료 어디 갔나요?" 문의가 쏟아지는데, 기술팀은 매뉴얼이 없으니 응대 자체가 불가능했습니다.
무슨 일이 있었냐면요.
주말 사이에 서버 용량이 부족해졌습니다. 그래서 호스팅 업체가 "오래된 파일 자동 삭제" 정책을 실행한 겁니다. 6개월 이상 다운로드 기록 없는 파일은 자동 삭제.
근데 생각해보면, 매뉴얼은 한 번 받으면 끝입니다. 여러 번 받을 이유가 없으니 다운로드 기록이 없는 게 당연한 건데...
3,000개 중 2,800개가 날아갔습니다.
백업은 있었을까요?
없었습니다.
"호스팅 업체가 알아서 해주겠지" 생각하고 있었는데, 알고 보니 호스팅 백업 정책이 하루 단위였습니다. 주말에 삭제됐으니 월요일엔 이미 백업에서도 사라진 뒤였죠.
복구 시도는 했습니다. 직원 PC에 캐시로 남은 파일 뒤지고, 고객들한테 "혹시 다운받으신 파일 있으면 보내달라"고 요청도 했습니다.
그렇게 해서 건진 게 40%. 나머지 60%는 그냥 사라졌습니다.
문제는 그 60%에 뭐가 포함돼 있었냐는 겁니다.
단종된 구형 제품 매뉴얼이었습니다.
다시 만들 수도 없습니다. 제품은 이미 생산 중단됐고, 설계 자료도 남아있지 않았거든요. 이제 고객이 "구형 매뉴얼 주세요" 하면 "죄송합니다, 없습니다"라고 할 수밖에 없게 된 겁니다.
복구 가능한 자료를 다시 만드는 데 직원 3명이 2개월간 매달렸습니다. 인건비만 수백만 원. 고객 불만으로 인한 손실은 계산조차 어려웠습니다.
대표는 "백업만 있었어도..." 하고 후회했지만, 이미 늦은 뒤였습니다.
비슷한 사례 하나 더 말씀드리겠습니다.
한 쇼핑몰에서 개발자가 실수로 자료실 폴더를 날렸습니다. rm -rf /uploads/board/ 명령을 실행하려다 경로를 잘못 입력해서 /uploads/ 전체를 삭제한 겁니다.
상품 이미지, 상세 페이지, 리뷰 사진. 전부 사라졌습니다.
다행히 전날 백업이 있어서 90%는 복구했는데, 최근 하루치 신상품 이미지는 살리지 못했습니다. 긴급하게 다시 촬영해서 올렸지만 신상품 출시가 하루 밀렸고, 프로모션 일정이 꼬이면서 매출 기회를 놓쳤습니다.
결국 하고 싶은 말은 이겁니다.
백업 없으면 위험합니다.
"언젠가 해야지"가 아니라 지금 해야 합니다. 사람 실수, 시스템 오류, 호스팅 정책, 해킹... 이런 상황에서 데이터를 지키는 방법은 백업밖에 없습니다.
백업할 때 중요한 점 몇 가지만 말씀드리면,
일단 수동으로 하면 까먹습니다. 반드시 자동으로 매일 돌아가게 설정해야 합니다.
그리고 서버 안에만 백업해두면 안 됩니다. 서버가 통째로 날아가면 백업도 같이 날아가거든요. 클라우드든 외장하드든 별도로 빼둬야 합니다.
또 하나, 백업 파일이 있다고 끝이 아닙니다. 실제로 복구가 되는지 테스트를 해봐야 합니다. 막상 복구하려는데 파일이 깨져있으면 소용없으니까요.
그리고 최신 백업만 남기지 말고, 어제 것, 지난주 것, 지난달 것까지 보관해두는 게 좋습니다. 오늘 백업에 문제가 있어도 어제 것으로 복구할 수 있으니까요.
보통 유지보수 계약에는 백업 관리가 기본으로 포함돼 있습니다. 자동 백업 설정, 정기 확인, 복구 테스트까지. 대표님이 직접 신경 쓰실 필요 없도록요.
백업은 보험입니다. 평소엔 쓸 일 없지만, 사고 나면 생명줄입니다.
지금 백업 상태가 어떤지 한번 확인해보시길 권합니다. 마지막 백업이 언제인지, 복구 테스트는 해봤는지. 확인이 안 된다면... 솔직히 위험한 상태입니다.
'PHP 유지보수' 카테고리의 다른 글
| 사내 시스템이 멈출 때 생기는 진짜 비용 (0) | 2026.06.30 |
|---|---|
| "처음부터 다 새로 만들자"가 꼭 정답은 아니다 (0) | 2026.06.23 |
| 왜 개발자들은 ‘작은 수정’이라도 큰일 날 수 있다’고 말할까? (0) | 2026.06.09 |
| 코드보다 중요한 건 ‘데이터 안전’ (0) | 2026.06.02 |
| 언제는 새로 만들고, 언제는 유지보수하는 게 맞나? (0) | 2026.05.26 |