VPS 백업 방법: 암호화·오프사이트·복원 가능성

모든 백업은 필요해지는 그날까지만 멀쩡해 보입니다. 스냅샷은 방금 다운된 바로 그 플랫폼 위에 놓여 있습니다. 매일 밤 돌아가는 tar 백업은 3월에 디스크가 가득 찬 이후로 계속 조용히 실패해 왔습니다. 데이터베이스 덤프는 쓰는 도중에 뜬 파일 복사본이라 복원해 봐야 아무것도 나오지 않습니다. 백업은 서버 구성 요소 중 유일하게 눈으로 봐서는 상태를 판단할 수 없는 부분입니다 — 오직 복원해봐야만 알 수 있습니다. 이 글은 하드웨어 장애, 자신의 실수, 그리고 자격 증명을 손에 넣은 타인까지 모두 견뎌내면서도, 보관하는 쪽에게 읽을 수 있는 사본을 넘기지 않는 백업을 만드는 방법을 다룹니다.

서버를 무너뜨리는 네 가지, 그리고 저마다 다른 해법이 필요한 이유

백업은 도구가 아니라 장애를 중심으로 설계해야 합니다. 실제로 발생하는 손실은 거의 전부 네 가지 시나리오로 설명되며, 각각은 보관해 둔 사본에 서로 다른 요구를 합니다. 그중 하나만 처리하는 구성은 다른 시나리오를 만나기 전까지는 완벽하게 충분해 보입니다.

스냅샷은 백업이 아닙니다

두 단어는 흔히 같은 뜻처럼 쓰이지만, 실제로는 실패 영역이 서로 다른 별개의 대상을 가리킵니다. 지금 가지고 있는 것이 무엇인지 아는 것이, 애초에 무언가를 가지고 있기는 한 건지를 결정합니다.

3-2-1, 그리고 다들 빠뜨리는 두 숫자

이 오래된 규칙이 지금도 유효한 이유는, 저장 체계가 아니라 독립성을 설명하기 때문입니다: 데이터 사본 세 개를, 서로 다른 종류의 저장 매체 두 곳에, 그중 하나는 다른 곳에 둡니다. 여기에 더해진 두 가지는 이 규칙이 처음 만들어졌을 때는 드물었지만 지금은 흔해진 장애들을 다룹니다.

• 사본 세 개. 운영 중인 데이터에 백업 두 개를 더한 것입니다. 사본이 두 개뿐이라면, 잘못된 복원 한 번이면 아무것도 남지 않는 셈입니다.
• 매체 두 가지, 또는 제공업체 두 곳. 임대 인프라에서 "매체"는 사실상 관리상의 독립성을 뜻합니다 — 같은 계정, 같은 플랫폼, 같은 잔액에서 나가는 두 번째 사본은 사본이 아니라 절차만 하나 늘어난 것입니다.
• 오프사이트 한 곳. 건물도, 네트워크도, 중요하다면 관할권도 다른 곳. /locations 는 이를 실현하는 실질적인 방법입니다 — 보호 대상 리전과는 독립적으로 장애를 겪는 리전을 고르세요.
• 불변이거나 오프라인인 사본 하나. 서버 자신은 지울 수 없는 사본입니다. 서버를 소유한 사람은 그 자격 증명도 함께 소유하기 때문입니다.
• 미검증 복원 0회. 한 번도 복원해 본 적 없는 백업은 가설일 뿐입니다. 중요한 것은 성공했다고 보고된 작업 수가 아니라, 실제로 완료한 복원 횟수입니다.

데이터는 백업하고, 나머지는 다시 만드세요

본능적으로는 모든 것을 이미지로 뜨고 싶어집니다. 하지만 비용이 많이 들고, 복원도 느리며, 손상된 바이너리와 망가진 패키지 상태, 그리고 언제 왜 생겼는지도 기억나지 않는 설정 드리프트까지 고스란히 보존해 버립니다. 서버에는 세 가지 종류의 콘텐츠가 있고, 그중 백업에 속하는 것은 하나뿐입니다.

