실제로 복구되는 VPS 백업

백업 전략은 서버가 죽는 밤에 처음 시험받는 것이 아니다. 그보다 몇 주 전, 아무도 적어두지 않는 세 가지 조용한 결정에서 이미 판가름 난다. 복사본을 어디에 둘 것인가, 그것을 지울 권한을 누구에게 줄 것인가, 그리고 실제로 그것을 복원해 본 사람이 있는가.

신원을 묻지 않는 호스팅은 그 대가로 무언가를 포기하게 만들며, 여기서 솔직히 말해두는 편이 낫다. 전화를 걸 담당자도 없고, 삭제된 볼륨을 되살려 주는 티켓도 없다. 자체 보존 정책은 그 이유를 분명히 밝힌다. 서버 데이터는 해지 후 24시간 이내에 파기되고, 디스크는 포맷이 아니라 암호학적으로 완전히 지워지며, 백업은 일절 보관되지 않는다. 이는 이 플랫폼을 구매할 가치가 있게 만드는 바로 그 특성을, 반대편에서 바라본 것일 뿐이다. 최악의 밤을 겪은 뒤에도 되찾고 싶은 것이 있다면, 그것은 이미 다른 곳에 있어야 하며, 그곳에 옮겨두는 사람은 바로 당신이다.

서버를 실제로 파괴하는 것

서버를 잃는 방식은 사람들이 상상하는 것과 거의 다르다. 하드웨어의 치명적 고장은 실제로 일어나지만 드물고, 유능한 호스트라면 이미 그에 대비해 설계해 둔 유일한 경우이기도 하다. 실제로 발생하는 손실은 훨씬 더 평범하며, 각각이 서로 다른 종류의 복사본을 무력화한다. 그래서 "백업이 있다"는 말은 그것이 어떤 상황을 견뎌내는지 말하기 전까지는 답이 되지 못한다.

이 표는 두려움의 목록이 아니라 점검표로 읽어야 한다. 같은 서버 안의 두 번째 디스크에 매일 밤 복사하는 것은 첫 번째 행만 답할 뿐이다. 같은 패널 안의 스냅숏은 첫 번째와 두 번째 행에 답한다. 서버가 닿을 수 없는 곳에, 지금도 갖고 있는 키로 보관된 복사본만이 다섯 가지 모두에 답한다.

스냅숏은 백업이 아니고, 당신의 호스트도 백업이 아니다

스냅숏은 자기 역할에는 탁월하다. 잘못된 업그레이드를 전송 없이 몇 초 만에 되돌린다. 스냅숏이 할 수 없는 것은 서버 자체를 앗아간 사건에서 살아남는 일이다. 같은 공급자, 같은 계정, 같은 결제 토큰, 같은 국가, 흔히 같은 스토리지 클러스터까지 모든 장애 영역을 서버와 공유하기 때문이다. 스냅숏은 당신 자신으로부터 지켜주고, 백업은 그 밖의 모든 것으로부터 지켜준다.

이 구분은 일반적인 호스트보다 여기서 더 중요하다. 흔히 있는 안전장치들이 의도적으로 제거되어 있기 때문이다. 고객 서버에 로그인하는 사람이 없으니 3월부터 백업 작업이 실패하고 있어도 아무도 알아채지 못한다. 계정에 연결된 신원이 없으니 "본인임을 증명하면 복원해 드리겠다"는 사람의 손을 거친 경로도 없다. 그리고 해지는 말 그대로 최종적이다. 잔액이 만료되는 것은 결제 문제가 아니라 데이터 손실 사건이다.

신분증을 보여준 적 없는 사람들을 위한 3-2-1 원칙

고전적인 규칙은 세 개의 복사본을, 두 종류의 매체에, 그중 하나는 오프사이트에 두라고 말한다. 이는 테이프와 회전 디스크의 시대에 쓰인 것이라, 매체에 관한 조항은 어느새 아무 의미도 없어졌다. 프로덕션 디스크도 NVMe, 백업 대상 디스크도 NVMe이니 이를 "두 매체"라고 부르는 것은 자기 자신에게 하는 이야기일 뿐이다. 지켜야 할 조항은 거리에 관한 것이며, 역외 인프라에서 거리는 킬로미터로 재지 않는다.

