서버 백업, 복구 테스트 없이 믿다 생기는 사고

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

백업이 있다는 말에 안심한 첫 번째 실수

파일만 복사하고 시스템은 빠뜨린 경우

장애가 터졌을 때 가장 많이 나오는 말은 의외로 간단합니다. 백업은 있습니다라는 말입니다. 그런데 실제 복구를 시작하면 업무 폴더 일부만 남아 있고, 데이터베이스 설정, 서버 계정, 방화벽 정책, 라이선스 정보는 비어 있는 경우가 적지 않습니다. 백업을 했다는 사실과 업무를 다시 움직일 수 있는 상태는 전혀 다릅니다.

특히 중소기업 IT시스템에서는 파일 서버, ERP 서버, 그룹웨어, NAS, 공유 프린터, 보안 장비가 한꺼번에 묶여 움직입니다. 파일 하나를 살리는 것보다 중요한 것은 사용자가 다시 로그인하고, 프로그램이 DB에 붙고, 지점에서 본사 서버로 정상 접속하는 흐름입니다. IT 자산의 범위를 먼저 잡지 않으면 백업 대상도 계속 빠집니다. 관련 용어를 확인하려면 IT자산관리시스템 정의처럼 자산을 관리 단위로 보는 관점이 도움이 됩니다.

담당자 PC에 남은 설정값의 위험

현장에서 더 위험한 실패는 문서화되지 않은 설정입니다. 예를 들어 서버 IP는 알고 있지만 실제 DB 포트가 무엇인지 모릅니다. NAS 계정은 있는데 백업 소프트웨어 암호는 전임자 개인 메신저에만 남아 있습니다. 이 상태에서 서버 장애가 나면 장비보다 사람이 병목이 됩니다.

• 하지 말아야 할 일: 공유 폴더만 외장하드에 복사하고 서버 백업이라고 부르기
• 반드시 남길 것: 서버 역할, IP, 계정 권한, 백업 경로, 복구 순서, 담당 연락망
• 확인할 질문: 이 자료만 보고 외부 엔지니어가 업무 서비스를 다시 열 수 있는가

백업 문서는 장비 설명서가 아니라 복구 작업자의 길 안내서여야 합니다. 담당자가 휴가 중이어도 같은 순서로 따라 할 수 있어야 합니다.

복구 테스트를 미룬 조직에서 벌어진 일

백업 성공 알림이 복구 성공을 뜻하지 않습니다

매일 새벽 백업 성공 메일이 온다고 해서 안심하면 안 됩니다. 백업 솔루션은 파일을 저장했다는 사실만 알려줄 뿐, 그 파일로 서비스가 살아나는지까지 보증하지 않는 경우가 많습니다. 실제로는 DB 파일이 열린 상태에서 복사되어 일관성이 깨졌거나, 운영체제 버전과 복원 이미지가 맞지 않거나, 가상화 서버의 스냅샷만 남고 외부 스토리지 연결 정보가 빠지는 일이 생깁니다.

서버 백업에서 가장 중요한 질문은 언제 백업했는가보다 얼마나 빨리, 어디까지 복구할 수 있는가입니다. 업무가 반나절 멈춰도 괜찮은 회사와 30분만 멈춰도 매출 손실이 생기는 회사는 설계가 달라야 합니다. 복구 목표 시간은 RTO, 허용 가능한 데이터 손실 범위는 RPO로 나눠 봐야 합니다. 이 두 기준 없이 백업 주기만 정하면 비용은 쓰고도 장애 때 답을 못 냅니다.

테스트를 안 하는 이유가 곧 사고 원인입니다

복구 테스트를 미루는 이유는 대체로 비슷합니다. 바쁘고, 운영 서버를 건드리기 무섭고, 테스트 장비가 없다는 이유입니다. 하지만 테스트를 하지 않은 백업은 보험이라기보다 소원에 가깝습니다. 최소한 분기 1회는 임시 장비나 격리된 가상 환경에서 복구해 보고, 로그인부터 핵심 프로그램 실행까지 확인해야 합니다.

1. 1단계: 최근 백업본을 별도 공간에 복원해 파일 무결성을 확인합니다.
2. 2단계: DB, 웹, 업무 프로그램처럼 의존성이 있는 서비스를 순서대로 기동합니다.
3. 3단계: 실제 사용자 계정으로 접속해 조회, 저장, 출력, 외부 접속을 확인합니다.
4. 4단계: 걸린 시간과 실패 원인을 기록해 다음 백업 정책에 반영합니다.

네트워크를 빼고 백업을 설계한 실수

백업 트래픽이 업무망을 느리게 만들 때

서버와 스토리지만 보고 백업을 설계하면 네트워크에서 사고가 납니다. 야간 백업이라 괜찮다고 생각했는데 매장, 병원, 공장처럼 늦은 시간에도 업무가 이어지는 곳은 다릅니다. 대용량 이미지 백업이 같은 스위치와 같은 회선을 지나가면 ERP 접속이 느려지고, CCTV 저장이나 그룹웨어 첨부파일 업로드까지 영향을 받습니다.

이때 흔한 실수는 네트워크 장비를 더 비싼 것으로 바꾸는 일입니다. 장비 교체 전에 먼저 백업 시간대, 대역폭 제한, VLAN 분리, NAS 위치, 방화벽 정책을 봐야 합니다. 네트워크 구축은 속도만 올리는 작업이 아니라 트래픽의 길을 정리하는 작업입니다. 백업망과 업무망을 나누면 같은 장비에서도 체감 안정성이 달라질 수 있습니다.

복구 순간에는 DNS와 방화벽도 백업 대상입니다

