VPS에 Proxmox Backup Server 설치 및 설정 가이드

VPS에서 Proxmox Backup Server를 운영할 때 얻는 이점

VPS에서 Proxmox Backup Server(PBS)를 운영하면 Proxmox VE(virtual environment) 클러스터가 이미 사용하는 것과 동일한 프로토콜을 지원하는 오프사이트 백업 대상을 확보하게 됩니다. 따라서 첫 번째 백업 이후의 모든 백업은 증분 방식으로 수행되며, 게스트 간 중복 제거가 적용되고, 외부로 전송되기 전에 암호화되며, 이후 검증이 가능합니다. 블록 볼륨이 포함된 VPS를 임대하여 Debian 13에 PBS를 설치하고, 해당 볼륨에 데이터스토어를 하나 생성한 뒤 Proxmox VE에서 pbs 유형의 스토리지로 추가하면 됩니다. 설치에는 10분 정도 소요됩니다. 설치 이후의 네임스페이스 관리, 가비지 컬렉션, 키 보관, 그리고 실제로 수행해 보는 복구 과정이 1년 뒤에도 해당 백업이 가치를 지닐지 결정합니다.

단순히 vzdump 파일을 임대 디스크로 복사하는 대신 PBS를 사용하는 이유는 청크 스토어(chunk store) 때문입니다. 클라이언트는 각 게스트 디스크를 약 4 MiB 크기의 청크로 분할하고 해시값을 생성한 뒤, 데이터스토어에 아직 존재하지 않는 청크만 업로드합니다. 실행 중인 가상 머신의 경우, 첫 번째 백업 이후 QEMU가 dirty bitmap을 통해 변경된 블록을 추적하므로 다음 백업 시에는 로컬 디스크에서 해당 블록만 읽어옵니다. 하루에 3 GB가 변경되는 200 GB 게스트는 하루에 약 3 GB만 전송합니다. 바로 이 점이 가정용 업링크와 임대 볼륨을 효율적으로 결합하게 해주며, 오프사이트 백업 대상으로 VPS를 사용하는 것이 지인의 집에 둔 여분 드라이브보다 나은 이유입니다. 하이퍼바이저 자체를 어디에 둘지 고민 중이라면 가정용 Proxmox와 임대 VPS 비교에서 해당 내용을 별도로 다룹니다.

볼륨을 임대하기 전에 크기 산정하기

크기 산정은 본인의 데이터를 바탕으로 수행하는 산술 작업입니다. 가상 디스크의 크기가 아니라 각 게스트가 실제로 사용하는 공간을 기준으로 삼고, 여기에 하루 동안 변경되는 데이터 양에 보관 일수를 곱한 값을 더합니다. 압축과 중복 제거는 이 수치를 개선하므로, 계산된 결과는 목표치가 아닌 상한선으로 간주하십시오.

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

위 행들은 예시일 뿐 실제 측정값이 아닙니다. 각 게스트 내부의 df -h에서 사용 중인 공간을 확인하고, PBS 작업 로그에 두 번째 및 세 번째 백업이 생성된 이후 해당 로그에서 일일 변경량을 확인하십시오.

예시의 메일 게스트는 120 GB를 사용하며 하루에 약 3.0 GB씩 변경되므로, 30일간의 스냅샷을 유지하려면 전체 복사본 1개와 30일간의 변경분을 합쳐 대략 210 GB가 필요합니다. 모든 3개 게스트에 대해 마지막 열을 합산하면 총합은 약 619 GB가 됩니다. 여기에 인덱스, 메타데이터, 그리고 가비지 컬렉션(garbage collection)이 원활하게 작동하기 위한 여유 공간으로 20%를 추가하면 1 TB 볼륨이 적절합니다.

나머지 계획은 간단합니다. PBS는 2 GB RAM으로도 충분히 작동하며 4 GB라면 쾌적합니다. 이는 부하가 큰 작업이 클러스터 측에서 발생하기 때문입니다. Proxmox VE 노드가 게스트 디스크를 읽어 청크(chunk) 단위로 나누고 해싱(hashing)을 수행합니다. VPS가 수행하는 작업은 청크를 기록하고 가비지 컬렉션과 검증(verification)이라는 두 가지 무거운 작업을 실행하는 것입니다. 데이터스토어는 하나의 큰 루트 디스크보다는 별도의 블록 볼륨으로 임대하십시오. 나중에 서버를 재구축하지 않고도 볼륨을 확장할 수 있기 때문입니다.

