암호화 VPS 백업.
오프사이트에, 중복 제거되어, 손댈 수 없는 곳에.

백업에 관한 논쟁은 거의 항상 첫 1분 만에 어긋납니다. 대화하는 두 사람이 서로 다른 장애를 머릿속에 그리고 있기 때문입니다. 한 사람은 죽은 드라이브를 떠올리고, 다른 사람은 계정이 사라진 어느 화요일 아침을 떠올립니다. 둘은 서로 다른 답을 필요로 하며, 첫 번째 장애에서만 살아남는 구성은 두 번째 장애로 시험받기 전까지는 안전해 보일 뿐입니다.

설계 단계에서 대비할 가치가 있는 장애 모드는 네 가지이며, 이들은 하나의 변주가 아닙니다 — 각각 서로 다른 방어 수단을 무력화합니다.

하드웨어. NVMe가 고장 나거나, 호스트 노드가 죽거나, 어레이에서 두 멤버가 동시에 빠질 수 있습니다. 모두가 대비하는 장애이지만, 최신 가상화 인프라에서는 가장 드문 장애이기도 합니다. 중복 스토리지가 이를 처리합니다. 중복 스토리지가 처리하는 것은 그것뿐이며, 바로 그래서 RAID는 백업이 아니고 한 번도 백업이었던 적이 없습니다: RAID는 모든 쓰기를 충실히 복제하는데, “모두 삭제”라는 쓰기 역시 예외가 아닙니다.

사람. 운영 환경에 대고 실행한 마이그레이션 스크립트. 엉뚱한 터미널에서 실행한 DROP TABLE. 인수 순서가 뒤바뀐 rsync. 이것이 실제 데이터 손실의 가장 흔한 원인이며, 압도적인 차이로 그렇습니다. 이에 대한 유일한 방어는 이력(history)입니다 — 실수가 일어나기 전의 사본을, 그 실수가 닿지 않은 곳에 보관하는 것입니다. 핵심 재료는 시간입니다: 유일한 사본이 30초 전 상태의 미러라면, 그 사본에는 이미 그 실수가 포함되어 있습니다.

악의적 행위. 누군가 루트 권한을 획득하거나, 패치되지 않은 애플리케이션을 통해 랜섬웨어가 침투합니다. 최신 랜섬웨어가 가장 먼저 하는 일은 백업 설정 — 자격 증명, 마운트된 공유, 클라우드 키 — 을 찾아 파괴하는 것입니다. 정상 작동하는 복원이야말로 재앙을 반나절짜리 사건으로 바꾸기 때문입니다. 삭제 권한이 있는 백업 자격 증명은 공격자가 그대로 물려받는 백업 자격 증명입니다. 이것이 바로 이 가이드의 추가 전용 챕터가 존재하는 이유입니다.

수탁형. 아무것도 고장 나지 않았고 공격도 없었습니다 — 그저 접근 권한을 잃었을 뿐입니다. 자동화된 사기 탐지 신호로 인한 계정 정지, 여행 중 결제 실패, 분쟁, 컴플라이언스 심사, 제공업체에 송달된 명령. 머신은 멀쩡하지만 닿을 수 없고, 그 계정 안의 모든 스냅샷도 함께 닿을 수 없게 됩니다. 이것이 바로 한 제공업체 안에서 아무리 이중화를 해도 대응할 수 없는 장애이며, 제대로 된 백업이 다른 지붕 아래에 있어야 하는 이유입니다.

마지막 행이 바로 이 가이드의 나머지 부분이 만들어가는 결과입니다. 바로 위 행보다 더 비싸지도 않습니다 — 추가 전용 설정은 무료이고, 두 번째 관할권도 첫 번째와 똑같이 $3.90입니다.

