백업 복구 테스트 체크리스트: 백업은 있는데 복구가 안 되는 이유

백업을 해두었다고 해서 데이터가 반드시 복구되는 것은 아닙니다. 실제 장애나 랜섬웨어 감염이 발생했을 때는 백업 파일이 손상되어 있거나, 복구 비밀번호를 모르거나, 백업 대상에서 중요한 폴더가 빠져 있거나, 복구 시간이 예상보다 오래 걸리는 문제가 생길 수 있습니다.

그래서 백업 전략에서 가장 중요한 질문은 “백업이 되었는가?”가 아니라 “정말 복구할 수 있는가?”입니다. 백업은 복구를 위해 존재하기 때문에, 정기적인 복구 테스트를 하지 않은 백업은 아직 검증되지 않은 백업이라고 보는 것이 안전합니다.

이번 글에서는 백업은 있는데 복구가 안 되는 대표적인 이유와, 개인 사용자와 소규모 회사가 바로 적용할 수 있는 백업 복구 테스트 체크리스트를 정리해보겠습니다.

백업 복구 테스트란?

백업 복구 테스트는 저장해둔 백업 데이터를 실제로 복원해보고, 파일이나 시스템이 정상적으로 열리는지 확인하는 과정입니다.

단순히 백업 프로그램 화면에 “성공”이라고 표시되는 것과 실제 복구가 가능한 것은 다릅니다. 백업 작업은 성공했지만 복구할 때 오류가 나거나, 파일은 복원되었지만 열리지 않거나, 데이터베이스가 정상적으로 기동되지 않는 경우도 있습니다.

백업 복구 테스트에서는 다음을 확인해야 합니다.

• 백업 파일이 실제로 존재하는지
• 복구 지점을 선택할 수 있는지
• 원하는 파일과 폴더가 백업 대상에 포함되어 있는지
• 복구한 파일이 정상적으로 열리는지
• 복구 권한과 계정이 정상적으로 작동하는지
• 복구 시간이 목표 시간 안에 들어오는지
• 랜섬웨어나 장비 고장 상황에서도 사용할 수 있는 백업인지

즉, 백업 복구 테스트는 백업 파일을 “보관”하는 단계에서 끝내지 않고, 실제 장애 상황에서 “사용 가능한 상태”인지 검증하는 작업입니다.

백업은 있는데 복구가 안 되는 이유

백업 실패보다 더 위험한 것은 백업이 잘 되고 있다고 믿었는데 실제로는 복구가 안 되는 상황입니다. 이런 문제는 생각보다 자주 발생합니다.

1. 중요한 폴더가 백업 대상에서 빠진 경우

가장 흔한 문제는 백업 대상 설정이 잘못된 경우입니다. 예를 들어 문서 폴더는 백업되지만 바탕화면, 다운로드 폴더, 회계 프로그램 데이터 폴더, 사진 원본 폴더가 빠져 있을 수 있습니다.

특히 업무용 프로그램은 사용자가 보기 쉬운 문서 폴더가 아니라 별도 경로에 데이터를 저장하는 경우가 있습니다. 백업 설정을 한 번만 해두고 확인하지 않으면 실제 중요한 데이터가 빠질 수 있습니다.

2. 백업은 성공했지만 파일이 손상된 경우

백업 파일이 있다고 해서 항상 정상 파일이라는 뜻은 아닙니다. 저장 장치 불량, 네트워크 오류, 백업 중단, 암호화 오류, 압축 파일 손상 등으로 인해 복구 파일이 열리지 않을 수 있습니다.

따라서 복구 테스트에서는 단순히 파일 목록만 확인하지 말고, 실제 문서, 사진, 압축 파일, 데이터베이스, 설정 파일을 열어봐야 합니다.

3. 백업 비밀번호나 암호화 키를 모르는 경우

보안을 위해 백업 파일을 암호화하는 것은 좋은 방법입니다. 하지만 백업 비밀번호, 복구 키, 관리자 계정 정보를 잃어버리면 백업 파일이 있어도 복구할 수 없습니다.

소규모 회사에서는 담당자가 퇴사하면서 백업 계정 정보와 암호화 키가 제대로 인수인계되지 않는 문제가 생기기도 합니다. 백업 복구 테스트는 이런 운영상 빈틈을 미리 발견하는 데 도움이 됩니다.

4. 백업 저장소가 원본과 함께 손상된 경우