장애 당일에는 서버 파일보다 접속 경로가 더 큰 문제로 드러납니다. 서버는 복원했는데 직원들이 접속하지 못합니다. 이유를 추적하면 DNS 레코드, 방화벽 NAT, VPN 라우팅, 내부 고정 IP 충돌 같은 네트워크 설정이 빠져 있습니다. 그래서 서버 백업 문서에는 네트워크 설정도 함께 들어가야 합니다.

• 하지 마세요: 백업 경로를 담당자 기억에만 맡기기
• 확인하세요: 복구 서버가 기존 IP를 그대로 써야 하는지, 임시 IP로도 업무가 가능한지
• 분리하세요: 백업 트래픽, 사용자 트래픽, 외부 접속 트래픽의 우선순위

보안 백업이라고 부르기 어려운 방식

랜섬웨어가 백업까지 지우는 구조

백업 폴더가 운영 서버에서 바로 쓰기 가능한 상태라면 공격자도 같은 권한으로 접근할 수 있습니다. 랜섬웨어가 공유 폴더를 암호화하면 원본과 백업이 동시에 망가집니다. 그래서 최신 인프라 운영에서는 백업을 단순 복사본이 아니라 격리된 복구 자산으로 봅니다. 쓰기 권한을 제한하고, 일정 기간 삭제할 수 없는 보관 정책을 두며, 관리자 계정도 다중 인증으로 보호해야 합니다.

보안 이슈는 먼 이야기가 아닙니다. 금융권을 다룬 24시간 감시 AI 방패 관련 보도처럼 공격과 방어는 상시 운영 체계의 문제가 되고 있습니다. 대기업만의 문제가 아니라 사내 서버 한 대, NAS 한 대를 쓰는 조직도 관리자 권한이 탈취되면 업무 전체가 멈출 수 있습니다.

장애와 보안 사고를 따로 보면 대응이 느려집니다

전산 장애 보도도 눈여겨볼 필요가 있습니다. 대형 증권사 전산 장애 피해 관련 기사처럼 시스템 중단은 고객 피해와 신뢰 하락으로 이어질 수 있습니다. 보안 사고든 장비 장애든 현장에서는 결국 같은 질문으로 모입니다. 언제부터 멈췄고, 어디까지 잃었고, 몇 분 안에 어느 수준으로 되돌릴 수 있느냐입니다.

• 운영 계정 분리: 평소 사용하는 관리자 계정과 백업 삭제 권한 계정을 나눕니다.
• 격리 보관: 운영 서버가 감염되어도 접근할 수 없는 저장소를 둡니다.
• 복구 로그 보관: 누가 언제 백업을 실행하고 복구를 시도했는지 남깁니다.
• 권한 최소화: 모든 직원이 백업 폴더를 수정할 수 있는 구조를 피합니다.

좋은 백업은 많이 저장하는 방식이 아니라, 공격받은 날에도 지워지지 않고 검증된 순서로 되돌아오는 방식입니다.

사무실 규모와 지점 수에 따라 선택이 갈립니다

작은 사무실은 단순하지만 검증된 구성이 유리합니다

직원 수가 많지 않고 서버가 한두 대인 사무실이라면 복잡한 장비보다 운영 가능한 구조가 먼저입니다. NAS, 외부 저장소, 클라우드 보관을 조합하되 담당자가 매주 확인할 수 있어야 합니다. 백업 소프트웨어 화면은 화려하지만 실제로 아무도 보지 않으면 장애 때 도움이 되지 않습니다. 작은 조직일수록 자동화된 알림과 짧은 복구 절차가 중요합니다.

이 경우 하지 말아야 할 일은 모든 것을 한 번에 크게 바꾸는 것입니다. 먼저 핵심 데이터가 어디에 있는지 확인하고, 그다음 서버 이미지와 업무 파일을 나눠 백업합니다. 월 1회라도 복구 연습을 해 보면 어떤 자료가 빠졌는지 바로 드러납니다. 비용은 저장 용량, 보관 기간, 외부 보관 방식에 따라 달라지므로 장비 가격보다 복구 시간을 기준으로 예산을 잡는 편이 현실적입니다.

여러 지점은 중앙 관리와 표준 절차가 필요합니다

반대로 지점, 공장, 매장, 병원이 여러 곳이라면 단순한 외장하드 백업으로는 부족합니다. 지점마다 담당자 숙련도가 다르고 네트워크 품질도 다르기 때문입니다. 본사에서 백업 상태를 한눈에 보고, 실패 알림을 받고, 지점별 복구 우선순위를 정할 수 있어야 합니다. VL시스템 같은 IT 인프라 운영 파트너가 필요한 순간도 대부분 여기서 생깁니다.

• 10~30명 규모 사무실: 핵심 서버 1대와 NAS 중심으로 시작하고, 매월 복구 테스트를 고정 일정으로 두는 선택이 맞습니다.
• 여러 지점이 있는 기업: 백업 서버, 네트워크 분리, 중앙 모니터링, 권한 관리까지 묶어 표준 운영안으로 설계하는 편이 안전합니다.
• 고객 서비스가 멈추면 손실이 큰 조직: 백업만이 아니라 대체 서버 기동, 회선 이중화, 장애 공지 절차까지 함께 준비해야 합니다.

작은 조직이라면 지금 당장 한 번 복구해 보는 것이 가장 빠른 선택입니다. 지점이 많고 업무 중단 비용이 큰 조직이라면 장비 구매보다 먼저 서버, 네트워크, 인프라 운영 절차를 한 장의 복구 흐름도로 만드는 쪽을 선택하는 것이 좋습니다.