3-2-1 규칙을 단일 VPS에 맞게 다시 설명합니다. 데이터 사본 세 개를, 서로 다른 두 종류의 스토리지에, 그중 하나는 오프사이트에 둡니다. 이 고전적인 공식은 테이프와 오피스 서버 시대에서 왔지만, 문구보다 정신이 더 잘 살아남습니다. 단일 셀프호스팅 서버에 적용하면 이렇게 됩니다: VPS 위의 실제 데이터, 어딘가 다른 곳의 두 번째 머신에 있는 저장소, 그리고 — 진짜로 대체 불가능한 것에 한해 — 집에 있는 디스크나 서랍 속에 직접 보관하는 세 번째 사본. 실제로 중요한 숫자는 3이 아닙니다. 데이터가 사라지기까지 얼마나 많은 독립적인 요소가 동시에 잘못되어야 하는가입니다. 갖출 가치가 있는 최소치는 2입니다.

파일시스템 전체를 백업하는 것은 나름대로 정당화할 수 있는 선택이지만, 동시에 낭비이기도 합니다. 서버 대부분은 패키지 관리자 한 번이면 다시 만들어낼 수 있으며, 거기서 나르는 기가바이트 하나하나가 저장소의 정리(prune)를 더 느리게, 보관 비용을 더 비싸게, 급할 때의 검색을 더 느리게 만듭니다. 유용한 접근은 그 반대입니다: 새로 설치했을 때 되돌려받지 못할 것들만 나열하는 것입니다.

일반적인 셀프호스팅 VPS라면 그 목록은 짧으며, 언제나 다음 다섯 가지를 포함합니다:

• 01데이터베이스 내용. 데이터 디렉터리가 아니라 덤프입니다. 이유는 5단계에서 다룹니다.
• 02사용자가 업로드한 파일. Docker 볼륨, 업로드나 미디어 디렉터리, 메일 저장소. 대개 용량의 대부분을 차지합니다.
• 03설정과 비밀 값. Compose 파일, .env 파일, 암호화 키, API 토큰. 용량은 작지만, 두 시간짜리 복원과 이틀짜리 복원의 차이를 만듭니다.
• 04직접 수정한 시스템 상태. /etc 디렉터리 전체는 통째로 포함해도 될 만큼 작습니다 — sshd 설정, 방화벽 규칙, systemd 유닛, cron 항목, 그리고 저녁 시간을 통째로 들여 구성한 메일 라우팅까지.
• 05신원이 결부된 모든 것. Tor 히든 서비스 키, Matrix 서명 키, WireGuard 개인 키, 노드 지갑. 이 중 하나라도 잃으면 서비스는 돌아오지 않습니다 — 같은 이름을 가진 다른 서비스가 돌아올 뿐입니다.

그 목록을 소스 서버에 두 개의 파일로 나누십시오. 포함 목록은 의도를 명확히 드러내고, 제외 목록은 잡음을 걸러냅니다. 두 파일 모두 백업 명령어가 읽으며, 둘 다 백업 대상 자체에 포함되어야 합니다.

/etc/backup/include.txt

/etc
/opt
/root
/var/backups
/var/lib/docker/volumes
/home

/etc/backup/exclude.txt

# Caches and rebuildable artefacts
**/node_modules
**/.cache
**/*.tmp
/var/lib/docker/volumes/*/_data/cache
# Log noise — keep the config, drop the volume
/var/log/journal
# Never back up the mount point you restore into
/mnt/restore

그 Docker 줄에 대해 두 가지를 짚어두겠습니다. 다들 여기서 걸려 넘어지기 때문입니다. 네임드 볼륨은 /var/lib/docker/volumes 아래에 있으며 여러분이 원하는 대상이 바로 이것입니다. 바인드 마운트는 여러분이 지정한 위치에 있는데, 보통 Compose 파일 옆이며 /opt로 커버됩니다. 컨테이너 이미지는 데이터가 아닙니다 — pull 한 번이면 다시 받아올 수 있으며, 이를 백업에 포함시키는 것은 필요 없는 기가바이트를 짊어지는 것입니다.

