윈도우 서버를 운영하다 보면 “언제 한 번 크게 장애 나겠지…” 하는 불안감이 늘 따라옵니다. 실제로는 장애가 나고 나서야 백업과 복구의 중요성을 깨닫는 경우가 많죠. 이번 글에서는 장애가 터졌을 때 당황하지 않고, 준비해 둔 백업으로 윈도우 서버를 단계별로 복구하는 현실적인 가이드를 정리해 보겠습니다.
왜 장애 복구 준비가 중요한가
서버 장애는 대부분 예고 없이 찾아옵니다.
하드디스크 고장, 랜섬웨어 감염, 잘못된 패치나 설정, 가상화 플랫폼 장애 등 원인은 다양하지만, 공통점은 “운영 중단 = 돈과 신뢰의 손실”이라는 점입니다.
특히 회사 서비스나 쇼핑몰, 그룹웨어를 올려 둔 윈도우 서버가 멈추면:
- 매출 손실, 내부 업무 마비, 고객 CS 폭증이 한 번에 발생합니다.
- “조금만 더 일찍 백업 설계할 걸…” 하는 후회가 거의 100% 따라옵니다.
저도 예전에 테스트 서버니까 괜찮겠지 하고 대충 운영하다가, 예상치 못한 디스크 불량으로 하루를 통째로 날려본 적이 있습니다. 그때 느꼈던 건 “백업은 옵션이 아니라 필수”라는 사실이었습니다. 여러분은 비슷한 경험 없으신가요?
복구를 위한 기본 개념 정리
본격적인 장애 복구 이야기에 앞서, 최소한 이 정도 개념은 머릿속에 정리해 두면 훨씬 수월합니다.
RPO, RTO 이해하기
- RPO(Recovery Point Objective)
얼마 전 시점까지의 데이터를 포기할 수 있는지에 대한 기준입니다. 예: “최대 4시간 전까지 데이터 손실은 허용” → 최소 4시간마다 백업 필요. - RTO(Recovery Time Objective)
장애 발생 후, 서비스가 언제까지 다시 살아나야 하는지에 대한 목표 시간입니다. 예: “2시간 안에 서비스 복구” → 전체 서버 복원 절차와 장비, 인력이 그 시간 안에 가능해야 합니다.
실무에서는 RPO/RTO를 먼저 잡고 나서, 그에 맞는 백업 주기(일일/시간 단위), 백업 종류(전체/증분/차등), 복구 시나리오를 설계하는 순서가 자연스럽습니다.
윈도우 서버 백업 전략 설계
장애 복구의 80%는 사실 “사전에 어떻게 백업해 두느냐”에서 갈립니다.
3-2-1 백업 원칙 적용
업계에서 가장 많이 이야기하는 것이 3-2-1 백업 전략입니다.
- 데이터 3개 이상 복사본 유지: 운영 중인 원본 + 최소 2개 백업본.
- 2가지 서로 다른 매체 사용: 예) 로컬 디스크 + NAS, 디스크 + 클라우드.
- 1개는 반드시 오프사이트(원격지) 보관: 화재·침수·랜섬웨어 등 물리/논리 재해 대비.
저는 최소한 “서버 내부 디스크 + 외장 백업 디스크 + 클라우드/원격 NAS” 구조를 선호합니다. 로컬이 날아가도 원격에 살아 있고, 랜섬웨어가 서버랑 공유 스토리지를 같이 암호화해도 별도 망에 있는 백업이 마지막 안전망 역할을 해줍니다.
백업 종류와 주기 설계
윈도우 서버 백업 전략을 짤 때는 보통 아래 조합을 많이 사용합니다.
- 전체(Full) 백업: 주 1회 또는 월 1회
- 증분(Incremental) 백업: 평일 매일 또는 수 시간 단위
- 차등(Differential) 백업: 전체 백업 이후 변경분만 모으는 방식
데이터 변화량이 큰 시스템이라면 “초기 1회 전체 백업 + 이후 영구 증분(Forever incremental)” 방식을 쓰는 솔루션도 있습니다. 이 방식은 저장 공간과 백업 시간을 많이 절약하면서도 복구 시에는 전체 시점을 맞춰 되돌릴 수 있다는 장점이 있습니다.
여기에 추가로 꼭 고려해야 할 건:
- 자동 스케줄링: “사람이 손으로 하는 백업”은 언젠가 반드시 빠집니다.
- 암호화·접근제어: 백업 데이터가 유출되면 그 자체가 리스크입니다.
Windows Server Backup(내장 기능) 활용
중소 규모 환경에서는 윈도우 서버에 기본 포함된 Windows Server Backup 기능만 제대로 써도 상당히 괜찮은 수준의 백업·복구 구성이 가능합니다.
Windows Server Backup 설치
- 서버 관리자에서 “역할 및 기능 추가” 실행.
- “역할”은 건너뛰고, “기능” 항목에서 Windows Server Backup을 체크 후 설치.
설치가 끝나면 “관리 도구” 또는 “Windows 관리 도구”에서 해당 콘솔을 실행할 수 있습니다.
기본 백업 구성
일반적인 파일 서버 또는 웹 서버라면 다음과 같이 구성하는 경우가 많습니다.
- 시스템 상태 + 중요한 데이터 볼륨 백업
- 스케줄: 하루 1회 새벽 시간대 전체 또는 증분
- 대상: 별도 데이터 디스크, 외장 스토리지 또는 네트워크 공유 폴더
Exchange 같은 애플리케이션도 Windows Server Backup으로 애플리케이션 단위 복구가 가능합니다.
장애 발생 시 단계별 복구 절차
이제 실제로 장애가 났다는 상황을 가정하고, 어떤 식으로 윈도우 서버 장애 복구를 진행할지 단계별로 정리해 보겠습니다.
1단계: 장애 유형 파악
먼저 아래를 빠르게 구분해야 합니다.
- 서버는 부팅이 되는가?
- OS만 망가졌는가, 아니면 데이터 볼륨까지 손상됐는가?
- 특정 애플리케이션(예: DB, Exchange)만 문제인가?
이 판단에 따라 “파일·폴더 복구로 끝낼지”, “볼륨/애플리케이션 복구를 할지”, “전체 서버 복구(베어 메탈 복구)를 할지”가 결정됩니다.
2단계: 파일/폴더 수준 복구
윈도우 서버는 파일 하나 날려먹은 수준이라면 Windows Server Backup에서 빠르게 복구할 수 있습니다.
- Windows Server Backup 실행 → “로컬 백업” 선택.
- 오른쪽 “작업”에서 복구… 클릭.
- 백업 위치(로컬 드라이브/원격 공유 폴더) 선택 후, 복구할 백업 날짜와 시간을 선택.
- 복구 유형을 파일 및 폴더로 선택 → 필요 파일/폴더 선택 → 원래 위치 또는 다른 위치로 복구.
실무 팁 하나를 덧붙이면, 중요한 설정 파일이나 웹 루트 폴더를 복구할 때는 가능하면 “다른 위치로 복구” 후 비교하면서 덮어쓰는 것을 추천합니다. 의도치 않은 설정 롤백을 막기 위해서죠.
3단계: 애플리케이션/데이터베이스 복구
Exchange처럼 애플리케이션 통합 백업을 사용했다면 다음과 같이 진행합니다.
- Windows Server Backup → 복구 마법사 실행.
- 백업 날짜 선택 후 복구 유형(Application) 선택.
- Exchange 등의 애플리케이션을 선택하고, 롤포워드 여부를 설정해 복구.
데이터베이스 서버나 별도 백업 솔루션을 쓰는 경우에는 각 솔루션의 복구 옵션(시점 복구, 로그 적용 등)을 따라야 합니다. 공통된 핵심은 “테스트 환경에서 복구 연습을 먼저 해보고, 운영에 적용하라”는 점입니다.
4단계: 전체 서버(베어 메탈) 복구
서버 자체가 부팅되지 않거나, OS+데이터 전체가 날아간 경우에는 **전체 서버 복구(베어 메탈 복구)**를 수행해야 합니다.
일반적인 절차는 아래와 같습니다.
- 윈도우 서버 설치 DVD 또는 부팅 USB로 서버를 부팅.
- 설치 화면에서 “컴퓨터 복구” 메뉴 선택.
- “문제 해결” → “시스템 이미지 복구” 선택.
- 미리 만들어 둔 시스템 이미지 백업을 선택하고 복원 진행.
환경에 따라 1~2시간 정도면 서버 전체를 이전 상태로 되돌릴 수 있습니다.
여기서 가장 많이 하는 실수가 두 가지입니다.
- 복구용 부팅 미디어(USB/DVD)를 만들어두지 않음.
- 마지막 전체 백업이 너무 옛날 것이라, 복구해도 데이터가 크게 뒤로 돌아가는 상황.
저는 그래서 새 서버를 구축할 때 “OS 설치 직후 + 기본 역할 구성 직후”에 꼭 한 번 전체 이미지를 떠 두고, 주기적으로 갱신해 두는 편입니다. 여러분도 새 서버를 만들 때 이 습관을 한 번 들여 보시면 좋겠습니다.
복구 계획에서 놓치기 쉬운 부분
장애 복구에서 기술적인 백업 자체만큼 중요한 게 “계획과 테스트”입니다.
복구 테스트(Drill) 필수
- DR(재해 복구) 훈련이나 BCP(업무 연속성) 테스트를 통해 실제로 백업에서 복원이 잘 되는지 주기적으로 확인해야 합니다.
- 문서로만 시나리오를 써 두고 실제로 한 번도 복구를 안 해 보면, 정작 실전에서 권한, 네트워크, 라이선스, 에이전트 문제 등으로 시간이 끝없이 지연될 수 있습니다.
제 경험상, “테스트 한 번 안 해보고도 괜찮을 것 같다”는 생각은 대부분 위험한 착각이었습니다. 최소 분기 1회라도 테스트 서버에 복구 연습을 해 보시는 걸 정말 추천드립니다.
보안과 백업 동시 고려
- 랜섬웨어 공격 시, 서버와 함께 네트워크 공유에 있는 백업까지 암호화당하는 사례가 많습니다.
- 따라서 백업 스토리지에 대해 별도 계정·접근제어, 오프라인 백업 또는 변경 불가 저장소(Immutable Storage) 같은 개념을 같이 고려해야 합니다.
마무리: “장애 복구는 기술이 아니라 습관”
윈도우 서버 장애 복구는 거창한 기술 이야기가 아니라, 평소에 얼마나 꼼꼼하게 백업 전략을 세우고, 주기적으로 점검하고, 한두 번이라도 복구 연습을 해봤느냐의 문제에 가깝습니다.
한 번만 큰 장애를 겪어도, 백업 설계를 위한 몇 시간과 추가 스토리지 비용이 얼마나 값싼 보험이었는지 절실하게 느끼게 됩니다.
저는 지금도 새로운 윈도우 서버를 만들 때마다 “이 서버가 오늘 죽으면, 몇 시간 안에 어디까지 살릴 수 있을까?”라는 질문부터 던지고 설계를 시작합니다. 여러분은 현재 운영 중인 윈도우 서버에 대해 같은 질문을 해 보셨나요? 아직이라면, 오늘이라도 백업 주기와 복구 시나리오를 한 번 점검해 보시는 건 어떨까요?