서버 백업, 온프레미스와 클라우드를 고르고 복구까지

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

서버 백업은 파일을 다른 장소에 복사하는 작업으로 끝나지 않습니다. 장애가 발생했을 때 업무를 허용 시간 안에 되살릴 수 있어야 비로소 제대로 된 백업입니다. 그런데 기업이 백업 저장소를 선택할 때 가장 자주 부딪히는 질문은 명확합니다. 사내에 백업 장비를 두는 온프레미스 방식과 외부 사업자의 저장 공간을 이용하는 클라우드 방식 중 어느 쪽이 더 유리할까요?

정답은 회사 규모보다 데이터 변화량, 복구 목표, 네트워크 품질에 따라 달라집니다. 이 글에서는 두 방식을 비용과 보안, 복구 속도로 맞붙여 보고, 선택한 방식이 실제 복구로 이어지도록 설계하는 순서를 살펴봅니다.

첫 번째 승부, 비용보다 복구 목표를 먼저 세운다

온프레미스 서버 백업이 앞서는 환경

온프레미스 백업은 NAS, 백업 전용 서버, 디스크 어플라이언스 같은 장비를 사내 전산실이나 별도 사업장에 설치하는 방식입니다. 초기에는 장비 구매비와 구축비가 들지만 대용량 데이터를 반복적으로 백업해도 인터넷 전송료가 거의 발생하지 않습니다. 수십 TB의 설계 파일이나 영상 데이터를 매일 변경하는 회사라면 장기간 운영 비용에서 유리해질 수 있습니다.

가장 강력한 장점은 복구 속도입니다. 10GbE 사내 네트워크로 백업 서버와 운영 서버를 연결하면 수 TB 데이터를 인터넷 회선에 의존하지 않고 복원할 수 있습니다. 생산 설비나 ERP처럼 한 시간의 중단도 손실이 큰 시스템에서는 이 차이가 결정적입니다. 반면 장비 장애, 용량 증설, 펌웨어 업데이트와 보증 만료까지 내부 담당자가 관리해야 하며, 본사 화재나 침수처럼 운영 서버와 백업 장비가 동시에 영향을 받는 사고에는 취약합니다.

서버의 기본 역할과 구조가 익숙하지 않다면 지식백과의 서버 설명을 먼저 확인하면 운영 서버와 백업 저장소를 구분하는 데 도움이 됩니다. 같은 랙에 백업용 디스크를 추가하는 것만으로는 독립된 백업 체계를 만들었다고 보기 어렵습니다.

• 온프레미스 우세: 매일 바뀌는 데이터가 많고 수 시간 이내 전체 복구가 필요한 환경
• 예측 가능한 지출: 장비 내용연수 동안 저장량이 크게 변하지 않는 환경
• 주의할 비용: 백업 소프트웨어 라이선스, 전력, 랙 공간, 유지보수와 장비 교체비
• 필수 조건: 운영 서버와 분리된 계정, 망 구간, 전원 및 장애 도메인 확보

클라우드 백업이 역전하는 환경

클라우드 백업은 초기 장비 구매 부담이 작고 필요한 만큼 저장 공간을 늘릴 수 있습니다. 여러 지점의 데이터를 한곳에서 관리하거나 전산실이 없는 소규모 기업에 특히 편리합니다. 사무실 전체가 재해를 입어도 외부 리전에 저장된 사본을 활용할 수 있다는 점도 온프레미스보다 강합니다.

하지만 월 저장료만 보고 가격을 판단하면 안 됩니다. 실제 비용에는 API 요청, 보관 등급 변경, 데이터 반출, 조기 삭제 수수료와 백업 솔루션 비용이 포함될 수 있습니다. 예를 들어 원본 10TB라도 일별 증분과 1년 보존 정책을 적용하면 논리적 백업량은 훨씬 커집니다. 견적을 비교할 때는 현재 원본 용량이 아니라 월 변경량과 보존 기간을 넣어 계산해야 합니다.

1. 업무별 허용 중단 시간인 RTO를 1시간, 4시간, 24시간처럼 구체적으로 적습니다.
2. 유실을 감수할 수 있는 데이터 시간인 RPO를 정합니다. RPO가 15분이면 하루 한 번 백업으로는 부족합니다.
3. 원본 용량과 하루 변경률, 월 증가율, 보존 기간을 측정합니다.
4. 전체 복구에 필요한 다운로드 시간과 데이터 반출 비용을 함께 산정합니다.
5. 3년 총비용으로 장비 구매형과 사용량 과금형을 비교합니다.

