스토리지를 RAID로 구성했는데 실수로 지운 파일을 되살리지 못하거나, 대기 서버까지 마련했는데 서비스가 복구되지 않는 일이 생긴다. 저장장치 장애를 견디는 구성, 서비스를 이어가는 구성, 과거 데이터를 되돌리는 수단은 각각 맡은 역할이 다르기 때문이다.
백업은 특정 시점의 데이터를 보존해 복원하는 방법이고, 이중화는 구성요소 장애가 발생했을 때 다른 구성요소로 서비스를 유지하거나 전환하는 설계다. 둘은 대체 관계가 아니다. 어떤 사고를 막고 싶은지, 데이터 손실과 중단을 얼마나 허용하는지에 따라 함께 조합해야 한다.
백업과 이중화는 복구하는 대상이 다르다
백업은 파일, 데이터베이스, 애플리케이션 설정 등 복구에 필요한 정보를 별도의 복구 지점으로 보관한다. 복구 시에는 보존된 사본 가운데 필요한 시점을 선택해 데이터를 돌려놓는다. 보존 주기와 기간, 사본의 위치, 복원 절차가 실제 복구 범위를 결정한다.
이중화는 서버, 네트워크 경로, 전원, 스토리지 등의 구성요소를 중복 구성한다. Active-Standby 방식에서는 주 장비에 장애가 나면 대기 장비로 전환하고, Active-Active 방식에서는 여러 장비가 동시에 요청을 처리할 수 있다. 다만 장비를 복수로 배치했다는 사실만으로 장애 시 자동 전환이나 서비스 지속이 보장되지는 않는다. 감지와 전환 절차, 데이터 정합성, 접속 경로, 남은 장비의 처리 능력이 함께 작동해야 한다.
| 구분 | 백업 | 이중화 |
|---|---|---|
| 보호 대상 | 데이터의 복구 가능한 시점 | 서버·경로 등 서비스 구성요소 |
| 기대 효과 | 삭제·손상 전 상태로 복원 | 일부 장비 장애 시 중단 축소 |
| 동작 방식 | 보관된 사본을 선택해 복원 | 정상 구성요소로 전환하거나 부하 분산 |
| 주요 한계 | 복원에 시간이 걸리고 복구 지점에 따라 손실 발생 | 잘못된 변경도 복제될 수 있고 공통 장애에 취약 |
| 핵심 시험 | 데이터를 복원해 업무 기능까지 확인 | 장애 전환과 전환 후 처리 능력 확인 |
RAID는 여러 디스크를 묶어 디스크 고장에 대한 가용성을 높이는 기술이다. 그러나 RAID 자체는 백업이 아니다. 사용자가 파일을 삭제하거나 데이터가 논리적으로 손상되면 변경 내용이 동일한 볼륨에 그대로 반영될 수 있다. 서버나 스토리지 전체가 침해·파손되는 상황을 대비하려면 별도의 복구 사본과 복원 절차가 필요하다.
복제가 있어도 과거의 정상 데이터가 남는 것은 아니다
복제는 한 시스템의 데이터를 다른 시스템에 동기화하는 방식이다. 디스크나 서버 장애가 발생했을 때 다른 쪽에서 업무를 이어가는 데 도움이 된다. 하지만 오삭제나 암호화된 파일처럼 잘못된 변경이 복제되면 대기 시스템에도 같은 상태가 전달될 수 있다. 복제 시점이 최신이라는 점이 언제나 유리한 것은 아니다.
시점 복구(Point-in-Time Recovery), 버전 관리, 스냅샷은 특정 시점의 상태로 돌아가는 데 쓸 수 있다. 다만 각 기능의 보존 기간과 저장 위치, 권한 구조는 제품과 구성에 따라 다르다. 운영 데이터와 동일한 장비·계정만으로 사본을 관리하면 원본 장애나 관리자 계정 침해가 사본에도 영향을 미칠 수 있다.
랜섬웨어에 대비할 때도 백업이 있다는 사실만 확인해서는 부족하다. 공격자가 운영 환경의 권한으로 백업 사본을 삭제하거나 암호화할 수 있는지, 백업 관리 계정이 분리돼 있는지, 오프라인 또는 변경·삭제 제한 사본이 있는지 확인해야 한다. CISA는 오프라인 백업 유지와 정기적인 복구 시험을 권고한다.
사고 시나리오별로 필요한 대책
| 사고 상황 | 중심 대책 | 함께 확인할 사항 |
|---|---|---|
| 서버 한 대의 고장 | 이중화·장애 전환 | 전환 자동화, 대기 용량, 접속 경로 |
| 디스크 고장 | RAID 또는 스토리지 이중화 | 다른 장비·장소에 백업이 있는지 |
| 사용자 오삭제 | 삭제 전 시점의 백업·버전 복구 | 보존 기간과 복구 권한 |
| 랜섬웨어·논리적 손상 | 격리된 정상 사본 복원 | 침해 범위, 사본 무결성, 계정 분리 |
| 건물 정전·화재 | 원격지 복구 환경과 사본 | 통신·인증·운영 인력·복구 순서 |
이 표는 일반적인 대응 방향이다. 실제 구성에서는 장애 범위가 여러 항목에 걸칠 수 있다. 예를 들어 스토리지 장애와 함께 건물 정전이 발생한다면 RAID만으로는 대응할 수 없다. 장애가 발생한 장소와 장비, 계정까지 함께 영향을 받는지를 따져 사본과 복구 환경을 분리해야 한다.
RTO와 RPO로 허용 수준을 수치화한다
RTO(Recovery Time Objective)는 업무를 복구하기까지 허용할 수 있는 목표 시간이다. RPO(Recovery Point Objective)는 복구 시 감수할 수 있는 데이터 손실의 범위로, 시간으로 표현한다. 두 목표는 IT 부서가 장비 성능만 보고 정하기보다 업무 담당자와 합의해야 한다.
가상 예시: 주문 시스템에 RTO 2시간, RPO 15분을 정했다면 장애 후 두 시간 안에 업무를 재개하고, 최대 15분 정도의 데이터만 잃도록 구성해야 한다. 하루 한 번 백업하는 방식은 15분 RPO를 충족하지 못할 수 있다. 더 잦은 백업이나 로그 기반 시점 복구, 복제 등을 검토하되, 복제가 오삭제·손상까지 전달할 위험에는 별도 버전 보관으로 대응해야 한다.
RTO는 데이터 복원 명령이 끝난 시간으로 계산하지 않는다. 장애 확인과 복구 결정, 장비 준비, 데이터 복원, 애플리케이션 기동, 사용자 접속과 주요 거래 확인을 거쳐 실제 업무가 재개될 때까지를 측정 범위에 포함해야 한다. AWS의 재해복구 지침도 복구 전략을 RTO·RPO 목표와 비용·복잡도의 균형으로 선택하고, 복제를 시점 복구 백업과 함께 고려하도록 안내한다.
백업 성공과 복구 성공을 따로 검증한다
백업 작업의 성공 로그는 사본 생성 작업이 완료됐다는 뜻이다. 그 사본으로 업무를 실제 복구할 수 있는지까지 증명하지는 않는다. 이중화 역시 장비가 대기 중이라는 표시만으로 전환 후 서비스가 정상인지 확인할 수 없다.
운영 점검에서는 두 시험을 분리한다.
- 전환시험: 승인된 점검 시간에 장애를 가정하고 대기 장비로 전환한다. 사용자 접속, 데이터 정합성, 남은 처리 용량, 원상 복귀 절차를 확인한다.
- 복원시험: 운영 환경과 분리된 시험 공간에서 백업 데이터를 복구한다. 파일 열기뿐 아니라 권한, 설정, 데이터베이스 정합성, 핵심 업무 기능을 점검한다.
- 결과 기록: 시험한 복구 지점, 실제 소요 시간, 확인한 업무 기능, 오류와 후속 조치를 기록한다.
복구 시험은 운영 데이터를 덮어쓰지 않도록 격리된 환경에서 계획해야 한다. 업무 담당자가 결과 확인에 참여해야 기술적으로 파일이 열리는 것과 실제 업무 처리가 가능한 것을 구분할 수 있다.
도입 검토서에는 ‘백업 운영 중’이나 ‘서버 이중화 완료’만 적기보다 보호하려는 사고, 복구 가능한 시점, 예상 업무 중단 시간, 최근 시험 결과를 함께 기록하자. 이 정보가 있어야 구성이 업무의 RTO·RPO를 충족하는지, 추가 투자가 필요한지 판단할 수 있다.