기업 백업 시스템, 복구 목표를 정하고 구축·검증하는 순서

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

랜섬웨어나 스토리지 장애가 발생했을 때 백업 파일이 있다는 사실만으로는 업무를 되살릴 수 없습니다. 어느 시점의 데이터를, 몇 시간 안에, 어떤 순서로 복구할지 정해 두지 않았다면 실제 장애 현장에서는 서버보다 의사결정이 먼저 멈춥니다.

VL시스템은 기업 백업 시스템을 설계할 때 무엇부터 확인하는지 재해복구 컨설턴트에게 물었습니다. 이번 인터뷰에서는 업무 영향도 파악부터 백업 구축, 복구 검증까지 현장에서 적용할 수 있는 흐름을 Q&A 형식으로 짚습니다.

첫 순서, 백업 장비보다 복구 목표를 먼저 묻습니다

Q. 백업 시스템 상담에서 가장 먼저 확인하는 것은 무엇입니까?

A. 서버 용량이나 백업 제품명이 아니라 ‘이 업무가 몇 시간 멈추면 손실이 커지는가’를 먼저 확인합니다. 기업이 운영하는 서버는 파일 공유, 그룹웨어, ERP, 데이터베이스처럼 역할이 다르며, 각 서비스에 허용되는 중단 시간도 서로 다르기 때문입니다. 서버의 기본 개념과 역할은 네이버 지식백과의 서버 설명에서도 확인할 수 있습니다.

이때 사용하는 기준이 RPO와 RTO입니다. RPO는 장애 발생 시 어느 시점까지의 데이터 손실을 허용할지, RTO는 서비스를 얼마 만에 정상화할지를 뜻합니다. 예를 들어 주문 데이터베이스의 RPO가 15분이라면 하루 한 번 백업으로는 요구를 충족할 수 없습니다. 반면 오래된 계약서를 보관하는 서버까지 15분 단위로 보호하면 비용과 운영 복잡도만 커질 수 있습니다.

• 업무 중요도: 매출, 고객 응대, 생산, 결산에 미치는 영향을 구분합니다.
• 허용 데이터 손실: 15분, 1시간, 1일 등 서비스별 RPO를 정합니다.
• 허용 중단 시간: 복구 완료까지 기다릴 수 있는 시간을 RTO로 명시합니다.
• 복구 순서: 인증·DNS·데이터베이스·업무 애플리케이션의 의존 관계를 기록합니다.

Q. 모든 서버에 같은 백업 정책을 적용하면 관리가 쉬워지지 않나요?

A. 설정은 단순해 보이지만 비용과 복구 성능을 함께 놓칠 가능성이 큽니다. 가상화 호스트 전체 이미지, 데이터베이스 트랜잭션 로그, 사용자 파일은 변경 패턴과 복원 방식이 다릅니다. 특히 백업 대상이 다른 시스템과 연결되어 있다면 단일 서버만 복원해도 서비스가 열리지 않을 수 있으므로 업무 흐름을 기준으로 보호 단위를 묶어야 합니다.

“백업 정책의 출발점은 데이터 용량이 아니라 업무가 견딜 수 있는 손실입니다. 용량은 장비를 정하지만 RPO와 RTO는 구조를 정합니다.”

1. 전체 IT 시스템과 데이터 소유 부서를 식별합니다.
2. 서비스 중단에 따른 영향을 상·중·하로 분류합니다.
3. 서비스별 RPO와 RTO를 현업 책임자와 합의합니다.
4. 인증 서버와 데이터베이스 등 선행 복구 대상을 표시합니다.

둘째 순서, 3-2-1 원칙을 기업 환경에 맞게 구현합니다

Q. 백업 사본은 몇 개를 어디에 보관해야 안전합니까?

A. 기본 출발점은 원본을 포함해 데이터 사본 3개, 서로 다른 저장 매체 2종, 외부 장소 사본 1개를 두는 3-2-1 백업 원칙입니다. 다만 백업 서버와 저장소가 운영 네트워크에서 같은 관리자 계정과 같은 권한을 사용한다면, 랜섬웨어가 세 사본에 모두 접근할 수 있습니다. 사본 개수뿐 아니라 계정, 네트워크, 관리 경로를 분리해야 합니다.

최근에는 외부 사본을 클라우드 오브젝트 스토리지나 원격 센터에 저장하고, 일정 기간 삭제와 변경을 막는 불변 저장소를 함께 사용합니다. 대규모 조직이 별도 재해복구 거점을 구성하는 이유도 물리적 사고의 영향 범위를 나누기 위해서입니다. 실제 인프라 이전과 통합의 관점은 데이터센터 및 재해복구센터 구축 사례처럼 업무 연속성을 중심으로 살펴볼 수 있습니다.

• 백업 관리 계정에 다중 인증을 적용합니다.
• 운영 서버의 도메인 관리자 계정과 백업 관리자 계정을 분리합니다.
• 백업 저장소 접근 포트를 필요한 서버에만 허용합니다.
• 보존 기간과 법정 보관 의무, 개인정보 파기 기준을 함께 검토합니다.
• 원격 전송량이 업무 회선을 압박하지 않도록 시간대와 대역폭을 조절합니다.

