백업은 돌고 있는데, 왜 복구는 안 되는가?

서버 백업을 하고 계시냐고 물으면 대부분 "돌고 있습니다"라는 답이 돌아옵니다. 실제로 돌고 있는 경우가 많습니다. 문제는 그다음 질문이 잘 이어지지 않는다는 데 있습니다. 무엇이 백업되고 있는지, 그것으로 업무가 어디까지 되살아나는지는 별개의 이야기입니다.

실제로 이런 경우를 본 적이 있습니다. 경영 정보 대부분을 NAS에 두고 쓰던 고객사가 랜섬웨어에 감염됐습니다. 데이터 복구를 시도했지만 원인을 알 수 없는 이유로 실패했고, 되살리는 데 상당히 애를 먹었습니다.

백업이 있다는 말과 복구가 된다는 말은 같은 뜻이 아닙니다. 이 글은 복구 리허설을 돌릴 여건이 안 되는 회사에서, 그래도 미리 확인해둘 수 있는 것이 무엇인지를 정리한 글입니다.

"복구가 끝났다"를 어디에 두고 계십니까

복구의 완료선은 회사마다 다릅니다. 그리고 이 선을 어디에 두느냐에 따라 백업 설계 자체가 달라집니다.

• 서버가 켜진다: 하드웨어와 OS가 올라온 상태입니다. 전산 담당 입장에서는 큰 고비를 넘긴 시점이지만, 현장은 아직 아무것도 못 합니다.
• 시스템에 로그인된다: 화면이 뜹니다. 여기서 "복구됐다"고 보고되는 경우가 많습니다.
• 현장 단말에서 실적이 입력된다: 설비 연동, 바코드 단말, 프린터까지 살아났는지가 여기서 드러납니다.
• 전날 마감 숫자가 맞는다: 데이터가 끊긴 구간이 없는지, 그 구간을 메울 수 있는지가 확인된 상태입니다.

완료선을 앞쪽에 두면 점검 항목은 서버 안에서 끝납니다. 마지막 단계에 두면 점검해야 할 대상이 서버 밖으로 넓어집니다. 장애가 났을 때 실제로 회사가 곤란해지는 지점은 대개 마지막 단계이므로, 백업 범위도 그 기준으로 잡는 편이 낫습니다.

완료선을 어디에 두느냐가 백업 범위를 결정합니다

백업 목록에 들어가 있지 않은 것들

복구가 막히는 지점은 백업 작업의 실패보다 백업 대상 목록의 누락인 경우가 많습니다. 그리고 누락되는 항목에는 공통점이 있습니다. 관리하는 사람이 전산 담당이 아니라는 점입니다.

서버 설정, 계정, 권한

데이터베이스를 백업하면 시스템이 통째로 백업된다고 이해하기 쉽습니다. 그러나 사용자 계정과 권한 체계, 서비스 실행 계정, 방화벽과 포트 설정, 구축 당시 성능을 맞추려고 조정해둔 값들은 별개입니다. 대부분 구축업체가 잡아둔 것이고, 문서로 남지 않은 채 서버 안에만 있습니다.

이런 항목이 빠지면 복구 후에 시스템은 뜨는데 특정 부서만 화면이 안 열리거나, 야간 배치가 실행되지 않는 식의 증상이 나타납니다. 데이터는 멀쩡하므로 원인을 찾는 데 시간이 오래 걸립니다.

인터페이스와 스케줄러

ERP와 생산관리 시스템 사이의 연동, 설비에서 데이터를 받아오는 수집 설정, 정해진 시각에 돌아가는 집계 작업들이 여기 해당합니다. 이 영역의 특징은 멈춰도 즉시 티가 나지 않는다는 것입니다. 화면은 정상이고 입력도 되는데, 며칠 뒤 집계 숫자가 이상해진 다음에야 연동이 끊겨 있었다는 사실이 드러납니다.

설비 제어 PC

검사기, 측정기, 각인기, 라벨 프린터에 붙어 있는 PC들입니다. 여기에는 장비 제조사가 설치한 전용 프로그램과 설정값, 검사 조건, 라벨 양식이 들어 있습니다. 백업 대상에서 빠지는 이유는 명확합니다. 자산 목록을 서버실 기준으로 세기 때문이고, 관리 주체가 전산이 아니라 설비나 품질이기 때문입니다.

이 PC가 고장 나면 라인이 섭니다. 그런데 복구 계획에는 대개 이름이 없습니다.

대상	관리 주체	빠졌을 때 나타나는 증상
업무 데이터·DB	전산	대개 백업 대상에 들어 있음
서버 설정·계정·권한	구축업체	시스템은 뜨는데 일부 업무가 막힘
인터페이스·스케줄러	구축업체	조용히 멈춘 뒤 집계에서 발견됨
설비 제어 PC	설비·품질	해당 공정 자체가 정지

빠지는 항목은 관리 주체가 전산이 아닌 것들입니다

복구는 전체본 하나로 되지 않습니다

실무에서 흔히 쓰는 방식은 시스템을 멈춘 상태에서 전체를 한 번 떠두고, 그 뒤로는 바뀐 부분만 이어서 쌓는 구조입니다. 전체 백업은 다시 일정 주기로 반복합니다. 주기를 얼마로 잡을지는 데이터의 중요도와 회사 사정에 따라 달라서 일반적인 정답을 말하기 어렵습니다. 하루치를 잃었을 때 손으로 다시 만들 수 있는지를 기준으로 정하는 편이 그나마 현실적입니다.