Debian 13에 Proxmox Backup Server 설치하기

2026년 8월 기준으로 현재 조합은 Debian 13(코드네임 trixie) 기반의 Proxmox Backup Server 4입니다. 이전 가이드들은 PBS 2와 Debian 11을 조합하며, 코드네임은 저장소 정의의 일부이므로 오래된 제품군 이름을 복사하면 apt에서 릴리스 파일을 찾을 수 없다는 오류가 발생합니다. 깨끗한 Debian 13 이미지에서 시작하십시오. 아래의 모든 명령은 root 권한으로 실행하거나 명시된 대로 sudo을 사용하십시오.

sudo apt update && sudo apt install -y wget
sudo 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

체크섬 값은 반드시 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45이어야 합니다. 일치하지 않으면 중단하십시오. 잘못된 키링은 검증되지 않은 서명으로 패키지를 설치하려는 것임을 의미합니다.

지원 계약이 없는 서버에 적합한 no-subscription 저장소를 사용하여 /etc/apt/sources.list.d/pbs.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

웹 인터페이스는 HTTPS 포트 8007에서 응답합니다. PBS는 운영체제와 동일한 계정인 PAM(pluggable authentication modules)을 통해 사용자를 인증하므로, 시스템 root 암호를 사용하여 root@pam으로 로그인하십시오. 인증서는 자체 서명되었으므로 브라우저에서 경고가 표시됩니다. 해당 인증서의 지문(fingerprint)은 나중에 Proxmox VE가 고정(pin)할 값이므로, 이 경고는 해결해야 할 문제가 아니라 예상된 동작입니다.

포트 8007은 공용 인터넷에 노출된 로그인 폼이므로 모든 사용자에게 열어두지 마십시오. 하나의 nftables 파일로 이를 제어할 수 있습니다. /etc/nftables.conf을 작성하면 현재 규칙 세트가 초기화되므로, 이 서버에서 다른 도구가 방화벽을 관리하고 있다면 이 단계를 건너뛰십시오.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

sudo systemctl enable --now nftables를 사용하여 규칙을 적용하십시오. 작업을 수행하는 동안 두 번째 SSH 세션을 열어두십시오. policy drop과 SSH 규칙의 오타 하나가 서버 접속을 차단할 수 있습니다. 203.0.113.7를 클러스터가 출발하는 주소로 바꾸십시오. 해당 주소가 유동적이라면 규칙을 공급자의 범위로 넓히거나 터널을 통해 연결을 종료하십시오. 대부분의 VPS 패널은 장비 앞단에 별도의 네트워크 방화벽을 두고 있으며, 해당 방화벽에서도 동일한 포트를 허용해야 한다는 점을 기억하십시오.

데이터스토어를 별도의 볼륨에 배치하기

데이터스토어는 루트 파일 시스템에 위치해서는 안 됩니다. 데이터스토어가 공유 루트 파일 시스템을 가득 채우면 백업이 실패하며, 원인 파악에 필요한 로깅을 포함한 서버의 모든 기능이 중단됩니다. 블록 볼륨을 연결하고, 포맷하고, 마운트한 뒤에야 마운트 지점 내부에 데이터스토어를 생성하십시오.

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

lsblk에서 장치 이름을 확인하십시오. 대부분의 KVM 이미지에서는 /dev/vdb이며 다른 이미지에서는 /dev/sdb이지만, 이를 단정하는 것은 위험합니다. 재부팅 후 장치 이름이 변경되어 데이터스토어가 잘못된 디스크를 가리키는 일을 방지하기 위해, /etc/fstab에 레이블을 기준으로 마운트 설정을 추가하십시오:

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt는 장치, 경로, 그리고 rw,relatime을 포함한 옵션을 출력해야 합니다. 이 한 줄에는 두 가지 실패 요인이 숨어 있습니다. 마운트가 되지 않은 상태에서 데이터스토어를 생성하면, PBS는 마운트 지점 아래의 루트 파일 시스템에 데이터를 기록합니다. 이후 마운트가 성공하면 기존 데이터는 삭제되지 않은 채 가려지게 되며, 데이터스토어는 비어 있는 것처럼 보이고 루트 파일 시스템은 여전히 가득 찬 상태로 남습니다. 옵션에 noatime이 포함되어 있으면 PBS는 작동을 거부합니다. 데이터스토어 생성 시점과 모든 가비지 컬렉션 수행 시점에 접근 시간 안전성 검사를 실행하기 때문입니다.

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

