VPS를 활용한 오프사이트 백업 구축 방법

오프사이트 백업 대상의 실체

오프사이트 백업 대상이란 원본과 독립적으로 장애가 발생하는 데이터 복사본을 보관하는 두 번째 머신을 의미하며, 다른 제공업체의 VPS를 사용하는 것이 대부분의 독자가 선택할 수 있는 가장 저렴한 방법입니다. 현실적인 형태는 세 가지입니다. VPS에서 실행되는 Proxmox Backup Server, SSH나 S3를 통해 접근하는 restic 저장소, 또는 백업 호스트가 데이터를 가져오는 rsync 미러입니다. 어떤 방식이 적합한지는 무엇을 복구해야 하는지, 그리고 얼마나 빠르게 복구해야 하는지에 따라 결정됩니다. 복사본을 삭제할 권한을 누가 갖느냐에 따라 나머지 세부 사항이 결정됩니다.

오프사이트란 서로 다른 장애 도메인을 의미합니다. 즉, 다른 제공업체를 이용해야 하며, 서버를 운영하는 계정과 로그인 정보를 공유하지 않는 별도의 계정을 사용해야 합니다. 같은 제공업체의 다른 리전에 있는 두 번째 서버는 특정 건물의 화재로부터는 안전할 수 있습니다. 하지만 제어 패널 계정이 탈취당하면 두 복사본을 모두 제어할 수 있으므로 안전하지 않습니다.

제공업체에서 제공하는 스냅샷은 이러한 두 번째 복사본이 아닙니다. 스냅샷은 동일한 패널 비밀번호로 보호되므로, 해당 비밀번호를 탈취한 공격자는 한 번의 세션으로 서버와 스냅샷을 모두 삭제할 수 있습니다. 또한 스냅샷 서비스는 일반 디스크보다 훨씬 비싼 기가바이트당 월간 요금을 청구하므로, 90일 치를 보관하는 것은 비용 부담이 큽니다. VPS 스냅샷과 백업의 차이를 읽어보고 의존 여부를 결정하는 것이 좋습니다.

어떤 방식이 적합한가

• Proxmox Backup Server (PBS): 소스는 Proxmox VE(가상 환경)이며, 복구 대상은 가상 머신 전체입니다. 디스크 이미지 수준에서 백업을 수행하며, 검증 작업 시 대상에 저장된 데이터를 다시 읽어 확인합니다.
• restic 저장소: 소스는 하나 이상의 Linux 호스트이며, 복구 대상은 디렉터리나 데이터베이스 덤프입니다. 클라이언트 측에서 암호화가 이루어지며, SSH와 S3, 그리고 자체 REST 프로토콜을 지원합니다.
• SSH를 통한 rsync (백업 호스트에서 가져오기): 대상 서버에 일반 파일 형태로 데이터를 저장하고자 할 때 사용합니다. ls 및 cat로 읽을 수 있으며, 데이터를 복구할 때 별도의 클라이언트 소프트웨어가 필요하지 않습니다.

결정을 내리기 어렵다면 restic을 사용하십시오. 데이터가 서버를 떠나기 전에 암호화되며, 대상 서버에는 SSH 계정과 디스크 공간만 있으면 충분합니다. VPS에서 restic 백업 설정하기에서 클라이언트 측 설정을 더 자세히 다루며, restic과 BorgBackup 비교에서는 이미 Borg를 사용 중인 경우의 선택 기준을 설명합니다.

대상 크기 산정: 1개월 보관 비용

중복 제거(deduplication) 기술 덕분에 예상보다 적은 용량이 사용됩니다. restic과 PBS는 파일을 가변 크기 청크로 분할하고 각 청크의 해시를 생성합니다. 고유한 청크는 한 번만 저장됩니다. 500 GB 데이터셋을 두 번째로 백업할 때 500 GB가 추가되지 않습니다. 변경된 청크만 추가됩니다.

따라서 저장소 크기는 스냅샷의 개수가 아니라 가장 오래된 스냅샷의 시점에 따라 결정됩니다. 500 GB 데이터가 있고 매일 5 GB의 새로운 고유 데이터가 발생한다고 가정합니다. 저장소는 500 GB의 기본 데이터와 정책상 보관하는 가장 오래된 스냅샷까지의 일수만큼 매일 약 5 GB를 추가로 보유합니다.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

