如何在 VPS 上部署 Proxmox Backup Server

在 VPS 上部署 Proxmox Backup Server 的實際效益

在 VPS 上部署 Proxmox Backup Server (PBS) 可作為異地備份目標，它使用與您的 Proxmox VE (virtual environment) 叢集相同的通訊協定。因此，除了首次備份外，後續所有備份皆為增量備份，並跨虛擬機進行重複資料刪除，在離開您的環境前即完成加密，且事後可進行驗證。您只需租用一台配備區塊儲存空間的 VPS，在 Debian 13 上安裝 PBS，於該儲存空間建立一個資料儲存庫 (datastore)，並在 Proxmox VE 中將其新增為 pbs 類型的儲存空間。安裝過程僅需 10 分鐘。後續的命名空間 (namespaces)、垃圾回收 (garbage collection)、金鑰保管 (key custody) 以及實際執行過的還原測試，才是決定該備份在一年後是否仍具備價值的關鍵。

選擇使用 PBS 而非僅將 vzdump 檔案複製到租用磁碟的原因在於其區塊儲存機制 (chunk store)。客戶端會將每個虛擬機磁碟分割為約 4 MiB 的區塊，進行雜湊運算，並僅上傳資料儲存庫中尚未存在的區塊。對於執行中的虛擬機，QEMU 會在首次備份後透過髒位圖 (dirty bitmap) 追蹤變更的區塊，因此後續備份僅需讀取本地磁碟中這些變更過的區塊。一個 200 GB 的虛擬機若每日變更 3 GB 資料，則每日僅需傳輸約 3 GB。這正是家用網路頻寬與租用儲存空間能協同運作的原因，也是 將 VPS 作為異地備份目標 優於放置在友人家中備用硬碟的原因。若您仍在評估 Hypervisor 本身應部署於何處，在家中與租用 VPS 部署 Proxmox 的比較 針對該問題有獨立的說明。

租用前先評估儲存空間大小

空間評估是基於您自身數據的算術運算。請採用每個 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 任務日誌中，從第二次與第三次備份的大小讀取每日變動量。

範例中的 mail Guest 使用了 120 GB，每日變動約 3.0 GB，因此三十份每日快照約需 210 GB：包含一份完整備份加上三十天的變動量。將所有 3 個 Guest 的最後一欄相加，總計約 619 GB。額外加上五分之一作為索引、元數據以及垃圾回收（garbage collection）運作所需的緩衝空間，最終建議租用 1 TB 的儲存空間。

其餘規劃需求較小。PBS 在 2 GB RAM 下即可運作，配置 4 GB 則更為充裕，因為高負載運算發生在叢集端：Proxmox VE 節點負責讀取 Guest 磁碟並執行分塊（chunking）與雜湊（hashing）。VPS 的工作則是寫入分塊，並執行垃圾回收與驗證這兩項重度任務。建議將資料儲存區（datastore）租用為獨立的區塊儲存（block volume），而非單一大容量的根磁碟，因為您可以在不重建伺服器的情況下，於日後擴充儲存空間。

在 Debian 13 上安裝 Proxmox Backup Server

截至 2026 年 8 月，目前的組合為 Proxmox Backup Server 4 搭配 Debian 13（代號 trixie）。舊版指南將 PBS 2 與 Debian 11 搭配，由於代號是儲存庫定義的一部分，複製舊的套件名稱會導致 apt 報錯，顯示找不到 release 檔案。請從乾淨的 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。若不相符，請立即停止。金鑰環錯誤表示您即將安裝未經核實簽章的套件。

將 /etc/apt/sources.list.d/pbs.sources 寫入無訂閱（no-subscription）儲存庫，這是未購買支援合約的伺服器所適用的正確設定：

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 埠。請以 root@pam 帳號及系統 root 密碼登入，因為 PBS 是透過 PAM（可插拔驗證模組）對該使用者進行驗證，即作業系統所使用的相同帳號。該憑證為自簽憑證，瀏覽器會顯示警告。該憑證的指紋即為後續 Proxmox VE 所需的鎖定值，因此該警告為預期行為，無需修復。

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 替換為叢集對外的位址。若該位址為動態，請將規則放寬至供應商的 IP 範圍，或透過隧道終止連線。請記住，大多數 VPS 控制面板在機器前方皆有獨立的網路防火牆，必須同步開放該埠。

將資料儲存區放置於獨立磁碟區

資料儲存區（datastore）不得存放於根檔案系統。當資料儲存區填滿共用的根檔案系統時，備份作業會失敗，伺服器上的其他服務亦會隨之崩潰，包含您用來排查問題所需的日誌記錄。請掛載區塊儲存裝置、進行格式化、掛載，最後再於掛載點內建立資料儲存區。

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