마지막으로, 무언가를 그 위에 쌓아 올리기 전에 결과를 직접 측정하십시오. 이 숫자가 어떤 저장소 등급을 주문해야 하는지, 그리고 첫 실행이 4분이 걸릴지 40분이 걸릴지를 알려줍니다:

du -sh --exclude=/var/lib/docker/overlay2 /etc /opt /root /home /var/lib/docker/volumes

저장소 호스트가 할 일은 하나뿐이며, 요구 사항도 거의 없습니다. 코어는 필요 없습니다. 여러분의 데이터를 절대 읽지 않으니까요 — 열 수 없는 암호화된 블롭을 보관할 뿐입니다. 메모리도 필요 없습니다. 중복 제거 작업은 소스 쪽에서 이루어지기 때문입니다. 필요한 것은 디스크, 고정된 주소, 그리고 소스 머신의 문제가 따라오지 않는 위치뿐입니다.

패널에서: 주문 → VPS → Sentinel, 이미지는 Debian 12, 그리고 — 바로 이것이 핵심입니다 — 소스가 실행 중인 요새와는 다른 요새를 선택하십시오. 작업은 Helsinki에서, 보관은 Reykjavík에서. 계정을 개설하는 데 이메일 주소가 필요하지 않으며, 청구서는 Monero, Bitcoin, Lightning, 그리고 그 밖에 지원되는 다른 자산으로 결제됩니다. 즉, 두 번째 머신이 첫 번째 머신에서 그토록 신경 썼던 신원을 다시 끌어들이지 않는다는 뜻입니다.

작업 세트 열은 일반적인 변경률로 1년간 보관되는 일일 스냅샷을 가정합니다. 거의 변하지 않는 파일이 대부분인 저장소는 이보다 훨씬 더 오래 버티고, 대용량 바이너리가 자주 다시 쓰이는 저장소는 그만큼 빨리 한계에 도달합니다. 마지막 행은 규모 감을 위한 것이자, 최악의 날이 오기 전까지는 다들 잊고 있는 세부 사항을 위한 것이기도 합니다: 오브젝트 스토리지는 다운로드에도 비용을 청구하며, 다운로드야말로 비상 상황에서 실제로 하게 되는 일입니다.

목적지에서는 — 권한 없는 사용자 하나와 디렉터리 하나.

adduser --disabled-password --gecos "" backup
install -d -m 0700 -o backup -g backup /srv/restic/web01

백업 사용자는 비밀번호도, sudo 권한도, 로그인할 대상도 없습니다. 오직 디렉터리를 소유하기 위해 존재할 뿐입니다. 여러 소스 머신을 백업한다면 소스마다 별도의 디렉터리를 부여하십시오 — 소스마다 별도의 저장소를 두면 한 서버가 침해되어도 다른 서버의 이력에는 영향을 주지 않습니다.

소스에서는 — 다른 어떤 용도로도 쓰이지 않는 키 하나.

ssh-keygen -t ed25519 -f /root/.ssh/id_backup -N "" -C "backup:web01"
cat /root/.ssh/id_backup.pub

로그인 키를 재사용하지 마십시오. 이 키는 새벽 3시에 무인 타이머가 사용해야 하기 때문에 디스크에 암호화되지 않은 채로 존재하는데, 바로 그렇기 때문에 단 하나의 목적지와 단 하나의 용도로만 범위를 좁혀야 하는 키입니다.

다시 목적지에서 — 그 키가 할 수 있는 일을 제한하십시오. 공개 키를 /home/backup/.ssh/authorized_keys에 붙여넣되, 앞에 접두사를 추가하십시오. restic을 SFTP로 사용할 경우:

restrict,from="198.51.100.7" ssh-ed25519 AAAAC3NzaC1lZDI1... backup:web01

