VPS를 암호화된 오프쇼어 스토리지에 백업하는 방법

서버를 배포하는 날 백업까지 갖춰두는 사람은 거의 없다. 그 일은 늘 나중에 일어난다 — 업그레이드 도중 디스크가 가득 차고 난 뒤, 엉뚱한 디렉터리에서 뭔가를 지운 뒤, 마이그레이션이 겉보기엔 멀쩡히 켜지지만 엉뚱한 답을 내놓는 데이터베이스를 남긴 뒤, 누군가 침입한 뒤에 말이다. 중요한 머신을 운영하는 것과 그 머신보다 오래 남을 사본을 갖는 것 사이의 간극은 셀프 호스팅에서 가장 위험한 시기이며, 대부분의 사람은 아무것도 눈치채지 못한 채 그 안에서 몇 달을 산다 — 오랫동안 아무 일도 없다가 어느 순간 모든 것이 한꺼번에 터지기 때문이다. 이 간극을 메우는 일은 어렵지도, 비싸지도 않다. 어렵게 느껴지는 이유는 "백업"이라는 한 단어가 서로 다른 네 가지를 가리키는 데 쓰이고, 그중 정작 최악의 날에 남아 있는 것은 단 하나뿐이기 때문이다.

백업이 아닌 네 가지

이 네 가지는 모두 실제로 유용하고 갖춰 둘 가치가 있다. 다만 그중 무엇도 백업은 아니며, 그렇다고 믿는 것이야말로 사람들이 안전하다고 여겼던 데이터를 잃는 가장 흔한 이유다. 이 구분은 트집 잡기가 아니다 — 이 네 가지는 하나같이, 백업이 가장 필요한 바로 그 상황에서 실패한다.

• RAID는 가동 시간을 지켜줄 뿐, 백업이 아니다. 어레이는 디스크 하나가 죽어도 오프라인이 되지 않고 버티며, 그래서 저희 스토리지 서버는 RAID-6로 구성되어 동시에 두 개까지의 장애를 견딘다. 하지만 삭제된 디렉터리나 잘못된 업그레이드, 누군가 암호화해 버린 파일 트리, 날아간 테이블 앞에서는 버티지 못한다 — 이런 일은 하나같이 모든 디스크에 같은 순간 그대로 기록되기 때문이다.
• 스냅샷은 되돌리기 기능일 뿐, 백업이 아니다. 데이터와 같은 스토리지 위에 놓여 있고, 대개 같은 머신의 root에게 그대로 보이며, 볼륨이나 호스트를 통째로 망가뜨리는 사고는 스냅샷까지 함께 끌고 간다. 되돌리기는 빠르지만, 박스 자체가 사라지면 아무 쓸모가 없다.
• 동기화는 복제일 뿐, 백업이 아니다. 동기화 도구는 애초에 저편을 이편과 똑같이 맞추기 위해 존재하므로, 삭제나 손상도 네트워크가 허락하는 한 가장 빠르게 사본으로 전파된다. Nextcloud, Dropbox, rclone sync 모두 설계상 이렇게 동작한다.
• 버전 관리와 휴지통은 편의 기능일 뿐, 백업이 아니다. 이들은 애플리케이션 자체의 기능으로 애플리케이션 데이터베이스 안에 보관되며, 보존 기간도 며칠 단위로 짧다. 정작 애플리케이션 자체가 고장 나면, 그 안의 이력도 함께 사라진다.
• 같은 서버 위의 사본은 오프사이트가 아니다. 문제가 머신 자체나 제공업체 계정, 하이퍼바이저, 압수처럼 큰 단위에서 터지면, 그 머신 위의 모든 파일은 어느 디렉터리에 있든 같은 장애 범위 안에 있다.

백업이란 공간이 분리되고, 시간이 분리되고, 통제권이 분리된 사본이다. 공간이 분리되어야 화재나 압수가 원본과 사본을 한꺼번에 앗아가지 못한다. 시간이 분리되어야 손상을 그대로 베낀 사본이 아니라 손상되기 이전으로 돌아갈 수 있다. 통제권이 분리되어야 운영 머신에서 훔친 자격 증명으로도 사본에는 손댈 수 없다. 이 셋 중 하나라도 빠졌다면, 그것은 백업의 탈을 쓴 편의 기능일 뿐이다.

