백업 시스템, 복구를 망치는 일곱 가지 구축 실수

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

백업 작업이 매일 성공으로 표시됐는데 장애 당일에는 파일 하나도 제대로 복원하지 못하는 일이 있습니다. 백업 장비와 소프트웨어를 갖추는 데는 비용을 썼지만, 무엇을 언제까지 복구해야 하는지 정하지 않은 채 저장만 반복했기 때문입니다.

기업의 백업 시스템은 데이터를 복사하는 기능이 아니라 업무를 다시 시작하게 만드는 IT 인프라입니다. 서버와 스토리지의 장애뿐 아니라 랜섬웨어, 운영자 실수, 계정 탈취, 건물 정전까지 고려해야 하며, 특히 다음 일곱 가지 실수는 구축 단계에서 반드시 피해야 합니다.

실수 1. 백업 성공 표시만 믿고 복구 결과를 확인하지 않습니다

성공한 작업과 복원 가능한 데이터는 다릅니다

관리 화면의 초록색 성공 표시는 백업 프로그램이 정해진 작업을 끝냈다는 뜻일 뿐입니다. 원본 데이터가 이미 손상됐거나 애플리케이션이 쓰기 작업을 하는 중에 복사됐다면 파일은 남아 있어도 데이터베이스와 업무 시스템이 정상적으로 열리지 않을 수 있습니다. 백업 대상에서 신규 볼륨이나 특정 폴더가 빠졌는데도 작업 자체는 성공으로 끝나는 사례도 흔합니다.

한 제조사는 ERP 데이터베이스 백업이 8개월 동안 정상 처리됐다고 판단했습니다. 그러나 실제 복원에서는 데이터 파일과 로그 파일의 시점이 맞지 않아 서비스 기동에 실패했고, 결국 전날 엑셀 자료를 모아 수작업으로 주문을 재입력해야 했습니다. 복구 테스트가 없는 백업은 검증되지 않은 기대에 가깝습니다.

테스트는 파일 다운로드 수준에서 끝내지 말고 서비스가 실제로 열리는 단계까지 진행해야 합니다. 서버의 기본 개념과 역할은 네이버 지식백과의 서버 설명도 함께 참고할 수 있으며, 복구 시에는 서버뿐 아니라 데이터베이스와 네트워크의 의존 관계까지 확인해야 합니다.

• 매일: 백업 실패, 소요 시간 급증, 저장 용량 이상을 자동 점검합니다.
• 매월: 무작위 파일과 폴더를 별도 위치에 복원해 해시값과 내용을 대조합니다.
• 분기: 핵심 업무 서버를 격리 환경에서 기동하고 로그인과 조회 기능을 시험합니다.
• 연 1회 이상: 담당자가 바뀐 상황을 가정해 복구 절차서만으로 모의훈련을 진행합니다.

실무 팁: 복구 테스트 결과에는 성공 여부만 적지 말고 시작 시각, 완료 시각, 오류 원인, 수동 작업, 실제 RTO 달성 여부를 기록해야 다음 투자가 정확해집니다.

실수 2. 운영 서버와 백업 장비를 한 공간에 모아둡니다

같은 위험을 공유하면 복사본도 함께 사라집니다

운영 서버 옆 랙에 백업 스토리지를 설치하면 전송 속도가 빠르고 관리도 편합니다. 하지만 화재, 누수, 과전압, 냉방 정지나 출입 침해가 발생하면 원본과 복사본이 동시에 피해를 입습니다. 서로 다른 장비라는 사실보다 서로 다른 장애 영역에 있는가가 더 중요합니다.

본사 서버실에 NAS 두 대를 설치하고 상호 복제한 기업이 있었습니다. 장비 한 대의 고장에는 대비했지만 천장 배관 누수로 같은 랙의 전원 장치가 손상되면서 두 복사본에 모두 접근하지 못했습니다. 이 사례에서 부족했던 것은 백업 개수가 아니라 위치와 매체의 분리였습니다.