이 작업은 0000부터 ffff까지 명명된 65536개의 하위 디렉터리를 포함하는 .chunks 디렉터리를 생성합니다. 데이터스토어는 몇 개의 큰 파일이 아니라 수십만 개의 작은 파일로 구성됩니다. 따라서 두 가지 사실이 뒤따릅니다. 일반적인 파일 수준 도구로 데이터스토어를 복사하는 것은 너무 느려 사용할 수 없으며, 백업이 실행되는 동안 생성된 공급자 볼륨 스냅샷은 일관된 복사본이 아닙니다. 이는 다른 환경에서 스냅샷이 백업을 대체할 수 없는 이유와 같습니다.

네임스페이스를 통한 호스트 간 충돌 방지

데이터 저장소는 기본적으로 평면 구조입니다. 백업은 vm/100, ct/101, host/<name>와 같은 이름으로 저장됩니다. ID가 100인 게스트를 가진 두 클러스터가 동일한 그룹에 데이터를 쓰면 스냅샷이 서로 섞이게 되며, 한쪽을 위해 작성한 보존 규칙이 다른 쪽의 스냅샷까지 계산하게 됩니다. 네임스페이스를 사용하면 하나의 데이터 저장소 안에서 각 소스마다 고유한 트리 구조를 할당할 수 있습니다.

PBS 호스트에서 네임스페이스를 생성하십시오. --repository 인자는 [[auth-id@]server[:port]:]datastore 형식을 따르므로, 로컬 네임스페이스는 root@pam@localhost:store1과 같이 지정하며, 이 명령은 루트 비밀번호를 요구합니다.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

중복 제거(deduplication) 기능은 이러한 분할의 영향을 받지 않습니다. 청크는 전체 데이터 저장소에서 공유되므로, 세 개의 네임스페이스에 분산된 10개의 Debian 게스트라 하더라도 기본 시스템은 단 한 번만 저장됩니다. 이것이 호스트당 하나의 데이터 저장소를 두는 것보다 네임스페이스를 사용하는 하나의 데이터 저장소를 권장하는 이유입니다. 데이터 저장소를 분리하면 청크 풀도 분리되며, 청크 풀이 분리되면 동일한 Debian 설치본에 대해 중복으로 비용을 지불하게 되기 때문입니다.

각 소스에 고유한 네임스페이스로 범위가 제한된 별도의 계정을 할당하십시오. API(애플리케이션 프로그래밍 인터페이스) 토큰은 사용자에게 귀속되며 자체 권한을 가진 자격 증명으로, 도난 위험이 있는 장비에서 사용하기에 적합합니다.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

토큰 명령은 비밀 값을 단 한 번만 출력합니다.

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

PBS는 이 값을 다시 보여줄 수 있는 형태로 저장하지 않으므로 지금 즉시 복사하십시오. 접근 제어 명령을 주의 깊게 확인하십시오. 이 명령은 사용자 이름이 아닌 토큰 이름인 backup@pbs!pve-home을 지정합니다. 토큰 권한은 토큰 자체를 명시한 항목에서만 계산되기 때문입니다. backup@pbs에 대한 항목만 설정하면 해당 토큰은 아무런 접근 권한을 갖지 못하며, 첫 번째 백업은 네트워크상의 문제가 아닌 권한 문제로 실패하게 됩니다. 경로 또한 중요합니다. /datastore/store1/pve-home으로 범위가 제한된 토큰은 office 네임스페이스의 어떤 데이터도 읽거나 삭제할 수 없으므로, 한 클러스터가 침해당하더라도 다른 사이트의 기록을 파괴할 수 없습니다.