백업을 원본과 같은 PC, 같은 NAS, 같은 서버 안에만 보관하면 장비 고장이나 랜섬웨어에 함께 영향을 받을 수 있습니다.

예를 들어 PC 내부의 다른 드라이브에 백업했는데 PC 전체가 고장 나거나, NAS 안에 원본과 백업을 같이 두었는데 NAS가 랜섬웨어에 감염되면 복구가 어려워집니다.

이 문제를 줄이려면 3-2-1 백업 원칙처럼 여러 복사본을 서로 다른 저장 위치에 두는 방식이 필요합니다.

5. 스냅샷을 백업으로 착각한 경우

스냅샷은 특정 시점의 상태로 빠르게 되돌리는 데 유용합니다. 하지만 스냅샷은 원본 스토리지와 강하게 연결되어 있는 경우가 많기 때문에, 원본 장비가 완전히 고장 나거나 스냅샷까지 삭제되면 복구가 어려울 수 있습니다.

스냅샷의 구조와 한계가 궁금하다면 기존 글인 스냅샷의 원리를 참고하면 좋고, 스냅샷과 백업의 차이는 스냅샷은 백업을 대체할 수 있을까? 글에서 따로 정리했습니다.

6. 복구 시간이 너무 오래 걸리는 경우

백업 데이터가 있더라도 복구 시간이 너무 오래 걸리면 업무 중단이 길어질 수 있습니다. 예를 들어 회사 파일 서버를 복구하는 데 2일이 걸린다면 백업은 있어도 실제 업무 피해는 커질 수 있습니다.

그래서 백업 정책을 만들 때는 단순히 백업 용량만 볼 것이 아니라 RTO와 RPO를 함께 봐야 합니다. RTO는 복구 시간 목표, RPO는 데이터 손실 허용 범위를 의미합니다. 이 개념은 RTO와 RPO란? 글에서 자세히 다뤘습니다.

7. 백업 주기가 실제 업무와 맞지 않는 경우

매주 1회 백업만 하는데 매일 중요한 업무 데이터가 생긴다면, 장애 발생 시 최대 일주일치 데이터를 잃을 수 있습니다. 백업 주기가 너무 길면 복구는 되더라도 손실이 큽니다.

백업 주기는 데이터 중요도와 변경 빈도에 따라 달라져야 합니다. 회계 자료, 계약서, 고객 데이터, 블로그 원고처럼 자주 바뀌는 데이터는 더 짧은 백업 주기가 필요할 수 있습니다.

8. 애플리케이션 데이터가 일관성 없이 백업된 경우

문서 파일은 단순 복사만으로도 복구가 되는 경우가 많지만, 데이터베이스나 업무용 프로그램은 다릅니다. 프로그램이 실행 중인 상태에서 단순 파일 복사 방식으로 백업하면 복구 후 데이터가 깨질 수 있습니다.

데이터베이스, 그룹웨어, 회계 프로그램, 가상머신, 서버 애플리케이션은 애플리케이션 일관성을 고려한 백업 방식이 필요합니다. 소규모 회사라도 중요한 프로그램 데이터는 단순 파일 복사만 믿지 않는 것이 좋습니다.

백업 복구 테스트가 필요한 이유

복구 테스트는 귀찮은 작업처럼 보일 수 있지만, 실제 사고가 발생하기 전에 문제를 찾을 수 있는 가장 현실적인 방법입니다.

백업 복구 테스트를 하면 다음을 확인할 수 있습니다.

• 백업 대상이 제대로 지정되어 있는지
• 백업 파일이 정상적으로 열리는지
• 복구에 필요한 계정과 권한이 준비되어 있는지
• 복구 비밀번호와 암호화 키가 보관되어 있는지
• 복구 시간이 목표 안에 들어오는지
• 랜섬웨어 감염 이전 시점으로 되돌릴 수 있는지
• 백업 저장소가 원본 장애와 분리되어 있는지
• 담당자가 실제 복구 절차를 알고 있는지

특히 랜섬웨어 대응에서는 백업 파일이 존재하는 것뿐만 아니라, 공격자가 접근하지 못한 정상 복구 지점이 있는지가 중요합니다. 랜섬웨어 대응 전체 흐름은 랜섬웨어의 이해와 대응 전략 글에서 함께 확인할 수 있습니다.

백업 복구 테스트 전 준비할 것