3-2-1 규칙, 그리고 2026년에도 통하는 버전

오래된 규칙은 이렇다: 데이터 사본 세 개를, 서로 다른 두 종류의 스토리지에, 그중 하나는 오프사이트에 둔다. 이 규칙이 세월을 잘 버틴 이유는 애초에 테이프에 관한 규칙이 아니라 서로 얽히지 않은 장애에 관한 규칙이기 때문이다. 그 이후로 두 가지가 추가로 자리 잡았는데, 둘 다 이 규칙이 처음 쓰였을 때는 흔치 않았던 일들 때문에 생겨났다.

• 사본 세 개. 운영 중인 데이터에 두 개를 더한다. 사본이 두 개뿐이라면 한 번만 더 장애가 나도 단일 실패 지점이 되며, 단일 실패 지점은 하필 첫 번째 문제를 아직 고치지 못한 사이에 함께 무너지는 습성이 있다.
• 스토리지 두 종류. 하드웨어도 다르고 소프트웨어도 다르며, 가능하다면 제공업체도 다른 편이 좋다. 같은 호스트 위의 볼륨 두 개는 하이퍼바이저와 컨트롤 패널, 계정을 공유하며 — 그 말은 곧 계정을 잃는 방식도 함께 공유한다는 뜻이다.
• 오프사이트 하나. 물리적으로 다른 곳에, 내 인프라가 죽어도 함께 죽지 않는 인프라 위에 둔다. 화재, 도난, 압수, 예고 없는 계정 정지에서 진짜로 힘을 발휘하는 사본이 바로 이것이다.
• 불변이거나 오프라인인 사본 하나. 랜섬웨어도, 루트 권한을 탈취한 침입자도 제일 먼저 백업부터 노린다. 서버가 쓸 수 있는 목적지는 서버가 지울 수 있는 목적지이기도 하다. 추가 전용 자격 증명이나 풀(pull) 방식 설계를 쓰면, 이 재앙이 그저 성가신 일 정도로 줄어든다.
• 검증되지 않은 복원은 0건이어야 한다. 한 번도 복원해 보지 않은 백업은 가설일 뿐이다. 사람들이 가장 많이 건너뛰고 가장 뼈아프게 후회하는 항목이 바로 이것이다 — 2년째 "성공"을 보고해 온 백업 작업이, 사실은 2년째 쓸모없는 아카이브만 쌓아 왔을 수도 있기 때문이다.

무엇을 백업할 것인가: 머신 전체가 아니라 상태

본능적으로는 서버 전체를 이미지로 뜨고 싶어진다. 하지만 대개는 잘못된 접근이다: 이미지 백업은 용량이 크고, 느리고, 일부만 골라 복원하기 번거로우며, 그 안에 담긴 대부분은 어차피 몇 분이면 재설치할 수 있는 기본 운영체제다. 다시 만들어낼 수 없는 것은 상태 — 당신이 직접 한 일 때문에만 존재하는 것들이다.