Proxmox VE에 백업 저장소로 VPS 추가하기

먼저 PBS 호스트에서 인증서 지문을 확인합니다.

sudo proxmox-backup-manager cert info | grep Fingerprint

그다음 클러스터의 아무 노드에서 다음을 실행합니다.

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

세 번째 줄의 플레이스홀더 위치에 cert info 값을 붙여넣습니다. --password에 값을 지정하지 않으면 pvesm이 입력을 요구하므로, 토큰 비밀값이 셸 기록에 남지 않습니다. 이 값은 /etc/pve/priv/storage/pbs-offsite.pw에 저장되며, 저장소 정의 자체는 /etc/pve/storage.cfg에 기록됩니다. 이 파일은 클러스터의 모든 노드로 복제되므로 한 번만 설정하면 전체 클러스터에 적용됩니다.

--prune-backups keep-all=1는 Proxmox VE에 아무것도 삭제하지 말라고 지시합니다. 보존 정책은 PBS 측에서 관리하며, 이에 대한 이유는 명확합니다. 토큰에 삭제 권한이 없으면 랜섬웨어에 의해 클러스터가 암호화되더라도, 공격자가 원격 저장소의 백업 기록을 삭제할 수 없기 때문입니다.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status을 실행하면 상태 열에 active이 표시되며, 데이터스토어의 전체 용량과 사용량이 함께 나타납니다. inactive가 표시된다면 노드가 8007 포트로 TLS(전송 계층 보안) 세션을 완료하지 못한 것입니다. 이는 자격 증명 문제라기보다 방화벽이나 인증서 지문 문제일 가능성이 높습니다.

첫 번째 백업은 모든 데이터를 업로드하므로 시작 전에 계산을 해보아야 합니다. 200 GB는 1600 기가비트이며, 100 Mbit 업링크는 초당 0.1 기가비트를 전송하므로 최소 4시간 반 이상이 소요되며 실제로는 더 오래 걸릴 수 있습니다. 대역폭 사용이 적은 시간에 시작하십시오. 이후 실행부터는 새로운 청크만 전송됩니다.

클라이언트 측 암호화와 키 보관 위치

VPS는 사용자가 소유하지 않은 컴퓨터입니다. 클라이언트에서 암호화를 수행하면 데이터 저장소에는 제공자가 읽을 수 없는 데이터 조각만 저장됩니다.

sudo pvesm set pbs-offsite --encryption-key autogen

이 명령은 /etc/pve/priv/storage/pbs-offsite.enc에 새로운 키를 기록합니다. 이 파일은 root만 읽을 수 있으며, /etc/pve의 나머지 데이터와 함께 복제됩니다. 다음 백업부터는 클라이언트가 각 데이터 조각을 외부로 전송하기 전에 암호화합니다. 서버는 여전히 스냅샷 목록과 그 크기를 확인할 수 있지만, 내용을 읽을 수는 없습니다.

이제 백업을 부채가 아닌 자산으로 만드는 부분을 다룹니다. 생성된 키에는 암호가 없으며, 보호 대상인 클러스터 내에만 존재합니다. 만약 클러스터를 도난당하거나 타인에 의해 암호화되더라도, VPS에는 아무도 열 수 없는 데이터만 남게 됩니다. 키를 생성한 당일에 클러스터 외부로 복사해 두십시오.

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

key paperkey는 키를 종이에 인쇄하여 다른 장소에 보관할 수 있는 문서 형태로 출력합니다. 이 파일 자체를 기밀로 취급하십시오. 파일을 가진 사람은 해당 키로 생성된 모든 백업을 복호화할 수 있기 때문입니다. 대규모 환경을 위해, PBS는 proxmox-backup-client key create-master-key으로 생성된 RSA(Rivest Shamir Adleman) 키 쌍인 마스터 키도 지원합니다. 이 방식에서는 각 백업이 자체 암호화 키를 공개 키로 암호화하여 저장하며, 개인 키는 복구를 위해 오프라인 상태로 유지됩니다.