restrict 옵션 하나로 포트 포워딩, 에이전트 포워딩, X11, PTY 할당이 모두 꺼지고 파일 전송만 남습니다. from= 절은 키를 소스 주소에 고정하므로, 서버에서 키가 유출되더라도 다른 곳에서는 쓸모가 없습니다. Borg의 경우 한 걸음 더 나아가 명령어 자체를 강제하십시오. 바로 여기에 추가 전용 모드가 자리합니다:

command="borg serve --append-only --restrict-to-path /srv/borg/web01",restrict ssh-ed25519 AAAAC3NzaC1lZDI1... borg:web01

이 한 줄이 랜섬웨어 방어의 전부입니다: 소스가 무엇을 보내든, 목적지는 오직 borg serve만 실행하며, 오직 그 경로 안에서만, 오직 추가만 가능한 모드로만 동작합니다. 소스에서 루트 셸을 획득하더라도 이 키로는 지난달 백업을 지울 수 없습니다.

목적지 이름을 소스에서 한 번만 지정하십시오. /root/.ssh/config에 넣어 이후의 모든 명령을 짧게 만들고, 주소가 단 하나의 파일에만 존재하도록 하십시오:

Host rkv-repo
    HostName 198.51.100.42
    User backup
    IdentityFile /root/.ssh/id_backup
    IdentitiesOnly yes

그런 다음 한 번은 직접 손으로 접속해서 — ssh rkv-repo — 호스트 키를 수락하십시오. 무인 타이머는 지문 확인 프롬프트에 응답할 수 없으며, 첫 백업이 일주일 동안 조용히 멈춰 있는 것은 흔한 사고입니다. 목적지 서버에 접속한 김에, 여러분이 소유한 다른 모든 머신과 똑같이 대우하십시오: 이 서버에도 첫 시간 보안 강화 체크리스트를 적용하십시오. 이 서버는 모든 것의 사본을 담고 있으니, 온전히 한 시간을 들일 가치가 있습니다.

데이터베이스 규칙, 한 번만 말씀드립니다. 실행 중인 데이터베이스 엔진은 상태를 메모리에 유지하다가 자신만의 시점에 디스크에 기록합니다. 그렇게 하는 도중에 파일을 읽으면 서로 다른 여러 순간이 뒤섞인 페이지 집합을 얻게 됩니다 — 복원될 수도, 손상된 채로 복원될 수도, 혹은 멀쩡히 열리지만 지난 한 시간이 조용히 빠진 상태로 복원될 수도 있는 파일입니다. 외부에서는 어느 쪽인지 알 방법이 없습니다. 그래서 백업은 운영 중인 파일을 절대 건드리지 않습니다: 먼저 덤프를 디스크에 기록하고, 백업은 그 덤프를 가져갑니다.

모든 것을 스크립트 하나에 담습니다. /usr/local/sbin/nb-backup.sh에 두고 실행 권한을 부여한 다음, 그 자체도 백업에 포함시키십시오:

#!/bin/sh
set -eu

# ---- 1. Consistent dumps, written where the include list will find them.
install -d -m 0700 /var/backups/db

# PostgreSQL in a container:
docker exec -t app-db pg_dumpall -U postgres | gzip -9 > /var/backups/db/postgres.sql.gz

# MariaDB / MySQL, InnoDB tables:
# docker exec -t mail-db mariadb-dump --single-transaction --all-databases \
#   | gzip -9 > /var/backups/db/mariadb.sql.gz

# SQLite — never a plain file copy:
# sqlite3 /opt/app/data/app.db ".backup '/var/backups/db/app.db'"

# ---- 2. The snapshot.
restic backup \
  --files-from /etc/backup/include.txt \
  --exclude-file /etc/backup/exclude.txt \
  --tag nightly --one-file-system

# ---- 3. Retention, then reclaim the space it freed.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

# ---- 4. Structural check every night; read 5% of the data on Sundays.
restic check
[ "$(date +%u)" = "7" ] && restic check --read-data-subset=5%