달러 열은 해당 저장소의 비용을 TB당 월 10 US 달러로 계산합니다. 이는 계산을 위한 예시일 뿐 특정 제공업체의 견적이 아니므로, 고려 중인 요금제의 실제 TB당 가격을 대입하십시오. 1주일간의 일일 백업은 약 535 GB를 차지합니다. 1년 치 전체 기록은 2,325 GB이며, 이는 1주일 치 비용인 $5.35와 비교하여 월 $23.25가 됩니다. 기록 보관은 저렴합니다. 비용의 대부분은 기본 복사본에서 발생합니다.

이미 압축되거나 암호화된 데이터에는 중복 제거가 효과가 없습니다. gzipped 데이터베이스 덤프는 실행할 때마다 내용이 완전히 바뀌므로, 각 덤프는 새로운 청크로 저장되어 매일 덤프 전체 크기만큼 저장소가 증가합니다. 덤프를 압축하지 않은 상태로 작성하고 백업 도구가 압축하게 하십시오. restic은 0.14 버전부터 압축 저장소를 지원하며, 0.19 버전에서는 fastest 및 better zstd 모드가 추가되었습니다. 사진 및 동영상 라이브러리도 같은 이유로 중복 제거 효율이 낮으므로, 위의 행을 참고하지 말고 실제 증가율을 기준으로 크기를 산정하십시오.

여기서는 CPU보다 유휴 디스크를 구매하는 것이며, 이는 스토리지 VPS가 일반 VPS보다 유리한 경우입니다.

대역폭과 복구 시간이 요금제를 결정하는 이유

디스크 비용은 저렴합니다. 첫 업로드와 최종 복구 과정이 비용을 결정하는 핵심 요소입니다. 500 GB는 4조 비트에 해당하므로, 이 값을 회선 속도로 나누면 전체 복구에 걸리는 최소 시간을 산출할 수 있습니다.

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

위 수치는 프로토콜 오버헤드를 제외한 회선 속도 기준이므로, 가장 이상적인 상황으로 간주해야 합니다. 100 Mbit/s 환경에서 전체 복구를 완료하려면 데이터를 사용하기 전까지 11.1 시간이 필요합니다. 가정용 40 Mbit/s 업로드 속도라면 27.8 시간이 소요됩니다. 1 Gbit/s 포트에서는 동일한 복구에 1.1 시간이 걸립니다. 파일 크기가 수백 킬로바이트 미만일 때는 파일당 오버헤드가 커지므로, 실제 복구 속도는 산술적인 계산보다 느려집니다.

여기서 두 가지 사실을 알 수 있습니다. 허용 가능한 서비스 중단 시간인 복구 목표 시간(RTO)이 4시간이라면, 100 Mbit/s 회선으로 500 GB를 복구하는 것은 이미 목표를 달성할 수 없으며, 더 저렴한 디스크를 사용해도 해결되지 않습니다. 또한 대부분의 VPS 요금제는 아웃바운드 트래픽을 제한하므로, 전체 복구를 한 번만 수행해도 백업 호스트의 월간 데이터 허용량 중 0.5 TB를 소모하게 됩니다. 데이터를 복구해야 하는 상황이 오기 전에 해당 허용량을 확인하고, 초과 시 제공업체가 어떤 조치를 취하는지 미리 파악하십시오.

첫 번째 백업은 전체 데이터셋을 대상으로 수행하며, 가장 오랜 시간이 걸리는 작업입니다. 금요일에 시작하고, 원본 서버의 업링크가 포화되지 않도록 속도를 제한하십시오. restic은 --limit-upload(KiB/s 단위) 옵션을 사용하고, rsync는 --bwlimit 옵션을 사용합니다.

형태 1: 원격 데이터스토어로 사용하는 Proxmox Backup Server

소스가 Proxmox VE이고 복구 단위가 가상 머신일 때 PBS가 적합합니다. VPS는 Proxmox ISO로 부팅할 수 없으므로 Debian 위에 PBS를 설치하십시오. 2026년 8월 기준 최신 버전은 4.2이며 Debian 13 (trixie)을 기반으로 합니다.

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