설계를 시작하기 전에 알아두어야 할 중요한 결과가 하나 있습니다. 암호화된 백업의 경우, 데이터 조각의 다이제스트는 평문 내용과 암호화 키를 결합하여 계산됩니다. 따라서 서로 다른 키로 암호화된 두 개의 동일한 데이터 조각은 서로 다른 다이제스트를 생성하며, 중복 제거(deduplication)가 이루어지지 않습니다. 키를 변경하면 다음 백업 시 모든 데이터를 다시 업로드하게 되며, 이전 데이터 조각은 스냅샷이 정리되고 수집될 때까지 저장소에 남아 있게 됩니다. 첫 번째 업로드를 시작하기 전에 암호화 여부를 결정하십시오.

Prune 마크와 가비지 컬렉션의 회수

이 섹션은 건너뛰기 쉽지만, 볼륨을 가득 채우는 주원인이 됩니다. 스냅샷을 Prune하면 메타데이터인 매니페스트, 인덱스, 로그, 노트가 제거됩니다. 이때 청크(chunk)는 전혀 삭제되지 않습니다. 청크는 여러 스냅샷이 공유하므로, 모든 인덱스를 읽어보기 전까지는 어떤 청크가 미사용 상태인지 알 수 없으며, 가비지 컬렉션이 바로 그 인덱스를 읽는 작업을 수행합니다. Prune 일정만 설정하고 가비지 컬렉션 일정을 설정하지 않은 데이터스토어는 용량이 계속 증가하기만 합니다.

두 가지 모두 설정하십시오. 먼저 네임스페이스당 하나의 작업으로 보존 정책을 설정합니다.

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

그다음, Prune 작업 이후 몇 시간 뒤이자 백업 윈도우를 벗어난 시간에 데이터스토어의 컬렉션 일정을 설정합니다.

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

PBS 호스트에서 이 분리 작업을 직접 확인해 보십시오.

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

Prune 작업을 실행한 뒤 df을 확인하면 사용량 수치에 변화가 없습니다. 가비지 컬렉션을 실행한 뒤 다시 df을 확인하면 수치가 변합니다.

가비지 컬렉션은 두 단계로 실행됩니다. 1단계는 데이터스토어의 모든 인덱스를 탐색하여 인덱스가 참조하는 모든 청크의 접근 시간을 업데이트합니다. 2단계는 접근 시간이 기준점보다 오래된 청크를 삭제합니다. 기준점은 작업 시작 24시간 5분 전이거나, 현재 기록 중인 가장 오래된 백업의 시작 시점 중 더 이른 시간입니다. 이러한 여유 시간(margin)이 존재하는 이유는 Linux가 파일시스템을 기본적으로 relatime 옵션으로 마운트하기 때문입니다. 이 옵션은 접근 시간을 읽을 때마다 업데이트하지 않고 대략 하루에 한 번만 업데이트합니다. 따라서 1시간 전에 기록된 청크는 아무것도 참조하지 않더라도 삭제되지 않으며, Prune으로 확보된 공간은 해당 청크가 마지막으로 접근된 후 하루가 지난 시점에 실행되는 첫 번째 컬렉션에서 나타납니다. 아무것도 회수되지 않은 것처럼 보이는 데이터스토어는 대개 이 시간 범위 내에 있는 경우입니다.

소규모 VPS에서 이 작업은 볼륨의 모든 청크 파일을 stat해야 하므로 시스템에 가장 큰 부하를 줍니다. 작업 로그는 제거된 항목과 유예 기간으로 인해 보류 중인 항목에 대한 요약으로 끝납니다. 보류 중인 항목이 많다면 다음 날 다시 실행하십시오. PBS는 gc-atime-safety-check 및 gc-atime-cutoff을 데이터스토어 튜닝 옵션으로 제공하지만, 두 옵션 모두 기본값으로 두어야 합니다. 이 옵션들은 접근 시간을 기록할 수 없는 스토리지를 위해 존재하며, noatime로 마운트된 파일시스템에서 안전 검사를 끄는 것은 라이브 스냅샷이 참조 중인 청크를 유실하게 만드는 원인이 됩니다.

검증을 통해 청크의 읽기 가능 여부 확인