• /etc, /home, /root, /srv, 웹 루트, 애플리케이션의 상태 디렉터리, 이름이 지정된 컨테이너 볼륨, 그리고 방금 생성한 데이터베이스 덤프가 담긴 디렉터리를 포함하세요.
• 배포 방법 그 자체도 포함하세요 — compose 파일, Ansible 또는 셸 스크립트, 새벽 2시에 급히 적어둔 메모까지입니다. 버전 관리 시스템에도 넣어두되, 백업에도 사본을 함께 두어서 복구가 또 다른 서비스에 접속 가능한지에 좌우되지 않도록 하세요.
• /proc, /sys, /dev, /run과 임시 디렉터리는 제외하세요. 이들은 커널 인터페이스이자 임시 작업 공간일 뿐이므로, 복사해 봐야 시간만 낭비하거나 작업 자체가 아예 멈춰버립니다.
• 패키지 캐시, 빌드 디렉터리, 의존성 트리, virtualenv처럼 빌드 과정에서 다시 만들어지는 것은 모두 제외하세요. 일반적인 애플리케이션 서버에서는 이런 것들이 디스크 대부분을 차지합니다.
• 데이터베이스를 제대로 덤프하고 있다면 실행 중인 데이터베이스 파일 자체는 제외하세요. 둘 다 백업하면, 새벽 세 시에 결국 누군가 복원하게 되는 것은 더 크고 쓸모없는 쪽입니다.
• 숨김 파일은 제외하지 마세요. Linux 서버에서 중요한 것의 절반은 점(.)으로 시작합니다.

데이터베이스는 파일 복사만으로는 살아남지 못합니다

복원이 실패하는 가장 흔한 원인이 바로 이것입니다. 구동 중인 데이터베이스는 상태를 메모리에 유지하며 순서 없이 기록하기 때문에, 실행 중인 상태로 파일을 복사하면 찢기고 절반만 쓰인 상태가 그대로 담깁니다. 이런 상태는 복원될 수도 있고, 조용히 손상된 채 복원될 수도 있고, 아예 복원되지 않을 수도 있습니다. 제대로 된 덤프를 뜬 다음, 그 덤프를 백업하세요.

• PostgreSQL: 데이터베이스별로는 pg_dump, 역할(role)까지 포함한 클러스터 전체에는 pg_dumpall을 사용하세요. 하루치 손실도 용납할 수 없다면 WAL 아카이빙을 추가해, 어젯밤이 아니라 원하는 특정 시점으로 복구할 수 있게 하세요.
• MySQL 또는 MariaDB: --single-transaction 옵션을 붙인 mysqldump는 쓰기를 막지 않고도 InnoDB에서 일관된 스냅샷을 얻어냅니다. MyISAM에서는 그렇지 않습니다 — MyISAM을 쓰지 말아야 할 이유가 하나 더 느는 셈입니다. 데이터셋이 크다면 mariabackup 같은 물리적 도구가 덤프를 재생하는 것보다 훨씬 빠르게 복원됩니다.
• SQLite: 파일을 절대 그냥 복사하지 마세요. 잠금을 올바르게 처리하는 .backup 명령이나 VACUUM INTO를 사용하세요. write-ahead 로그가 활성 상태인 데이터베이스를 복사하는 것은 언젠가 반드시 지게 되어 있는 동전 던지기와 같습니다.
• Redis: 백그라운드 저장을 실행시켜 그 결과로 나온 스냅샷 파일을 백업하거나, append-only 모드로 실행해 로그를 백업하세요. 쓰는 도중인 스냅샷을 그대로 복사하면 잘려나간 파일만 남고, 이는 불러오면 빈 데이터셋으로 로드됩니다.
• 컨테이너: 볼륨이 곧 데이터입니다. 복사에 걸리는 몇 초 동안 스택을 멈추거나, 컨테이너 안에서 덤프 도구를 직접 실행하세요 — 하지만 구동 중인 데이터베이스의 볼륨을 그냥 tar로 묶어놓고 백업이라 부르지는 마세요.
• 그 밖에 지속적으로 실행되는 프로세스를 가진 것 — 검색 인덱스, 메시지 큐, 원장 데몬 등 — 은 저마다 일관된 상태로 내보내는 명령을 따로 갖추고 있습니다. 장애가 터진 뒤가 아니라 지금 미리 찾아두세요.

도구 고르기

네 가지 도구로 거의 모든 경우를 다룰 수 있습니다. 가장 중요한 속성은 암호화가 어디서 일어나는가입니다. 데이터가 전송 중에만 암호화되고 저장 시에는 스토리지 제공업체가 암호화한다면, 그 제공업체는 데이터를 읽을 수 있습니다 — 그리고 백업은 여러분이 다른 모든 곳을 그토록 단단히 조여둔 시스템에서, 어느샌가 가장 약한 지점이 되어버립니다.