해당 체크섬을 Proxmox 패키지 저장소 페이지에 게시된 값과 비교하십시오. apt 저장소는 검증한 키만큼만 신뢰할 수 있습니다. 그런 다음 /etc/apt/sources.list.d/proxmox.sources을 작성하십시오:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

데이터스토어에 별도의 파일 시스템이나 볼륨을 할당하십시오. 데이터스토어가 가득 차면 백업이 중단되며, 루트 파일 시스템을 공유하는 데이터스토어가 가득 차면 서버 전체가 다운됩니다.

다음으로 소스에서 사용할 계정을 생성하고, 비밀번호 대신 토큰을 부여하십시오.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

토큰 시크릿은 한 번만 출력되며 다시 읽을 수 없으므로 나타날 때 저장하십시오. 역할은 토큰만큼 중요합니다. DatastoreBackup는 자신의 백업을 생성하고 복구할 수 있으며, Datastore.Prune 권한을 가지지 않으므로 해당 토큰은 자신이 작성한 스냅샷을 삭제할 수 없습니다.

PBS의 보존 정책은 두 부분으로 나뉘며, 사람들은 종종 두 번째 부분을 간과합니다. Prune은 스냅샷을 제거합니다. Garbage collection은 살아남은 스냅샷이 참조하지 않는 청크를 제거합니다. 여유 공간은 Prune이 아닌 Garbage collection 이후에 확보됩니다.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

제거할 스냅샷 목록이 올바른지 확인한 후 --dry-run을 실행하십시오. Garbage collection은 두 단계로 진행됩니다. 먼저 참조 중인 모든 청크의 접근 시간을 업데이트한 다음, 접근 시간이 실행 시작 24시간 5분 이전인 청크를 삭제합니다. 이 유예 기간은 진행 중인 백업이 작성 중인 청크가 삭제되는 것을 방지하기 위해 존재합니다. 데이터스토어에서 Prune은 매일, Garbage collection은 매주 실행되도록 예약하십시오. 또한 대상이 자신의 청크를 다시 읽고 복구 전에 디스크 손상을 보고하도록 검증 작업을 추가하십시오.

소스 자체가 PBS 인스턴스인 경우, 오프사이트 장비가 데이터를 밀어넣는(push) 대신 가져올(pull) 수 있습니다.

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

기본 pull 방향으로 VPS에서 해당 동기화 작업을 실행하십시오. VPS가 홈 데이터스토어에 접근하므로, 홈 장비는 오프사이트 복사본에 접근할 수 있는 자격 증명을 보유하지 않게 됩니다.

형태 2: SSH 또는 S3를 이용한 restic 저장소

Debian과 Ubuntu 모두 restic 패키지를 제공하지만, 업스트림 버전보다 뒤처져 있습니다. 2026년 8월 기준으로 0.19.1 버전이 최신입니다. 소스 호스트에 공식 바이너리를 설치하십시오.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version은 버전과 빌드에 사용된 Go 컴파일러 정보를 출력합니다. 이후 업그레이드는 sudo restic self-update 명령을 사용하며, 이는 공식 바이너리에서만 작동하고 apt로 설치한 복사본에서는 작동하지 않습니다.

백업용 VPS에 다른 권한이 없는 전용 계정을 생성한 뒤, 소스 호스트의 공개 키를 /home/resticsrv/.ssh/authorized_keys에 복사하십시오.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

SFTP를 통해 소스에서 저장소를 초기화하십시오.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

해당 비밀번호는 이 서버나 백업 대상 서버가 아닌 다른 곳에 보관하십시오. 비밀번호를 분실하면 저장소는 복구할 방법이 전혀 없으며 읽을 수 없게 됩니다. 이것이 클라이언트 측 암호화가 사용자에게 요구하는 조건입니다.

보관 정책은 하나의 명령으로 수행하며, 그 뒷부분은 디스크 공간을 확보하는 역할을 합니다.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget은 스냅샷을 삭제합니다. prune은 해당 스냅샷만 참조하던 팩 파일을 삭제하며, --prune는 실제로 삭제된 항목이 있을 때 이를 자동으로 실행합니다. 이 옵션이 없으면 저장소 크기는 줄어들지 않습니다. restic check은 저장소 구조를 검증하며, --read-data-subset=10%는 팩 파일의 10분의 1을 다시 읽고 해시를 계산하여 전체를 읽는 비용 없이 대상의 손상을 감지합니다. 다른 형태인 --read-data-subset=1/10는 고정된 10분의 1을 확인하므로, 매주 첫 번째 숫자를 증가시키면 10주에 걸쳐 전체 저장소를 확인할 수 있습니다.