복구 테스트를 시작하기 전에는 무작정 복원 버튼을 누르면 안 됩니다. 원본 데이터를 덮어쓰지 않도록 별도 테스트 위치를 준비하고, 어떤 데이터를 어떤 기준으로 확인할지 정해야 합니다.

준비 항목	확인 내용
테스트 대상	사진, 문서, 업무 폴더, 데이터베이스, 서버 이미지 중 무엇을 복구할지 정합니다.
복구 위치	원본을 덮어쓰지 않도록 별도 폴더, 별도 PC, 테스트 서버에 복원합니다.
복구 시점	가장 최근 백업과 과거 백업 중 어떤 시점을 복구할지 정합니다.
확인 기준	파일 개수, 파일 열기, 용량, 수정일, 프로그램 실행 여부를 확인합니다.
계정 정보	백업 관리자 계정, 복구 권한, 암호화 키, 2단계 인증 수단을 확인합니다.
소요 시간	복구 시작부터 실제 사용 가능 상태까지 걸린 시간을 기록합니다.
결과 기록	성공, 실패, 오류 메시지, 개선 사항을 문서로 남깁니다.

백업 복구 테스트 절차

개인이나 소규모 회사라면 아래 순서만 따라도 기본적인 복구 테스트를 할 수 있습니다.

1단계. 중요한 데이터 목록 작성

먼저 어떤 데이터를 반드시 살려야 하는지 정리합니다. 모든 데이터를 동일한 중요도로 볼 필요는 없습니다.

• 개인 사진과 영상
• 문서, 계약서, 증빙 자료
• 블로그 글 원고와 이미지 파일
• 회계 자료와 세금 관련 파일
• 고객 정보와 업무 공유 폴더
• 서버 설정 파일과 데이터베이스
• 프로그램 설치 파일과 라이선스 정보

중요 데이터 목록을 만들어야 백업 대상 누락 여부를 확인할 수 있습니다.

2단계. 백업 위치 확인

백업 데이터가 어디에 저장되어 있는지 확인합니다. 외장하드, NAS, 클라우드, 원격 서버, 이뮤터블 백업 저장소 등 저장 위치를 구분해야 합니다.

백업 저장 위치와 기술을 비교하고 싶다면 백업 스토리지 기술 글을 참고하면 좋습니다.

3단계. 복구 지점 선택

복구 테스트에서는 가장 최근 백업만 확인하지 말고, 며칠 전 또는 몇 주 전 백업도 함께 확인하는 것이 좋습니다. 랜섬웨어는 감염 직후 바로 발견되지 않을 수 있기 때문에, 감염 이전의 정상 시점이 필요할 수 있습니다.

예를 들어 다음과 같이 테스트할 수 있습니다.

• 오늘 새벽 백업 파일 복구
• 3일 전 백업 파일 복구
• 1주일 전 백업 파일 복구
• 월말 전체 백업 파일 복구

4단계. 원본이 아닌 위치에 복원

복구 테스트를 할 때는 원본 데이터를 덮어쓰지 않도록 주의해야 합니다. 반드시 테스트 폴더, 외장 드라이브, 별도 PC, 테스트 서버처럼 안전한 위치에 복원합니다.

특히 업무용 서버나 데이터베이스는 운영 중인 원본 서버에 바로 복원하면 장애를 만들 수 있습니다. 가능하면 별도 테스트 환경에서 복구 절차를 검증해야 합니다.

5단계. 복구한 파일을 직접 열어보기

파일이 복원되었다고 끝이 아닙니다. 실제로 열어보고 내용이 정상인지 확인해야 합니다.

• 문서 파일이 열리는지
• 엑셀 파일의 시트와 수식이 정상인지
• 사진과 영상이 깨지지 않았는지
• 압축 파일이 정상 해제되는지
• 업무 프로그램에서 데이터가 열리는지
• 데이터베이스가 정상적으로 기동되는지
• 권한과 공유 설정이 유지되는지

테스트 대상 파일은 매번 하나만 확인하지 말고, 여러 유형의 파일을 골고루 확인하는 것이 좋습니다.

6단계. 복구 시간 기록

복구에 걸린 시간을 반드시 기록합니다. 백업 용량이 커질수록 복구 시간이 예상보다 길어질 수 있습니다.

예를 들어 100GB 파일 복구는 괜찮았지만 2TB NAS 전체 복구는 하루 이상 걸릴 수 있습니다. 클라우드 백업은 인터넷 속도와 다운로드 제한에 영향을 받을 수 있습니다.

