Proxmox Backup Server VPS 部署與異地備份

在 VPS 上部署 Proxmox Backup Server 實際提供的功能

在 VPS 上部署 Proxmox Backup Server (PBS)，就能建立一個異地備份目標。它使用 Proxmox VE（虛擬環境）叢集現有的相同通訊協定。因此，除了第一次備份之外，後續備份都會採用增量備份，並在不同客體之間進行去重複。資料離開所在地前會先加密，之後也能驗證備份完整性。你可以租用一台配備區塊儲存區的 VPS，在 Debian 13 上安裝 PBS，於該儲存區建立一個 datastore，再在 Proxmox VE 中將其新增為 pbs 類型的儲存。安裝只需十分鐘。之後的設定，包括 namespace、垃圾回收、金鑰保管，以及實際執行過的還原作業，才會決定這份備份在一年後是否仍然有用。

使用 PBS，而不是將 vzdump 檔案複製到租用的磁碟，原因在於其 chunk store。用戶端會將每個客體磁碟切割成約 4 MiB 的區塊，計算雜湊值，並只上傳 datastore 尚未儲存的區塊。對於執行中的虛擬機器，QEMU 會在第一次備份後追蹤 dirty bitmap 中的變更區塊，因此下一次執行時只需從本機磁碟讀取這些區塊。每天變更 3 GB 的 200 GB 客體，每天約會傳送 3 GB。這讓家用上行連線能與租用的儲存區搭配運作，也是 將 VPS 作為異地備份目標 優於放在朋友家中的備用磁碟的原因。如果你仍在決定 hypervisor 本身應部署在哪裡，家用 Proxmox 與租用 VPS 的比較 會另外說明這個問題。

租用前先估算儲存區大小

容量估算是以您自己的數據進行算術計算。請採用每個 guest 實際使用的空間，而不是其虛擬磁碟的大小，再加上每日變動量乘以保留天數。壓縮與重複資料刪除都能進一步降低需求，因此應將結果視為上限，而不是目標值。

[
  {
    "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
  }
]

這些資料列是計算範例，不是實測結果。請在每個 guest 內從 df -h 讀取已使用空間；PBS 工作日誌中第二份與第三份備份建立後，再從其大小讀取每日變動量。

範例中的郵件 guest 使用 120 GB，每日變動量約為 3.0 GB，因此保留 30 天每日快照約需 210 GB：包含一份完整複本，以及 30 天的變動資料。將所有 3 個 guest 的最後一欄相加，總量約為 619 GB。再加上五分之一的空間，供索引、中繼資料與垃圾回收作業使用，建議採用 1 TB 的儲存區。

其餘需求不高。PBS 使用 2 GB RAM 即可正常運作，配置 4 GB 會更寬裕，因為耗用資源較多的工作是在叢集端執行：Proxmox VE 節點會讀取 guest 磁碟，並執行分塊與雜湊計算。VPS 只需寫入資料塊，並執行垃圾回收與驗證這兩項高負載工作。請將資料儲存區租用為獨立的 block volume，而不要使用一個大型 root disk，因為日後可以直接擴充 volume，無須重建伺服器。

在 Debian 13 上安裝 Proxmox Backup Server

截至 2026 年 8 月，目前的搭配是 Debian 13（代號 trixie）上的 Proxmox Backup Server 4。較舊的指南會將 PBS 2 搭配 Debian 11，而代號是 repository 定義的一部分，因此複製舊的 suite 名稱會導致 apt 顯示缺少 release file。請從純 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。如果不是，請停止操作。錯誤的 keyring 表示你即將安裝由尚未驗證的來源簽署的套件。

使用 no-subscription repository 寫入 /etc/apt/sources.list.d/pbs.sources。對沒有支援合約的伺服器，這是正確的 repository：

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

Web 介面會在 HTTPS port 8007 上提供服務。使用系統 root 密碼登入 root@pam，因為 PBS 會透過 PAM（pluggable authentication modules）驗證該使用者；這些帳號也是作業系統使用的帳號。憑證是 self-signed，瀏覽器會顯示相關警告。Proxmox VE 之後會使用該憑證的 fingerprint 進行固定，因此這項警告是預期行為，不是需要修正的問題。