• 데이터베이스는 복사가 아니라 덤프하라. 엔진이 쓰는 도중에 그대로 복사한 데이터베이스 파일은 찢어진 파일이며, 복원될 수도, 잘못 복원될 수도 있는데 어느 쪽인지 알려주지도 않는다. 엔진 자체의 덤프 도구를 쓰거나, 서비스를 멈추거나, 파일시스템 스냅샷을 뜬 뒤 그로부터 덤프하라.
• 애플리케이션 데이터 디렉터리. 업로드된 파일, 미디어, 생성된 자산 — 데이터베이스가 가리키는 파일 트리다. 반드시 데이터베이스와 같은 시점에 담아야 한다, 그러지 않으면 존재하지 않는 파일을 가리키는 색인만 복원하게 된다.
• 설정, 그리고 손으로 직접 고친 것들. 웹 서버와 리버스 프록시 설정, systemd 유닛, cron 항목, 방화벽 규칙, 새벽 두 시에 손봐 놓고 다시는 기억하지 못할 스무 가지 자잘한 수정 사항까지.
• 비밀 값과 키는 따로, 더 조심스럽게 다뤄라. TLS 인증서와 그 개인 키, SSH 호스트 키, API 토큰, 그리고 무엇보다 지갑 파일과 시드. 이런 것들은 대여한 머신 한 곳에만 있지 않은, 별도의 암호화된 사본을 가질 자격이 있다.
• 컨테이너 정의와 볼륨. compose 파일과 환경 파일에 더해, 이름 붙은 볼륨까지 — 사람들이 잊어버리는 부분이 바로 이것이다. 컨테이너 자체는 다시 만들기 쉽지만, 그 볼륨은 그렇지 않기 때문이다.
• 설치된 것 자체가 아니라 그 목록. 패키지와 버전, 무엇이 어디서 돌아가는지를 짧게 정리한 목록은 루트 파일시스템 전체를 이미지로 뜬 것보다 더 빠르고 더 작게 복원된다.

구분선은 단순하다: 스크립트나 패키지 매니저로 10분이면 다시 만들 수 있다면 백업하지 말고 — 방법만 적어 두어라. 당신이나 사용자가 한 일 때문에만 존재하는 것이라면 사본이 필요하다. 이 원칙은 작은 사이트부터, 지갑과 데이터베이스가 전부이고 나머지는 재설치하면 그만인 BTCPay 인스턴스를 거쳐, 파일 트리와 데이터베이스를 함께 담지 않으면 어느 쪽도 별 쓸모가 없는 Nextcloud 서버까지 그대로 적용된다.

목적지 용량 산정, 그리고 실제로 드는 비용

사람들은 이 비용을 심하게 과대평가하곤 하는데, 보통 첫 전체 사본의 용량을 계산한 뒤 보관하려는 일수만큼 그냥 곱해 버리기 때문이다. 최신 백업 도구는 그렇게 동작하지 않는다. 데이터를 청크로 쪼개서 같은 청크는 한 번만 저장하고, 압축될 것은 압축한다 — 그래서 대부분 변하지 않은 서버의 두 번째 스냅샷은 거의 공짜나 다름없고, 매일 서른 번 찍은 스냅샷도 첫 스냅샷의 서른 배 근처에도 가지 않는다.

• 평범한 속도로 변하는 서버에서 일반적인 보존 정책을 쓴다면, 대략 운영 중인 상태의 용량에 이력 보관분으로 30~50퍼센트를 더한 만큼을 예산으로 잡아라.
• 용량 증가를 좌우하는 것은 빈도가 아니라 보존 기간이다. 이틀치만 보관하는 매시간 스냅샷이, 3년치를 보관하는 매일 스냅샷보다 더 저렴하다. 실제로 어디까지 거슬러 갈 일이 있을지 정한 뒤, 그 지점까지 자동으로 잘라내라.
• 이미 압축된 데이터는 다시 압축되지 않는다. 동영상, 사진, 아카이브, 암호화된 덩어리는 원본 크기에 가깝게 남으므로, 미디어가 많은 서버라면 영리한 설정이 아니라 진짜 용량이 필요하다.
• 데이터베이스는 덤프끼리 중복 제거가 잘 되지 않는다. 살짝만 달라진 데이터베이스라도 압축된 덤프는 완전히 다른 바이트 스트림이 되기 때문이다. 압축하지 않은 채로 덤프하고 압축은 백업 도구에 맡기면, 스토리지 비용이 크게 줄어든다.
• 느린 부분은 첫 업로드뿐이다. 그 이후로는 매일 밤 실행되는 작업이 변경분만 옮기며, 대부분의 서버에서 그 양은 몇 메가바이트에 지나지 않는다. 여기서는 전송량이 무제한이므로, 첫 업로드는 예산이 아니라 인내심의 문제다.