세 개의 복사본, 두 개의 공급자, 두 개의 관할권으로 다시 쓰자. 두 복사본을 동시에 앗아가는 실패는 물리적인 경우가 거의 없다. 접근 권한을 잃은 계정, 힘든 한 주를 보낸 공급자, 한 나라에는 미치지만 다른 나라에는 미치지 않는 법적 조치 같은 것들이다. 같은 랙 안의 두 서버는 절차만 하나 더 붙은 하나의 복사본이고, 같은 법체계 아래의 두 서버도 크게 나을 것이 없다. 관할권 가이드에서 첫 번째와 노출 위험이 겹치지 않는 두 번째 관할권을 고르는 방법을 다룬다.

실제로는 비용도 얼마 들지 않는다. 백업 대상은 코어가 필요 없고 네트워크도 거의 필요 없다. 필요한 것은 디스크와 주소뿐이다. 가장 작은 VPS 등급이라도 우리의 일곱 개 지역 중 다른 곳에 있다면 restic이나 Borg의 훌륭한 엔드포인트가 되며, 테라바이트 단위 아카이브라면 실제 드라이브를 갖춘 전용 서버가 어떤 오브젝트 스토리지보다 테라바이트당 비용이 저렴하다. 데이터가 정말로 크고 거의 읽히지 않는 경우, 경제성은 압도적으로 베어메탈 쪽으로 기운다.

많은 사람이 프로덕션에서는 제대로 하면서 백업 대상에서는 놓치는 것이 하나 있다. 바로 같은 방식으로 결제하는 것이다. 본인 명의 카드로 산 두 번째 서버는 첫 번째 서버에서 애써 떼어낸 신원을 조용히 다시 붙여 놓으며, 이제 그 서버는 모든 것의 완전한 복사본까지 쥐고 있다. 프로덕션 서버를 모네로로 결제했다면 백업 서버도 똑같이 대우받아야 한다.

대부분의 사람이 건너뛰는 세 번째 복사본은, 원격 실패를 한꺼번에 겪어도 유일하게 무사한 복사본이다. 물리적으로 손에 쥔 디스크를 이따금 갱신하고 오프라인으로 보관하는 것이다. 대부분의 사람에게는 한 달에 한 번이면 충분하다. 커피 한 잔 값의 관심만 들이면 되고, 다른 두 복사본이 함께 무너지는 시나리오에서도 살아남는 복사본이다.

Push, Pull, 그리고 하룻밤의 사고가 두 복사본을 한꺼번에 삼키는 실수

거의 모든 사람이 처음 만드는 구성은 이렇다. 프로덕션 서버에서 매일 밤 작업이 실행되어 백업 대상의 키나 토큰을 쥔 채 접속하고 데이터를 밀어 넣는다(push). 이 방식은 잘 작동하고 간단하지만, 서버 인생 최악의 날에야 비로소 드러나는 성질이 하나 있다. 프로덕션 서버를 장악한 자가 백업도 함께 장악한다는 것이다.

이것은 가정이 아니다. 자신의 존재를 알리기 전에 피해자의 백업부터 지우거나 암호화하는 것은 이를 상업적으로 하는 이들의 표준 절차이며, 자격 증명은 cron 작업이나 환경 파일 안에 그대로 놓여 있어 찾는 데 1분도 걸리지 않는다. 공격자가 지울 수 있는 복사본은 두 번째 복사본이 아니다. 그것은 지연 시간이 붙은 첫 번째 복사본의 거울일 뿐이다.

깔끔한 해법은 두 가지이며, 이미 해두었어야 할 기본 하드닝과도 잘 어우러진다.

• 추가 전용(append-only) 대상. 두 주요 도구 모두 클라이언트가 데이터를 추가할 수는 있지만 지울 수는 없는 모드를 지원한다. Borg는 대상 쪽 SSH 키를 borg serve --append-only로 고정해 이를 구현하고, restic은 --append-only로 시작한 REST 서버로 구현한다. 프로덕션 서버는 매일 밤 쓰기만 할 뿐, 구조적으로 이력을 파괴할 능력 자체가 없다. 오래된 스냅숏 정리는 그다음 대상 쪽에서, 프로덕션 서버가 시작할 수 없는 세션 안에서 이루어진다.
• Push 대신 Pull. 방향을 뒤집는다. 백업 호스트가 프로덕션에 접속해 읽고 저장한다. 프로덕션은 대상에 대한 자격 증명을 전혀 갖지 않으므로 훔칠 것이 없다. 프로덕션 쪽에서 쓰는 키는 restrict와 강제된 command=로 제한해, 훔친 백업 키가 셸로 이어지지 못하게 한다.