정상적으로 업로드된 백업이라도 1년 뒤에는 읽을 수 없는 상태가 될 수 있습니다. 검증 과정은 청크를 다시 읽어 인덱스에 저장된 체크섬과 비교하므로, 복구 시점이 아닌 정해진 일정에 따라 손상 여부를 파악할 수 있습니다.

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

소규모 VPS에서는 스레드 수를 낮게 유지하십시오. 검증 작업은 디스크와 CPU 자원을 소모하며, 다른 작업과 자원을 두고 경쟁하게 됩니다. 일정 관리는 웹 인터페이스의 datastore 내 Verify Jobs 탭을 사용하십시오. 이미 검증된 스냅샷은 건너뛰고 30일이 지난 스냅샷을 다시 검증하는 주간 작업을 설정하면, 중복 작업 없이 전체 데이터 저장소를 주기적으로 점검할 수 있습니다.

검증에 실패한 스냅샷은 datastore 보기에서 실패로 표시됩니다. 이를 무시하지 마십시오. 청크는 공유되므로, 기본 이미지의 청크 하나만 손상되어도 해당 청크를 참조하는 모든 스냅샷이 실패할 가능성이 큽니다. 복구 방법은 실패한 스냅샷을 삭제(forget)하고 새로운 백업을 수행하여 누락된 청크를 다시 업로드하는 것입니다. 만약 오류가 계속 발생한다면 datastore 하위의 스토리지를 의심해야 하며, 검증 작업이 문제를 발견하기 전에 드라이브 상태를 미리 알 수 있도록 VPS의 디스크 상태 모니터링을 설정하십시오.

복구 테스트 및 클러스터 외부에서의 테스트

백업은 직접 복구해 보기 전까지는 정상 작동 여부를 알 수 없습니다. 서로 다른 항목을 검증하는 두 가지 테스트를 수행해야 합니다.

클러스터 내에서 게스트 전체 복구:

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

pvesm list의 첫 번째 열은 볼륨 ID이며 타임스탬프를 포함하고 있으므로, 예시를 그대로 입력하지 말고 본인의 ID를 복사하십시오. 사용하지 않는 게스트 ID와 다른 스토리지에 복구한 뒤, 네트워크 인터페이스를 연결하지 않은 상태로 시작하십시오. 백업 정상 여부를 확인하기 위해 실행 중인 게스트 위에 덮어쓰기 방식으로 복구해서는 안 됩니다. 복구 도중 실패할 경우 기존의 정상적인 복사본까지 손실될 수 있기 때문입니다.

두 번째 테스트는 아무도 수행하지 않는 테스트입니다. 클러스터가 있는 건물이 사라졌다고 가정하고, 클러스터에 포함된 적 없는 장비에서 복구를 시도하십시오. Debian 13 시스템에서 클라이언트 전용 저장소를 /etc/apt/sources.list.d/pbs-client.sources와 같이 추가합니다.

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

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

따옴표로 표시된 세 개의 자리 표시자에 본인의 값을 입력하고, 마지막 줄의 아카이브 이름은 snapshot files가 출력한 값을 사용하십시오. 이 테스트는 첫 번째 테스트가 증명할 수 없는 사항을 확인해 줍니다. 즉, 보유한 키 파일로 실제 데이터를 복호화할 수 있는지, 그리고 클러스터 설정이 저장된 적 없는 장비에서 클라이언트를 구동할 수 있는지 검증하는 것입니다. 필요한 네 가지 값(저장소 문자열, 토큰 비밀값, 지문, 키 파일)을 기록하여 재난 복구 계획서가 지정하는 장소에 함께 보관하십시오.

중복 제거가 디스크 비용에 미치는 영향과 한계

중복 제거는 실제로 작동하며 전체 데이터스토어에 걸쳐 적용됩니다. 10개의 Debian 게스트가 기본 시스템의 사본 하나를 공유하므로, 두 번째로 생성된 동일한 게스트를 저장하는 데 드는 비용은 거의 없습니다. 또한 클라이언트가 서버에 이미 존재하는 청크에 대해서는 데이터 대신 체크섬만 전송하므로 업로드 대역폭도 절약됩니다.

중복 제거가 수행하지 못하는 부분에 대해서는 명확히 이해해야 합니다.