실행이 강제로 종료되면 다음 실행은 repository is already locked exclusively by PID 오류와 함께 중단됩니다. 백업이 실행 중이지 않음을 확인한 후 restic unlock 명령으로 잠금을 해제하십시오.

객체 스토리지의 경우 저장소 문자열은 s3:https://s3.example.net/web1이 되며, 자격 증명은 AWS_ACCESS_KEY_ID 및 AWS_SECRET_ACCESS_KEY에 저장합니다. 그 외 모든 과정은 동일하며, 이것이 restic이 동일한 VPS에서 실행 중인 자체 호스팅 MinIO 객체 스토리지와 통신하는 방식입니다.

형태 3: SSH를 통한 rsync와 읽기 전용 키

이 형태의 보안 속성은 방향성에 있습니다. 백업 VPS가 소스 서버에 연결하여 데이터를 읽어옵니다. 소스 서버는 백업 호스트에 대한 키나 경로를 가지고 있지 않으므로, 소스 서버가 침해되더라도 백업 데이터에는 전혀 접근할 수 없습니다.

백업 VPS에서 키 쌍을 생성한 뒤, 강제 명령(forced command)을 사용하여 공개 키를 소스 서버에 설치하십시오.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync은 Debian 13 및 Ubuntu 24.04의 /usr/bin/rrsync 경로에 있는 rsync 패키지에 포함되어 있습니다. -ro은 읽기 전용 접근만 허용하며 -no-del를 내포하므로, 이 키를 사용하여 소스 서버에 데이터를 쓰거나 삭제할 수 없습니다. restrict는 포트 포워딩 및 pty를 포함하여 이 작업에 불필요한 SSH 기능을 비활성화하므로, 이 키를 대화형 로그인에 사용할 수 없습니다. 경로는 지정한 디렉터리를 기준으로 상대 경로로 처리되므로, 원격 경로 /은 소스 서버의 /srv을 의미합니다.

데이터를 가져올 때는 하드링크를 사용하여 이력을 보관합니다. 새로운 트리에서 변경되지 않은 파일은 이전 트리의 파일과 하드링크로 연결되므로, 파일을 복사하지 않고 디렉터리 항목만 추가되어 용량을 절약합니다.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

마지막에 수행하는 이름 변경 작업은 날짜별 디렉터리의 신뢰성을 보장합니다. rsync가 종료 코드 0으로 완료된 후에만 디렉터리 이름이 생성되므로, 전송이 중단된 경우 완료된 스냅샷처럼 보이지 않습니다. 오래된 트리는 한 줄의 명령어로 삭제하여 30개만 유지하십시오.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

이 형태의 비용에 대해 명확히 인지해야 합니다. 하드링크는 파일 단위로만 중복을 제거하므로, 4 GB 디스크 이미지 내에서 1바이트만 변경되어도 전체 4 GB가 다시 복사됩니다. 반면 restic이나 PBS는 변경된 청크만 저장합니다. 또한 대상 서버에 파일이 평문으로 저장되므로, 백업 VPS의 root 권한을 가진 사용자는 누구나 파일을 읽을 수 있습니다.

클라이언트 측 암호화: 대상 서버가 평문을 볼 수 없도록 설정

백업용 VPS를 완전히 통제할 수 없는 장비로 간주하십시오. VPS에는 제공자가 있으며, 제공자의 직원이나 고장 난 디스크가 외부로 반출될 가능성이 존재합니다.

restic은 데이터를 전송하기 전 소스에서 모든 청크를 암호화하므로, 저장소에는 암호문과 크기 및 타이밍에 관한 메타데이터만 남습니다. PBS는 암호화를 선택 사항으로 제공합니다. 키를 생성한 뒤 모든 백업 작업 시 해당 키를 전달하십시오.

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

종이로 된 키를 출력하여 물리적인 장소에 보관하십시오. Proxmox 문서에서는 이 위험성을 명확히 경고합니다. 키가 없으면 백업된 파일에 접근할 수 없습니다. 키를 백업 대상 서버에 보관하지 마십시오. 암호문 옆에 보관된 키는 아무런 보호 기능을 제공하지 못합니다.