echo "backup ok: $(date -u +%FT%TZ)"

그 스크립트 안의 세 가지 세부 사항은 겉보기보다 훨씬 많은 일을 합니다. 맨 위의 set -eu는 덤프가 실패하면 실행을 중단시켜, 어제 덤프를 앞으로 6개월간 조용히 스냅샷으로 남기는 일을 막아줍니다. forget과 prune이 한 명령어로 묶여 있는 이유는, 공간을 회수하지 않는 보존 정책은 결국 가득 차는 디스크이기 때문입니다. 그리고 일요일 점검은 인덱스만이 아니라 실제 데이터의 일부를 읽습니다 — 저장소 손상은 드물고 조용하며, 이를 찾아내는 유일한 방법은 실제로 읽어보는 것뿐입니다.

타이머. 작은 유닛 파일 두 개. 여기서는 cron이 아니라 systemd가 올바른 스케줄러입니다. 타이머는 Persistent 옵션을 제공하기 때문입니다 — 머신이 꺼져 있던 동안 놓친 실행은 조용히 건너뛰어지는 대신 다음 부팅 시 실행됩니다 — 그리고 journalctl이 모든 실행 이력을 보관해주기 때문이기도 합니다.

/etc/systemd/system/nb-backup.service

[Unit]
Description=Nightly encrypted offsite backup
Wants=network-online.target
After=network-online.target docker.service

[Service]
Type=oneshot
EnvironmentFile=/etc/backup/restic.env
ExecStart=/usr/local/sbin/nb-backup.sh
Nice=10
IOSchedulingClass=idle

/etc/systemd/system/nb-backup.timer

[Unit]
Description=Nightly encrypted offsite backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=45m
Persistent=true

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now nb-backup.timer
systemctl list-timers nb-backup.timer
systemctl start nb-backup.service && journalctl -u nb-backup.service -n 40 --no-pager

무작위 지연은 장식이 아닙니다. 인터넷상의 모든 셀프호스팅 서버는 정확히 03:00에 유지보수를 실행하며, 로그 로테이션, 인증서 갱신, 컨테이너 업데이트와 정확히 같은 초에 시작하는 백업은 밤새 이들과 I/O를 두고 싸우게 됩니다. 시작 시각을 45분에 걸쳐 분산시키는 데는 아무 비용도 들지 않으면서, 원인 모를 밤샘 지연이라는 문제 유형 전체를 없애줍니다.

그런 다음, 실패를 요란하게 만드십시오. 이것은 모두가 건너뛰는 단계이지만, 위의 모든 것이 할 가치가 있었는지를 결정짓는 단계이기도 합니다. 작동을 멈춘 백업은 아무것도 알려주지 않습니다: 타이머는 계속 실행되고, 서비스는 계속 실패하며, 마지막으로 정상이었던 스냅샷은 점점 과거로 밀려나는데도 대시보드는 계속 초록색입니다. 실제로 눈에 띄는 알림을 보내는 OnFailure= 유닛을 서비스에 추가하고, 한 달에 한 번 스냅샷 목록 맨 위를 확인하십시오. 한 줄, 그리고 하나의 습관입니다.

restic snapshots --latest 3        # is the newest one from last night?
systemctl list-timers nb-backup.timer   # is the timer still armed?

지금까지의 모든 내용은 사고를 방어합니다. 이번 장은 공격자를 방어하며, 설계 문제는 한번 보고 나면 불편해집니다: 소스 머신은 매일 밤 저장소에 접속해야 하므로, 소스 머신은 저장소에 대한 작동하는 자격 증명을 가지고 있어야 합니다. 소스를 장악한 자가 그 자격 증명도 장악합니다. 자격 증명이 삭제할 수 있다면, 공격자도 삭제할 수 있습니다 — 그리고 최신 랜섬웨어는 무엇이든 암호화하기 전에 정확히 바로 이 일을 의도적으로 수행합니다. 복원 가능한 피해자는 몸값을 지불하지 않기 때문입니다.

