[홈](https://servhidden.com/ko) /
[프라이버시 호스팅 가이드](https://servhidden.com/ko/guides) /
VPS 백업 전략: 암호화·오프사이트·복구 테스트






운영


# 실제로 복구되는 VPS 백업



KYC 없는 호스팅은 서류 절차와 함께 안전망도 없애 버립니다. 백업은 보관되지 않고, 데이터는 해지 후 24시간 안에 파기되며, 복구된 사본으로 끝나는 지원 경로도 없습니다. 이 글은 실전 계획입니다. 무엇을 복사할지, 어디에 둘지, 공격자가 그것을 지우지 못하게 막는 법, 그리고 실제로 복구된다는 것을 증명하는 법까지 다룹니다.


[Read the 가이드](#guide-body)
[FAQ](#guide-faq)






## 이 페이지에서




- [가이드](#guide-body)

- [FAQ](#guide-faq)

- [관련 가이드](#guide-related)

- [추천 페이지](#guide-cta)






KYC 없음
암호화폐 결제 전용
로그 없음
DMCA 무시
전체 root 권한
NVMe SSD





20분 읽기
Aug 2026 업데이트

이 페이지에서

[01서버를 실제로 파괴하는 것](#서버를-실제로-파괴하는-것)
[02스냅숏은 백업이 아니고, 당신의 호스트도 백업이 아니다](#스냅숏은-백업이-아니고-당신의-호스트도-백업이-아니다)
[03신분증을 보여준 적 없는 사람들을 위한 3-2-1 원칙](#신분증을-보여준-적-없는-사람들을-위한-3-2-1-원칙)
[04Push, Pull, 그리고 하룻밤의 사고가 두 복사본을 한꺼번에 삼키는 실수](#push-pull-그리고-하룻밤의-사고가-두-복사본을-한꺼번에-삼키는-실수)
[05원본에서 암호화하고, 키는 누가 쥘지 정하라](#원본에서-암호화하고-키는-누가-쥘지-정하라)
[06도구 선택, 표 하나로 정리](#도구-선택-표-하나로-정리)
[07실행 중인 것은 파일이 아니다](#실행-중인-것은-파일이-아니다)
[08무엇을 백업할 것인가, 그리고 다들 잊는 부분들](#무엇을-백업할-것인가-그리고-다들-잊는-부분들)
[09시험해 보지 않은 복구는 소문일 뿐이다](#시험해-보지-않은-복구는-소문일-뿐이다)
[10계속 돌아가도록 자동화하기](#계속-돌아가도록-자동화하기)
[11요약](#요약)
[FAQ자주 묻는 질문](#guide-faq)
[→추천 페이지](#guide-cta)







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

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

## 서버를 실제로 파괴하는 것

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

| 무엇이 잘못되는가 | 보통 이렇게 일어난다 | 무엇이 당신을 구하는가 |
| --- | --- | --- |
| **본인의 실수** | 셸 변수가 비어 있는 상태에서 실행한 rm -rf, 프로덕션을 가리킨 마이그레이션, 잘못된 테이블을 지운 배포 | 실수 *이전*의 오프박스 복사본이라면 무엇이든 — 즉 보존 기간이 알아차리기까지 걸리는 시간보다 더 길어야 한다는 뜻 |
| **조용한 손상** | 죽어가는 NVMe, 재부팅 중 잘린 쓰기, 일주일째 손상된 행을 쓰고 있던 데이터베이스 | 알려진 정상 시점까지 거슬러 올라갈 만큼 깊은 버전별 복사본. 단일 미러 복사본은 손상까지 충실히 그대로 복제한다 |
| **침해** | 탈취된 키, 패치되지 않은 애플리케이션, 오염된 의존성 — 그리고 마지막으로, 고의로 지워지는 당신의 백업 | 침해된 서버가 지울 권한 자체를 갖지 못한 복사본. 여기서는 그것만이 유효하다 |
| **공급자 또는 국가 단위 사건** | 하드웨어 손실, 데이터센터를 겨냥한 법적 조치, 더 이상 접근할 수 없는 계정이나 토큰 | 그 공급자에 있지 않고 그 관할권 아래 있지도 않은 복사본 |
| **키 분실** | 잊어버린 암호구, 그것이 보호하던 서버와 함께 지워진 키 파일, 아무도 내보내 두지 않은 LUKS 헤더 | **없음.** 복구 방법이 아예 없는 유일한 행이며, 하드웨어 고장보다 더 흔하다 |

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

백업 대상에게 필요한 것은 코어가 아니라 디스크와 주소입니다. 다른 관할권에 있는 가장 저렴한 두 번째 서버만으로도 충분한 엔드포인트가 되며, 첫 번째 공급자에게 사고가 났을 때 살아남는 유일한 복사본이 됩니다.

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

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

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

**24시간 조항이 이 모든 논리의 핵심이다.** 이 플랫폼에서는 해지된 서버의 데이터가 하루 안에 파기되며, 디스크는 포맷이 아니라 암호학적으로 완전히 지워진다. 삭제 취소도, 조용한 콜드 스토리지 계층도, "예전 복사본을 찾았다"로 끝나는 지원 결과도 존재하지 않는다. 하나라도 보관한다는 것은 지워 달라고 요청받은 데이터를 계속 붙들고 있다는 뜻이기 때문이다. 안전장치와 프라이버시는 단 한 번 이루어진 같은 거래다.

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

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

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

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

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

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

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

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

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

깔끔한 해법은 두 가지이며, 이미 해두었어야 할 [기본 하드닝](https://servhidden.com/ko/guides/first-hour-vps-hardening-checklist)과도 잘 어우러진다.

- **추가 전용(append-only) 대상.** 두 주요 도구 모두 클라이언트가 데이터를 추가할 수는 있지만 지울 수는 없는 모드를 지원한다. Borg는 대상 쪽 SSH 키를 borg serve --append-only로 고정해 이를 구현하고, restic은 --append-only로 시작한 REST 서버로 구현한다. 프로덕션 서버는 매일 밤 쓰기만 할 뿐, 구조적으로 이력을 파괴할 능력 자체가 없다. 오래된 스냅숏 정리는 그다음 대상 쪽에서, 프로덕션 서버가 시작할 수 없는 세션 안에서 이루어진다.

- **Push 대신 Pull.** 방향을 뒤집는다. 백업 호스트가 프로덕션에 접속해 읽고 저장한다. 프로덕션은 대상에 대한 자격 증명을 전혀 갖지 않으므로 훔칠 것이 없다. 프로덕션 쪽에서 쓰는 키는 restrict와 강제된 command=로 제한해, 훔친 백업 키가 셸로 이어지지 못하게 한다.

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

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

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

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

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

- 암호구는 서버에 root만 읽을 수 있는 파일로만 두고 --password-file로 참조해, 프로세스 목록이나 셸 기록에 절대 나타나지 않게 한다.

- 사람이 읽을 수 있는 사본을 관련된 모든 기기 밖에도 보관하라. 서랍 속 종이 한 장이, 당신도 접근을 잃을 수 있는 계정에 동기화되는 비밀번호 관리자보다 정말로 낫다.

- 저장소에 두 번째 키를 추가하라. restic key add나 내보낸 Borg 키면 된다. 그러면 암호구 하나를 잊어도 아카이브의 끝이 아니라 사소한 불편으로 끝난다.

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

## 도구 선택, 표 하나로 정리

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

| 도구 | 전송 전 암호화 | 중복 제거 | 추가 전용 대상 | 적합한 상황 |
| --- | --- | --- | --- | --- |
| **restic** | 예, 저장소 전체 | 예 | 예, REST 서버를 통해 | 기본 선택지. SFTP, 오브젝트 스토리지, 자체 서버를 모두 지원해 대상이 거의 무엇이든 될 수 있다 |
| **BorgBackup** | 예, 저장소 전체 | 예, 그룹 중 최고 | 예, SSH로 네이티브 지원 | SSH로 접속하는 리눅스 대상 하나. 데이터가 크고 반복적일 때 타의 추종을 불허한다 |
| **rsync + 로테이션** | 아니오 — 대상이 모든 것을 그대로 본다 | 부분적, 하드링크를 통해 | 아니오 | 프라이버시보다 즉각적인 부분 복구가 더 중요할 때, 완전히 통제하는 서버로 미러링 |
| **rclone** | rclone crypt를 쓸 때만 | 아니오 | 스토리지 공급자에 따라 다름 | 이미 존재하는 아카이브를 오브젝트 스토리지로, 또는 공급자 간에 옮길 때 |
| **ZFS 복제** | 암호화된 데이터셋일 때만 | 예, 블록 단위 | 스냅숏 권한을 통해 | ZFS 서버 두 대 사이의 복제. 매우 빠르지만 양쪽 모두에 엄격한 조건이 붙는다 |
| **tar + age 또는 GPG** | 예, 아카이브를 암호화하면 | 아니오 | 해당 없음 | 단순함이 효율보다 중요한, 작고 가끔 만들며 영구 보관하는 아카이브 |

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

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

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

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

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

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

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

- /etc 전체, 직접 작성한 systemd 유닛과 타이머, 그 밖에 있는 모든 crontab.

- TLS 인증서와 그 개인 키, 최소한 ACME 계정 키만이라도 있어야 인증서가 처음부터 다시 시작하지 않고 갱신된다.

- 방화벽 규칙과 패키지 목록. 이 둘을 합치면 어떤 기억보다도 빠르게 서버의 형태를 되살릴 수 있다.

- 애플리케이션 시크릿과 환경 파일. 코드 저장소에서 의도적으로 제외된 것들이라 다른 어디에도 남아 있지 않다.

- 텍스트로 내보낸 DNS 레코드. 리버스 DNS와 PTR 항목까지 포함되며, 이는 서버가 아니라 공급자 쪽에 있는 것들이다.

**어떤 키는 데이터가 아니라 정체성이다.** Tor 어니언 서비스의 개인 키는 곧 그 주소*이다*. 이를 잃으면 다른 무엇을 복원했든 같은 [.onion 주소](https://servhidden.com/ko/guides/how-to-host-a-tor-hidden-service)로는 돌아올 수 없다. WireGuard 서버 키를 잃으면 그동안 나눠준 모든 클라이언트 설정을 다시 발급해야 한다. 메일 서버의 DKIM 키를 잃으면 새 셀렉터로 [전달률](https://servhidden.com/ko/guides/offshore-mail-server-setup)을 처음부터 다시 쌓아야 한다. Lightning 노드의 시드와 채널 상태는 파일이 아니라 자금을 의미할 수도 있다. [노드 호스팅 가이드](https://servhidden.com/ko/guides/crypto-node-hosting-guide)에서 이 점을 분명히 밝히고 있다. 이런 것들은 따로 복사해 오프라인으로 보관하고, 그것이 지키는 데이터보다 더 소중하게 다루어라.

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

백업 소프트웨어는 스스로에 대해 보고하는데, 정직하게 보고하는 대상이 엉뚱하다. "스냅숏 완료"는 저장소에 데이터가 쓰였다는 뜻일 뿐이다. 그 저장소를 이 서버가 아닌 다른 기기에서, 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 가이드](https://servhidden.com/ko/guides/server-opsec-staying-anonymous)에서 다룬다.

## 요약

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

- 복사본 하나를 두 번째 공급자, 두 번째 관할권에 두고, 첫 번째와 같은 방식으로 프라이버시를 지키며 결제하라.

- 그 복사본을 추가 전용으로 만들거나 대상 쪽에서 끌어오게(pull) 하여, 침해된 서버가 그것을 파괴할 수 없게 하라.

- 도구가 원본에서 암호화하게 두고, 키는 관련된 두 서버 모두에서 떼어 놓아라.

- 데이터베이스는 덤프하고, 실행 중인 것은 무엇이든 멈추거나 스냅숏을 떠라. 살아 있는 상태를 그대로 복사하지 마라.

- 정체성 키(onion, WireGuard, DKIM, 노드 시드)는 따로 백업하라. 이것들은 다시 만들어낼 수 없기 때문이다.

- 일회용 서버 위에 한 번 복원해 보고, 시간을 재고, 무엇이 빠졌는지 적어 두라.

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





FAQ

## VPS 백업 — 자주 묻는 질문





### 01
ServHidden가 제 VPS를 백업해주나요?



아니요, 이는 빠뜨린 것이 아니라 의도적인 정책입니다. 저희 보존 정책은 백업을 전혀 보관하지 않으며, 서버 데이터는 해지 후 24시간 이내에 파기되고, 디스크는 포맷이 아니라 암호학적으로 완전히 지워진다고 명시합니다. 삭제를 요청받은 뒤에도 데이터 사본을 갖고 있는 것은 이 플랫폼이 존재하는 이유와 모순됩니다. 서버가 사라져도 남기고 싶은 모든 것은 직접 서버 밖으로 복사해야 하며, 이상적으로는 두 번째 관할권의 두 번째 공급자에게 옮겨야 합니다.





### 02
스냅숏도 백업이라고 할 수 있나요?



아닙니다. 스냅숏은 자신이 나온 서버와 모든 장애 영역을 공유합니다. 같은 공급자, 같은 계정, 같은 국가, 흔히 같은 스토리지까지요. 잘못된 업그레이드를 되돌리는 데는 탁월하지만, 계정이나 공급자, 서버 자체를 잃는 상황에는 아무 소용이 없습니다. 스냅숏은 되돌리기 버튼으로, 백업은 보험으로 여기세요. 서로 다른 문제를 해결하며 둘 다 필요합니다.





### 03
restic와 BorgBackup 중 무엇을 써야 하나요?



대상이 오브젝트 스토리지, SFTP, 혹은 아직 정하지 못한 무언가일 수 있다면 restic을 쓰세요. 가장 많은 백엔드를 지원합니다. 대상이 SSH로 접속하는 리눅스 서버 한 대이고 데이터가 크고 반복적이라면 BorgBackup을 쓰세요. 중복 제거 성능이 그룹 중 가장 뛰어납니다. 둘 다 데이터가 서버를 떠나기 전에 원본에서 암호화하며, 둘 다 추가 전용 대상을 지원합니다. 이 둘 사이의 선택보다 훨씬 더 중요한 것이 바로 이 지점입니다.





### 04
공격자가 제 백업을 지우지 못하게 하려면 어떻게 해야 하나요?



동기가 아니라 능력을 없애야 합니다. 대상을 추가 전용으로 만들어 프로덕션 서버의 자격 증명이 데이터를 추가할 수는 있어도 지울 수는 없게 하거나, 연결 방향을 뒤집어 백업 호스트가 프로덕션에서 끌어오게 하고 프로덕션 서버는 자격 증명을 아예 갖지 않게 하세요. 자신의 존재를 알리기 전에 백업부터 지우는 것은 이를 상업적으로 하는 공격자들의 표준 절차이며, 공격자가 지울 수 있는 복사본은 두 번째 복사본이 아닙니다.





### 05
두 번째 복사본은 어디에 두어야 하나요?



다른 공급자, 다른 관할권에 두고, 프로덕션 서버만큼 사생활을 지키며 결제하세요. 두 복사본을 동시에 앗아가는 사건은 물리적인 경우가 드뭅니다. 계정 접근 상실, 공급자의 힘든 한 주, 한 나라에는 미치지만 다른 나라에는 미치지 않는 법적 조치 같은 것들이죠. 같은 랙 안의 두 서버는 절차만 하나 더 붙은 하나의 복사본일 뿐입니다. 도구가 원본에서 암호화하기 때문에, 두 번째 호스트를 반드시 신뢰할 필요는 없습니다.





### 06
백업은 얼마나 자주 해야 하나요?



다시 해도 괜찮은 작업량을 기준으로 거꾸로 계산하세요. 블로그는 하루치를 잃어도 아무도 모르지만, 쇼핑몰은 한 시간치 주문도 잃으면 안 됩니다. 서버 한 대짜리 구성이라면 매일 밤이 적절한 기본값이며, 쓰기 작업이 중요하다면 데이터베이스 덤프는 더 자주 하세요. 빈도보다 더 중요한 것은 보존 깊이입니다. 손상은 몇 주가 지나서야 알아채는 경우가 많으니, 손상이 시작되기 이전 시점까지 거슬러 올라갈 수 있을 만큼 충분한 이력을 남겨 두세요.





### 07
제가 통제하지 않는 서버에 암호화된 백업을 두어도 안전한가요?



내용물에 관해서는 안전합니다. restic과 Borg는 데이터가 원본을 떠나기 전에 암호화하므로 대상은 읽을 수 없는 블롭만 저장하고 키는 결코 이동하지 않습니다. 대상이 알게 되는 것은 메타데이터입니다. 대략 얼마나 많은 데이터를 갖고 있는지, 어떻게 변하는지, 작업이 언제 실행되는지 정도죠. 보통은 이 정도로 충분합니다. 그렇지 않다면 일정을 불규칙하게 바꾸고, 프로덕션 서버와 소유 관계가 연결되지 않은 서버에 저장소를 두세요.





### 08
백업 암호구를 잃어버리면 어떻게 되나요?



아카이브는 영구히 사라지며, 누구에게도 구제받을 방법이 없습니다. 이 주제 전체에서 가장 흔한 완전 손실이자 복구 경로가 아예 없는 유일한 실패입니다. 암호구는 관련된 모든 기기 밖 어딘가에 보관하고, 함께 잃을 수도 있는 계정보다는 종이를 선호하며, 저장소에 두 번째 키를 추가해 비밀번호 하나를 잊어도 아카이브의 끝이 아니라 사소한 불편으로 끝나게 하세요.




관련 가이드

## 계속 읽기


[### 2026년 오프쇼어 호스팅 관할권 선택 방법

구매


오프쇼어 관할권 선택을 위한 실용적인 의사결정 프레임워크: 데이터 보존법, MLAT 노출, DMCA 입장, 법원 처리 속도, 실제 집행 현황 — 국가별로 살펴봅니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/choosing-an-offshore-jurisdiction)
[### 프라이버시가 중요한 워크로드를 위한 VPS vs 전용 서버

구매


언제 VPS로 충분한지, 언제 shared tenancy가 liability가 되는지, 언제 bare metal만이 정직한 답인지 설명합니다. Hardware isolation, hypervisor risk, 그리고 cost vs threat model을 다룹니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/vps-vs-dedicated-for-privacy)
[### KYC 없는 VPS에서의 자체 호스팅 VPN: WireGuard vs OpenVPN

운영


자체 호스팅 VPN이 상용 제공업체보다 나은 이유와, 2026년 프라이버시·성능·운영 위험 측면에서 WireGuard와 OpenVPN이 실제로 어떻게 비교되는지 알아봅니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### AI 추론을 위한 RTX 4090 vs H100 SXM5 (RTX 5090은 어디에 적합할까)

구매


구매 가이드: 2026년 자체 호스팅 LLM, 이미지, 영상, 음성, 파인튜닝 워크로드에 어떤 NVIDIA GPU를 쓸지. RTX 4090 vs RTX 5090 vs H100 SXM5 vs 듀얼 H100 — VRAM, 처리량, $/토큰, 각각이 유리한 경우.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/rtx-4090-vs-h100-for-ai-inference)
[### MT4 / MT5 / cTrader Forex 트레이딩을 위한 오프쇼어 Windows RDP

운영


완벽 가이드: Forex 트레이딩에 Windows RDP를 쓰는 이유, 저지연 오프쇼어 관할권 선택 방법, MT4 / MT5 / cTrader / Expert Advisor 설정, 브로커 서버까지의 지연 시간, 그리고 KYC 없는 결제 경로.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/offshore-windows-rdp-for-forex-trading)
[### DMCA 무시 호스팅 해설: 2026년 현재 실제 의미

구매


"DMCA 무시" 호스팅이 실제로 제공하는 것, 이를 진정으로 뒷받침하는 관할권, 이를 필요로 하는 워크로드, 그리고 이 용어가 커버하지 않는 저작권 함정.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/dmca-ignored-hosting-explained)
[### 크립토로 익명 도메인 등록: 2026년 WHOIS 프라이버시

프라이버시


신원 노출 없는 도메인 등록을 위한 2026년 실용 가이드: TLD별 WHOIS 체계, 레지스트라 선택, 크립토 결제 옵션, 그리고 어쨌든 신원을 노출시키는 운영상 실수들.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/anonymous-domain-registration-with-crypto)
[### 호스팅을 위한 암호화폐 결제: Monero vs Bitcoin vs USDT

프라이버시


결제 코인이 호스트가 여러분에 대해 알게 되는 것에 어떤 영향을 미치는지. XMR, BTC, USDT의 프라이버시, 수수료, 최종성, 체인 분석 노출 — 명확한 추천과 함께.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### 오프쇼어 호스팅은 정말 익명입니까? 솔직한 답변

프라이버시


오프쇼어, No-KYC 호스팅은 일반 호스팅업체가 수집하는 신원 정보를 제거합니다. 하지만 "익명성"은 결제 방식과 제공업체의 로그 정책, 그리고 사용자 자신의 운영 보안(opsec)에 따라 달라집니다. 실제로 무엇이 추적 가능한지 알려드립니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/is-offshore-hosting-truly-anonymous)
[### VPS 보안 강화 첫 1시간: 체크리스트

운영


새 VPS를 한 시간 이내에 안전하게 만드는 구체적이고 순서화된 체크리스트입니다: SSH 키, 방화벽, fail2ban, 자동 업데이트, 그리고 대부분의 기회주의적 공격을 막는 공격 표면 축소까지 다룹니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/first-hour-vps-hardening-checklist)
[### KYC 없는 호스팅이란? 정의, 합법성 및 작동 방식

프라이버시


KYC 없는 호스팅은 신원 확인 없이 서버를 임대할 수 있는 서비스입니다. 이름, 이메일, 신분증이 전혀 필요하지 않습니다. 이 서비스가 무엇인지, 어떻게 작동하는지, 합법성은 어떤지, 그리고 진정한 KYC 없는 공급자를 어떻게 선택하는지 상세히 설명합니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/what-is-no-kyc-hosting)
[### 오프쇼어 호스팅은 합법인가? 2026년 솔직한 답변

구매


오프쇼어 호스팅은 합법입니다 — 이용자와 제공업체 모두에게 해당됩니다. 이 용어가 실제로 무엇을 의미하는지, 법적 경계가 어디에 있는지, 버려야 할 오해들, 그리고 책임감 있게 활용하는 방법을 설명합니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/is-offshore-hosting-legal)
[### Monero(XMR)로 호스팅 결제하는 방법 — 단계별 가이드

프라이버시


Monero(XMR)로 VPS 또는 전용 서버 비용을 결제하는 단계별 가이드: XMR이 가장 프라이버시 보호에 뛰어난 옵션인 이유, 구매 방법, 그리고 결제 절차 — 인보이스 발행부터 서버 가동까지.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/how-to-pay-for-hosting-with-monero)
[### 웹사이트를 익명으로 호스팅하는 방법 — 2026년 실전 가이드

프라이버시


신원을 전혀 남기지 않고 웹사이트를 호스팅하는 방법을 계층별로 설명하는 실전 가이드입니다. 계정, 결제, 도메인, 관할권, 접속 방식, 콘텐츠 — 각 계층을 빠짐없이 다룹니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/how-to-host-a-website-anonymously)
[### VPS에 WireGuard VPN 설정하는 방법 — 단계별 가이드

운영


WireGuard로 VPS에 나만의 프라이빗 VPN 구축하기: 직접 호스팅하는 VPN이 상용 VPN보다 나은 이유, 설치부터 클라이언트 연결까지의 전체 설정 과정, 그리고 보안 강화 방법.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### GPU 서버에 LLM 직접 운영하는 방법 — 2026년 가이드

운영


임대한 GPU 서버에서 나만의 대형 언어 모델을 운영하는 방법: API 대비 셀프 호스팅의 장점, GPU와 모델 선택 기준, Ollama 또는 vLLM을 이용한 설정 방법, 그리고 실제 비용까지.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/self-host-an-llm-on-a-gpu-server)
[### 불릿프루프 호스팅 vs 오프쇼어 호스팅 — 차이점은 무엇인가요?

구매


불릿프루프 호스팅과 오프쇼어 호스팅은 늘 혼동되지만, 둘은 같은 것이 아닙니다. 실제 차이점, 그것이 중요한 이유, 그리고 당신에게 실제로 필요한 것이 무엇인지 알아보세요.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/bulletproof-vs-offshore-hosting)
[### Bitcoin으로 VPS 구매하는 방법 — 단계별 안내 (2026)

구매


Bitcoin으로 VPS를 구매하는 방법을 초보자도 쉽게 따라할 수 있도록 안내합니다. BTC 마련, 플랜 선택, 청구서 결제, 그리고 카드 없이 익명으로 서버를 받는 전 과정을 다룹니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/how-to-buy-a-vps-with-bitcoin)
[### 2026년 DMCA 무시 호스팅에 최적화된 국가

구매


미국식 저작권 삭제 요청의 영향을 받지 않는 서버를 원한다면 — 실질적으로 통하는 국가들, DMCA 무시의 진정한 의미, 그리고 선택 방법을 알아보세요.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/best-countries-for-dmca-ignored-hosting)
[### Tor 히든 서비스(.onion 사이트) 호스팅 방법 — 2026년 가이드

운영


VPS에서 Tor 어니언 서비스를 설정하는 방법: 히든 서비스란 무엇인지, 왜 가장 강력한 익명 호스팅 형태인지, 전체 설정 과정, 그리고 실제로 익명성을 유지하는 방법을 안내합니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/how-to-host-a-tor-hidden-service)
[### 오프쇼어 메일 서버 설정 — 2026년 프라이빗 이메일 자체 호스팅

운영


오프쇼어 VPS에서 나만의 프라이빗 이메일 서버를 운영하세요: 이메일 자체 호스팅이 필요한 이유, 준비 사항, 올인원 메일 스택을 활용한 실용적인 설정 방법, 그리고 이메일 전달율을 높이는 방법까지 안내합니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/offshore-mail-server-setup)
[### 크립토 노드 호스팅 가이드 — VPS에서 블록체인 노드 운영하기

운영


서버에서 블록체인 노드를 호스팅하는 방법: 직접 노드를 운영해야 하는 이유, Bitcoin·Ethereum·Monero 등 각 체인별 서버 사양 산정, 설정 방법, 그리고 프라이버시를 유지하는 법.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/crypto-node-hosting-guide)
[### Stable Diffusion용 GPU 호스팅 — 나만의 이미지 서버 운영하기

운영


자체 GPU 서버에서 Stable Diffusion 실행하기: 이미지 생성을 직접 호스팅해야 하는 이유, 적합한 GPU 선택 방법, 웹 UI 설정, 그리고 호스팅 서비스와의 비용 비교.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/gpu-hosting-for-stable-diffusion)
[### 서버 OpSec — 서버를 운영하면서 익명성 유지하기

프라이버시


익명 서버를 운영하는 모든 이를 위한 작전 보안 가이드: 신원을 노출시키는 실수들, 이를 방지하는 습관들, 그리고 정체성을 진정으로 분리하는 방법.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/server-opsec-staying-anonymous)
[### 시드박스 설정 가이드 — 2026년 나만의 프라이빗 시드박스 구축하기

운영


서버에서 직접 시드박스를 구축하는 방법: 시드박스의 정의, 서버 사양 선정, 웹 UI가 있는 토런트 클라이언트 설치, 그리고 프라이버시 및 보안 유지.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/seedbox-setup-guide)
[### 자체 VPS로 DPI 검열 우회하기 (2026 가이드)

프라이버시


VPN이 갑자기 먹통이 됐나요? 자체 VPS로 DPI 검열을 우회하는 방법을 알아봅니다: 심층 패킷 검사(DPI)가 실제로 탐지하는 것, 2026년 기준 5가지 프로토콜 중 어떤 차단에 어떤 프로토콜이 효과적인지, 그리고 VLESS+REALITY 전체 설정 과정까지 다룹니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/bypass-dpi-censorship-with-your-own-vps)
[### VPS 전체 디스크 암호화: LUKS 설정과 실제로 보호되는 것

운영


LUKS로 VPS를 암호화하는 방법을 다룹니다: 암호화된 데이터 볼륨, SSH 원격 잠금 해제를 사용한 전체 루트 암호화, 소형 서버에서 실제로 중요한 설정, 그리고 디스크 암호화가 실제로 무엇을 막아주는지에 대한 솔직한 설명까지 함께 다룹니다.


8개 자주 묻는 질문](https://servhidden.com/ko/guides/full-disk-encryption-on-a-vps)
[### 오리진 서버 IP 숨기기: CDN, 리버스 프록시, 그리고 여전히 새는 것들

프라이버시


오프쇼어 서버 앞에 CDN을 둘지 말지 판단하는 방법을 다룹니다: CDN이 실제로 무엇을 숨겨 주는지, 그 대가로 함께 떠안게 되는 신고 창구, 완벽하게 설정해도 오리진 IP가 그래도 새는 여섯 가지 경로, 그리고 여러분 자신의 서버를 직접 점검하는 방법까지 다룹니다.


8개 자주 묻는 질문](https://servhidden.com/ko/guides/hiding-your-origin-server-ip)
[### Matrix 셀프호스팅: 연합과 메타데이터의 진실

운영


Matrix 홈서버가 실제로 바꾸는 것: Synapse와 Conduit 비교, 되돌릴 수 없는 server_name, 디스크를 채우는 미디어, 연합이 드러내는 정보.


8개 자주 묻는 질문](https://servhidden.com/ko/guides/self-host-a-matrix-server)
[### 웹사이트를 다운타임 없이 역외 호스팅으로 이전하는 방법

운영


호스트 마이그레이션을 지루한 일로 만드는 순서 — DNS TTL을 며칠 전에 낮추고, 두 서버를 동시에 띄운 채 쓰기 동결은 시간이 아니라 분 단위로 끝내는 것 — 과 이전이 남기는 패시브 DNS·Certificate Transparency·WHOIS 흔적을 정리하는 방법까지 담았습니다.


8개 자주 묻는 질문](https://servhidden.com/ko/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

운영


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


8개 자주 묻는 질문](https://servhidden.com/ko/guides/self-host-a-crypto-payment-gateway)




## 오늘 밤의 백업이 내려앉을 곳을 마련하세요



일곱 개 관할권, 모든 플랜에 무제한 대역폭, 월 $7.50부터 시작하는 서버로 훌륭한 restic·Borg 엔드포인트를 만드세요. KYC 없음, 이메일 없음, 암호화폐 결제만 — 프로덕션뿐 아니라 백업 대상에도 그대로 적용됩니다.


[VPS 요금제 보기](https://servhidden.com/ko/vps)
[전용 서버](https://servhidden.com/ko/dedicated)
[전체 로케이션](https://servhidden.com/ko/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "7개 오프쇼어 관할권의 VPS 및 전용 서버. KYC 없음, 로그 없음, 암호화폐 전용. 아키텍처 차원에서 프라이버시를 설계했습니다.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "VPS 백업 전략: 암호화·오프사이트·복구 테스트",
    "description": "호스트는 백업을 보관하지 않습니다. 서버를 파괴하는 진짜 원인과 restic·Borg 비교, 잊기 쉬운 키 관리, 복구 테스트까지 정리했습니다.",
    "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-20T00:00:00+00:00",
    "dateModified": "2026-08-20T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy",
    "inLanguage": "ko",
    "keywords": "VPS 백업, 서버 백업 전략, 오프사이트 백업, 암호화 백업, restic BorgBackup 비교, 3-2-1 백업 규칙, append-only 백업, 백업 복구 테스트",
    "articleSection": "운영",
    "wordCount": 3974
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "ServHidden가 제 VPS를 백업해주나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "아니요, 이는 빠뜨린 것이 아니라 의도적인 정책입니다. 저희 보존 정책은 백업을 전혀 보관하지 않으며, 서버 데이터는 해지 후 24시간 이내에 파기되고, 디스크는 포맷이 아니라 암호학적으로 완전히 지워진다고 명시합니다. 삭제를 요청받은 뒤에도 데이터 사본을 갖고 있는 것은 이 플랫폼이 존재하는 이유와 모순됩니다. 서버가 사라져도 남기고 싶은 모든 것은 직접 서버 밖으로 복사해야 하며, 이상적으로는 두 번째 관할권의 두 번째 공급자에게 옮겨야 합니다."
            }
        },
        {
            "@type": "Question",
            "name": "스냅숏도 백업이라고 할 수 있나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "아닙니다. 스냅숏은 자신이 나온 서버와 모든 장애 영역을 공유합니다. 같은 공급자, 같은 계정, 같은 국가, 흔히 같은 스토리지까지요. 잘못된 업그레이드를 되돌리는 데는 탁월하지만, 계정이나 공급자, 서버 자체를 잃는 상황에는 아무 소용이 없습니다. 스냅숏은 되돌리기 버튼으로, 백업은 보험으로 여기세요. 서로 다른 문제를 해결하며 둘 다 필요합니다."
            }
        },
        {
            "@type": "Question",
            "name": "restic와 BorgBackup 중 무엇을 써야 하나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "대상이 오브젝트 스토리지, SFTP, 혹은 아직 정하지 못한 무언가일 수 있다면 restic을 쓰세요. 가장 많은 백엔드를 지원합니다. 대상이 SSH로 접속하는 리눅스 서버 한 대이고 데이터가 크고 반복적이라면 BorgBackup을 쓰세요. 중복 제거 성능이 그룹 중 가장 뛰어납니다. 둘 다 데이터가 서버를 떠나기 전에 원본에서 암호화하며, 둘 다 추가 전용 대상을 지원합니다. 이 둘 사이의 선택보다 훨씬 더 중요한 것이 바로 이 지점입니다."
            }
        },
        {
            "@type": "Question",
            "name": "공격자가 제 백업을 지우지 못하게 하려면 어떻게 해야 하나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "동기가 아니라 능력을 없애야 합니다. 대상을 추가 전용으로 만들어 프로덕션 서버의 자격 증명이 데이터를 추가할 수는 있어도 지울 수는 없게 하거나, 연결 방향을 뒤집어 백업 호스트가 프로덕션에서 끌어오게 하고 프로덕션 서버는 자격 증명을 아예 갖지 않게 하세요. 자신의 존재를 알리기 전에 백업부터 지우는 것은 이를 상업적으로 하는 공격자들의 표준 절차이며, 공격자가 지울 수 있는 복사본은 두 번째 복사본이 아닙니다."
            }
        },
        {
            "@type": "Question",
            "name": "두 번째 복사본은 어디에 두어야 하나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "다른 공급자, 다른 관할권에 두고, 프로덕션 서버만큼 사생활을 지키며 결제하세요. 두 복사본을 동시에 앗아가는 사건은 물리적인 경우가 드뭅니다. 계정 접근 상실, 공급자의 힘든 한 주, 한 나라에는 미치지만 다른 나라에는 미치지 않는 법적 조치 같은 것들이죠. 같은 랙 안의 두 서버는 절차만 하나 더 붙은 하나의 복사본일 뿐입니다. 도구가 원본에서 암호화하기 때문에, 두 번째 호스트를 반드시 신뢰할 필요는 없습니다."
            }
        },
        {
            "@type": "Question",
            "name": "백업은 얼마나 자주 해야 하나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "다시 해도 괜찮은 작업량을 기준으로 거꾸로 계산하세요. 블로그는 하루치를 잃어도 아무도 모르지만, 쇼핑몰은 한 시간치 주문도 잃으면 안 됩니다. 서버 한 대짜리 구성이라면 매일 밤이 적절한 기본값이며, 쓰기 작업이 중요하다면 데이터베이스 덤프는 더 자주 하세요. 빈도보다 더 중요한 것은 보존 깊이입니다. 손상은 몇 주가 지나서야 알아채는 경우가 많으니, 손상이 시작되기 이전 시점까지 거슬러 올라갈 수 있을 만큼 충분한 이력을 남겨 두세요."
            }
        },
        {
            "@type": "Question",
            "name": "제가 통제하지 않는 서버에 암호화된 백업을 두어도 안전한가요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "내용물에 관해서는 안전합니다. restic과 Borg는 데이터가 원본을 떠나기 전에 암호화하므로 대상은 읽을 수 없는 블롭만 저장하고 키는 결코 이동하지 않습니다. 대상이 알게 되는 것은 메타데이터입니다. 대략 얼마나 많은 데이터를 갖고 있는지, 어떻게 변하는지, 작업이 언제 실행되는지 정도죠. 보통은 이 정도로 충분합니다. 그렇지 않다면 일정을 불규칙하게 바꾸고, 프로덕션 서버와 소유 관계가 연결되지 않은 서버에 저장소를 두세요."
            }
        },
        {
            "@type": "Question",
            "name": "백업 암호구를 잃어버리면 어떻게 되나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "아카이브는 영구히 사라지며, 누구에게도 구제받을 방법이 없습니다. 이 주제 전체에서 가장 흔한 완전 손실이자 복구 경로가 아예 없는 유일한 실패입니다. 암호구는 관련된 모든 기기 밖 어딘가에 보관하고, 함께 잃을 수도 있는 계정보다는 종이를 선호하며, 저장소에 두 번째 키를 추가해 비밀번호 하나를 잊어도 아카이브의 끝이 아니라 사소한 불편으로 끝나게 하세요."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "홈",
            "item": "https://servhidden.com/ko/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "프라이버시 호스팅 가이드",
            "item": "https://servhidden.com/ko/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "VPS 백업 전략: 암호화·오프사이트·복구 테스트",
            "item": "https://servhidden.com/ko/guides/vps-backup-strategy"
        }
    ]
}
```