실제로 이것은 당신의 스택 전체에서 가장 저렴한 보험이다. 스토리지 서버는 월 $7.99부터 RAID-6 구성으로 1 TB를 주는데, 이는 VPS 몇 대의 상태를 다 합친 것보다도 훨씬 넉넉한 용량이며, 월 $12.99의 STO-2는 그 두 배를 준다. 미디어 라이브러리와 긴 보존 기간에서는 용량이 진짜로 중요해진다: 월 $22.99의 STO-4는 4 TB를, 월 $39.99의 STO-8은 8 TB를 준다. 목적지는 rsync, SFTP, S3 호환 API를 지원하므로 웬만한 백업 도구는 플러그인 없이도 곧바로 붙으며, 볼륨은 저장 시 AES-256으로 암호화되고 직접 키를 가져와 쓰는 것도 지원한다 — 다만 다음 절에서 설명하듯, 어차피 데이터가 소스를 떠나기 전에 암호화해 두는 편이 좋다.

도구 고르기: 각각이 실제로 무엇을 위한 것인가

여기서 고민을 오래 할 필요는 없다. 도구 세 가지면 사실상 모든 경우를 커버하고, 셋 다 무료이며, 이들 사이의 차이는 하나라도 쓰느냐 마느냐의 차이에 비하면 사소하다. 벤치마크가 아니라 당신의 문제 모양에 맞춰 고르면 된다.

• restic — 대부분의 서버에 기본으로 추천하는 도구. 클라이언트 측에서 암호화하고, 중복을 제거하며, 데몬 없이 정적 바이너리 하나로 끝난다. SFTP, S3 호환 엔드포인트, 일반 디렉터리에 그대로 쓸 수 있다. 추가 전용(append-only) 모드는 침해당한 서버조차 지울 수 없는 목적지로 가는 가장 쉬운 길이다.
• BorgBackup — 중복 제거와 압축이 뛰어나고, 느린 회선에서도 매우 효율적이며, 오래 검증되어 성숙한 도구다. 원격 저장소를 쓰려면 목적지에도 자체 에이전트가 있어야 하는데, 스토리지를 눈에 띄게 아낄 수 있다는 점을 생각하면 감수할 만한 작은 제약이다.
• rclone — 오브젝트 스토어 사이에서 데이터를 옮기는 것이 본업이거나, 버전 이력이 아니라 미러가 필요할 때 맞는 도구다. 직접 쓴다면 자체 crypt 레이어와 함께 써라, 그리고 일반 동기화는 삭제도 그대로 전파한다는 점을 기억하라.
• 데이터베이스에는 언제나 엔진 자체의 덤프 도구를 써라. mysqldump, pg_dump와 그에 준하는 도구는 엔진이 확실히 다시 읽어 들일 수 있는, 일관된 논리적 사본을 만들어 낸다. 파일로 덤프한 다음 그 파일을 restic이나 Borg가 집어 가게 하라 — 영리한 파일 단위 복사로 덤프를 대신하려 하지 마라.
• 제공업체 스냅샷은 빠른 로컬 계층으로만 써라. 위험한 업그레이드 전후로 빠르게 되돌리기 위해 찍어 두되, 이를 세 사본 중 하나로 세지는 마라.

단계별 안내: 한 번에 끝내는 실제로 작동하는 암호화 백업

