모두
모두콘텐츠
몇 년 전 월 1만 원대 서버를 운영하던 고객이 백업 요금으로 서버비보다 많은 돈을 내고 있었습니다. 확인해 보니 매일 전체 파일을 새로 저장하고 있었고, 복구에 필요 없는 캐시와 임시 파일까지 포함돼 있었습니다. 백업은 용량을 먼저 재고, 얼마나 오래 보관할지 정하면 비용을 꽤 정확히 계산할 수 있습니다.
서버 용량보다 실제 백업 대상을 먼저 센다
서버 디스크가 200GB라고 해서 매일 200GB를 백업할 필요는 없습니다. 운영체제와 다시 설치할 수 있는 프로그램을 빼고, 복구해야 할 데이터가 무엇인지 나눠 봐야 합니다. 일반적인 웹사이트라면 업로드 파일, 데이터베이스, 설정 파일, 인증서와 키가 우선입니다. 캐시, 로그, 임시 압축 파일은 보관 목적에 따라 제외하거나 별도 기간을 적용할 수 있습니다.
예를 들어 사용 중인 디스크가 120GB여도 실제 복구 대상이 파일 60GB와 데이터베이스 20GB라면 기준 용량은 80GB입니다. 다음으로 하루에 바뀌는 양을 측정합니다. 방문자가 많아도 읽기 요청 위주라면 변경량은 작을 수 있고, 방문자가 적어도 매일 영상을 올리는 사이트라면 변경량이 큽니다. 트래픽 수치만으로 백업 용량을 추정하면 어긋나는 이유입니다.
측정할 때는 일주일 정도 파일 증가량과 데이터베이스 크기 변화를 기록하는 편이 좋습니다. 하루 평균뿐 아니라 업로드가 몰리는 날도 확인해야 합니다. 백업 프로그램이 압축이나 중복 제거를 지원하면 실제 저장량은 줄 수 있지만, 처음 예산을 잡을 때부터 그 효과를 크게 반영하지는 않습니다.
보관 기간과 복사본 수로 저장비를 계산한다
기본 계산식은 ‘최초 전체 백업 용량 + 하루 변경량 × 추가 보관 일수’입니다. 복사본을 두 곳에 두면 그 결과에 2를 곱합니다. 80GB를 처음 저장하고 하루 2GB가 바뀌며 30일치를 보관한다면, 단순 계산으로 한 곳에 80 + 2 × 29 = 138GB가 필요합니다. 두 곳이면 276GB입니다.
저장 단가를 예시로 1GB당 월 30원이라고 가정하면 월 저장비는 8,280원입니다. 이 숫자는 특정 업체의 요금이 아닙니다. 실제 청구액에는 저장 방식, 요청 횟수, 최소 보관 기간, 세금이 영향을 줍니다. 특히 증분 백업은 이전 백업에 의존하므로 오래된 복사본을 지울 때도 복구에 필요한 데이터가 남도록 백업 도구가 관리해야 합니다.
보관 기간은 길수록 안전하다고 단정하기 어렵습니다. 실수로 파일을 지운 사실을 보통 며칠 안에 알아차리는 사이트라면 일별 30개와 월별 몇 개를 조합할 수 있습니다. 반대로 조용히 데이터가 훼손되는 사고가 걱정된다면 더 오래된 복구 지점이 필요합니다. 어느 시점까지 되돌릴 수 있어야 하는지부터 정해야 저장 공간도 낭비하지 않습니다.
복구할 때 드는 돈과 시간을 따로 잡는다
저장비만 보고 백업 서비스를 고르면 복구 당일 예상 밖의 비용이 나옵니다. 다른 서버로 데이터를 꺼낼 때 전송 요금이 붙을 수 있고, 빠른 복구를 위해 임시 서버를 띄우면 그 사용료도 듭니다. 앞의 80GB 사례에서 외부 전송 단가를 가정상 1GB당 100원으로 두면 한 번 꺼내는 데 8,000원입니다. 분기마다 한 번 복구 시험을 한다면 월평균 약 2,700원을 예산에 더할 수 있습니다.
사람이 쓰는 시간도 비용입니다. 매달 백업 상태 확인과 복구 시험에 30분을 쓰고 작업 시간을 시간당 3만 원으로 계산하면 월 1만 5천 원입니다. 앞선 저장비와 시험 전송비까지 합치면 월평균 약 2만 6천 원입니다. 실제 지출과 내부 작업 시간을 구분해 적어 두면 요금제 비교가 쉬워집니다.
복구 목표도 비용을 바꿉니다. 하루치 데이터 손실을 감수할 수 있으면 일별 백업으로 충분할 수 있습니다. 주문이나 예약이 쌓이는 서비스에서 한 시간 이상 잃기 어렵다면 백업 주기를 짧게 하거나 데이터베이스의 변경 기록을 별도로 보관해야 합니다. 빨리 복구해야 한다면 전송 속도와 임시 서버 준비 시간까지 계산해야 하고요.
싼 요금제를 쓸 때 확인할 세 가지
첫째, 호스팅 업체가 제공하는 백업이 같은 계정이나 같은 장애 범위에만 있는지 확인합니다. 서버 장애와 계정 삭제가 함께 영향을 주면 복사본도 같이 사라질 수 있습니다. 적어도 한 벌은 운영 서버와 분리된 저장 위치에 두는 편이 안전합니다.
둘째, 데이터베이스와 파일의 시점이 맞는지 봅니다. 파일을 복사하는 동안 데이터베이스가 계속 바뀌면 백업 파일은 있어도 게시물의 첨부 파일이 빠질 수 있습니다. 데이터베이스 덤프나 일관된 스냅샷을 쓰고, 백업이 끝났다는 알림만 믿지 말고 시험 복구로 확인해야 합니다.
셋째, 삭제 권한을 분리합니다. 운영 서버가 침해됐을 때 같은 자격 증명으로 백업까지 지울 수 있으면 복사본이 두 개여도 의미가 약합니다. 백업 전용 계정, 삭제 제한, 별도 보관 기간을 확인할 만합니다. 이런 기능이 없다면 저렴한 저장 공간을 추가하는 것보다 접근 권한부터 고치는 편이 낫습니다.
작은 사이트라면 처음부터 비싼 백업 상품을 살 이유는 많지 않습니다. 복구 대상이 20GB이고 하루 변경량이 0.5GB라면 30일치 한 벌은 약 35GB입니다. 다만 월 몇 천 원을 아끼려다 복구가 안 되는 상태로 두면 계산 자체가 무의미해집니다. 저는 백업 요금을 비교할 때 저장 용량보다 먼저 복구해 본 날짜를 확인합니다.