請從 lsblk 取得裝置名稱。在大多數 KVM 映像檔中為 /dev/vdb，其他則為 /dev/sdb，切勿預設裝置名稱。請透過標籤（label）將掛載資訊加入 /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 將拒絕運作，因為它會在建立資料儲存區及每次執行垃圾回收（garbage collection）時進行存取時間（atime）安全檢查。

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

上述操作會建立一個 .chunks 目錄，其中包含 65536 個子目錄，命名從 0000 到 ffff。資料儲存區由數十萬個小檔案組成，而非少數大型檔案。這導致兩項後果：使用一般檔案層級工具複製資料儲存區的速度極慢且毫無意義；而在備份執行期間取得的儲存供應商磁碟快照，並非一致性的資料副本，這與在其他環境中 快照無法取代備份 的原因相同。

命名空間可避免兩台主機發生衝突

資料儲存區（datastore）預設為扁平結構。備份檔命名為 vm/100、ct/101 與 host/<name>。若兩個叢集各有一個 ID 為 100 的客體，它們會寫入同一個群組，導致快照交錯，且為其中之一設定的保留規則會誤算另一方的快照。命名空間（namespaces）能讓每個來源在同一個資料儲存區內擁有各自的樹狀結構。

請在 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'

重複資料刪除（deduplication）不受此分割影響。區塊（chunks）在整個資料儲存區內共享，因此分散在三個命名空間中的十個 Debian 客體，仍只會儲存一份基礎系統。這正是採用「單一資料儲存區搭配命名空間」而非「每台主機一個資料儲存區」的原因：獨立的資料儲存區意味著獨立的區塊池，而獨立的區塊池會導致重複儲存相同的 Debian 安裝檔，造成空間浪費。

請為每個來源建立專屬帳號，並限制其存取範圍至對應的命名空間。API（應用程式介面）權杖（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'

權杖指令僅會顯示一次密鑰：

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

請立即複製，因為 PBS 不會儲存任何可供再次查看的密鑰副本。請務必仔細檢查存取控制指令。指令中指定的是權杖名稱 backup@pbs!pve-home，而非使用者名稱，因為權杖權限僅依據指定該權杖本身的項目來計算。若僅設定 backup@pbs 的項目，該權杖將完全無法存取，導致首次備份因權限不足而失敗，而非網路問題。路徑同樣重要：受限於 /datastore/store1/pve-home 的權杖無法讀取或刪除 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 提示您輸入，確保權杖密鑰不會留在 shell 歷史紀錄中。該數值會儲存於 /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 (transport layer security) 連線，這通常是防火牆或指紋設定問題，而非憑證問題。

首次備份會上傳所有資料，因此請在開始前先計算所需時間。200 GB 等於 1600 gigabits，若上傳頻寬為 100 Mbit，每秒可傳輸 0.1 gigabit，理論最快需約四個半小時，實際時間則會更長。請選擇在不需要頻寬時執行備份。後續的備份作業僅會傳輸新增的資料區塊。

客戶端加密與金鑰存放位置

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 也支援主金鑰（master key），即透過 proxmox-backup-client key create-master-key 建立的 RSA (Rivest Shamir Adleman) 金鑰對；此時每個備份會將其專屬的加密金鑰以公開金鑰加密後儲存，而私密金鑰則保持離線以供復原使用。

在開始之前，有一項設計後果必須先了解。對於加密備份，資料區塊的摘要（digest）是根據明文內容與加密金鑰結合後計算得出；因此，兩個相同的資料區塊若使用不同的金鑰加密，會產生不同的摘要，且彼此無法進行重複資料刪除（deduplication）。更換金鑰意味著下一次備份必須重新上傳所有資料，而舊的區塊將持續佔用空間，直到其快照被刪除並執行垃圾回收為止。請務必在第一次上傳前決定加密策略。

修剪標記與垃圾回收機制

此區段若被略過，儲存空間將會被填滿。修剪（prune）快照僅會移除其元數據（metadata），包含清單、索引、日誌與註記，並不會刪除任何區塊（chunks）。由於區塊在多個快照間共用，系統必須讀取所有剩餘索引才能判斷區塊是否閒置，而這正是垃圾回收（garbage collection）的工作。若資料儲存庫（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

接著在資料儲存庫上設定回收排程，時間點應設在修剪作業完成後的數小時，並避開備份視窗：

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，數值才會變動。