rsync 미러에는 이에 대응하는 기능이 없습니다. 파일은 그대로 파일 형태로 저장됩니다. 데이터가 민감하다면 대상 서버가 이를 읽을 수 있음을 감수하거나, 앞서 언급한 다른 두 가지 방식 중 하나를 사용해야 합니다.

침해된 소스 서버가 자체 백업을 삭제하지 못하도록 방지하기

소스 서버를 장악한 공격자는 다음으로 백업을 찾으려 하며, 백업을 업로드하는 자격 증명은 해당 머신에 그대로 저장되어 있습니다. 만약 해당 자격 증명으로 삭제까지 가능하다면 공격자는 이를 악용할 것입니다.

PBS는 역할(role)을 통해 이 문제에 대응합니다. DatastoreBackup 권한만 가진 토큰은 새로운 스냅샷을 작성하고 자신의 스냅샷을 복원할 수는 있지만, 스냅샷 삭제에는 별도의 Datastore.Prune 권한이 필요하므로 삭제를 수행할 수 없습니다. 보존 정책(retention)을 PBS 측에서 실행하면, 소스 서버는 데이터를 삭제할 수 있는 자격 증명을 전혀 보유하지 않게 됩니다.

SFTP를 사용하는 restic은 이러한 권한 분리가 불가능합니다. 리포지토리에 데이터를 쓰는 SSH 키가 리포지토리 내의 데이터를 삭제할 수도 있기 때문입니다. 이에 대한 해결책은 REST 백엔드를 사용하는 것입니다. 백업 VPS에서 --append-only 옵션으로 rest-server를 실행하면 새로운 백업 생성은 허용하되 기존 데이터의 삭제 및 수정은 방지할 수 있습니다. 클라이언트에서는 rest:https://backup.example.net:8000/web1을 사용하여 RESTIC_REST_USERNAME 및 RESTIC_REST_PASSWORD을 설정하면 됩니다. 이때 소스 서버에서 restic forget --prune를 실행하면 실패하게 되는데, 이는 의도된 결과입니다. 따라서 보존 정책은 별도의 자격 증명을 가진 두 번째 머신에서 실행해야 합니다. 또한 restic 매뉴얼은 추가 전용(append-only) 리포지토리에서 개수 기반 정책 대신 --keep-within를 사용할 것을 권장합니다. 공격자가 쓰레기 스냅샷으로 리포지토리를 가득 채워 실제 백업본이 --keep-last 기간을 벗어나 밀려나는 상황을 방지하기 위함입니다.

rsync는 소스 서버가 타겟에 대한 자격 증명을 보유하지 않는 '풀(pull)' 방식을 통해 동일한 문제를 구조적으로 해결합니다.

세 가지 방식 모두 하나의 규칙으로 요약됩니다. 백업을 삭제할 수 있는 자격 증명은 백업 대상이 아닌 다른 머신에 두어야 합니다.

복구 훈련을 일정에 포함하십시오

한 번도 복구해 본 적 없는 백업은 가설에 불과합니다. 매 분기마다 1시간을 할애하여 테스트하십시오.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r 명령이 아무것도 출력하지 않는다면 복구된 트리와 실제 데이터가 일치한다는 의미입니다. PBS에서는 동일한 훈련을 proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/ 명령으로 수행하며, 대상의 청크를 다시 읽어 체크섬 오류를 보고하는 예약된 검증 작업이 추가됩니다.

복구 훈련은 단순히 바이트가 온전하다는 것 이상의 사실을 증명해야 합니다.

• 원본 서버가 사라졌다고 가정하는 것이므로, 원본이 아닌 제3의 머신에서 복구하십시오. 즉, 저장소 암호나 PBS 키에 원본 없이도 접근할 수 있어야 합니다.
• 복구 시간을 측정하여 기록하고, 설정했던 RTO와 비교하십시오. 위 차트는 전송 하한선을 보여줍니다. 실제 복구 시간은 복호화 및 디스크 쓰기 시간, 그리고 필요한 스냅샷을 찾는 데 소요된 시간을 포함합니다.
• 데이터베이스 덤프와 같이 상태를 가진 데이터를 복구한 뒤, 이를 임시 인스턴스에 로드해 보십시오. 단순히 tar 파일이 압축 해제된다고 해서 애플리케이션이 정상적으로 시작된다는 증거는 되지 않습니다.