기본 출발점으로는 원본을 포함해 데이터 사본 3개, 서로 다른 매체 2종, 외부 위치 사본 1개를 두는 3-2-1 원칙을 적용할 수 있습니다. 여기에 변경이 어렵거나 삭제할 수 없는 사본 1개와 복구 오류 0건을 목표로 더한 3-2-1-1-0 방식이 랜섬웨어 대응에 유리합니다.

1. 운영 스토리지와 백업 저장소의 장비, 전원, 계정을 분리합니다.
2. 두 번째 복사본은 다른 건물이나 신뢰할 수 있는 원격 데이터센터로 전송합니다.
3. 세 번째 사본에는 오브젝트 잠금, WORM 또는 오프라인 매체를 적용합니다.
4. 외부 사본에서 실제 복원이 가능한지 네트워크 대역폭과 인증 절차를 시험합니다.

실수 3. 백업 관리자 계정을 운영 도메인과 공유합니다

편리한 통합 로그인이 랜섬웨어의 지름길이 됩니다

백업 서버를 사내 도메인에 가입시키고 도메인 관리자 계정으로 관리하면 초기 운영은 편합니다. 문제는 업무용 PC에서 탈취된 고권한 계정이 운영 서버와 백업 저장소까지 한 번에 열어 준다는 점입니다. 공격자는 암호화 전에 백업 보존 정책을 줄이고 복구 지점을 삭제해 되돌아갈 길부터 차단합니다.

특히 백업 저장소를 일반 파일 공유처럼 열어 두거나 서비스 계정에 불필요한 삭제 권한을 주면 피해 범위가 커집니다. 백업 콘솔, 운영체제, 스토리지 관리 화면에 같은 비밀번호를 사용한 경우도 마찬가지입니다. 백업 인프라는 운영망이 침해됐다는 전제로 별도의 신뢰 경계를 가져야 합니다.

접근 통제는 제품 구매보다 계정 설계에서 시작합니다. 일상 모니터링 계정과 정책 변경 계정을 나누고, 긴급 관리자 계정은 금고화해 사용 기록을 남겨야 합니다. 다중 인증을 적용하더라도 복구용 토큰과 비상 코드를 같은 PC나 메일함에 보관하면 의미가 줄어듭니다.

• 백업 전용 관리자 계정은 일반 업무와 이메일 확인에 사용하지 않습니다.
• 콘솔 접속은 관리 전용 단말과 지정된 네트워크 구간에서만 허용합니다.
• 저장소 삭제, 보존 기간 변경, 관리자 추가에는 재인증과 별도 승인을 요구합니다.
• 서비스 계정의 대화형 로그인과 원격 접속을 차단하고 비밀번호를 주기적으로 교체합니다.
• 삭제 및 정책 변경 로그는 백업 서버 밖의 로그 저장소에도 전송합니다.

실수 4. 모든 업무에 같은 복구 목표를 적용합니다

RPO와 RTO가 없으면 비용도 우선순위도 흔들립니다

모든 서버를 하루 한 번 백업한다는 정책은 단순하지만 업무 영향은 반영하지 못합니다. 주문 데이터가 10분만 사라져도 손실이 큰 시스템과 일주일 전 자료로도 업무를 이어갈 수 있는 보관 서버에 같은 주기를 적용하면, 한쪽은 보호가 부족하고 다른 쪽은 저장 비용을 낭비하게 됩니다.

RPO는 장애 시 허용할 수 있는 데이터 손실 시점이고, RTO는 서비스를 다시 사용할 때까지 허용되는 시간입니다. 예를 들어 RPO 15분, RTO 2시간이라면 최대 15분 분량의 변경 데이터만 잃어야 하며 장애 발생 후 2시간 안에 업무를 재개해야 합니다. 두 숫자를 혼동해 백업 주기만 짧게 만들면 복원 속도가 따라오지 못할 수 있습니다.