Port 8007 上的是公開網際網路可存取的登入表單，因此不要讓所有來源都能連線。單一 nftables 檔案即可涵蓋此設定。寫入 /etc/nftables.conf 會 flush 目前的 ruleset，因此如果此主機已有其他元件管理 firewall，請略過這個步驟。

#!/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 session：policy drop 加上一個 SSH 規則中的拼字錯誤，就可能讓你無法登入自己的伺服器。將 203.0.113.7 替換為叢集對外連線所使用的位址。如果該位址是動態的，請將規則放寬至供應商的網段，或將連線終止在 tunnel 中；另請注意，大多數 VPS 控制面板會在主機前方提供獨立的 network firewall，該 firewall 也必須允許相同的 port。

將資料儲存區放在獨立磁碟區

資料儲存區不得位於根檔案系統。資料儲存區填滿共用的根檔案系統後，備份會失敗，伺服器上的其他功能也會失效，包括排查原因所需的日誌。連接區塊磁碟區、格式化並掛載後，才能在掛載點內建立資料儲存區。

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

這會建立一個 .chunks 目錄，其中包含 65536 個子目錄，名稱從 0000 到 ffff。資料儲存區包含數十萬個小檔案，而不是少數大型檔案。因此會有兩個結果。使用一般檔案層級工具複製資料儲存區，速度慢到無法實用；而提供者在備份執行期間建立的磁碟區快照，也不是資料儲存區的一致副本。這與其他地方所述的原因相同：快照無法取代備份。

命名空間可避免兩台主機互相衝突

資料儲存區預設採用扁平結構。備份會命名為 vm/100、ct/101 和 host/<name>。如果兩個叢集各自都有 ID 為 100 的 guest，兩者就會寫入同一個群組，快照會交錯排列，而為其中一個叢集設定的保留規則也會計入另一個叢集的快照。命名空間會在同一個資料儲存區內，為每個來源提供獨立的樹狀結構。

請在 PBS 主機上建立命名空間。--repository 引數的格式為 [[auth-id@]server[:port]:]datastore，因此本機命名空間的寫法是 root@pam@localhost:store1，而此命令會要求輸入 root 密碼。

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'

這種分割不會影響重複資料刪除。區塊會在整個資料儲存區中共用，因此分布在 3 個命名空間中的 10 個 Debian guest 仍只會儲存一份基礎系統。這就是使用一個搭配命名空間的資料儲存區，而不是每台主機各使用一個資料儲存區的理由：分開的資料儲存區代表分開的區塊集區，而分開的區塊集區代表同一份 Debian 安裝內容必須重複付費儲存數次。

請為每個來源建立個別帳號，並將其限定在自己的命名空間中。API（application programming interface）token 是隸屬於使用者並具有自身權限的認證憑證，適合用在可能遭竊的機器上。

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'

token 命令只會完整顯示 secret 一次：

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

請立即複製它，因為 PBS 不會保留任何可再次顯示的形式。請仔細檢查存取控制命令。該命令指定的是 token，即 backup@pbs!pve-home，而不是使用者，因為 token 的權限只會根據直接指定該 token 的項目計算。只有 backup@pbs 的項目會讓 token 完全沒有存取權限，導致第一次備份因權限不足而失敗，而不是因網路上可見的問題失敗。路徑同樣重要：限定在 /datastore/store1/pve-home 的 token 無法讀取或刪除 office 命名空間中的任何內容，因此即使某個叢集遭到入侵，也無法摧毀其他站點的歷史備份。

將 VPS 加入 Proxmox VE 作為備份儲存

先在 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 會提示輸入該值，因此 token secret 不會出現在 shell 歷程記錄中。它會儲存在 /etc/pve/priv/storage/pbs-offsite.pw，而儲存區定義會寫入 /etc/pve/storage.cfg。該定義會複製到叢集的每個節點，因此整個叢集只需設定一次。

--prune-backups keep-all=1 會告訴 Proxmox VE 不要刪除任何資料。保留原則應設定在 PBS 端，後文會進一步說明。原因很直接：這樣 token 不需要刪除權限。若叢集遭 ransomware 加密，叢集就無法連線到異地備份，刪除原本用來救援的歷史備份。

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

pvesm status 會在狀態欄顯示 active，旁邊則會顯示 datastore 的總容量與已使用空間。inactive 表示節點無法在 port 8007 上完成 TLS (transport layer security) 工作階段。這通常是防火牆或指紋問題，而不是認證資訊問題。

