백업 · 복구

백업이란?

백업·복구 체계가 갖춰지면 사고가 났을 때 회사가 던지는 질문이 바뀝니다. '데이터가 날아갔는데 어떡하죠'가 아니라 '몇 시 기준으로 되돌릴까요, 몇 시간이면 라인이 다시 돕니까'가 됩니다. 손실을 시간 단위로 환산해 답할 수 있는 상태가 백업 체계의 실체이고, 그래서 IT 부서만의 숙제가 아니라 생산·영업·회계가 함께 결정해야 할 경영 판단입니다. 어디까지 잃어도 회사가 견디는가를 먼저 합의하지 않으면 장비를 사도 기준이 없습니다.

실무 설계는 두 숫자에서 출발합니다. RPO(복구 시점 목표)는 '몇 시간 전 데이터까지 잃어도 되는가', RTO(복구 시간 목표)는 '몇 시간 안에 업무를 되돌려야 하는가'입니다. 마감 중인 회계 데이터는 RPO 1시간·RTO 4시간, 사내 공지 게시판은 RPO 24시간·RTO 3일처럼 자산별로 다르게 잡습니다. 방식은 전체 백업, 변경분만 담는 증분, 기준일 이후 누적분을 담는 차등으로 나뉘고 보관도 일 단위 30일·월 단위 12개월처럼 층을 만듭니다. 3-2-1에 '1개는 오프라인, 검증 오류 0건'을 더한 3-2-1-1-0이 요즘 기준이며, 이중화(RAID·실시간 미러링)는 백업이 아닙니다 — 원본이 암호화되면 사본도 같은 순간 암호화됩니다.

현장에서 가장 흔한 사고는 '백업은 돌고 있었는데 복구가 안 되는' 경우입니다. 실패 알림 메일이 석 달째 스팸함에 쌓여 있었거나, 백업 스토리지가 같은 도메인·같은 사내망에 물려 있어 랜섬웨어가 본체와 사본을 한 번에 잠근 사례가 계속 나옵니다. 클라우드·SaaS를 쓰니 알아서 해준다는 말도 위험합니다. 사업자는 인프라 장애만 책임지고, 직원이 지운 파일은 휴지통 보관 기간이 지나면 돌아오지 않습니다. 반기 1회라도 실제 복구 훈련을 돌리지 않으면 그 체계는 있는 게 아니라 있다고 믿는 것에 가깝고, 복구 후 업무가 실제로 돌아간 시각까지 재봐야 RTO 숫자가 진짜가 됩니다.