복구 시간이 목표보다 길다면 백업 저장소, 네트워크, 복구 우선순위, 백업 방식 자체를 다시 검토해야 합니다.

7단계. 실패 원인을 기록하고 수정

복구 테스트에서 실패가 나왔다면 오히려 좋은 발견입니다. 실제 사고 전에 문제를 찾았기 때문입니다.

다음 항목을 기록해두면 다음 테스트에 도움이 됩니다.

• 테스트 날짜
• 복구한 백업 시점
• 복구 대상
• 복구 위치
• 성공 여부
• 걸린 시간
• 발생한 오류
• 수정할 사항
• 다음 테스트 예정일

개인 사용자를 위한 복구 테스트 체크리스트

개인 사용자는 복잡한 기업용 절차보다 꾸준히 확인할 수 있는 간단한 체크리스트가 좋습니다.

확인	체크 항목	권장 주기
□	사진, 문서, 블로그 자료가 백업 대상에 포함되어 있는지 확인	월 1회
□	외장하드 또는 NAS 백업 파일이 실제로 생성되는지 확인	월 1회
□	임의의 문서와 사진을 별도 폴더에 복원해 열어보기	월 1회
□	클라우드 백업의 버전 관리와 휴지통 보관 기간 확인	분기 1회
□	백업용 외장하드를 백업 후 분리 보관	백업할 때마다
□	백업 비밀번호와 복구 계정 정보 확인	분기 1회
□	스마트폰 사진과 문서 백업 상태 확인	월 1회
□	중요 데이터 전체를 다른 저장소에 추가 복사	반기 1회

개인 사용자라면 최소한 한 달에 한 번은 중요한 파일 몇 개를 직접 복구해보는 것이 좋습니다. 백업이 자동으로 돌아간다고 해도 실제 파일을 열어보지 않으면 안심하기 어렵습니다.

소규모 회사를 위한 복구 테스트 체크리스트

소규모 회사는 담당자가 바뀌어도 복구할 수 있도록 절차와 기록을 남기는 것이 중요합니다. 백업 담당자 한 명만 알고 있는 구조는 위험합니다.

확인	체크 항목	권장 주기
□	부서별 공유 폴더와 업무 프로그램 데이터가 백업 대상에 포함되어 있는지 확인	월 1회
□	NAS, 외장하드, 클라우드, 원격지 백업 성공 여부 확인	주 1회
□	중요 폴더를 테스트 위치에 복원하고 파일 열기 검증	월 1회
□	회계 프로그램, 데이터베이스, 그룹웨어 데이터 복구 테스트	분기 1회
□	랜섬웨어 감염 전 시점으로 되돌릴 수 있는지 확인	분기 1회
□	복구에 걸린 시간과 RTO 충족 여부 기록	테스트할 때마다
□	마지막 백업 시점과 RPO 충족 여부 확인	테스트할 때마다
□	백업 관리자 계정, MFA, 암호화 키, 복구 권한 확인	분기 1회
□	담당자 부재 시 다른 사람이 복구 절차를 따라 할 수 있는지 확인	반기 1회

NAS를 사용하는 소규모 회사라면 NAS 백업 전략 정리 글과 함께 보면서 스냅샷, 원격 백업, 외장하드 오프라인 백업, 클라우드 백업을 조합하는 것이 좋습니다.

랜섬웨어 대비 복구 테스트

랜섬웨어 대비 복구 테스트는 단순한 파일 복원보다 더 엄격하게 봐야 합니다. 랜섬웨어는 원본 데이터뿐 아니라 연결된 백업 저장소까지 암호화하거나 삭제하려고 할 수 있기 때문입니다.

랜섬웨어 대비 복구 테스트에서는 다음을 확인합니다.

• 감염 이전 시점의 백업을 찾을 수 있는지
• 백업 저장소가 랜섬웨어 감염 PC와 분리되어 있는지
• 외장하드 백업이 백업 후 분리되어 있는지
• 클라우드 백업에 버전 관리와 보존 기간이 설정되어 있는지
• 이뮤터블 백업 또는 변경 불가 보관 기능이 적용되어 있는지
• 관리자 계정이 탈취되어도 백업 삭제가 어려운 구조인지
• 복구 후 악성코드가 다시 실행되지 않도록 격리 절차가 있는지
• 복구한 파일이 정상이고 암호화되지 않았는지