1. 01목적지를 배포하고 먼저 잠그기보호 대상 서버들과는 다른 리전에 스토리지 서버를 둔다. 키 전용 SSH, 전용 사용자 계정, 그리고 여기에 쓰게 될 머신들의 자격 증명을 재사용하지 않는다.
2. 02도구를 건드리기 전에 상태 목록부터 정하기반드시 살아남아야 할 모든 경로와 모든 데이터베이스를 적어 둔다. 지금 텍스트 파일 하나에 10분을 들이면, 나중에 아무도 적어두지 않은 디렉터리 하나를 복원 도중에 발견하는 사태를 막을 수 있다.
3. 03암호화된 저장소 초기화하기강력한 저장소 비밀번호를 생성하고, SFTP나 S3 위에 저장소를 초기화한 뒤, 그 비밀번호는 백업 대상 서버가 아닌 곳에 보관한다. 키가 죽어버린 머신에만 있는 저장소는 복구할 수 없다.
4. 04먼저 데이터베이스를 덤프한 다음 아카이브하기각 데이터베이스를 스테이징 디렉터리에 덤프한 뒤, 그 덤프와 파일 트리 전체에 대해 백업을 한 번에 실행하는 래퍼 스크립트를 만든다. 이 순서가 데이터베이스와 파일을 서로 일치시켜 준다.
5. 05첫 백업을 실행하고 끝까지 지켜보기처음 한 번이 가장 오래 걸린다. 연결이 끊겨도 죽지 않도록 터미널 멀티플렉서 안에서 실행하고, 걸린 시간을 적어 두어라 — 이제 복원에 걸리는 시간도 함께 알게 된 셈이다.
6. 06보존 기간을 정하고 자동으로 정리하기매일 7개, 매주 4개, 매달 6개 정도의 스냅샷이면 대부분의 서버에 충분하다. 같은 작업 안에 정리(prune)까지 설정하라, 그러지 않으면 저장소는 언젠가 멈출 때까지 계속 불어난다.
7. 07일정을 등록하고, 실패는 시끄럽게 만들기매일 밤 실행되는 타이머나 cron 항목에, 작업이 성공을 보고하지 않을 때 울리는 알림까지 더한다. 조용히 있는 백업 작업은, 눈치채기까지 걸리는 몇 달 동안은 백업이 아예 없는 것과 구별되지 않는다.
8. 08오늘 당장, 다른 머신에서 백업으로부터 뭔가를 복원해 보기아카이브 목록을 보는 것으로는 부족하다 — 실제 파일 하나와 실제 데이터베이스 하나를 임시 서버에 진짜로 복원해 보아야 한다. 이것을 한 번이라도 해 보기 전까지, 당신이 가진 것은 백업이 아니라 백업 스크립트일 뿐이다.

서버를 죽인 바로 그 사건에서도 사본을 살아남게 하기

이 부분이 백업과, 공격자에게 그저 성가신 존재를 가르는 지점이다. 서버가 백업을 지울 수 있는 자격 증명을 쥐고 있다면, 루트 권한 탈취든 랜섬웨어든 잘못된 스크립트 한 줄이든 같은 순간에 두 사본 모두에 손을 댈 수 있다. 해법은 더 강한 비밀번호가 아니라 구조 자체에 있다.

• 소스 쪽에는 추가 전용 자격 증명을 써라. restic과 Borg 모두 쓰는 쪽 머신이 새 스냅샷은 만들 수 있어도 기존 스냅샷은 지우거나 정리할 수 없는 모드를 지원한다. 정리는 다른 곳에서, 별도의 키로, 일정에 따라 실행하면 된다.
• 가능하다면 풀(pull) 방식 설계를 택하라. 소스가 밀어 넣는 대신 목적지가 소스에 손을 뻗어 가져오는 구조라면, 소스는 아카이브에 대한 자격 증명을 아예 쥔 적조차 없게 된다.
• SSH 키나 저장소 비밀번호를 여러 서버에 걸쳐 재사용하지 마라. 머신 하나가 침해되면 그 머신 하나의 백업만 잃어야지, 보유한 인프라 전체를 잃어서는 안 된다.
• 적어도 사본 하나는 다른 관할권, 다른 장애 범위에 두어라. 리전을 분산시키는 것은 과민 반응이 아니다 — 하드웨어 사고 하나로 끝나느냐, 전부를 잃느냐를 가르는 차이다.
• 저장소 키는 인프라 바깥에 완전히 따로 보관하라. 비밀번호 관리자, 하드웨어 토큰, 금고 속 종이 — 그 저장소가 보호하는 머신들만 아니면 어디든 좋다.
• 수상할 만큼 빨리 "성공"하기 시작한 백업을 눈여겨보라. 예전엔 20분 걸리던 작업이 이제 40초 만에 끝난다면, 대개 비어 있거나 마운트되지 않은 디렉터리를 백업하고 있는 것이며, 그러면서도 계속 성공을 보고할 것이다.