범정부 규모처럼 다수 서비스를 연결하는 시스템도 업무 연속성과 서비스 간 관계가 핵심입니다. 관련 개념의 폭을 살펴보려면 범정부 IT 서비스 시스템 설명을 참고할 수 있습니다. 기업 환경에서도 사용자 인증, DNS, 방화벽 정책처럼 다른 서비스가 의존하는 기반 요소를 먼저 복구해야 합니다.

표의 수치는 정답이 아니라 논의를 시작하기 위한 예시입니다. 현업 부서에 “얼마나 빨리 복구할까요?”라고만 묻지 말고, 한 시간 중단 시 취소되는 주문 수와 재입력 인력, 계약상 위약금까지 질문해야 현실적인 목표가 나옵니다.

실수 5. 데이터만 복사하고 시스템 의존 관계를 빼먹습니다

파일은 돌아왔는데 서비스가 열리지 않는 이유

웹 서버 파일과 데이터베이스를 복원했는데 사용자가 로그인하지 못하는 상황이 생길 수 있습니다. 인증 서버, DNS, 인증서, 방화벽 규칙, 로드밸런서 설정, 암호화 키가 함께 복구되지 않았기 때문입니다. 가상머신 이미지 하나만 확보했다고 전체 IT 시스템이 되살아나는 것은 아닙니다.

실제로 인증서 개인키를 백업 대상에 포함하지 않아 복구 서버에서 HTTPS 서비스를 시작하지 못하거나, 데이터 암호화 키를 원본 서버의 로컬 디스크에만 보관해 데이터베이스를 읽지 못하는 실패가 발생합니다. 반대로 민감한 키를 일반 백업 파일에 평문으로 넣으면 유출 위험이 커집니다. 복구 가능성과 보안성을 함께 설계해야 합니다.

IT 자산의 구성과 관계를 파악하는 배경은 IT자산관리시스템 용어 설명에서 확인할 수 있습니다. 다만 자산 목록만으로는 부족하므로 각 서비스가 참조하는 IP, 포트, 계정, 인증서와 시작 순서를 연결한 서비스 지도를 만들어야 합니다.

1. 기반 계층: 전원, 스토리지, 가상화 호스트와 관리 네트워크를 확인합니다.
2. 공통 서비스: DNS, 시간 동기화, 디렉터리, 인증 및 비밀 관리 시스템을 복구합니다.
3. 데이터 계층: 데이터베이스와 메시지 큐의 일관성을 검증합니다.
4. 애플리케이션 계층: API, 웹 서버, 배치 작업을 정해진 순서로 기동합니다.
5. 사용자 경로: 방화벽, 로드밸런서, 인증서와 외부 연동을 시험합니다.

전문가 조언: 복구 절차서에는 “DB를 복원한다”보다 실행 명령, 담당 역할, 필요한 권한, 정상 판정 기준과 실패 시 되돌리는 방법까지 적어야 합니다.

실수 6. 보존 기간을 길게 잡으면 안전하다고 생각합니다

무작정 쌓인 복사본은 비용과 개인정보 위험을 키웁니다

백업을 오래 보관할수록 안전해 보이지만 모든 데이터를 무기한 저장하면 스토리지 비용, 검색 시간, 유출 범위가 함께 늘어납니다. 삭제해야 할 개인정보가 오래된 백업에 계속 남을 수 있고, 복구 시점이 수백 개로 늘어나 운영자가 올바른 사본을 고르는 데도 시간이 걸립니다.

반대 방향의 실수도 있습니다. 저장 공간이 부족하다는 이유로 최근 7일치만 남겼는데 손상이 한 달 전부터 조용히 누적됐다면 정상 데이터로 돌아갈 지점이 없습니다. 백업 보존 정책은 “며칠치” 한 줄이 아니라 변경 빈도, 오류 발견 시간, 법적·계약상 요구와 월말 업무 주기를 반영해 여러 층으로 구성해야 합니다.