중요한 백업은 가능하면 공격자가 쉽게 지우거나 수정하지 못하도록 보호해야 합니다. 이와 관련된 개념은 변경 불가 백업(Immutable Backup) 구축 가이드에서 이어서 볼 수 있습니다.

백업 방식별 복구 테스트 포인트

백업 방식에 따라 확인해야 할 포인트도 달라집니다.

백업 방식	테스트 포인트	주의할 점
풀백업	전체 데이터를 한 번에 복구할 수 있는지 확인	복구는 단순하지만 저장 공간과 시간이 많이 필요할 수 있음
증분백업	풀백업과 이후 증분백업 체인이 모두 정상인지 확인	중간 증분 파일이 손상되면 복구에 문제가 생길 수 있음
차등백업	풀백업과 최신 차등백업 조합으로 복구되는지 확인	백업 용량 증가와 복구 시점 선택을 확인해야 함
스냅샷	원하는 시점으로 되돌릴 수 있는지 확인	스냅샷 저장 공간 부족과 삭제 권한을 주의해야 함
클라우드 백업	다운로드 속도, 복원 경로, 계정 보안을 확인	대용량 복구 시 시간이 오래 걸릴 수 있음
외장하드 백업	외장하드 연결 후 파일이 정상적으로 열리는지 확인	백업 후 분리 보관해야 랜섬웨어 피해를 줄일 수 있음
이뮤터블 백업	보존 기간 안에 삭제나 변경이 불가능한지 확인	보존 정책을 잘못 설정하면 비용이나 운영 문제가 생길 수 있음

풀백업, 증분백업, 차등백업의 차이가 헷갈린다면 풀백업과 증분백업 글을 먼저 참고하면 좋습니다.

복구 테스트 결과 기록 양식

복구 테스트는 한 번 하고 끝내는 것이 아니라 기록을 남겨야 의미가 있습니다. 아래 항목만 기록해도 다음 테스트와 문제 해결에 도움이 됩니다.

기록 항목	예시
테스트 날짜	2026년 6월 10일
테스트 담당자	관리자 또는 백업 담당자
복구 대상	업무 공유 폴더, 회계 데이터, 사진 원본 폴더
복구 시점	전날 새벽 백업, 1주일 전 백업
복구 위치	테스트 PC, 별도 NAS 폴더, 테스트 서버
복구 소요 시간	35분, 2시간 10분 등 실제 시간
검증 결과	파일 열림, DB 기동 성공, 권한 정상
발견된 문제	일부 폴더 누락, 속도 느림, 권한 오류
개선 조치	백업 대상 추가, 보존 기간 수정, 회선 속도 점검
다음 테스트 예정일	다음 달 또는 다음 분기

복구 테스트 주기 추천

복구 테스트 주기는 데이터 중요도에 따라 달라질 수 있습니다. 하지만 아무 기준이 없다면 아래 정도로 시작해볼 수 있습니다.

대상	권장 복구 테스트	설명
개인 문서와 사진	월 1회 파일 몇 개 복구	중요 파일이 정상적으로 열리는지 확인
블로그 자료와 작업 파일	월 1회 폴더 단위 복구	원고, 이미지, 설정 파일 누락 여부 확인
소규모 회사 공유 폴더	월 1회 중요 폴더 복구	업무 문서와 권한 복구 확인
업무 프로그램 데이터	분기 1회 애플리케이션 복구	프로그램에서 데이터가 실제로 열리는지 확인
서버와 데이터베이스	분기 1회 이상	테스트 서버에서 기동 여부 확인
전체 재해복구 시나리오	반기 또는 연 1회	장비 고장, 랜섬웨어, 사무실 장애 상황 가정

시스템을 크게 변경했거나, 백업 솔루션을 바꿨거나, 저장소를 이전했거나, 담당자가 바뀐 경우에는 정기 주기와 관계없이 복구 테스트를 다시 하는 것이 좋습니다.

복구 테스트에서 자주 하는 실수

복구 테스트를 하더라도 아래 실수를 하면 실제 사고 대응에는 부족할 수 있습니다.

• 항상 같은 파일 하나만 복구해보고 끝내는 것
• 원본 위치에 바로 복구해서 기존 데이터를 덮어쓰는 것
• 복구한 파일을 열어보지 않고 목록만 확인하는 것
• 복구 시간을 기록하지 않는 것
• 암호화 키와 관리자 계정 정보를 확인하지 않는 것
• 랜섬웨어 감염 전 시점 복구 가능 여부를 확인하지 않는 것
• 백업 담당자 한 명만 복구 절차를 아는 것
• 클라우드 동기화를 백업으로 착각하는 것
• 스냅샷만 믿고 외부 백업을 만들지 않는 것
• 테스트 결과를 문서로 남기지 않는 것