第一次備份會上傳所有資料，因此開始前先計算所需時間。200 GB 等於 1600 gigabits，而 100 Mbit uplink 每秒可傳輸 0.1 gigabit，因此理論上至少需要約四個半小時，實際時間通常更久。請在不需要使用該頻寬時開始備份。之後每次執行只會傳送新的 chunks。

用戶端加密，以及金鑰的存放位置

VPS 是你不擁有的電腦。請在用戶端進行加密，讓資料儲存區只保存供應商無法讀取的資料區塊。

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

這會將新的金鑰寫入 /etc/pve/priv/storage/pbs-offsite.enc，只有 root 可讀取，並與 /etc/pve 的其他內容一併複製。從下一次備份開始，用戶端會先將每個資料區塊加密，再傳送出去。伺服器仍可列出你的快照及其大小，但無法讀取快照內容。

接下來是讓這套機制成為備份、而不是責任的部分。產生的金鑰沒有 passphrase，而且只存在於受其保護的叢集上。如果該叢集遭竊，或被他人加密，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 會將金鑰輸出成適合列印在紙上、並存放於其他位置的文件。請將該檔案本身視為 secret，因為任何持有該檔案的人都能解密使用它建立的所有備份。對於較大型的環境，PBS 也支援 master key。這是使用 proxmox-backup-client key create-master-key 建立的 RSA（Rivest Shamir Adleman）金鑰組，其中每份備份都會將自己的加密金鑰以公開金鑰加密，而私密金鑰則保持離線，以便復原。

開始之前就應了解這項設計的一項影響，而不是事後才發現。對於加密備份，資料區塊 digest 是由純文字內容與加密金鑰共同計算而得。因此，在不同金鑰下加密的兩個相同資料區塊，會產生不同的 digest，彼此無法 deduplicate。變更金鑰後，下一次備份會再次上傳所有資料，而舊資料區塊會一直保留，直到其快照遭到 prune 並完成收集。請在第一次上傳前決定是否使用加密。

剪除標記，垃圾回收釋放空間

這是最容易被略過、卻會填滿磁碟區的部分。剪除快照會移除其中繼資料：manifest、indexes、log 與 notes，但完全不會刪除 chunk。多個快照會共用 chunk，因此必須讀取所有仍存在的 index，才能確認某個 chunk 未被使用；負責讀取這些 index 的工作就是垃圾回收。只有剪除排程、沒有垃圾回收排程的 datastore 只會持續增長。

請同時設定這兩項。先設定保留原則，每個 namespace 建立一個工作：

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

接著在 datastore 上設定垃圾回收排程，安排在剪除工作數小時後，並避開備份時段：

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

執行剪除工作，接著執行 df，使用量不會變動。執行垃圾回收後，再次執行 df，使用量才會變動。

垃圾回收分為兩個階段。第一階段會掃描 datastore 中的每個 index，並更新這些 index 所參照之每個 chunk 的存取時間。第二階段會刪除存取時間早於截止時間的 chunk。截止時間是執行開始前 24 hours and 5 minutes，或仍在寫入的最舊備份開始時間，取較早者。這項緩衝時間是必要的，因為 Linux 預設會以 relatime 掛載檔案系統，約每天更新一次存取時間，而不是每次讀取都更新。因此，即使目前沒有任何參照，剛寫入一小時的 chunk 也不會被刪除；剪除所釋放的空間，會在 chunk 上次被存取超過一天後執行的第一次垃圾回收中顯現。datastore 看似沒有回收任何空間時，通常只是仍在這段等待期間內。

在小型 VPS 上，這是主機執行的負載最高工作，因為它會對磁碟區上的每個 chunk 檔案執行 stat。工作日誌結尾會摘要顯示已移除的項目，以及因寬限期而仍待處理的項目。如果待處理項目很多，請隔天再執行一次。PBS 提供 gc-atime-safety-check 和 gc-atime-cutoff 作為 datastore 調校選項，兩者都應維持預設值：這些選項是為無法記錄存取時間的儲存設備而設計；在以 noatime 掛載的檔案系統上關閉安全檢查，可能會刪除仍被現存快照參照的 chunk。