예를 들어 일반 업무 파일은 일간 30일, 주간 12주, 월간 12개월처럼 세대별로 나눌 수 있습니다. 데이터베이스는 전체 백업과 증분 또는 트랜잭션 로그의 연결이 끊기지 않도록 관리해야 하며, 장기 보관본은 운영 백업과 다른 저장 등급으로 이동해 비용을 낮출 수 있습니다.

• 데이터 소유 부서와 함께 생성 목적, 민감도, 법적 보존 근거를 문서화합니다.
• 일간·주간·월간 복사본의 삭제 시점과 예외 승인자를 지정합니다.
• 중복 제거율이나 압축률만 믿지 말고 복구 시 재수화 시간과 비용을 측정합니다.
• 퇴직자 자료와 고객 개인정보의 삭제 요청이 백업 정책에 어떻게 반영되는지 확인합니다.
• 보존 기간을 변경할 때 기존 복사본에도 소급 적용되는지 제품 동작을 시험합니다.

저렴한 저장소도 꺼내 읽을 때 별도 비용이 들거나 복원 준비에 수 시간이 필요할 수 있습니다. 따라서 월 저장료만 비교하지 말고 전송, 조회, 복원, 조기 삭제 수수료까지 포함한 3년 총비용을 계산해야 예상 밖의 지출을 줄일 수 있습니다.

실수 7. 예산과 복구 시간을 숫자로 검증하지 않습니다

용량보다 변경량과 전송 시간이 먼저입니다

백업 제품 견적을 받을 때 운영 데이터 20TB라는 숫자만 전달하면 실제 비용을 맞히기 어렵습니다. 하루 변경률이 2%인지 20%인지, 압축이 잘되는 문서인지 이미 압축된 영상인지, 보존 기간과 외부 전송량이 얼마인지에 따라 필요한 용량과 네트워크가 크게 달라집니다. 초기 구매가는 낮아도 라이선스, 원격 저장, 유지보수와 복원 트래픽이 누적될 수 있습니다.

시간 계산도 단순하지만 자주 빠집니다. 유효 복원 처리량이 초당 100MB라면 1TB를 순수 전송하는 데에도 약 2.8시간이 필요하고, 10TB는 약 28시간이 걸립니다. 검증, 압축 해제, 네트워크 경합과 애플리케이션 기동 시간을 더하면 실제 RTO는 더 길어집니다. “백업이 매일 6시간 안에 끝난다”는 사실이 “복구도 6시간이면 된다”는 뜻은 아닙니다.

중견 조직이라면 처음부터 모든 시스템을 같은 수준으로 보호하기보다 2~4주 동안 데이터 변경률과 백업 창을 측정한 뒤 핵심 서비스부터 적용하는 편이 현실적입니다. 구축 작업에는 정책 설계 3~5일, 계정·망 분리 2~5일, 초기 전체 백업 1~수일, 복구 훈련 1~2일 정도를 별도로 잡아야 합니다. 장비 조달이나 회선 증설 기간은 여기에 추가됩니다.

1. 원본 용량, 일일 변경률, 연간 증가율을 각각 기록합니다.
2. RPO에 맞춰 백업 빈도를 정하고 업무 시간대의 회선 사용률을 측정합니다.
3. 전체 복원과 개별 파일 복원의 처리량을 따로 시험합니다.
4. 장비·구독료뿐 아니라 운영 인력, 외부 저장, 복원 전송 비용을 36개월 기준으로 계산합니다.
5. 핵심 서비스는 분기마다 최소 1회, 일반 서비스는 반기마다 최소 1회 복구 시간을 다시 측정합니다.

현실적인 승인 기준은 제품 기능의 개수가 아니라 숫자로 남아야 합니다. 예를 들어 “주문 시스템 RPO 15분, RTO 2시간, 분기 복구훈련 1회, 외부 불변 사본 30일, 복구 오류 0건”처럼 정하면 예산이 어디에 필요한지 분명해집니다. 이 수치를 달성하지 못하는 백업 시스템에는 저장 공간을 더 사기 전에 병목 구간과 복구 절차를 고칠 시간을 먼저 배정해야 합니다.