두 번째 사본은 어디에 두어야 할까

목적지는 디스크 공간이기도 하지만, 그만큼이나 관할권이자 결제 관계이기도 합니다. 보호하려는 서버로부터 얼마나 독립적인지를 기준으로 대략 정리한 네 가지 선택지입니다.

단계별로 구축하기

1. 1

   가장 먼저 두 숫자를 정하세요

   얼마만큼의 데이터 손실까지 감당할 수 있는지 — 즉 실행 주기 사이의 간격 — 그리고 얼마나 오래 다운되어 있어도 괜찮은지입니다. 나머지는 모두 이 두 답에서 자연스럽게 따라옵니다. 정적 사이트를 매시간 백업하는 것은 보여주기에 지나지 않습니다. 반면 주문 데이터베이스를 매일 밤 백업하는 것은 어느 튜토리얼에서 그대로 물려받을 게 아니라 신중하게 직접 내려야 할 결정입니다.

2. 2

   목적지 만들기

   다른 리전에 두 번째 인스턴스를 만들고, 전용 SSH 키와, 홈 디렉터리가 곧 저장소인 권한 없는 전용 사용자를 하나 둡니다. 그 외에는 아무것도 돌리지 않습니다. 키를 강제 명령 하나로 제한해, 자격 증명을 도난당해도 백업을 추가하는 것 말고는 셸조차 열 수 없게 하세요.

3. 3

   키를 생성하고 다른 곳에 보관하세요

   길고 무작위한 패스프레이즈를 만들어, 서버를 잃어도 남아 있을 곳에 기록해 두세요. 저장소를 초기화한 다음, 오직 적어둔 정보만으로 제3의 머신에서 그 내용을 조회할 수 있는지 직접 증명하세요. 안 된다면, 백업을 단 하나라도 쓰기 전에 그 문제부터 고치세요.

4. 4

   먼저 데이터베이스를 덤프하세요

   일관된 덤프를 스테이징 디렉터리에 기록하고, 하나라도 실패하면 0이 아닌 종료 코드를 반환하는 짧은 스크립트를 만드세요 — 파일 백업과 동시에가 아니라 그 이전에 실행해야 합니다. 덤프가 실패해도 그대로 진행되는 작업은, 결국 30일치가 모두 0바이트 파일로 남는 사태로 이어지는 흔한 원인입니다.

5. 5

   중요한 경로를 백업하세요

   도구가 포함 목록을 향하도록 지정하고, 제외 목록을 적용한 다음, 첫 실행 결과를 반드시 검산하세요. 40 GB짜리 서버인데 새로 만든 저장소가 300 MB밖에 안 된다면 무언가가 조용히 빠지고 있는 것이고, 38 GB나 된다면 제외 설정이 제대로 작동하지 않고 있는 것입니다.

6. 6

   일정을 잡고, 실패는 반드시 시끄럽게 알리세요

   무작위 지연을 둔 systemd 타이머를 쓰거나, 익숙하다면 cron을 쓰세요. 그런 다음 작업이 상태를 보고하게 만드세요: 성공하면 모니터링 시스템으로 하트비트를 보내고, 하트비트가 끊기면 알림이 오도록 하세요. 백업이 멈춰도 눈에 보이는 방식으로는 아무것도 망가지지 않기 때문에, 조용한 실패야말로 백업의 가장 흔한 실패 방식입니다 — 정말로 모든 것이 무너지기 전까지는요.

7. 7

   보존 기간을 정하고, 실제로 정리(prune)하세요

   하루 동안은 시간 단위로, 2주 동안은 일 단위로, 두어 달은 주 단위로, 1년은 월 단위로 보관하세요. 그런 다음 정리(prune) 작업을 실행해 저장소가 더 이상 커지지 않는지 확인하세요. 설정만 해두고 실제로 실행하지 않는 보존 정책은 결국 목적지를 가득 채워, 백업 자체를 함께 무너뜨립니다.

8. 8

   오늘 당장 무언가를 복원해 보세요

   테스트용 작업 말고 — 실제 파일을 임시 디렉터리로 복원해서 열어보고 확인하세요. 그런 다음 머신 전체를 복원하는 날짜도 달력에 잡아두세요. 첫 전체 복원에서는 항상 무언가가 드러납니다: 빠진 경로, 잘못된 권한, 인증서, 예전 서버에만 존재했던 데이터베이스 사용자 같은 것들입니다.