驗證可確認區塊仍然可讀取

備份即使順利上傳，一年後仍可能無法讀取。驗證會重新讀取區塊，並與索引中儲存的 checksums 比對，讓系統能依排程找出損壞，而不是等到還原時才發現。

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

在小型 VPS 上，請將 thread 數量設低。驗證受磁碟與 CPU 效能限制，否則會與伺服器上的其他工作爭用資源。若要設定排程，請在 Web 介面的 datastore 的 Verify Jobs 分頁中建立工作：每週執行一次，略過已驗證的 snapshot，並重新驗證超過 30 天的內容。如此可在一段時間內涵蓋整個 store，同時避免重複工作。

驗證失敗的 snapshot 會在 datastore 檢視畫面中標示為 failed。請勿忽略。區塊會由多個 snapshot 共用，因此，base image 中的單一損壞區塊通常會使所有參照該區塊的 snapshot 都驗證失敗。修復方式是忘記失敗的 snapshot，然後執行新的備份，讓系統再次上傳遺失的區塊。如果持續出現失敗，應懷疑 datastore 底層的儲存設備，並設定 VPS 上的磁碟健康監控，讓磁碟在 verify job 發現問題前先發出通知。

測試還原，然後在沒有叢集的環境中測試

在還原過備份之前，無法確認備份是否可用。這兩項測試檢查的是不同事項。

在叢集上還原整個 guest：

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

pvesm list的第一欄是 volume ID，時間戳記也是其中的一部分，因此請複製您自己的值，不要直接輸入範例。請還原至未使用的 guest ID，並使用不同的 storage，然後在中斷其 network interface 的情況下啟動。請勿為了確認備份可用而覆寫正在執行的 guest，因為還原若在中途失敗，也會一併損失可正常運作的副本。

第二項測試通常沒有人執行。假設存放叢集的建築物已經不存在，然後從一台從未加入該叢集的機器進行還原。在任何 Debian 13 主機上，將僅含 client 的 repository 加入為 /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

請使用您自己的值填入三個引號括起來的 placeholder，並從 snapshot files 輸出的內容取得最後一行的 archive 名稱。這可驗證第一項測試無法驗證的事項：您的 key file 副本能解密實際資料，而且您可以從未保存過叢集設定的機器控制 client。請記下它所需的四個值：repository 字串、token secret、fingerprint 及 key file，並將它們一起保存於災難復原計畫指定的位置。

磁碟去重對儲存費用的影響與限制

去重確實有效，而且會套用到整個 datastore。10 台 Debian guest 可以共用一份基礎系統，因此第二台相同的 guest 幾乎不會增加儲存空間。去重也能節省上傳頻寬，因為對於伺服器已經持有的區塊，client 只需傳送 checksum，不必傳送資料。

以下是去重無法做到的事項，必須明確說明。

• 它不會縮減持續變動的資料。資料庫若每天晚上重寫檔案的大部分內容，就會每天產生新的區塊，而保留政策會進一步放大所需空間。
• 如上所述，它無法跨越加密金鑰的界線。
• 它無法跨越 datastore 的界線，這正是採用 namespace 的原因。
• 它無法避免 volume 被填滿。datastore 滿載時，備份會失敗；唯一的處理方式是擴大 volume 或縮短保留期限。

不要在其下方再疊加另一層去重。區塊抵達時，已由 client 完成去重與壓縮，因此在 datastore 下方使用 ZFS deduplication，只會耗用 RAM 尋找那些在寫入前就已移除的重複資料。此處應在 volume 上使用一般的 ext4 或 xfs。

Web 介面會顯示 datastore 的去重倍率。這個數值反映你的 guest，且是唯一值得用來規劃的數值，因為公開的倍率通常反映的是其他人的資料。如果你也需要備份非 Proxmox guest 機器上的檔案，請在同一台 VPS 上並行執行這些備份：PBS 是具備 hypervisor 感知能力的整台 guest 備份目標，而 restic 與 BorgBackup 會以目錄為備份對象；將 restic 備份至 VPS 則適合 PBS 原本就不 intended to cover 的筆記型電腦與獨立伺服器。

失效模式與可觀察到的現象