현장 팁: 백업 예산을 먼저 정하고 복구 수준을 끼워 맞추면 핵심 시스템도 느린 보관 등급에 들어가기 쉽습니다. 업무 손실액을 기준으로 RTO와 RPO를 세운 뒤 저장 방식을 선택하는 편이 안전합니다.

두 번째 승부, 보안과 속도를 실제 장애로 검증한다

랜섬웨어 앞에서는 저장 위치보다 격리가 중요하다

온프레미스는 데이터가 사내에 남아 있어 통제하기 쉽다는 인상을 줍니다. 그러나 운영 도메인의 관리자 계정으로 백업 서버까지 접근할 수 있다면 랜섬웨어가 원본과 백업을 함께 암호화할 수 있습니다. 반대로 클라우드도 접근 키를 운영 서버에 평문으로 저장하거나 삭제 권한을 과도하게 부여하면 안전하지 않습니다. 결국 승부를 가르는 것은 장소보다 계정 분리, 변경 불가 보관, 다중 인증입니다.

권장 기준은 3-2-1 원칙을 확장한 방식입니다. 데이터 사본을 세 개 이상 유지하고, 서로 다른 두 종류의 매체에 저장하며, 한 사본은 외부에 둡니다. 여기에 한 사본을 변경 불가 상태로 만들고 복구 오류가 없는지 확인하면 랜섬웨어와 운영 실수를 함께 대비할 수 있습니다. 물리적으로 분리한 테이프든 객체 잠금이 설정된 클라우드 저장소든, 정해진 기간 동안 관리자도 삭제할 수 없어야 의미가 있습니다.

백업 대상은 파일만이 아닙니다. 계정, 장비 정보, 라이선스와 구성 변경 이력을 함께 관리해야 복구 후 시스템이 정상 동작합니다. 관련 개념은 IT자산관리시스템 용어 설명에서도 확인할 수 있습니다. 자산 목록과 백업 정책을 연결하면 폐기된 서버의 백업을 계속 보관하거나 신규 서버를 누락하는 일을 줄일 수 있습니다.

• 관리 계정 분리: 운영 서버 관리자와 백업 관리자의 계정을 다르게 구성합니다.
• 삭제 방지: 중요 사본에는 객체 잠금, WORM 또는 오프라인 보관을 적용합니다.
• 전송·저장 암호화: TLS 전송과 저장 데이터 암호화를 모두 사용하고 키 권한을 분리합니다.
• 접근 기록: 대량 다운로드, 정책 변경, 삭제 시도를 별도 로그로 남기고 알림을 설정합니다.
• 복구 전 검사: 감염된 시점의 데이터를 그대로 복원하지 않도록 악성코드 검사 절차를 둡니다.

복구 속도 대결은 계산보다 훈련에서 판가름 난다

백업 제품 화면에 성공 표시가 떠 있어도 복구 가능성을 보장하지는 않습니다. 파일이 손상됐거나 애플리케이션 일관성이 깨졌을 수 있고, 암호화 키나 관리자 비밀번호가 없어서 복원이 중단될 수도 있습니다. 특히 데이터베이스는 단순 파일 복사보다 트랜잭션 로그와 애플리케이션 일관성을 고려한 백업이 필요합니다.

온프레미스는 근거리 복원 속도가 빠르지만 백업 장비 자체가 고장 나면 대응이 지연될 수 있습니다. 클라우드는 저장소 내구성과 지역 분산에서 유리하지만 대규모 전체 복구 때 회선이 병목이 됩니다. 10TB를 1Gbps 회선으로 내려받는 이론적 최소 시간만 약 22시간이며, 실제로는 프로토콜 오버헤드와 다른 업무 트래픽 때문에 더 길어집니다. 평소 증분 백업이 잘되더라도 재해 시 전체 데이터를 받아야 한다면 이 시간을 RTO에 반영해야 합니다.

1. 월 1회는 무작위 파일을 골라 원본과 해시값을 비교합니다.
2. 분기 1회는 데이터베이스나 가상 서버 한 대를 격리망에 복원합니다.
3. 반기 1회는 담당자 연락부터 서비스 개통까지 재해 복구 훈련을 진행합니다.
4. 측정한 복구 시간이 목표 RTO를 넘으면 회선, 캐시 장비 또는 보관 등급을 조정합니다.
5. 훈련 결과와 실패 원인, 다음 조치 담당자를 문서로 남깁니다.