垃圾回收分為兩個階段。第一階段會遍歷資料儲存庫中的所有索引，並更新這些索引所參照之每個區塊的存取時間。第二階段會刪除存取時間早於截止點的區塊；截止點為作業開始前 24 小時又 5 分鐘，或是最舊備份開始寫入的時間點，取兩者較早者。此緩衝時間的存在，是因為 Linux 預設以 relatime 掛載檔案系統，這會導致存取時間大約每日更新一次，而非每次讀取時更新。因此，一小時前寫入的區塊即使尚未被參照也不會被刪除，而修剪所釋放的空間，會在區塊最後一次被觸發後的隔天首次回收作業中顯現。若資料儲存庫顯示未回收任何空間，通常只是因為還在緩衝時間內。

在小型 VPS 上，這是系統負載最重的作業，因為它必須對磁碟區上的每個區塊檔案執行 stat。任務日誌結尾會總結已移除的內容，以及因寬限期而暫緩處理的項目。若有大量項目暫緩，請於隔日再次執行。PBS 提供了 gc-atime-safety-check 與 gc-atime-cutoff 作為資料儲存庫的調校選項，建議維持預設值：這些選項僅適用於無法記錄存取時間的儲存設備；若在以 noatime 掛載的檔案系統上關閉安全檢查，將導致現有快照參照的區塊遺失。

驗證可確保區塊仍可讀取

備份即使成功上傳，一年後仍可能無法讀取。驗證程序會重新讀取區塊並與索引中儲存的校驗和進行比對，藉此在排程中發現損壞，而非等到還原時才發現。

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

在小型 VPS 上應保持較低的執行緒數量。驗證作業受限於磁碟與 CPU 效能，若設定過高將會與伺服器上的其他任務爭搶資源。關於排程，請使用網頁介面中資料儲存庫的 Verify Jobs 分頁：設定每週執行一次的任務，並勾選跳過已驗證的快照，同時重新驗證超過 30 天的資料，即可在不重複執行工作的情況下，隨時間覆蓋整個儲存庫。

驗證失敗的快照會在資料儲存庫檢視中標記為失敗。請勿忽略此類錯誤。由於區塊是共用的，基礎映像檔中單一損壞的區塊通常會導致所有參照該區塊的快照皆驗證失敗。修復方式為刪除失敗的快照並執行新的備份，系統將會重新上傳遺失的區塊。若錯誤持續出現，請檢查資料儲存庫底層的儲存裝置，並設定 VPS 磁碟健康監控，以便在驗證任務發現問題前，磁碟能先行發出警示。

測試還原，並在叢集外進行驗證

除非您實際執行過還原，否則無法確認備份是否有效。請執行以下兩項測試，兩者檢查的重點各不相同。

在叢集上還原完整虛擬機：

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，其中包含時間戳記，請複製您實際的 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 輸出的實際名稱。此測試能證明第一項測試無法確認的事項：確認您的金鑰檔案確實能解密真實資料，且您能從一台從未持有叢集設定的機器上操作用戶端。請將還原所需的四項數值（儲存庫字串、token secret、指紋碼以及金鑰檔案）記錄下來，並存放在災難復原計畫所指定的安全位置。

重複資料刪除對磁碟帳單的影響

重複資料刪除功能確實存在，且適用於整個資料儲存區（datastore）。若 10 個 Debian 客體機共用同一份基礎系統，則第二個相同的客體機幾乎不佔用額外儲存空間。此功能亦可節省上傳頻寬，因為當伺服器已持有某個區塊（chunk）時，客戶端僅需傳送校驗和（checksum）而非實際資料。

必須明確指出此功能無法達成的事項：

• 它無法縮減變動中的資料。若資料庫每晚重寫大量檔案，則每晚都會產生新的區塊，且保留策略會使這些區塊倍增。
• 它無法跨越加密金鑰邊界，如前所述。
• 它無法跨越資料儲存區邊界，這正是使用命名空間（namespaces）的主要原因。
• 它無法阻止儲存區空間耗盡。當資料儲存區已滿，備份將會失敗，唯一的解決方案是擴大儲存區容量或縮短保留期限。

請勿在下方堆疊另一層重複資料刪除機制。區塊在抵達時已由客戶端完成重複資料刪除與壓縮，因此在資料儲存區下方使用 ZFS 重複資料刪除，只會浪費 RAM 去尋找那些在寫入前已被移除的匹配項。在此情境下，使用標準的 ext4 或 xfs 檔案系統才是正確選擇。

網頁介面會顯示資料儲存區的重複資料刪除率（deduplication factor）。該數值反映了您的客體機狀況，也是唯一值得納入規劃的參考指標，因為公開的比例數據僅代表他人的資料。若您同時需要備份非 Proxmox 客體機的檔案層級資料，可將其與 PBS 並行運行於同一台 VPS 上：PBS 是針對完整客體機設計的虛擬化感知目標，而 restic 與 BorgBackup 則適用於目錄備份，至於 restic 備份至 VPS 的方案，則能涵蓋 PBS 原本不支援的筆記型電腦與獨立伺服器。

故障模式與現象