儲存顯示為非作用中。 當節點無法完成與連接埠 8007 的 TLS 工作階段時，pvesm status --storage pbs-offsite 會輸出 inactive。先檢查 VPS 上的防火牆，再檢查供應商獨立的網路防火牆，最後檢查指紋。與憑證不再相符的指紋，會產生與連接埠遭封鎖相同的可見結果。每次更換憑證時，指紋也會變更。

第一次備份因權限而失敗。 存取控制項目必須指定 token，而不是使用者，且必須涵蓋儲存所指向的 namespace。先在 Web 介面的 datastore 權限分頁確認這兩點，再檢查其他位置。

Garbage collection 拒絕啟動。 存取時間安全性檢查失敗。這幾乎一律表示 datastore 檔案系統是以 noatime 掛載。執行 findmnt -no OPTIONS /mnt/datastore/store1 確認，在 /etc/fstab 修正該選項，然後重新掛載。不要為了略過檢查而停用它。

Datastore 只會持續增長。 Prune 工作會執行，但沒有任何資料被回收。原因可能是沒有 garbage collection 排程，或每次 collection 都在備份後立即執行，因此落在 24 小時的保留寬限期內。使用 proxmox-backup-manager datastore show store1 檢查排程。

原本很快的備份現在需要數小時。 如果 guest 曾經停止、遷移或還原，便會遺失 dirty bitmap。因此，即使上傳的資料很少，下一次執行仍會在 cluster 端讀取整個磁碟。工作日誌會顯示執行時間很長，但上傳量很小；下一次執行則會再次變快。如果 VPS 上的所有工作都變慢，原因通常不在 datastore，應先測量 來自吵雜鄰居的 CPU steal time。

FAQ

為什麼 Proxmox Backup Server 執行 prune job 時，datastore 仍持續成長？

因為 prune 只會移除 snapshot metadata：manifest、indexes、log 和 notes。只有 garbage collection 刪除不再被任何 index 參照的 chunks 後，這些 chunks 才會從磁碟移除。請使用 proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' 為 datastore 設定排程，並在執行 proxmox-backup-manager garbage-collection start store1 前後，對 datastore path 執行 df -h 以確認結果。至少要等待一天，因為第二階段只會移除 access time 早於 24 小時又 5 分鐘的 chunks。

Proxmox Backup Server VPS 需要多少磁碟空間？

先加總每個 guest 實際使用的空間，再加上每個 guest 的每日變更量乘以保留天數。這個總量是上限，因為 compression 和 deduplication 都能降低實際需求。再為 indexes 和作業空間增加約五分之一，最後向上取整為可購買的 volume 大小。兩週後，請對照 datastore view 中的實際使用量重新檢查，因為在第一次 backup 前所做的估算，方向一定會有偏差。

Backup encryption key 應儲存在哪裡？

不要只儲存在它所保護的 cluster 上。Proxmox VE 會將它儲存在 /etc/pve/priv/storage/<storage>.enc，該檔案會複製到每個 node，因此 cluster 遺失時也會一併遺失。第一天就將它複製到外部，使用 proxmox-backup-client key paperkey 列印，並將該副本存放在另一棟建築物中。另請注意，該 key 會參與 chunk digest 的計算，因此之後更換 key 時，下一次 backup 會重新上傳所有資料。

每個 Proxmox host 都需要一個 datastore，還是應使用 namespaces？

使用一個 datastore，並為每個來源 host 或 cluster 建立一個 namespace。Deduplication 只會跨 datastore 運作，不會在不同 datastore 之間運作，因此依 host 分割 datastore 會重複儲存相同的 base images。Namespaces 可將 backup groups 分開，因此即使兩個 host 都有 ID 為 100 的 guest，也不會互相衝突；格式為 /datastore/store1/pve-home 的 access control path，則可將每個 host 的 API token 限制在自己的 namespace 中。

小型 VPS 能否負荷 Proxmox backup server 的工作？

通常可以，homelab 尤其如此，因為 chunking 和 hashing 是在 Proxmox VE node 上執行，而不是在 backup server 上執行。VPS 只需寫入 chunks，並執行兩項負載較高的工作：garbage collection 和 verification。請配置 4 GB RAM，並將 verification 的 thread 數量維持在較低值。將兩項工作都排在 backup window 之外；如果執行時間仍遠超過磁碟所需的時間，請先測量 steal time，再考慮購買更大的方案。