복구 훈련에서는 가장 숙련된 담당자가 아니라 당직자나 대체 인력도 문서만 보고 복원할 수 있는지 확인해야 합니다. 특정 개인의 기억에 의존하는 절차는 장애 상황에서 가장 먼저 흔들립니다.

세 번째 선택, 혼합 백업으로 복구 시간을 어디까지 줄일까

자주 쓰는 데이터는 가까이, 재해 사본은 멀리 둔다

두 방식 중 하나만 골라야 한다는 전제부터 내려놓으면 설계가 단순해집니다. 실무에서는 최근 백업을 사내 저장소에 두고 장기 보관본이나 변경 불가 사본을 클라우드로 전송하는 하이브리드 백업이 균형 잡힌 선택입니다. 일상적인 파일 삭제나 서버 오류는 내부 저장소에서 빠르게 복구하고, 랜섬웨어나 사업장 재해에는 외부 사본을 사용합니다.

모든 데이터를 같은 기준으로 다루지는 마세요. 주문·회계 데이터베이스는 짧은 RPO와 빠른 복구가 필요하지만, 종료된 프로젝트 문서는 낮은 비용의 장기 보관 등급으로 옮겨도 됩니다. 시스템별 중요도를 3개 등급으로 나누면 비용과 성능의 대결을 업무 가치에 맞게 조정할 수 있습니다. 다만 장기 보관 등급은 복원 요청 후 준비 시간이 길 수 있으므로 긴급 복구 대상에는 적합하지 않습니다.

• A등급 핵심 시스템: 15분~1시간 간격 백업, 사내 고속 복구본과 클라우드 변경 불가 사본을 함께 유지합니다.
• B등급 일반 업무: 하루 수회 증분 백업과 일 단위 외부 복제를 적용합니다.
• C등급 보관 자료: 낮은 빈도로 백업하고 저비용 장기 보관 계층을 활용합니다.
• 공통 정책: 보존 기간이 끝난 개인정보와 불필요한 사본은 승인 절차에 따라 안전하게 삭제합니다.

“클라우드에 백업하면 사내 장비는 정말 없어도 되나요?”

가장 자주 받는 질문에 대한 답은 업무가 허용하는 복구 시간에 따라 다르다입니다. 문서 중심의 소규모 조직이고 전체 데이터가 수백 GB 수준이며 하루 정도의 중단을 감수할 수 있다면 클라우드만으로도 운영할 수 있습니다. 에이전트 설치, 암호화, 버전 보존, 다중 인증과 복구 테스트가 갖춰졌다는 조건에서입니다.

반면 수 TB 이상의 파일 서버, 가상화 호스트, 생산 시스템을 몇 시간 안에 복원해야 한다면 사내 복구용 저장소를 남기는 편이 현실적입니다. 클라우드에 안전한 사본이 있어도 회선 속도보다 빠르게 데이터를 가져올 수는 없습니다. 원본이 20TB이고 실제 다운로드 속도가 평균 500Mbps라면 단순 전송에만 약 89시간이 필요합니다. 서비스 설치와 데이터 검증 시간까지 더하면 복구 목표를 크게 넘길 수 있습니다.

따라서 클라우드 전용 여부를 결정하기 전에는 한 번의 시험 복구를 실행해야 합니다. 시스템 전반의 서비스 관계까지 고려해야 한다면 범정부 IT 서비스 시스템 설명처럼 여러 구성요소가 연결된 서비스 관점도 참고할 만합니다. 서버 한 대가 켜지는 것과 사용자가 업무를 다시 시작하는 것은 서로 다른 복구 기준이기 때문입니다.

1. 업무량이 적은 시간에 대표 서버나 데이터 세트를 하나 선정합니다.
2. 새 장비 또는 격리된 가상 환경에 클라우드 백업을 내려받습니다.
3. 다운로드, 복호화, 서비스 설치, 데이터 검증 시간을 각각 기록합니다.
4. 계정 로그인, 데이터 조회, 외부 시스템 연동까지 실제 사용자 시나리오로 확인합니다.
5. 측정 시간이 RTO를 넘는다면 사내 캐시 저장소를 추가하거나 핵심 데이터만 우선 복구하도록 순서를 바꿉니다.

이 시험에서 클라우드만으로 목표 시간을 충족하면 사내 백업 장비를 줄일 근거가 생깁니다. 충족하지 못했다면 온프레미스 복구본은 중복 투자가 아니라 업무 중단 시간을 사는 장치입니다. 최종 선택은 저장 위치의 유행이 아니라, 실제로 측정된 복구 시간과 데이터 유실 허용 범위가 결정해야 합니다.