Pull이 더 강력한 모델이지만 운영에 품이 조금 더 들고, 이미 Borg나 restic을 쓰고 있다면 추가 전용은 거의 공짜다. 둘 중 무엇을 택하든 "공격자가 내 백업을 지웠다"는 결과가 아니라 시도로 그친다. 이 가이드에서 하나만 가져간다면 바로 이 절이어야 한다.

원본에서 암호화하고, 키는 누가 쥘지 정하라

제대로 된 두 도구는 네트워크를 건너기 전에 백업 대상 서버에서 먼저 암호화한다. 대상은 자신이 해석할 수 없는 블롭만을 저장하며, 바로 이 점이 다른 공급자로의 복사본을 안전하게 만든다. 두 번째 호스트는 신뢰할 만하거나 친근할 필요가 없다. 접근 가능하고 디스크가 있으면 그만이다. 바로 이 하나의 성질이 "아무것도 모르는 나라의 서버"를 위험에서 인프라로 바꿔 놓는다.

이는 서버 자체의 디스크를 암호화하는 것과는 다른 메커니즘이며, 두 가지는 서로 다른 질문에 답한다. VPS 전체 디스크 암호화 가이드는 서버가 켜져 있는 동안 디스크 암호화가 무엇을 지키고 무엇을 지키지 못하는지를 다룬다. 백업 암호화는 둘 중 더 쉽고 더 값진 쪽이다. 위협 모델이 정직하기 때문이다. 데이터는 정지 상태로, 당신이 통제하지 않는 하드웨어 위에 있고, 키는 그곳에 결코 가지 않는다.

그리고 이는 위험 전체를 키 관리 문제로 옮겨 놓는다. 이제 암호구는 완전한 손실을 일으키는 단일 지점이 되며, 사람들이 예상하는 것보다 더 나쁜 단일 지점이다. 잃어버려도 조용하기 때문이다. 아무것도 깨지지 않고 백업은 계속 돌아가며, 정작 필요한 바로 그 순간에야 알게 된다. 이를 고치는 습관은 세 가지다.

• 암호구는 서버에 root만 읽을 수 있는 파일로만 두고 --password-file로 참조해, 프로세스 목록이나 셸 기록에 절대 나타나지 않게 한다.
• 사람이 읽을 수 있는 사본을 관련된 모든 기기 밖에도 보관하라. 서랍 속 종이 한 장이, 당신도 접근을 잃을 수 있는 계정에 동기화되는 비밀번호 관리자보다 정말로 낫다.
• 저장소에 두 번째 키를 추가하라. restic key add나 내보낸 Borg 키면 된다. 그러면 암호구 하나를 잊어도 아카이브의 끝이 아니라 사소한 불편으로 끝난다.

세 가지 모두를 관통하는 규칙은 이렇다. 키의 유일한 사본이, 백업이 대신하기 위해 존재하는 바로 그 서버에만 있다면, 당신에게는 백업이 없다. 있는 것은 암호화된 블록 더미와 그것에 관한 이야기뿐이다.

도구 선택, 표 하나로 정리

도구 선택은 연결 방향이나 키 상태보다 덜 중요하다. 그래서 첫 번째가 아니라 여섯 번째로 다루는 것이다. 그렇다고 차이가 없는 것은 아니며, 작업에 맞지 않는 형태를 고르면 나중에 일이 늘어난다.

서버 한 대뿐이라면 두 번째 VPS로의 restic이 가장 확실하게 가는 지름길이다. 시드박스나 미디어 아카이브처럼 비슷한 대용량 파일이 많은 경우, Borg의 중복 제거는 디스크가 꽉 차는 것과 여유로운 것의 차이를 만든다. 시드박스 가이드에서 이런 작업 부하의 스토리지 측면을 더 자세히 다룬다.

실행 중인 것은 파일이 아니다

세상에서 가장 흔한 손상된 백업은 살아 있는 데이터베이스를 그대로 파일 복사한 것이다. 오류 없이 끝나고, 크기도 딱 맞으며, 복원하면 엔진이 열기를 거부하는 테이블이 나온다. 복사가 지나가던 순간 데이터베이스는 한창 쓰기 중이었다. 당신이 저장한 것은 페이지가 넘어가는 순간의 사진일 뿐이다.