여기서 리전 선택은 사소한 디테일이 아니라 진짜 결정이다. 백업과 운영 서버가 하나의 조치로 함께 압수될 수 있어서는 안 되기 때문이다. 운영 대상에 이것이 중요하다면 위치를 의도적으로 고르는 일에 몇 분을 들일 가치가 있으며, 목적지를 소스와는 다른 법적 체계 안에 두는 것이야말로 이 작업 전체의 핵심이다.

복원: 아무도 미리 연습하지 않는 부분

복원은 시시한 이유로 실패하며, 하필 최악의 순간에 실패한다 — 대부분의 사람이 복원을 시도하는 때가 바로 그 순간뿐이기 때문이다. 아래의 실패는 하나같이 훈련 중이라면 몇 분 만에 드러나지만, 실제 장애 중이라면 몇 시간이 걸려서야 드러난다.

• 저장소 비밀번호가 죽어버린 그 서버에만 있어서, 아카이브는 멀쩡하지만 영영 읽을 수 없다.
• 데이터베이스는 복원됐지만 파일 트리는 세 시간 뒤에 실행된 백업에서 가져와서, 애플리케이션이 존재하지 않는 파일을 가리키는 레코드를 보여준다.
• 백업이 어느 순간 조용히 마운트가 풀린 디렉터리를 그대로 담아서, 1년 내내 매일 밤 빈 폴더를 성실하게 아카이브해 왔다.
• 복원 순서를 아무도 몰라서 — 데이터베이스가 먼저인지 파일이 먼저인지, 서비스를 멈추고 할지 켠 채로 할지 — 절반만 복원된 상태를 버리고 처음부터 다시 시작해야 했다.
• 복원이 실제 회선으로 11시간이 걸리는데, 아무도 그 시간을 측정해 본 적이 없었고, 복구 계획은 1시간이면 될 거라고 가정하고 있었다.
• 파일 소유권과 권한이 잘못 복원되어서, 모든 것이 다 있는데도 애플리케이션이 시작을 거부한다.
• 테스트해 본 것은 가장 최신 스냅샷뿐인데, 정작 복구해야 할 손상은 6주 전부터 시작되어 있었다.

1년에 두 번 하는 훈련이 이 모든 것을 바로잡는다. 한 번 쓰고 버릴 VPS를 배포하고, 실제 저장소에서 그 안으로 복원하고, 서비스를 켜고, 데이터를 확인한 뒤, 머신을 없애라. 몇 달러와 한 시간이면 되는 일이며, 이것으로 백업 시스템 전체가 믿음에서 사실로 바뀐다. 런북을 펼쳐 놓은 채 한 번 해 보고, 런북이 거짓말한 부분은 그때그때 고쳐라.

프라이버시 계층: 백업이 당신의 익명성을 무너뜨릴 수 있다

이 항목은 오프쇼어로 운영할 때만 해당하며, 첫 업로드 이후가 아니라 이전에 미리 생각해 두어야만 제대로 다룰 수 있다. 백업이란 당신의 인프라를 완전하고, 색인까지 되어 있고, 오래 남는 형태로 다른 어딘가에 그대로 옮겨 놓은 것이다. 그래서 원본과 똑같이 민감하면서도, 원본보다 훨씬 잊어버리기 쉽다.

• 파일명과 디렉터리 구조는 내용이 암호화되어 있어도 그 자체로 메타데이터다. restic과 Borg의 클라이언트 측 암호화는 이름까지 감춰 주지만, 단순한 rsync 미러는 그렇지 않다. 디렉터리 목록 하나만으로도 이 서버가 무엇이고 누가 운영하는지 알아내기에 충분한 경우가 많다.
• 목적지 계정도 이 이야기의 일부다. 본명 카드로 대여한 백업 볼트는, 소스 머신을 아무리 깨끗하게 유지했어도 그 볼트가 담고 있는 모든 것에 당신의 이름을 붙여 버린다.
• 백업 트래픽은 두 주소 사이를 잇는, 지속적이고 예약되어 있으며 대용량인 연결이다. 서버가 만들어 내는 패턴 중에서도 유난히 읽기 쉬운 축에 속하며, 매일 밤 어김없이 목적지를 가리킨다.
• 오래된 스냅샷은 그것을 만든 결정보다 오래 살아남는다. 1년 전에 더는 저장하지 않기로 한 무언가도, 보존 정책이 한 번도 정리하지 않았다면 여전히 아카이브 안에 있다. 이는 복구에는 좋은 특성이지만, 노출에는 나쁜 특성이다.
• 로그와 셸 히스토리도 다른 모든 것과 함께 쓸려 들어간다. 운영 머신에서는 그토록 조심했던 IP 주소, 명령어, 자격 증명이 아카이브 안에는 그대로 담겨 있는 경우가 흔하다.