해결책은 더 나은 비밀번호가 아닙니다. 비대칭 권한입니다: 소스는 데이터를 추가할 수는 있지만 제거할 수는 없습니다. 이를 구현하는 세 가지 방법을, 제대로 구현하기 쉬운 순서대로 소개합니다.

첫째 — SSH를 통한 강제 추가 전용 방식. 이것은 Borg의 홈그라운드이며, 여러분이 소유한 머신에서 얻을 수 있는 가장 깔끔한 답입니다. 3단계에서 만든 authorized_keys 항목이 borg serve --append-only를 강제하므로, 근단(near end)이 무엇을 요청하든 원단(far end)은 삭제를 거부합니다. 정리(pruning)는 여전히 필요하지만, 이는 목적지 쪽에서, 소스가 영향을 미칠 수 없는 일정에 따라, 소스가 접근할 수 없는 계정으로 실행됩니다. 소스에서 루트 권한을 얻은 공격자는 저장소를 쓰레기로 채울 수는 있어도, 자신이 도착하기 전날 밤의 아카이브는 지울 수 없습니다.

둘째 — 추가 전용 REST 엔드포인트. restic의 동반 도구인 rest-server에도 동일한 성질을 가진 --append-only 모드가 있습니다: 새 블롭은 받아들이지만 기존 블롭은 제거할 수 없습니다. 목적지에서 TLS 뒤에 이를 실행하고, RESTIC_REPOSITORY가 sftp: 대신 https:// URL을 가리키게 하면, 방어의 형태는 동일합니다. 목적지에 서비스 하나가 더 필요할 뿐, 얻는 보장은 똑같습니다.

셋째 — 오브젝트 락. S3 호환 스토리지에서는 버저닝과 오브젝트 락 보존 기간을 함께 쓰면, 프로그램이 아니라 스토리지 계층 자체가 강제하는 방식으로 그 기간이 끝날 때까지 삭제가 불가능해집니다. 세 가지 방법 중 가장 강력하지만 가장 비싸며, 제공업체 계정을 다시 끌어들입니다 — 이는 이 가이드 전체가 분산시키려던 바로 그 수탁 위험을 되돌려놓는 셈입니다. 세 번째 사본으로는 합리적이지만, 유일한 사본으로 쓰기에는 어색합니다.

이 중 어느 것도 맞지 않는다면 — 순수 SFTP, 즉 쓸 수 있어서 지울 수도 있는 키뿐이라면 — 그렇지 않은 척하지 말고, 소스가 전혀 손댈 수 없는 독립적인 두 번째 사본을 추가하십시오. push 대신 pull 방식을 쓰십시오: 목적지가 소스에 로그인해서 필요한 것을 읽고 저장하게 하는 것입니다. 그러면 자격 증명은 노출되지 않은 머신에 있게 되고, 소스에 있는 공격자는 백업을 가리키는 어떤 것도 찾지 못합니다. 설정하는 데 조금 더 손이 가지만, 위험을 정확히 옳은 방향으로 뒤집어 줍니다.

무엇을 선택하든, 다른 보안 통제를 검증할 때와 똑같은 방식으로 검증하십시오 — 실제로 깨뜨려 보는 것입니다. 소스에서 백업 키로 삭제를 시도해보십시오. 올바른 결과는 거부입니다.

borg delete ::name-of-an-old-archive
# → Remote: Repository is in append-only mode. Refusing to delete.

백업이 왜 다른 곳에 있어야 하는지 대부분의 사람에게 물으면 화재, 홍수, 혹은 데이터센터의 정전이라는 답이 돌아옵니다. 모두 사실이고, 모두 점점 더 드물어지고 있으며, 모두 백 킬로미터의 거리만으로 해결됩니다. 그러나 2026년에 실제로 비즈니스를 무너뜨리는 장애는 행정적인 것이며, 거리만으로는 이에 아무 대응도 되지 않습니다.