빠져나가는 방법은 세 가지이며, 품이 드는 순서대로 나열하면 이렇다. 덤프하기: mysqldump --single-transaction은 쓰기 작업을 잠그지 않고도 일관된 InnoDB 덤프를 주고, pg_dump는 PostgreSQL에서 같은 일을 한다. 스냅숏 뜨기: 파일시스템을 멈추거나 LVM 또는 ZFS 스냅숏을 떠서 그 스냅숏에서 복사한 뒤 풀어준다. 매일 밤 덤프하기에는 너무 큰 데이터셋을 다룰 때 쓰는 방법이다. 아니면 멈추기: 작은 서비스라면 새벽 4시의 2분짜리 다운타임이 더할 나위 없이 훌륭한 일관성 전략이며, 예외 상황이 전혀 없는 유일한 방법이다.

같은 논리는 데이터베이스를 넘어서도 이어진다. 컨테이너의 쓰기 가능 레이어는 버려도 되지만 볼륨은 그렇지 않으며, 그 옆의 docker compose 파일과 환경 변수도 마찬가지다. 데이터는 복원하지만 정의는 복원하지 못하는 백업은 결국 스택을 기억에 의존해 재구성하게 만든다. 메시지 큐, 영속성을 켠 Redis, MTA가 쓰고 있는 메일 스풀도 모두 같은 대우를 받아야 한다. 멈추거나 스냅숏을 뜨거나 덤프하되, 그대로 복사해 놓고 무사하길 바라지는 말라.

무엇을 백업할 것인가, 그리고 다들 잊는 부분들

대부분의 사람은 뻔한 대상, 즉 데이터베이스와 애플리케이션 디렉터리만 백업하고 나머지는 압박 속에서 손으로 다시 만든다. 시간이 잡아먹히는 곳은 바로 이 재구성 단계다. 올바른 데이터 더미가 아니라 실제로 작동하는 시스템으로 되돌려 주는 백업은 이 지루한 층까지 포함한다.

• /etc 전체, 직접 작성한 systemd 유닛과 타이머, 그 밖에 있는 모든 crontab.
• TLS 인증서와 그 개인 키, 최소한 ACME 계정 키만이라도 있어야 인증서가 처음부터 다시 시작하지 않고 갱신된다.
• 방화벽 규칙과 패키지 목록. 이 둘을 합치면 어떤 기억보다도 빠르게 서버의 형태를 되살릴 수 있다.
• 애플리케이션 시크릿과 환경 파일. 코드 저장소에서 의도적으로 제외된 것들이라 다른 어디에도 남아 있지 않다.
• 텍스트로 내보낸 DNS 레코드. 리버스 DNS와 PTR 항목까지 포함되며, 이는 서버가 아니라 공급자 쪽에 있는 것들이다.

시험해 보지 않은 복구는 소문일 뿐이다

백업 소프트웨어는 스스로에 대해 보고하는데, 정직하게 보고하는 대상이 엉뚱하다. "스냅숏 완료"는 저장소에 데이터가 쓰였다는 뜻일 뿐이다. 그 저장소를 이 서버가 아닌 다른 기기에서, 11개월 전에 무엇을 설정했는지 기억하지 못하는 사람이 읽을 수 있는지에 대해서는 아무 말도 해주지 않는다.

먼저 저렴한 무결성 검사부터 시작하라. 일정을 잡아 restic check --read-data-subset=5%나 borg check --verify-data를 돌리되, 이는 아카이브를 검증할 뿐 당신이 그것을 실제로 쓸 수 있는지는 검증하지 못한다는 점을 알아두라. 진짜 훈련은 다르며, 한 번 오후 시간을 들이면 된다. 평소 쓰지 않는 지역에 시간 단위로 새 서버를 하나 주문한다. 저장소 주소와 암호구, 그리고 당신의 메모만으로 그 위에 복원한다. 서비스를 띄운다. 전체 과정의 시간을 잰다. 그런 다음 그 서버를 없앤다. 총비용은 몇 달러이며, 이는 당신이 신뢰할 수 있는 숫자를 만들어내는 유일한 훈련이다.