다만 주기와 별개로, 이 구조에는 알아둘 성질이 하나 있습니다. 전체본과 그 이후의 증분은 사슬로 이어져 있습니다. 중간에 한 칸이 비면 복구는 그 지점에서 멈춥니다. 뒤에 쌓인 증분이 멀쩡하게 남아 있어도 이어 붙일 기준이 없기 때문입니다. 증분 백업이 하루 실패했다는 알림이 사소해 보이지 않는 이유가 여기 있습니다.

증분이 한 칸 비면 복구는 그 지점에서 멈춥니다

복구에 걸리는 시간도 이 구조를 따라갑니다. 마지막 전체본이 오래됐을수록 그 뒤에 이어 붙여야 할 증분이 많아지고, 복구 시간은 그만큼 길어집니다. 전체 백업 주기를 늘리면 저장 공간과 정지 시간은 아끼지만 복구 시간을 내주는 셈입니다. 어느 쪽을 감수할지는 그 시스템이 몇 시간 멈춰도 되는지에 달려 있습니다.

돌고는 있는데, 보는 사람이 없는 백업

백업 작업이 설정돼 있는 것과 백업이 관리되고 있는 것은 다릅니다. 구축 시점에 일정이 등록되고 나면, 그 뒤로는 아무도 들여다보지 않는 상태가 이어지기 쉽습니다.

두 가지가 특히 자주 비어 있습니다. 하나는 백업 파일이 어디에 쌓이고 언제까지 보관되는지를 아는 사람이 없는 경우입니다. 보관 기간이 짧게 잡혀 있으면 오래된 것부터 지워지는데, 이때 전체본이 먼저 사라지고 증분만 남는 상황이 생길 수 있습니다. 앞서 본 것처럼 기준점이 없는 증분은 단독으로 쓸 수 없습니다. 랜섬웨어나 데이터 오염처럼 발견이 늦는 사고에서 이 차이가 크게 벌어집니다.

다른 하나는 실패 알림이 도착하는 메일함을 아무도 열지 않는 경우입니다. 퇴사자 계정으로 설정돼 있거나, 매일 오는 정상 알림에 묻혀 실패 메일이 구분되지 않는 식입니다. 알림이 오고 있다는 사실 자체는 점검 결과가 아닙니다.

복구 리허설 없이 확인할 수 있는 8가지

실제 복구 테스트가 가장 확실하지만, 예비 장비와 정지 시간이 필요해 실행하기 어려운 경우가 많습니다. 그런 경우에도 아래 항목은 책상에서 확인할 수 있습니다. 답이 막히는 항목이 곧 취약한 지점입니다.

확인 항목	점검 기준
백업 파일이 저장되는 위치	원본 서버와 물리적으로 분리돼 있는가
보관 기간	가장 최근 전체본과 그 이후 증분이 빠짐없이 남아 있는가
전체 백업 주기	그 간격만큼 데이터를 잃어도 업무가 감당되는가
마지막 복구 시도 시점	한 번이라도 실제로 되살려본 적이 있는가
실패 알림 수신자	재직 중인 담당자가 실제로 열어보는 계정인가
설정·계정·권한 기록	서버 밖에 문서 형태로 남아 있는가
설비 제어 PC	백업 대상 목록에 한 대라도 올라와 있는가
복구 가능 인원	절차를 아는 사람이 두 명 이상인가

여덟 항목 중 답이 바로 나오는 것이 절반에 못 미친다면, 백업 장비를 늘리기 전에 목록부터 다시 적는 편이 낫습니다. 대부분의 경우 돈이 아니라 범위의 문제입니다.

백업이 무사히 되살아나도, 공유 폴더 안에서 어느 파일이 유효한 최신본인지 모르면 복구 뒤에 현장은 다시 멈칫합니다. 도면처럼 수정본이 계속 쌓이는 파일이라면 도면 파일이 엉키는 이유 - 파일명과 버전 규칙에서 정리한 이름 규칙을 백업 범위와 함께 정해두는 편이 좋습니다.

마지막 하나, 사람

복구 절차를 아는 사람이 한 명뿐인 상태는 백업이 없는 것과 위험의 성격이 비슷합니다. 그 한 명이 자리를 비운 날 장애가 나면 회사는 절차가 아니라 연락처에 기대게 됩니다. 이 구조는 백업만의 문제가 아니라 사내에서 만들어진 거의 모든 시스템에 공통으로 나타납니다. 이 부분은 자동화를 만든 사람이 퇴사하면 생기는 일에서 따로 다뤘습니다.

정리하면, 백업을 점검한다는 것은 작업이 도는지 보는 일이 아니라 무엇이 목록에 없는지를 찾는 일에 가깝습니다. 완료선을 전날 마감 숫자에 두고 목록을 역산해보시면, 지금 빠져 있는 것이 무엇인지 비교적 빨리 드러납니다.

시스템이 돌아와도 끝이 아닙니다. 장애 동안 현장이 종이로 남긴 기록을 다시 넣는 과정에서 숫자가 한 번 더 어긋나는데, 그 지점은 장애가 끝난 뒤, 종이에 남은 숫자는 어디서 어긋나는가?에 정리했습니다.