계정 하나는 단일 장애점입니다. 자동화된 사기 탐지 신호로 인한 정지, 비행기를 타고 있는 동안 발생한 지불 거절(chargeback), 컴플라이언스 심사, 머신이 아니라 회사 앞으로 도착한 삭제 요청(takedown) — 이 중 무엇이든 그 계정 아래 있는 모든 서버에 동시에 영향을 미치며, 스냅샷을 보관하는 서버도 예외가 아닙니다. 기술적 이중화는 완벽했지만 무의미해집니다. 이에 대한 유일한 대응 구조는 서로 다른 두 제공업체, 혹은 적어도 서로 다른 두 법적 주체 아래의 두 계정입니다.

관할권 하나는 하나의 법적 틀입니다. 네 곳의 노르딕 요새는 서로 바꿔 쓸 수 없습니다 — 스웨덴, 핀란드, 노르웨이, 아이슬란드는 각기 조금씩 다른 것을 보호하며, 노르웨이와 아이슬란드는 아예 유럽연합 밖에 있습니다. 작업 머신과 그 저장소를 이 중 두 곳에 나누어 두면, 사본이 단순히 다른 곳에 있는 것이 아니라 완전히 독립된 두 번째 규정 체계 아래 놓이게 됩니다. 노르딕 관할권 레퍼런스에서 법령을 하나씩 살펴봅니다.

그리고 목적지는 아무것도 알지 못합니다. 바로 이것이 분리를 트레이드오프가 아니라 저렴한 선택으로 만들어 주는 이유입니다. restic과 Borg 모두 데이터가 소스를 떠나기 전에 암호화하므로, 저장소 호스트는 자신이 열 수 없는 블롭을 보관할 뿐입니다. 어떤 파일을 담고 있는지도, 몇 개인지도, 이름이 무엇인지도 알지 못합니다. 여러분은 제3자에게 신뢰를 확장하는 것이 아니라, 자기 자신조차 읽을 수 없는 디스크를 빌리는 것입니다. 이는 “완전히 신뢰하지 않는 제공업체를 백업 대상으로 써도 되는가?”라는 질문에 대한 솔직한 답이기도 합니다 — 암호화된 저장소라면, 신뢰는 거의 개입할 여지가 없습니다.

지연 시간은 문제가 되지 않습니다. Helsinki에서 Reykjavík까지는 백본상으로 30 ms, Helsinki에서 Stockholm까지는 8 ms, Stockholm에서 Oslo까지는 11 ms입니다. 매일 밤 실행되는 백업은 이 숫자들 중 어느 것에도 신경 쓰지 않으며, 디스크 처리량에 의해 제한되는 복원 역시 마찬가지입니다. 네트워크 거리가 아니라 법적 거리를 기준으로 짝을 선택하십시오 — 노르딕 지역 안에서 네트워크 거리는 반올림 오차 수준에 불과합니다.

한 가지 더 분명히 짚어둘 가치가 있습니다. 이것이 바로 이 가이드가 일반적인 시스템 관리자 블로그가 아니라 이 사이트에 실려 있는 이유이기 때문입니다: 두 번째 머신은 첫 번째 머신이 이미 답했던 모든 질문을 다시 열어놓습니다. 작업용 VPS를 신분증 없이 Monero로 결제해 주문했는데, 그것을 위한 백업 서버는 법인 카드와 여권 스캔본으로 주문했다면, 이 쌍은 정확히 더 약한 절반만큼만 식별 불가능합니다. 익명 VPS 호스팅 축 가이드는 가입, 결제, 네트워크라는 세 개의 층을 다루며, 이는 웹 서버와 마찬가지로 백업 대상에도 그대로 적용됩니다.