이 훈련이 확실하게 드러내는 것은 데이터가 아니다. 아무도 적어두지 않은 빠진 패키지, 백업 경로 밖에 살고 있던 설정, 지금 대체하려는 바로 그 서버의 셸 기록에만 존재했던 암호구, 저장소 형식을 읽을 수 있는 도구 버전, 이런 것들이다. 이 모두는 미리 고치기는 아주 쉽지만 장애 도중에 발견하기는 비참하다.

이 훈련이 알려주는 두 숫자를 적어 두라. 복구에 걸린 시간, 그리고 그 일정이 잃을 수 있는 작업량. 이 둘이 곧 백업 정책이다. 위의 모든 것은 그 둘을 위한 구현 세부사항일 뿐이다.

계속 돌아가도록 자동화하기

작업은 cron이 아니라 systemd 타이머로 실행하라. 로그가 한곳에 모이고, 마지막 실행에 대한 실제 기록이 남으며, 재부팅에도 살아남는 일정을 얻는다. cron은 추가 작업 없이는 이 중 어느 것도 주지 않는다. 암호구는 유닛 파일 자체에 넣지 마라. 셸 접근 권한이 있는 사람이라면 누구나 systemctl cat만으로 그대로 읽을 수 있다.

그다음으로, 사람들을 실제로 당황시키는 실패 양상을 해결하라. 오류가 아니라 침묵이다. 6주 전에 멈춘 백업은 완벽하게 실행된 백업과 똑같아 보인다. 둘 다 아무 출력도 내지 않기 때문이다. 실패가 아니라 부재를 경보하라. 작업이 성공할 때마다 모니터에 핑을 보내게 하고, 그 핑이 도착하지 않을 때 모니터가 불평하게 하라. 그리고 그 모니터는 감시 대상 서버가 아닌 다른 곳에 두어라. 다운된 서버는 자신이 다운되었다고 보고할 수 없기 때문이다.

기본값에 맡기지 말고 보존 기간을 의도적으로 정하라. --keep-daily 7 --keep-weekly 4 --keep-monthly 6 같은 설정이면 오늘 밤 알아챌 실수와 봄이 되어서야 알아챌 손상을 모두 커버하면서도 무한정 늘어나지 않는다. 추가 전용으로 전환했다면 정리(pruning)는 대상 쪽에서 실행하라. 그것이 애초에 추가 전용으로 전환한 이유다. 우리 네트워크에서는 전송량이 병목이 되는 경우가 거의 없다 — 모든 플랜에서 대역폭이 무제한이므로 할당량이 아니라 일관성을 기준으로 일정을 짜고, 조용한 시간대에 맞춰 타이밍을 확인하라. 이 모든 것을 둘러싼 더 넓은 습관은 서버 OpSec 가이드에서 다룬다.

요약

이 페이지에서 다른 것은 다 잊더라도 이 여섯 가지만은, 대략 이 순서로 하라.

• 복사본 하나를 두 번째 공급자, 두 번째 관할권에 두고, 첫 번째와 같은 방식으로 프라이버시를 지키며 결제하라.
• 그 복사본을 추가 전용으로 만들거나 대상 쪽에서 끌어오게(pull) 하여, 침해된 서버가 그것을 파괴할 수 없게 하라.
• 도구가 원본에서 암호화하게 두고, 키는 관련된 두 서버 모두에서 떼어 놓아라.
• 데이터베이스는 덤프하고, 실행 중인 것은 무엇이든 멈추거나 스냅숏을 떠라. 살아 있는 상태를 그대로 복사하지 마라.
• 정체성 키(onion, WireGuard, DKIM, 노드 시드)는 따로 백업하라. 이것들은 다시 만들어낼 수 없기 때문이다.
• 일회용 서버 위에 한 번 복원해 보고, 시간을 재고, 무엇이 빠졌는지 적어 두라.

이 중 어느 것도 특별하지 않고, 주말을 통째로 잡아먹지도 않는다. 오후 한나절의 설정과 한 번의 훈련이면, 프로젝트를 끝장내는 종류의 손실을 막을 수 있다. 당신에 대해 아무것도 의도적으로 남기지 않는 플랫폼에서는, 당신이 직접 만든 복사본만이 유일하게 존재하는 것이다. 이는 이 방식의 대가이며, 공정한 대가다. 첫 번째와 다른 관할권에서 두 번째 서버를 띄우고, 오늘 밤의 백업이 내려앉을 곳을 마련해 주어라.