Q. 구축 비용은 무엇에 따라 크게 달라집니까?

A. 견적은 단순 원본 용량보다 일일 변경량, 보존 기간, 중복 제거율, 복구 속도, 원격 사본 방식에 좌우됩니다. 원본이 10TB라도 변경량이 작으면 증분 백업 공간을 절약할 수 있지만, 영상이나 압축 파일처럼 중복 제거 효과가 낮은 데이터는 예상보다 저장 공간을 많이 사용합니다. 라이선스 역시 서버 수, CPU 소켓, 가상머신 수, 보호 용량 중 어떤 기준으로 과금되는지 확인해야 합니다.

저가형 NAS만으로 시작하면 초기 비용은 낮지만 동시 복구 성능, 불변 기능, 제조사 지원에서 한계가 생길 수 있습니다. 반대로 모든 데이터를 고성능 장비에 장기 보관하는 구성은 과투자입니다. 최근 복구용 데이터는 빠른 디스크, 장기 보관본은 비용 효율적인 원격 저장소에 두는 계층화가 현실적입니다.

1. 최소 30일간 일일 변경량과 데이터 증가율을 측정합니다.
2. 일반 파일, 데이터베이스, 가상머신별 보존 주기를 나눕니다.
3. 장비·라이선스 외에 회선, 원격 보관, 유지보수 비용을 포함합니다.
4. 전체 복구와 개별 파일 복구에 필요한 성능을 각각 시험합니다.

셋째 순서, 복구 시험 결과로 투자 우선순위를 다시 세웁니다

Q. 백업 작업이 성공으로 표시되면 검증이 끝난 것 아닌가요?

A. 아닙니다. ‘백업 성공’은 데이터 기록 작업이 오류 없이 끝났다는 뜻일 뿐, 업무 서비스가 정상적으로 열리는지는 보장하지 않습니다. 손상된 원본이 그대로 복제됐거나 암호화 키와 인증 정보가 빠졌을 수도 있습니다. 그래서 기업 백업 시스템은 복구 성공 여부와 실제 소요 시간을 별도 지표로 관리해야 합니다.

복구 시험은 운영 서버를 덮어쓰지 않는 격리 네트워크에서 진행하는 것이 안전합니다. 파일 한 개 복원, 가상머신 부팅, 데이터베이스 시점 복구, 여러 서버가 연결된 업무 서비스 복구를 차례로 시험합니다. 담당자가 바뀌어도 수행할 수 있도록 화면 경로, 명령어, 계정 보관 위치, 의사결정권자 연락처를 복구 절차서에 남겨야 합니다.

• 매월: 중요 파일과 데이터베이스 샘플을 복원해 무결성을 확인합니다.
• 분기: 핵심 가상머신을 격리 환경에서 부팅하고 로그인까지 점검합니다.
• 반기: 부서 담당자가 참여해 실제 업무 기능과 데이터 시점을 검증합니다.
• 변경 직후: 서버 이전, 애플리케이션 업데이트, 계정 체계 변경 후 복구 문서를 갱신합니다.

Q. 예산이 제한적이라면 무엇부터 개선해야 합니까?

A. 첫 번째 우선순위는 매출·생산·고객 서비스와 직접 연결된 시스템의 RPO와 RTO를 확정하는 일입니다. 두 번째는 백업 계정과 저장소를 운영 환경에서 분리하고, 삭제할 수 없는 사본을 확보하는 것입니다. 세 번째가 반복 가능한 복구 시험이며, 그 결과가 목표 시간을 넘을 때 네트워크 회선이나 저장장치 성능에 투자해야 합니다.

네 번째로 문서와 책임 체계를 다듬습니다. 기업의 IT 서비스는 서버 한 대가 아니라 사람, 프로세스, 네트워크, 애플리케이션이 연결된 구조이므로 IT 서비스 시스템 관련 개념처럼 전체 서비스 관점에서 접근할 필요가 있습니다. 마지막으로 장기 보관 데이터의 저장 등급을 조정하면 핵심 복구 성능을 훼손하지 않고 비용을 낮출 수 있습니다.

“예산이 부족할수록 장비 목록부터 줄이지 말고, 반드시 살아나야 할 업무의 순서를 먼저 좁혀야 합니다. 중요 시스템 정의, 권한 분리, 불변 사본, 복구 시험, 성능 증설의 순서로 판단하면 투자의 효과가 선명해집니다.”

1. 업무 중요도와 복구 목표 확정 — 보호 범위와 허용 손실을 먼저 결정합니다.
2. 백업 권한 및 네트워크 분리 — 운영 환경 침해가 사본으로 번지는 경로를 차단합니다.
3. 원격·불변 사본 확보 — 랜섬웨어와 물리적 재해에 대응합니다.
4. 정기 복구 시험 — 성공 여부와 소요 시간을 수치로 남깁니다.
5. 병목 구간 투자 — 측정 결과에 따라 저장장치, 회선, 자동화 순으로 보강합니다.