• 변경되는 데이터는 축소하지 못합니다. 매일 밤 파일의 상당 부분을 다시 쓰는 데이터베이스는 매일 새로운 청크를 생성하며, 보존 정책에 따라 이 청크들은 배가됩니다.
• 위에서 언급했듯이 암호화 키 경계를 넘어 데이터를 중복 제거하지 못합니다.
• 네임스페이스를 사용하는 주된 이유인 데이터스토어 경계를 넘어 데이터를 중복 제거하지 못합니다.
• 볼륨이 가득 차는 것을 막지 못합니다. 데이터스토어가 가득 차면 백업은 실패하며, 유일한 해결책은 볼륨을 늘리거나 보존 기간을 단축하는 것뿐입니다.

그 아래에 또 다른 중복 제거 계층을 쌓지 마십시오. 청크는 이미 클라이언트에 의해 중복 제거 및 압축된 상태로 도착합니다. 따라서 데이터스토어 하위의 ZFS 중복 제거는 이미 제거된 데이터를 찾기 위해 RAM을 낭비하게 됩니다. 이 경우에는 볼륨에 일반 ext4나 xfs를 사용하는 것이 올바른 선택입니다.

웹 인터페이스는 데이터스토어에 대한 중복 제거율을 보고합니다. 이 수치는 사용자의 게스트를 기준으로 하며, 다른 사람의 데이터를 기준으로 한 공개된 비율은 참고할 가치가 없으므로 이 수치만을 계획에 활용해야 합니다. Proxmox 게스트가 아닌 머신에 대한 파일 단위 백업이 필요한 경우, 동일한 VPS에서 병행하여 실행하십시오. PBS는 전체 게스트를 대상으로 하는 하이퍼바이저 인식 타겟인 반면, restic 및 BorgBackup은 디렉터리를 대상으로 하며, restic을 이용한 VPS 백업은 PBS가 지원하지 않는 노트북이나 독립형 서버에 적합합니다.

실패 유형 및 확인 사항

스토리지 상태가 비활성으로 표시됩니다. 노드가 8007 포트로 TLS 세션을 완료할 수 없으면 pvesm status --storage pbs-offsite은 inactive을 출력합니다. VPS의 방화벽, 제공업체의 별도 네트워크 방화벽, 그리고 핑거프린트를 차례로 확인하십시오. 핑거프린트가 인증서와 일치하지 않으면 포트가 차단된 것과 동일한 방식으로 실패하며, 인증서가 교체될 때마다 핑거프린트도 변경됩니다.

첫 번째 백업이 권한 문제로 실패합니다. 접근 제어 항목은 사용자 이름이 아닌 토큰을 지정해야 하며, 스토리지가 가리키는 네임스페이스를 포함해야 합니다. 다른 곳을 확인하기 전에 웹 인터페이스의 데이터스토어 권한 탭에서 이 두 가지를 모두 확인하십시오.

가비지 컬렉션이 시작되지 않습니다. 접근 시간 안전성 검사가 실패한 경우이며, 이는 거의 항상 데이터스토어 파일 시스템이 noatime로 마운트되었음을 의미합니다. findmnt -no OPTIONS /mnt/datastore/store1를 실행하여 확인하고, /etc/fstab에서 옵션을 수정한 뒤 다시 마운트하십시오. 이 검사를 우회하기 위해 기능을 비활성화하지 마십시오.

데이터스토어 용량이 계속 증가합니다. 프룬(prune) 작업이 실행되어도 공간이 회수되지 않습니다. 가비지 컬렉션 일정이 없거나, 백업 직후에 실행되어 모든 컬렉션이 24시간 유예 기간 내에 포함되는 경우입니다. proxmox-backup-manager datastore show store1을 사용하여 일정을 확인하십시오.

빠르던 백업이 몇 시간씩 걸립니다. 중지, 마이그레이션 또는 복원된 게스트는 더티 비트맵(dirty bitmap)을 잃게 됩니다. 따라서 다음 실행 시 클러스터 측에서 전체 디스크를 읽게 되며, 실제 업로드 데이터는 적더라도 작업 시간이 길어집니다. 작업 로그에는 업로드 수치는 작지만 긴 소요 시간이 표시되며, 그다음 실행부터는 다시 빨라집니다. 만약 VPS의 모든 작업이 느리다면 원인은 보통 데이터스토어 외부의 문제이며, 노이지 네이버로 인한 CPU 스틸 타임을 가장 먼저 측정해야 합니다.