백업과 장기 보관 데이터를 구분해서 관리하고 싶다면 백업과 아카이브 전략의 통합 글도 함께 참고할 수 있습니다.

자주 묻는 질문

Q1. 백업 프로그램에서 성공이라고 나오면 복구 테스트가 필요 없나요?

필요합니다. 백업 작업 성공은 백업 파일 생성이 완료되었다는 의미일 뿐, 실제 복구가 정상적으로 되는지는 별도로 확인해야 합니다. 복구한 파일을 직접 열어보고, 필요한 경우 프로그램이나 데이터베이스까지 실행해봐야 합니다.

Q2. 개인 사용자도 복구 테스트를 해야 하나요?

네. 개인 사용자도 사진, 문서, 블로그 원고, 세금 자료처럼 잃어버리면 곤란한 데이터가 있습니다. 한 달에 한 번 정도 중요한 파일 몇 개를 복구해보는 것만으로도 백업 문제를 미리 찾을 수 있습니다.

Q3. 복구 테스트는 원본 폴더에 바로 해도 되나요?

권장하지 않습니다. 원본 데이터를 덮어쓸 수 있기 때문에 별도 테스트 폴더, 외장하드, 테스트 PC, 테스트 서버에 복구하는 것이 안전합니다.

Q4. 얼마나 자주 복구 테스트를 해야 하나요?

개인 파일은 월 1회 간단한 복구 테스트가 좋고, 소규모 회사의 중요 데이터는 월 1회 또는 분기 1회 이상 테스트하는 것이 좋습니다. 서버나 데이터베이스처럼 중요한 시스템은 변경 후에도 반드시 테스트해야 합니다.

Q5. 랜섬웨어 대비 복구 테스트에서 가장 중요한 것은 무엇인가요?

감염 이전 시점으로 복구할 수 있는지, 백업 저장소가 공격자에게 삭제되거나 암호화되지 않았는지, 오프라인 또는 이뮤터블 백업이 있는지를 확인하는 것이 중요합니다.

Q6. 클라우드 백업도 테스트해야 하나요?

네. 클라우드 백업도 계정 잠금, 권한 문제, 다운로드 속도, 버전 관리 설정, 보존 기간 문제로 복구가 어려울 수 있습니다. 대용량 데이터는 복구 시간이 오래 걸릴 수 있으므로 실제 다운로드와 복원을 테스트해야 합니다.

Q7. 복구 테스트에서 실패하면 어떻게 해야 하나요?

실패 원인을 기록하고 바로 수정해야 합니다. 백업 대상 누락이면 대상 폴더를 추가하고, 권한 문제라면 복구 계정을 점검하고, 속도 문제가 있으면 저장소나 네트워크를 개선해야 합니다. 실패 자체보다 실패를 기록하지 않고 방치하는 것이 더 위험합니다.

마무리

백업은 데이터를 보호하기 위한 시작점이지만, 복구 테스트는 그 백업이 실제로 쓸 수 있는지 확인하는 과정입니다. 백업 파일이 있어도 복구가 안 되면 사고 상황에서는 아무 의미가 없습니다.

복구 테스트에서는 백업 대상, 복구 지점, 복구 위치, 파일 무결성, 계정 권한, 암호화 키, 복구 시간, 랜섬웨어 감염 전 시점 복구 가능 여부를 함께 확인해야 합니다.

개인 사용자는 한 달에 한 번 중요한 파일 몇 개를 복원해보는 것부터 시작하면 됩니다. 소규모 회사는 NAS, 클라우드, 외장하드, 이뮤터블 백업을 조합하고, 정기적으로 복구 테스트 결과를 기록해야 합니다.

결국 좋은 백업 전략은 “백업이 있다”가 아니라 “문제가 생겼을 때 정해진 시간 안에 정상 데이터로 복구할 수 있다”로 증명되어야 합니다.

참고 자료

• CISA - StopRansomware Guide
• NIST SP 800-34 Rev.1 - Contingency Planning Guide for Federal Information Systems
• AWS Backup - Restore testing
• Microsoft Learn - Azure Backup documentation
• Microsoft Learn - Restore VMs by using Azure Backup