해법은 평범하다. 내용뿐 아니라 이름까지 암호화하는 도구를 써라. 목적지도 소스를 대여했던 것과 같은 방식으로 빌려라 — 당신이 누구인지 물은 적 없는 호스트에서, 암호화폐 잔액으로 결제하고, 결제 흔적까지 지우고 싶다면 Monero 충전을 써라. 트래픽 패턴 자체가 신경 쓰인다면 전송을 WireGuard 터널을 통해 보내라. 그리고 운영 서버에 적용했던 것과 똑같은 첫 10분 하드닝을 스토리지 박스에도 적용하라. 모든 것의 사본을 쥐고 있는 머신은 원본보다 가치가 낮은 표적이 아니라, 오히려 더 높은 표적인 경우가 많기 때문이다.

사람들이 데이터를 잃게 만드는 실수들

• RAID나 스냅샷, 동기화 폴더를 백업으로 믿었다가, 정작 중요한 날에야 그것들이 어느 범주였는지 알게 되는 경우.
• 유일한 사본을, 보호하려는 대상과 같은 서버나 같은 계정, 같은 제공업체 위에 두는 경우.
• 데이터베이스를 덤프하지 않고 파일 그대로 복사했다가, 미묘하게 조용히 잘못된 아카이브를 복원하는 경우.
• 파일 트리와 데이터베이스를 서로 다른 시점에 백업해서, 복원 시 둘이 서로 맞지 않는 경우.
• 저장소 비밀번호를, 그 저장소가 보호하는 바로 그 머신에 저장해 두는 경우.
• 소스에 목적지에 대한 완전한 삭제 권한을 줘서, 침해 한 번이 아카이브까지 함께 끌고 가는 경우.
• 한 번도 정리하지 않다가, 목적지가 가득 차서 매일 밤 작업이 몇 주째 조용히 실패하고 있었음을 알게 되는 경우.
• 수백 기가바이트의 공개 블록체인 데이터는 백업하면서, 정작 지갑 파일은 어느 아카이브에도 들어 있지 않은 경우.
• 실패에 대한 알림은 설정해 두었지만 실행 자체가 없어진 경우에 대한 알림은 두지 않아서, 아예 돌지 않게 된 작업이 아무것도 보고하지 않는 경우.
• 가장 최신 스냅샷만 테스트하다가, 실제 장애 중에야 손상이 그보다 더 이전부터 있었다는 것을 알게 되는 경우.

백업은 당신이 설정할 것 중 가장 흥미롭지 않으면서도, 없으면 되돌릴 수 없는 유일한 것이다. 서버 위의 다른 모든 것은 패키지 매니저와 오후 한나절이면 다시 지을 수 있다. 상태는 그럴 수 없다. 여기에 한 번만 제대로 시간을 들여라: 살아남아야 할 것을 목록으로 적고, 데이터베이스를 덤프하고, 암호화된 아카이브를 다른 나라의 스토리지 서버로 보내고, 일정에 따라 정리하고, 조용해지면 알림이 울리게 하고, 터미널을 닫기 전에 진짜로 무언가를 복원해 보아라. 그러고 나면 그냥 내버려 두어라. 좋은 백업 시스템의 척도는, 그것이 존재한다는 사실조차 잊고 지내다가 어느 날 아침 재앙을 그저 조금 성가신 한 시간으로 바꿔 놓을 때 비로소 깨닫게 된다는 것이다.