보존 기간, 그리고 길게 잡을수록 오히려 저렴한 이유

보존 기간은 보통 디스크 용량에 맞춰 대충 정해진 뒤 그대로 잊힙니다. 어떤 실수까지 복구할 수 있는지를 보존 기간이 결정하는 만큼, 한 번쯤은 신중하게 생각해볼 가치가 있습니다. 7일짜리 보존 기간은 화요일에 지운 파일은 잡아내지만, 6주 전에 시작되어 리포트가 이상하게 나오고 나서야 드러난 손상이나, 한 달 동안 조용히 머신에 머물러 있다가 움직인 침입자는 잡아내지 못합니다.

중복 제거 덕분에 실제 비용은 표에서 보이는 것보다 훨씬 저렴합니다: 거의 바뀌지 않은 서버를 상대로 한 두 번째 실행은 바뀐 부분만 저장하므로, 40 GB짜리 머신이라면 1년치 월별 복원 시점을 모두 합쳐도 보통 0.5테라바이트가 아니라 몇 기가바이트 수준에 그칩니다. 무엇으로부터 복구해야 하는지를 기준으로 정책을 정한 다음, 청구서를 확인해보세요. 대개는 넉넉한 버전도 충분히 감당할 수 있다는 걸 알게 될 것입니다.

불변성: 랜섬웨어를 막아내는 부분

지금까지의 이야기는 상대가 엔트로피, 즉 무작위한 고장이라는 전제 위에 있습니다. 하지만 상대가 root 권한을 쥔 사람이라면, 평범한 백업 작업은 그 자체로 공격자를 위한 설명서나 다름없습니다 — 자격 증명은 서버 위에 있고, 목적지는 설정 파일 안에 있으며, 암호화가 시작되기도 전에 저장소부터 지워집니다. 이 연결 고리를 끊는 방법은 네 가지이며, 그중 어느 하나만 적용해도 결과는 달라집니다.

• 추가 전용(append-only) 저장소. Borg의 서버 측 append-only 모드나, append-only 모드로 돌리는 restic의 REST 서버는 새 데이터는 받아들이지만 삭제는 거부합니다. 서버는 쓸 수 있지만, 지우는 것은 오직 다른 곳에 있는 여러분만 할 수 있습니다.
• 풀(pull) 방식 백업. 백업 호스트가 직접 연결을 시작하고, 유일한 자격 증명도 그쪽이 쥐고 있습니다. 프로덕션 서버에는 키도, 목적지 주소도, 저장소로 가는 경로도 아예 없습니다.
• 오브젝트 락(object lock). 버킷 수준에서 보존 기간이 강제되는 S3 호환 스토리지로, 자격 증명이 원래 무엇을 허용하든 상관없이 스토리지 계층 자체가 삭제를 거부합니다.
• 호스트마다 다른 자격 증명. 머신 하나가 침해당했다고 해서 다른 모든 머신의 이력까지 드러나서는 안 됩니다. 서로 다른 키, 서로 다른 경로, 서로 다른 제한을 두세요.
• 진짜로 오프라인인 사본 하나. 플러그를 뽑아둔 디스크는 지금까지 만들어진 그 어떤 원격 공격에도 끄떡없습니다. 유행과는 거리가 멀지만, 아직 진 적이 없습니다.

복구 훈련

복원은 하나의 절차이며, 아무도 실제로 해본 적 없는 절차는 그저 소설일 뿐입니다. 지금 한 번, 그리고 이후로는 6개월마다 한 번씩 이 훈련을 실행하고, 배운 것을 기록해두세요 — 그 기록은 결국 데이터 자체만큼이나 가치 있는 것이 됩니다.

1. 1

   빈 인스턴스를 배포하세요

   같은 운영체제 버전에, 다른 것은 아무것도 설치하지 않습니다. 잠깐 쓰고 지울 VPS 하나면 충분하고, 전체 과정에 드는 비용은 점심 한 끼 값도 안 됩니다.

2. 2

   적어둔 것만으로 복원하세요

   저장소 주소, 패스프레이즈, 명령어만 사용하세요. 만약 죽었다고 가정한 바로 그 서버에만 존재하는 무언가가 필요하다면, 방금 허점을 하나 발견한 것입니다 — 발견해도 아무 대가가 없는 지금 이 순간에 말이죠.