儲存空間顯示為非作用中。 當節點無法完成通往 8007 埠的 TLS 連線時，pvesm status --storage pbs-offsite 會顯示 inactive。請先檢查 VPS 上的防火牆，接著檢查供應商提供的獨立網路防火牆，最後檢查指紋碼。若指紋碼與憑證不符，其故障現象與連接埠被封鎖時相同；每當憑證更換時，指紋碼亦會隨之變更。

首次備份因權限不足而失敗。 存取控制項目必須指定 token 而非使用者，且必須涵蓋儲存空間所指向的 namespace。在檢查其他項目之前，請先於網頁介面的資料儲存庫權限分頁中確認上述兩點。

垃圾回收無法啟動。 這是因為存取時間安全檢查失敗，通常代表資料儲存庫的檔案系統以 noatime 模式掛載。請執行 findmnt -no OPTIONS /mnt/datastore/store1 進行確認，修正 /etc/fstab 中的選項，並重新掛載。請勿為了繞過此問題而停用該檢查。

資料儲存庫空間持續增長。 執行修剪作業後卻未回收任何空間。原因可能是未設定垃圾回收排程，或是因為回收作業緊接在備份之後執行，導致所有回收作業都落在 24 小時的寬限期內。請使用 proxmox-backup-manager datastore show store1 檢查排程。

原本快速的備份作業耗時數小時。 若客體機處於停止、遷移或還原狀態，將會遺失其髒位元圖（dirty bitmap），導致下一次執行時，叢集端必須讀取整個磁碟，即使實際傳輸的資料量極少。工作日誌會顯示執行時間很長但上傳數據很小，而隨後的執行作業就會恢復正常速度。若 VPS 上所有作業都很慢，原因通常不在資料儲存庫本身，此時應優先測量 來自鄰居的 CPU steal time。

FAQ

為什麼執行 prune 工作後，Proxmox Backup Server 的資料儲存區（datastore）空間仍持續增加？

因為 prune 只會移除快照的中繼資料：包含清單（manifest）、索引（indexes）、日誌與備註。資料區塊（chunks）會保留在磁碟上，直到垃圾回收（garbage collection）刪除那些不再被任何索引參照的區塊為止。請為資料儲存區設定 proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' 排程，並在執行 proxmox-backup-manager garbage-collection start store1 前後透過 df -h 檢查資料儲存區路徑，以驗證空間釋放狀況。請預留至少一天的延遲，因為垃圾回收的第二階段只會移除存取時間超過 24 小時又 5 分鐘的區塊。

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

請先加總每台虛擬機實際使用的空間，再將每台虛擬機的每日變動量乘以保留天數。由於壓縮與重複資料刪除（deduplication）機制，此總和為空間需求的上限。接著額外預留約五分之一的空間作為索引與運作緩衝，最後無條件進位至您可購買的儲存容量。在兩週後，請根據資料儲存區檢視介面的實際使用量重新評估，因為在首次備份前所做的預估，通常都會與實際情況有落差。

備份加密金鑰應該存放在哪裡？

除了它所保護的叢集之外，任何地方皆可。Proxmox VE 會將金鑰存放在 /etc/pve/priv/storage/<storage>.enc，該路徑會同步至所有節點，因此若叢集損毀，金鑰也會隨之遺失。請在第一天就將金鑰複製出來，使用 proxmox-backup-client key paperkey 列印備份，並將該副本存放在不同的建築物內。此外，由於金鑰會參與區塊摘要（chunk digest）的計算，若日後更換金鑰，下一次備份將會重新上傳所有資料。

我應該為每個 Proxmox 主機建立一個資料儲存區，還是使用命名空間（namespaces）？

建議每個來源主機或叢集使用一個資料儲存區與一個命名空間。重複資料刪除機制僅在單一資料儲存區內運作，跨儲存區無效，因此若按主機拆分，會導致重複儲存相同的基礎映像檔。命名空間可將備份群組區隔開來，確保兩台主機若皆擁有 ID 為 100 的虛擬機時不會發生衝突，且透過 /datastore/store1/pve-home 格式的存取控制路徑，可將各主機的 API token 限制在其專屬的命名空間內。

小型 VPS 能否勝任 Proxmox 備份伺服器？

對於家庭實驗室（homelab）環境通常可以，因為區塊化（chunking）與雜湊（hashing）運算是在 Proxmox VE 節點上執行，而非備份伺服器。VPS 主要負責寫入區塊，並執行垃圾回收與驗證這兩項負載較重的工作。請為其配置 4 GB RAM，並將驗證執行緒數量維持在較低水準。請將上述兩項工作排程在備份時段之外；若執行時間仍遠超磁碟應有的效能，請在升級方案前先測量 CPU 竊取時間（steal time）。