FAQ

Prune 작업을 실행해도 Proxmox Backup Server 데이터스토어 용량이 계속 늘어나는 이유는 무엇입니까?

Prune 작업은 매니페스트, 인덱스, 로그, 메모와 같은 스냅샷 메타데이터만 제거하기 때문입니다. 청크(chunk)는 어떤 인덱스에서도 참조하지 않게 될 때까지 가비지 컬렉션(garbage collection)에 의해 삭제되지 않고 디스크에 남아 있습니다. proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'를 사용하여 데이터스토어에 가비지 컬렉션 일정을 설정하고, proxmox-backup-manager garbage-collection start store1 실행 전후에 데이터스토어 경로에서 df -h을 실행하여 이를 확인하십시오. 가비지 컬렉션의 2단계는 접근 시간이 24시간 5분 이상 지난 청크만 제거하므로 최소 하루 이상의 지연 시간이 발생할 수 있습니다.

Proxmox Backup Server VPS에는 어느 정도의 디스크 용량이 필요합니까?

각 게스트가 실제로 사용하는 공간을 합산한 뒤, 각 게스트의 일일 변경분에 보관 기간(일수)을 곱하여 더하십시오. 압축과 중복 제거 기능이 유리하게 작용하므로 이 합계는 최대치가 됩니다. 인덱스와 작업 공간을 위해 약 5분의 1을 추가한 다음, 구매 가능한 볼륨 크기로 올림 하십시오. 첫 백업 전의 추정치는 항상 어느 한쪽으로 틀릴 수밖에 없으므로, 2주 뒤 데이터스토어 뷰에서 실제 사용량을 확인하여 재조정하십시오.

백업 암호화 키는 어디에 보관해야 합니까?

보호 대상인 클러스터 내부를 제외한 모든 곳에 보관하십시오. Proxmox VE는 키를 /etc/pve/priv/storage/<storage>.enc에 저장하는데, 이는 모든 노드로 복제되므로 클러스터가 손실되면 함께 사라집니다. 첫날 키를 외부로 복사하고 proxmox-backup-client key paperkey을 사용하여 출력한 뒤, 해당 사본을 다른 건물에 보관하십시오. 또한 키는 청크 다이제스트의 일부로 사용되므로, 나중에 키를 교체하면 다음 백업 시 모든 데이터를 다시 업로드해야 한다는 점을 유의하십시오.

Proxmox 호스트당 하나의 데이터스토어가 필요합니까, 아니면 네임스페이스를 사용해야 합니까?

소스 호스트나 클러스터당 하나의 데이터스토어와 하나의 네임스페이스를 사용하는 것이 좋습니다. 중복 제거는 데이터스토어 내부에서만 작동하고 데이터스토어 간에는 작동하지 않으므로, 호스트별로 나누면 동일한 기본 이미지가 여러 번 저장됩니다. 네임스페이스는 백업 그룹을 분리하므로, ID가 100인 게스트를 가진 두 호스트가 충돌하지 않으며 /datastore/store1/pve-home 형식의 접근 제어 경로를 통해 각 호스트의 API 토큰을 해당 네임스페이스로 제한할 수 있습니다.

작은 VPS로도 Proxmox 백업 서버를 원활하게 운영할 수 있습니까?

홈랩 환경이라면 대개 가능합니다. 청킹(chunking)과 해싱(hashing) 작업은 백업 서버가 아닌 Proxmox VE 노드에서 수행되기 때문입니다. VPS는 청크를 기록하고 가비지 컬렉션과 검증(verification)이라는 두 가지 무거운 작업을 수행합니다. 4 GB의 RAM을 할당하고 검증 스레드 수를 낮게 유지하십시오. 두 작업 모두 백업 시간대를 피해 일정을 잡고, 그럼에도 디스크 성능 대비 작업 시간이 너무 오래 걸린다면 더 큰 플랜을 구매하기 전에 스틸 타임(steal time)을 측정해 보십시오.