세상에서 가장 저렴한 디스크라도 한 번이라도 복구에 성공하기 전까지는 아무런 가치가 없습니다.

FAQ

VPS 제공업체의 스냅샷은 오프사이트 백업인가요?

아닙니다. 제공업체의 스냅샷은 서버와 동일한 계정, 동일한 관리 패널, 동일한 청구서 내에 존재합니다. 해당 계정의 로그인 권한을 탈취한 공격자는 서버와 모든 스냅샷을 한 번에 삭제할 수 있습니다. 스냅샷은 위험한 업그레이드 전 빠른 롤백을 위해 유용할 뿐, 물리적으로 분리된 두 번째 저장소가 아닙니다. 오프사이트 백업은 다른 계정, 가급적 다른 제공업체에 위치해야 하며, 원본 서버가 접근할 수 없는 별도의 자격 증명을 사용해야 합니다.

한 달 치 백업을 보관하려면 디스크 용량이 얼마나 필요한가요?

스냅샷 개수가 아닌 가장 오래된 스냅샷의 보관 기간을 기준으로 산정하십시오. 중복 제거 도구는 고유한 데이터 조각을 한 번만 저장하므로, 저장소 크기는 대략 원본 데이터 크기에 '일일 변경되는 고유 데이터 용량 × 보관 일수'를 더한 값입니다. 500 GB 데이터에서 매일 5 GB가 변경된다면, 일주일 치 일간 백업은 약 535 GB이며 1년 치 이력은 2,325 GB가 됩니다. 디스크가 가득 차면 다음 백업이 실패하고, restic의 prune 작업 시 데이터를 재구성할 여유 공간이 필요하므로 충분한 여유 용량을 확보하십시오.

침해당한 서버가 자신의 오프사이트 백업을 삭제할 수 있나요?

네, 이를 방지하도록 설계하지 않았다면 가능합니다. 일반적인 SSH나 SFTP 저장소를 사용하면 쓰기 권한이 있는 키로 삭제도 가능합니다. 원본 서버에는 데이터를 삭제할 수 없는 자격 증명을 부여하십시오. 예를 들어 DatastoreBackup 역할만 부여하고 Datastore.Prune 권한은 제외한 PBS API 토큰을 사용하거나, --append-only 옵션으로 실행된 rest-server에 restic을 연결하여 기존 백업의 삭제 및 수정을 차단하십시오. 원본 서버가 백업 호스트에 대한 자격 증명을 전혀 가지지 않는 '풀(pull)' 방식의 설계를 적용하면 더욱 안전합니다. 보관 주기 관리(retention)는 원본 서버가 아닌 백업 호스트 측에서 수행하십시오.

백업용 VPS에 Proxmox Backup Server를 설치해야 하나요, 아니면 restic을 사용해야 하나요?

복구 단위에 맞춰 도구를 선택하십시오. 원본이 Proxmox VE이고 가상 머신 전체를 복구해야 한다면 디스크 이미지 수준에서 백업하고 한 번에 VM을 복구할 수 있는 PBS가 적합합니다. 원본이 Linux 호스트이고 파일이나 데이터베이스 덤프를 복구해야 한다면, 대상 서버의 SSH 계정만 있으면 되고 전송 전 암호화를 수행하는 restic이 적합합니다. 두 도구를 함께 사용하는 것도 일반적입니다. 하이퍼바이저는 PBS로, 그 위에서 동작하지 않는 서버들은 restic으로 백업하십시오.

VPS 백업에서 복구하는 데 얼마나 걸리나요?

데이터 크기를 네트워크 속도로 나눈 값이 이론적인 최소 시간이며, 여기에 복호화 및 쓰기 시간을 더해야 합니다. 100 Mbit/s 회선에서 500 GB를 복구할 경우 이론상 11.1 시간이 소요되며, 1 Gbit/s 포트에서는 1.1 시간이 소요됩니다. 파일 개수가 많으면 파일별 오버헤드로 인해 실제 속도는 이보다 느려집니다. 실제 복구 시간을 한 번 측정해 보십시오. 복구 계획은 오직 측정된 수치만을 신뢰할 수 있습니다.