자동 백업이 돌고 있다고 믿었는데, 열어보니 백업이 아니었습니다
복원하려던 날에야 백업의 실체를 알았습니다
직원 PC 하나가 아침에 안 켜졌습니다. 저장장치가 죽은 것으로 판명이 났고, 저는 크게 걱정하지 않았습니다. 회사 자료는 매일 밤 외장 드라이브로 자동 백업이 돌고 있다고 알고 있었기 때문입니다.
외장 드라이브를 다른 PC에 꽂고 나서야 상황을 알았습니다. 백업 폴더의 최신 날짜가 8개월 전이었습니다. 8개월 전까지 남아 있던 백업 중에도 열리지 않는 압축 파일이 섞여 있었습니다. 백업은 돌고 있던 게 아니라, 8개월 전 어느 날 조용히 멈춘 채 있었습니다.
그날 이후 알게 된 것들입니다.
- 자료는 다행히 대부분 살렸습니다. 백업이 아니라 다른 경로들에서였습니다.
- 백업이 멈춘 원인은 시시할 만큼 단순했습니다. 그리고 8개월간 아무도 몰랐던 이유는 백업의 성공 여부를 확인하는 절차가 어디에도 없었기 때문입니다.
- 이 일 뒤로 백업 체계를 다시 짰는데, 핵심은 더 좋은 백업 도구가 아니라 복원 시험이라는 절차 하나였습니다.
백업이 멈춘 원인: 드라이브가 꽉 찼고, 알림은 아무 데도 안 갔습니다
멈춘 원인부터 확인했습니다. 백업 프로그램의 기록을 열어보니 8개월 전 어느 날부터 매일 밤 같은 실패가 찍혀 있었습니다. 대상 드라이브의 공간이 부족하다는 내용이었습니다.
외장 드라이브가 가득 찬 겁니다. 백업 프로그램은 오래된 백업을 지우고 자리를 만드는 설정이 꺼져 있었고, 실패 알림은 프로그램 안의 기록 화면에만 남았습니다. 그 화면은 아무도 열어보지 않는 화면이었습니다.
그러니까 이 백업 체계는 성공은 조용하고 실패도 조용한 구조였습니다. 잘되든 안되든 똑같이 조용하니, 밖에서 보면 구분이 안 됩니다. 8개월을 아무도 모른 게 이상한 일이 아니었습니다.
열리지 않는 압축 파일의 정체
8개월 전까지 남아 있던 백업 중에도 몇 개는 열리지 않았습니다. 확인해보니 백업이 도는 시각에 켜져 있던 PC에서 파일이 사용 중이어서, 일부 파일이 잠긴 채로 건너뛰어지거나 깨진 채 담긴 것이었습니다. 즉 날짜가 찍혀 있다고 그 안이 온전하다는 보장이 없었습니다. 백업 파일의 존재와 백업의 성공은 다른 문제였습니다.
자료를 실제로 살린 곳은 백업 폴더가 아니었습니다
정작 복구는 백업 바깥에서 이뤄졌습니다. 살린 경로를 적어두면 이렇습니다.
| 자료 | 살린 경로 |
|---|---|
| 거래처 문서, 계약 관련 | 메일함의 주고받은 첨부파일 |
| 정산 엑셀 최신본 | 공유 폴더에 올려둔 사본 |
| 세금계산서 관련 | 국세청 홈택스에서 재조회 |
| 급여 관련 | 세무법인이 보관 중인 사본 요청 |
| 사진, 스캔본 일부 | 복구 업체에 맡긴 저장장치에서 부분 복구 |
여기서 배운 게 두 가지입니다. 하나는 업무 자료의 상당수가 원본을 다시 받을 수 있는 곳이 존재한다는 점입니다. 세금계산서는 국세청에 있고, 주고받은 문서는 상대방에게도 있습니다. 다른 하나는 그럼에도 그 PC에만 존재하던 자료, 그 직원이 만들던 작업 중간본들은 끝내 일부를 잃었다는 점입니다. 복구 업체 비용은 수십만 원 단위였고, 그마저 전부를 돌려주지는 못했습니다.
복구에 들어간 시간도 만만치 않았습니다. 표의 경로들을 하나씩 뒤지고 상대방에게 사본을 요청하고 회신을 기다리는 데 꼬박 나흘이 갔습니다. 백업이 제대로 있었다면 반나절이면 끝났을 일입니다. 백업의 값어치는 평소에는 0원처럼 보이다가, 이런 날 한꺼번에 청구됩니다.
복기: 우리가 갖고 있던 것은 백업이 아니라 백업 프로그램이었습니다
정리하고 나서 무엇이 문제였는지 적어봤습니다. 백업 프로그램을 설치하고 일정을 걸어둔 것까지는 몇 년 전에 되어 있었습니다. 문제는 그 이후의 전부였습니다.
- 성공했는지 아무도 확인하지 않았습니다. 확인 담당도, 확인 주기도 정해진 적이 없습니다.
- 실패해도 아무에게도 알려지지 않았습니다. 알림이 사람에게 닿는 경로가 없었습니다.
- 복원을 한 번도 해본 적이 없었습니다. 백업에서 파일을 꺼내 열어본 것이 이번 사고가 처음이었습니다.
- 백업 대상이 한 부, 한 장소였습니다. 외장 드라이브 하나가 전부였고, 그 드라이브는 PC 옆에 상시 꽂혀 있었습니다. 화재나 도난이면 원본과 같이 사라지는 위치입니다.
백업 프로그램을 돌리는 것과 백업을 갖고 있는 것은 다른 상태인데, 우리는 앞의 것을 해놓고 뒤의 것을 가졌다고 믿고 있었습니다.
다시 짠 체계
거창한 장비를 들이지는 않았습니다. 바꾼 것은 다섯 가지입니다.
손대기 전에 다른 안도 검토했습니다. 외부 백업 대행 업체에 통째로 맡기는 방법도 견적을 받아봤습니다. 관리는 편해지겠지만 회사 자료가 외부 서버에 통째로 올라가는 구조가 마음에 걸렸고, 매달 나가는 비용도 새로 생기는 지출이었습니다. 지금 갖고 있는 외장 드라이브와 이미 쓰던 클라우드 저장소만으로 뼈대를 다시 세우는 쪽이 저희 규모에는 더 맞다고 판단했습니다.
두 벌, 두 장소로 나눴습니다
하나는 사무실의 외장 드라이브, 하나는 클라우드 저장소입니다. 공공기관과 보안 업계에서 흔히 권하는 3-2-1 원칙, 즉 사본 세 벌을 두 가지 매체에 두고 한 벌은 다른 장소에 두라는 기준을 다 채우지는 못했지만, 기존보다 백업 사본과 보관 장소를 하나씩 늘렸습니다.
실패가 시끄럽게 만들었습니다
백업이 실패하면 관리용 메신저 방으로 알림이 오게 걸었습니다. 반대로 성공은 조용히 두었습니다. 매일 오는 성공 알림은 한 달이면 아무도 안 읽게 되고, 그 사이에 낀 실패 알림도 같이 묻히기 때문입니다.
매월 말일에 복원 시험을 합니다
월말 정산 마감 절차에 한 줄을 추가했습니다. 백업에서 아무 파일이나 세 개를 골라 실제로 꺼내 열어보는 것입니다. 5분이면 끝납니다. 이 5분이면 백업이 멈춰 있어도 8개월이 아니라 한 달 안에 알 수 있습니다.
날짜를 확인하는 게 아니라 파일을 열어보는 것이 핵심입니다. 날짜는 8개월 전에도 찍혀 있었습니다.
드라이브가 차기 전에 자리를 만들게 했습니다
오래된 백업을 자동으로 지워 공간을 확보하는 설정을 켰습니다. 이번 사고의 직접 원인을 그대로 둘 이유가 없었습니다. 보관 기간은 석 달로 잡았습니다. 더 길게 두고 싶은 마음도 있었지만, 기간을 늘리면 드라이브가 다시 차는 날이 온다는 게 이번에 배운 것이라, 용량 안에서 확실히 도는 쪽을 택했습니다.
백업 대상 목록도 이때 처음 만들었습니다
체계를 다시 짜면서 알게 된 것이 하나 더 있습니다. 기존 백업이 무엇을 백업하고 있었는지가 어디에도 안 적혀 있었다는 점입니다. 확인해보니 백업 대상은 문서 폴더 하나뿐이었고, 바탕화면과 다운로드 폴더에 쌓여 있던 작업 파일들은 처음부터 대상 밖이었습니다. 이번에 잃은 자료의 일부도 거기 있던 것들입니다.
그래서 PC마다 백업 대상 폴더 목록을 한 장으로 적고, 반대로 업무 파일은 그 폴더 안에서만 작업한다는 규칙을 같이 세웠습니다. 백업 범위를 넓히는 것과 작업 위치를 좁히는 것, 두 방향에서 좁혀야 빈틈이 닫혔습니다.
우리 사무실에도 되느냐는 질문에는
이 체계를 우리 사무실에도 쓸 수 있느냐는 질문을 받으면 두 군데부터 물어봅니다. 하나는 실패 알림이 도착할 경로가 이미 있는지입니다. 저희는 관리용으로 쓰던 메신저 방이 있어서 거기에 알림을 붙이기만 하면 됐지만, 그런 방이 없는 곳이라면 알림이 사람에게 닿을 경로부터 새로 만들어야 하고, 그 경로를 만드는 일이 생각보다 손이 갑니다.
복원 시험을 얹을 자리가 있는지도 갈립니다. 저희는 월말 정산 마감이라는, 매달 거르지 않고 도는 절차가 이미 있어서 거기에 한 줄만 끼우면 됐습니다. 그런 정기 절차가 없는 사무실이라면 복원 시험을 위한 일정을 별도로 잡아야 하는데, 새로 만든 일정은 처음 몇 달은 잘 지켜지다가 바쁜 시기가 오면 가장 먼저 밀리는 자리가 됩니다. 이미 도는 루틴에 붙이느냐, 새 루틴을 만드느냐가 오래가는지 아닌지를 가르는 갈림길이라고 봅니다.
5분짜리 습관이 자리 잡기까지
체계를 다시 짠 뒤로 사고는 없었습니다. 그렇다고 손이 덜 간 것도 아닙니다. 매달 세 개 파일을 골라 열어보는 5분은 짧지만, 그 5분을 월말 마감 목록에서 빼먹지 않고 챙기는 일 자체가 새로운 습관으로 자리 잡기까지는 시간이 걸렸습니다. 처음 두어 달은 마감이 다 끝난 뒤에야 복원 시험을 빼먹었다는 걸 뒤늦게 알아채고 그 자리에서 확인한 적도 있습니다.
실패 알림을 관리용 메신저 방으로 보내게 한 것도 처음에는 방을 시끄럽게 만들지 않을까 걱정했습니다. 실제로는 실패가 잦지 않아서 큰 문제는 아니었지만, 드라이브 공간이 부족해지는 시점이 다가오면 경고성 알림이 며칠 연속으로 오는 구간이 생겼고, 그때는 다른 업무 알림과 섞여서 잠깐 헷갈렸습니다. 지금은 그 구간에 온 알림만 따로 눈여겨보는 정도로 넘어가고 있습니다.
꺼내서 열려야 백업입니다
- 백업의 성공 여부는 백업 프로그램이 아니라 복원으로 확인합니다. 꺼내서 열리는 것만이 백업입니다.
- 실패는 사람에게 닿는 경로로 알려져야 합니다. 프로그램 안의 기록 화면은 알림이 아닙니다.
- 한 벌 한 장소는 백업이 아니라 사본입니다. 장소를 나눠야 원본과 함께 죽는 구조를 벗어납니다.
- 원본을 다시 받을 수 있는 자료와 이 PC에만 있는 자료를 구분해두면, 사고가 났을 때 무엇부터 살릴지 순서가 나옵니다.
8개월 동안 멈춰 있던 백업을 발견한 날의 그 서늘함은 겪어본 사람만 압니다. 그 감각을 잊지 않으려고 이 기록을 남깁니다.
그래서 요즘은 질문부터 던집니다
다른 부서 담당자를 만나면 백업 프로그램 이름이나 설정 화면 얘기는 꺼내지 않습니다. 대신 “저희 백업, 마지막으로 파일 하나 꺼내서 열어보신 게 언제입니까”라고 먼저 묻습니다. 대부분 바로 답을 못 합니다. 백업이 돌고 있다는 것과 백업에서 무언가를 꺼내본 적이 있다는 것은 완전히 다른 질문인데, 사고 전의 저도 그 차이를 구분하지 못했습니다.
도구 이름을 나열하면 다들 자기 회사에도 비슷한 도구가 있다고 안심하고 넘어갑니다. 그런데 정작 필요한 건 도구 교체가 아니라 확인 절차였기 때문에, 도구 얘기로 시작하면 대화가 엉뚱한 방향으로 흘러갑니다. 그래서 요즘은 도구 얘기는 뒤로 미루고 복원 시험이라는 절차 하나만 먼저 설명합니다.
이어서 읽을 기록