3. 3

   애플리케이션보다 데이터를 먼저 되살리세요

   데이터베이스 덤프를 불러오고, 파일을 제자리에 두고 나서, 소유권과 권한을 바로잡으세요. 소유권은 흔히 놀라게 되는 부분입니다: 예전 서버의 숫자 사용자 ID가 새 서버에서도 그대로 맞아떨어지는 경우는 거의 없습니다.

4. 4

   서비스를 시작하고 실제로 사용해 보세요

   상태 확인 명령 하나로 끝내지 마세요 — 직접 로그인하고, 페이지를 띄우고, 쿼리를 실행하고, 메시지를 보내보세요. 시작되는 서비스와 실제로 작동하는 서비스는 같은 것이 아닙니다.

5. 5

   시간을 재고, 그 숫자를 적어두세요

   전체 과정이 얼마나 걸렸나요? 그것이 여러분의 진짜 복구 시간이며, 거의 항상 예상했던 것보다 몇 배는 더 걸립니다. 이 기록을 패스프레이즈 옆에 함께 보관하고, 스택이 바뀔 때마다 둘 다 갱신하세요.

솔직히 말해서, 비용은 얼마나 들까

백업은 인프라에서 가장 저렴한 보험이지만, 늘 가격을 이유로 생략되곤 합니다. 데이터가 평범한 데이터답게 압축되고 중복 제거된다고 가정했을 때, 작은 서버를 기준으로 한 구체적인 숫자를 살펴보겠습니다.

이 숫자들을 각각이 막아주는 장애 비용과 비교해보세요. 숫자를 직접 적어보는 것 자체가 핵심입니다 — 일단 금액을 적어놓고 나면, 백업에 반대하는 주장은 사실 돈 문제였던 적이 한 번도 없다는 게 드러납니다.

호스트가 차지하는 자리

백업 계획도 보호 대상인 서버와 똑같이 두 가지에 좌우됩니다: 사본을 둘 독립적인 장소, 그리고 여러분이 누구인지 새로운 기록을 남기지 않는 결제 수단입니다. 백업은 원본이 지키고자 했던 모든 것을 고스란히 담은 사본이기 때문에, 이 둘은 원본 서버에서보다 여기서 오히려 더 중요합니다.

저희의 모든 /vps 및 /storage 요금제는 KYC 없이 선불 암호화폐 잔액으로 배포되며, /locations 에 나열된 15개 리전 전체에서 이용할 수 있습니다 — 그러니 이 과정 어디에서도 신원 확인을 한 번 더 거치지 않고도, 두 번째 사본을 첫 번째 사본과는 다른 관할권에 둘 수 있습니다. 모든 인스턴스에는 5초짜리 되돌리기를 위한 즉시 스냅샷이 기본 포함되어 있고, 무제한 대역폭 덕분에 첫 업로드든 비상시 복원이든 트래픽 요금이 매겨지는 일이 없으며, /storage 는 콘텐츠 검사 없이 $8.99/mo부터 시작하는 테라바이트급 RAID 보호 디스크를 더해줍니다. 지원하는 코인은 /pay-with 에서, 관할권이 실제로 무엇을 바꾸는지는 /offshore-hosting 에서 확인할 수 있으며, 디스크 암호화와 호스트가 머신에 대해 볼 수 있는 것과 볼 수 없는 것을 다루는 글은 /guides 에 있습니다.

체크리스트

• 도구를 고르기 전에, 무엇에 대비하고 있는지부터 명확히 하세요.
• 스냅샷은 되돌리기 버튼으로만 여기고, 절대 백업으로 취급하지 마세요.
• 데이터와 설정만 백업하고, 운영체제는 스크립트로 다시 만드세요.
• 모든 데이터베이스를 저마다의 일관된 내보내기 명령으로 덤프하고, 그 덤프를 백업하세요.
• 무엇이든 머신을 떠나기 전에 클라이언트 측에서 암호화하세요.
• 저장소 패스프레이즈는 서버를 잃어도 남아 있을 곳에 보관하세요.
• 적어도 사본 하나는 다른 제공업체, 다른 리전, 다른 결제 경로 아래에 두세요.
• 사본 하나는 추가 전용, 풀(pull) 방식, 또는 오프라인으로 두어, root 권한이 뚫려도 지울 수 없게 하세요.
• 성공한 실행이 없을 때 알림이 오도록 하세요 — 실패는 조용히 일어나며, 그 침묵 자체가 증상입니다.
• 오늘은 파일 하나를, 그리고 1년에 두 번은 머신 전체를 복원해 보세요. 시간을 재고 기록하세요.