前言

如果你有認真對待自己的資料,應該聽過 3-2-1 備份原則

  • 3 份備份
  • 2 種不同的儲存媒介
  • 1 份異地備援

前兩項在家中的 Homelab 環境相對容易做到,但「異地」這個字往往是大多數人的盲點。硬碟壞掉?用 Proxmox Backup Server (PBS) 還原。系統崩潰?從 PBS 拉一份回來。但若是家裡發生火災、淹水,或是更平凡的情況——你不小心把整台 Proxmox VE 的 NVMe 連資料一起刪掉——這時候同一個屋簷下的所有備份都會跟著陪葬。

我的 Homelab 環境是一台 Proxmox VE 搭配一台 Proxmox Backup Server,跑著包含 k3s、Vaultwarden 等各種服務。在研究了很久的異地備援方案後,我決定在歐洲架設一台 PBS,讓它透過 WireGuard 隧道主動把家裡的備份「拉」過去,讓 321 中的那個「1」真正落地。

這篇文章會記錄完整的架構決策過程,從為什麼選 Hetzner、選哪個方案、到實際的設定步驟,以及中間踩過的坑。

為什麼選 Hetzner

Hetzner 是一間位於德國的基礎設施供應商,在評估異地備援的雲端供應商時,我的優先考量是:便宜隱私安全技術友善

GCP / AWS 的問題

第一個念頭當然是最熟悉的 GCP 或 AWS,畢竟都是主流雲端。但把兩者丟進計算機後,答案很快就出來了:

以我「最終」需要的規格:

  • 2 vCPU / 4GB RAM VM
  • 80GB 高速 Storage 用於 PBS 備份
  • 500GB 慢速 Storage 用於 NAS 備份
方案 預估月費
Hetzner
- CX23
- 80GB Volume
- BX11 Storage Box
約 $15.73 USD
AWS 同級配置
- t3.medium
- gp3 80GB
- S3 500GB
約 $50 USD
GCP 同級配置 相近

光是這個差距就已經結案了。AWS 和 GCP 的小型運算實例本身就已經比 Hetzner 貴好幾倍,Block Storage 的單價更是幾乎翻倍,再加上對外流量費用(下載資料還要另外收),災難復原時光是把 500GB 拉回來就可能要多付幾十美元。

值得一提的是,Hetzner 在 2026 年 4 月 1 日起進行了一波漲價,幅度在 30% 至 37% 之間,官方說明是 IT 產業硬體成本大幅上升所致——DRAM 價格在 2025 年因 AI 基礎設施擴張而暴漲約 171%,直接推高了所有雲端供應商的運營成本。即便如此,和 AWS、GCP 相比 Hetzner 依然便宜很多,只是原本那個「便宜得離譜」的優勢稍微縮小了一點。

Hetzner 的額外優勢

除了純粹的成本考量,Hetzner 還有兩個讓我決定選它的理由:

GDPR 保護。Hetzner 總部位於德國,受嚴格的歐盟 GDPR 規範約束。對比 Google Drive 或其他美國雲端服務,Hetzner 作為 IaaS,不會主動掃描你的資料內容。若搭配 ResticBorgBackup 的客戶端加密,對 Hetzner 來說儲存的就只是無法解讀的亂碼區塊,而不是你的照片或 Vaultwarden 資料。

相比之下,Google Drive 有眾所周知的 Hash 特徵碼比對機制,曾有人因此遭到誤判封號,而且一旦帳號被停用,Gmail、Google Photos、所有 Google 服務全部連坐,申訴幾乎是緣木求魚。

Hetzner Storage Box 的生態系。Hetzner 不只有 VPS,還提供專用的檔案儲存服務 Storage Box。最基本的 BX11 方案提供 1TB 空間,月費 $4.00,且官方原生支援 SFTP/SSH,與 Restic 和 BorgBackup 的相容性極佳。這讓我能把 NAS 的備份也一起整合進來,形成一個完整的異地備援生態系,後面會再提到這塊。

為什麼不是 Scaleway

評估過程也有考慮 Scaleway,同樣是法國的歐洲雲端服務商,隱私保護上與 Hetzner 並駕齊驅。但放在「自建基礎設施」的使用場景下,數據說話:

  • 同規格的運算實例,Scaleway 的 DEV1-M 月費約 €7.60,Hetzner CX23 漲價後也只要 $4.99。
  • 80GB Block Storage,Scaleway 約 €6.40,Hetzner 約 $6.14。
  • 入門實例的網路頻寬,Scaleway 會鎖定在 200~400 Mbps,Hetzner 給的是 1 Gbps。

Scaleway 的強項是 Managed Kubernetes 和 Serverless 這類 PaaS 服務,對於自建 PBS 的需求來說是大材小用,且價格直接貴了一倍。

但 Hetzner 的 Object Storage 在 reddit 上的評價一直都是不建議使用,Object Storage 領域則相對會推薦 Scaleway。

架構決策:CX23 + 100GB Volume,而不是 CX33

Hetzner 提供了非常多型號,最直覺的選擇可能是直接租一台 CX33(4 vCPU / 8GB RAM / 80GB NVMe),但我最終選的是 CX23(2 vCPU / 4GB RAM / 40GB NVMe,$4.99/月)加掛一個獨立的 80GB SSD Volume($6.14/月)

為什麼不直接用 CX33 的本機硬碟(以及為什麼現在更不值得)

第一輪把家裡的備份同步過去之後,數據出來了:光是基準備份就吃掉了 47.51 GB。

CX33 的 80GB 空間扣掉:

  • Debian 系統與 PBS 套件:約 5~6 GB
  • GC 與系統緩衝(建議預留 20%):約 15~20 GB

實際能給 PBS Datastore 用的最多只有 55~60 GB,對 47.51 GB 的基準備份幾乎沒有增量空間,也沒有足夠的緩衝讓 Garbage Collection 正常運作。GC 是 PBS 清理孤立資料塊的過程,需要額外的臨時空間,若硬碟寫滿,GC 直接崩潰,備份任務失敗。

所以 CX33 看起來夠用,但實際上…存在較多變數。

CX23 + 獨立 Volume 的優勢

把儲存與運算分離才是正確的做法:

  • CX23 本機 40GB NVMe(系統碟):扣掉 Debian + PBS 套件約 5GB,剩下 ~35GB 高速 NVMe 作為系統使用,還足夠順手跑一些輕量服務(例如我把原本跑在 Oracle 免費主機上的 Gatus 監控服務遷移過來)。
  • 80GB SSD Volume(資料碟):獨立掛載為 /mnt/datastore/HC_Volume_xxxxxx,PBS 的全部讀寫都限制在這個空間,不影響系統碟。47.51 GB 的基準備份加上未來的增量,80GB 扣掉 GC 緩衝後仍有足夠空間,且 keep-last=1 的策略讓磁碟用量保持可預測。

至於 CPU 和記憶體,PBS 本身並不吃重,2 vCPU / 4GB 跑 WireGuard + PBS + Gatus 完全綽綽有餘。CX33 多給的 4 vCPU 和 4GB RAM 對這個使用場景純粹是浪費——漲價後 CX33 的月費更高,這個選擇只會更加確定。

為什麼不用 Hetzner Storage Box 當 PBS 的 Datastore

Storage Box 的底層是 HDD 網路儲存,IOPS 極低。PBS 在執行 Garbage Collection 時,需要針對幾萬個小 Chunk 進行大量的隨機讀寫,這正是 HDD 的死穴。Storage Box 適合的場景是大檔案的順序讀寫,例如透過 Restic 備份 NAS 的影片和照片,不適合 PBS 這類需要高 IOPS 的備份引擎。

整體架構圖

最終確立的架構如下:

%%{init: {'theme':'dark'}}%%
flowchart TD
    subgraph Homelab ["Homelab"]
        PVE["Proxmox VE
192.168.1.99"] PBS_HOME["家中 PBS
192.168.1.249"] NAS["OpenMediaVault NAS"] end subgraph Hetzner ["Hetzner"] FW["Hetzner Firewall
SSH 僅限固定 IP + WireGuard UDP 51820
其餘全部封鎖"] PBS_HZ["CX23 PBS — 10.0.0.4
系統碟:40GB NVMe
資料碟:80GB SSD Volume"] SB["Storage Box BX11 1TB"] end PVE -->|"每週備份(LAN,高速)"| PBS_HOME PBS_HOME -->|"Sync Job / PBS Pull 模式
透過 WireGuard 隧道"| FW FW --> PBS_HZ NAS -->|"Restic SFTP / AES-256 加密"| SB

WireGuard 的路由器是我家裡的 Mikrotik RB5009UG+S+,它作為 WireGuard Server 端,Hetzner 上的 Debian 則作為 Client,建立 Split-tunnel 只把前往 10.0.0.0/24192.168.1.0/24 的流量導進隧道,其餘流量走 Hetzner 自己的外網。

實作步驟

一、Hetzner 主機建立

在 Hetzner Cloud Console 建立新的 Server:

  • 型號:CX23(2 vCPU / 4GB RAM / 40GB NVMe)
  • OS:Debian 13 (Trixie)
  • Networking:IPv4 + IPv6(IPv4 月費 €0.50,不要省這個錢)
  • 地區:選擇 Falkenstein(德國)或是 Helsinki(芬蘭),從台灣連沒什麼差別,但 Hetzner 的 Storage Box 只服務於這兩個區域,選擇同一個即可。
  • SSH Key:事先產生 ed25519 金鑰並上傳

產生金鑰時建議加上 -C 參數附上識別標籤:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519.hetzner -C "raiven-hetzner-pbs"

同時建立一個 100GB 的 Volume,在建立 Server 時一併 Attach 上去。

建立完後,在 Hetzner Firewall 設定以下規則:

方向 協定 Port 來源
Inbound TCP 22 家中固定 IP/32
Inbound UDP 51820 家中固定 IP/32
Inbound ICMP - Any(方便除錯)
Outbound Any Any Any

所有未明確允許的 Inbound 流量(包含 PBS 的 8007 Port)都會被阻擋在公網之外,只能透過 WireGuard 內網存取。

完成後等待建立

二、掛載 Volume

SSH 進入 Hetzner 後,若在建立時就有同時建立 Volume,通常會直接幫你 mount,至少我在 debian 13 的建立過程是這樣。若是建完 server 才掛載的話,可以到 volume 頁面查看 tips。

三、安裝 Proxmox Backup Server

在 Debian 13 上安裝 PBS,可以參考官方文件,撰寫這篇文章時 Proxmox Backup Server 版本為 4.1.5,基於 debian 13:

wget https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg \
  -O /etc/apt/trusted.gpg.d/proxmox-release-trixie.gpg

echo "deb http://download.proxmox.com/debian/pbs trixie pbs-no-subscription" \
  > /etc/apt/sources.list.d/pbs-no-subscription.list

apt update && apt install proxmox-backup-server -y

安裝過程若跳出 postfix 設定,選擇 Local only 即可。

安裝完成後,PBS 會自動監聽 8007 Port。由於 Hetzner Firewall 已封鎖公網存取,需要先設定好 WireGuard 才能進入 Web GUI。記得設定 root 密碼(PBS Web GUI 需要 PAM 密碼驗證):

passwd root

四、設定 WireGuard

Hetzner 上的 Debian 作為 WireGuard Client,需要連回家裡的 Mikrotik RB5009。

在 Hetzner 產生金鑰

cd /etc/wireguard
wg genkey | tee private.key | wg pubkey > public.key
echo "--- Private Key ---" && cat private.key
echo "--- Public Key ---" && cat public.key

將 Public Key 備用,等一下要填到 RouterOS 裡。

在 Mikrotik RouterOS 新增 Peer

/interface wireguard peers add \
  interface=wg \
  name=hetzner-pbs \
  allowed-address=10.0.0.4/32 \
  public-key="<Hetzner 的 Public Key>" \
  comment="Hetzner PBS Sync"

在 Hetzner 建立 WireGuard 設定檔 (/etc/wireguard/wg0.conf):

[Interface]
PrivateKey = <Hetzner 的 Private Key>
Address = 10.0.0.4/24

[Peer]
# RouterOS 的 Public Key
PublicKey = <RB5009 的 Public Key>
Endpoint = 114.34.106.153:51820
# Split-tunnel:只把家中內網與 WG 網段導進隧道
AllowedIPs = 10.0.0.0/24, 192.168.1.0/24
PersistentKeepalive = 25

啟動並設定開機自啟:

systemctl enable --now wg-quick@wg0

驗證隧道:

ping 192.168.1.249

若有回應,代表 WireGuard 隧道打通。這時在家裡的瀏覽器輸入 https://10.0.0.4:8007 即可安全登入 Hetzner PBS 的 Web 介面。

五、設定 PBS Sync Job

PBS 的同步是 Pull(拉取)模式,由 Hetzner 端主動連回家裡把資料拉走。這個設計有個重要的含義:是 Hetzner 上的 PBS 在設定 Sync Job,而不是家裡的 PBS。

在家裡的 PBS(192.168.1.249)建立專用帳號

進入 https://192.168.1.249:8007

  1. Access Control -> User Management -> Add
    • User name: hetzner-sync(Realm 自動帶入 @pbs)、設定密碼
  2. Permissions -> Add -> User Permission
    • Path: /datastore/<你的 Datastore 名稱>
    • User: hetzner-sync@pbs
    • Role: DatastoreReader(只給讀取權限,Hetzner 不需要寫入)
  3. 記錄下 Dashboard 頁面的 Fingerprint 字串

在 Hetzner PBS(10.0.0.4)建立 Datastore 與 Sync Job

進入 https://10.0.0.4:8007

  1. Datastore -> Add
    • Name: debian-pbs-datastore
    • Backing Path: /mnt/datastore/HC_Volume_xxxxxx
  2. Remotes -> Add
    • Name: Home-PBS
    • Host: 192.168.1.249
    • Auth ID: hetzner-sync@pbs
    • Password: 剛才設定的密碼
    • Fingerprint: 從家裡 PBS 複製的指紋字串
  3. 進入 debian-pbs-datastore Datastore -> Sync Jobs -> Add
    • Source Remote: Home-PBS
    • Source Datastore: 家中 PBS 的 Datastore 名稱
    • Schedule: 依需求設定(例如 weekly 或自訂 cron)
    • Rate In: 可設定限速(例如 10 代表 10 MB/s),避免佔用家裡上傳頻寬

建立完成後,先手動執行一次 Run now 確認任務能正常拉資料。第一次同步需要傳輸完整的基準備份,之後每次只傳輸增量差異,速度會快很多。

備份策略與空間管理

Sync 與 Prune 是分開的

這是 PBS 一個容易被誤解的設計:Sync 和 Prune 是完全獨立的動作。Hetzner 端可以設定與家裡 PBS 完全不同的保留策略。

我目前的設定是:

  • 家裡 PBS:每週備份,保留 4 週(作為快速本地還原使用)
  • Hetzner PBS:只保留 keep-last=1,也就是每個備份目標只保留最後一份

「只保留一份」聽起來好像很危險,但對異地備援這個使用場景來說,其實是非常合理的決策。我要的不是異地的歷史版本,而是「確定有一份可以在災難發生時重建環境的備份」。只保留一份的好處是空間消耗極為可預測,不會因為保留策略設定錯誤而撐爆 100GB Volume。

運作流程是這樣的:

步驟 動作 說明
1. Sync 拉取新的快照 把家裡最新的備份增量拉過來,只傳輸差異部分
2. Prune 刪除舊的索引 根據策略移除超過保留數量的快照索引,GUI 上消失
3. GC 物理清理孤立 Chunks 實際回收不再被任何快照引用的資料塊

三個步驟分開執行,建議排程順序是:Sync -> Prune -> GC,且都放在半夜流量低峰執行。

跨國傳輸速度分析

第一次看到 Sync Job 的傳輸速率圖表時,我以為哪裡設定錯了——家裡是中華電信 500M/500M,但 Hetzner PBS 從家裡拉資料時,實際吞吐量只有 5 MB/s 左右(約 40 Mbps),距離上限差了好幾倍。

這不是 WireGuard 的效能問題,根本原因有三個:

1. 跨國高延遲的 TCP 壅塞控制

台灣到 Hetzner 德國/芬蘭機房的 RTT(往返延遲)通常在 230~280ms。WireGuard 底層雖然是 UDP,但 PBS 的同步流量包在隧道裡面是走 HTTP/2(基於 TCP)。傳統的 TCP Cubic 壅塞演算法在高延遲的環境下,會嚴格限制傳輸視窗大小,理論頻寬完全發揮不出來。這是物理現實,不是配置問題。

2. PBS 的「碎檔」傳輸特性

PBS 備份的本質不是傳輸一個大檔,而是傳輸幾萬個去重後的小 Chunk,每個通常只有幾十 KB 到 4 MB。在本機傳輸時,來回確認的延遲只有 1ms,速度飛快;但跨國每次確認都要等 250ms,即使 HTTP/2 支援多路復用,這種極度碎片化的 I/O 在長距離傳輸上會產生巨大的等待成本。

3. 中華電信的國際路由

中華電信的「500M」保證的是連到中華電信機房的速度,不是國際頻寬。連往歐洲通常需要繞經太平洋海纜到美國,再穿過大西洋到歐洲。尖峰時段跨國海纜壅塞是很正常的,在這種條件下跑到 5 MB/s 其實已經算不錯的表現。

開啟 BBR 改善跨國速度

Google 開發的 TCP BBR 壅塞控制演算法專門針對高延遲與輕微掉包的長距離網路設計,在 Hetzner 伺服器與家裡的 PBS 主機上都啟用 BBR,通常能把跨國吞吐量從 5 MB/s 提升到 10~15 MB/s。

在 Hetzner Debian 上(家裡的 PBS 主機同樣適用):

echo "net.core.default_qdisc=fq" >> /etc/sysctl.d/99-bbr.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.d/99-bbr.conf

sysctl --system

sysctl net.ipv4.tcp_congestion_control

對於每週只跑一次增量備份的場景,多花個十分鐘還是幾分鐘其實差異不大,重要的是它能穩定跑完。這個設定讓每次增量同步能在背景默默完成,而不需要我去盯著它。

延伸:NAS 資料的備份

架設好 PBS 的同時,也順手解決了 NAS 備份的問題。我的 OpenMediaVault NAS 上存著一些照片和文件,總量不超過 500GB,一直想找個方便又安全的方案備份到異地。

為什麼選 Restic 而不是 Rclone

Rclone 是同步工具,Restic 是備份工具。兩者的核心差異:

比較項目 Restic Rclone
加密機制 強制預設啟動,AES-256,資料離開 NAS 前已加密 可選附加功能,設定較繁瑣
版本控制 原生快照支援,可還原到任意時間點 無原生支援,預設會覆蓋舊檔
去重複化 區塊層級去重,移動/改名不重新上傳 無,改檔名視為新檔全量上傳
防誤刪 舊快照保留,刪錯有後悔藥 執行 Sync 會把誤刪同步到遠端

NAS 最常見的資料損失不是硬碟壞掉,而是手滑誤刪,或是整理檔案時搬錯位置。Rclone 的同步行為在這種情境下是災難,Restic 的快照機制才是正確的防護。

Storage Box + Restic 實作

在 Hetzner 購買 BX11 Storage Box(1TB,€4.00/月),會獲得一組 SFTP 帳號。

在 OpenMediaVault 上安裝 Restic:

apt install restic

建議先處理 ssh key 與免密碼 ssh,避免 restic 的 sftp 過程中斷:

cat <<EOF >> ~/.ssh/config
Host hetzner-sb
    HostName xxxxxxxxx.your-storagebox.de
    User xxxxxxxxx
    Port 23
    IdentityFile ~/.ssh/id_ed25519.hetzner
EOF
chmod 600 ~/.ssh/config

ssh-copy-id hetzner-sb

初始化加密備份庫:

export RESTIC_PASSWORD='xxxxxxxxxxxxxxxxx'
restic -r sftp:hetzner-sb:/home/backup_omv init

執行備份:

export RESTIC_PASSWORD="xxxxxxxxxxxxxxxxx"
export RESTIC_REPOSITORY="sftp:hetzner-sb:/home/backup_omv"
export BACKUP_SOURCE="/srv/dev-disk-by-uuid-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/appdata"
restic backup "$BACKUP_SOURCE" --verbose
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

把這個指令寫進 OMV 的排程,設定每週執行一次,就是一個完全自動、客戶端加密、且具備版本歷史的異地備份。

加密金鑰請務必備份,遺失後所有歷史備份都無法解密。

成本總覽

整套架構的每月費用(2026 年 4 月漲價後)

項目 規格 月費
Hetzner CX23 2 vCPU / 4GB RAM / 40GB NVMe(系統 + PBS + Gatus) $4.99
80GB SSD Volume PBS Datastore 專用($0.0767/GB) $6.14
IPv4 固定 Public IP $0.60
BX11 Storage Box 1TB(NAS Restic 備份) $4.00
總計 $15.73(約 NT$ 510)

帳單上的貨幣單位是否為歐元或美元,取決於你的帳號設定與所在地區。以上數字來自實際帳單,未稅。

相比 AWS 同等配置(t3.medium + gp3 80GB + S3 500GB)約 $50 USD(NT$ 1,600 起),Hetzner 這套方案依然便宜了將近 70%,且在隱私保護上反而更勝一籌。

雖然這次漲價讓總費用從原本的約 $13 漲到 $15.73,幅度確實有感,但對照全球雲端市場的普漲趨勢(OVHcloud 同期也宣佈 5~10% 漲價,AWS/GCP 本來就貴),Hetzner 依然是自架 PBS 異地備援的 CP 值最高選擇。

這每個月 NT$ 510,換來的是:

  • 一份在歐洲的 Proxmox VE 完整備份,隨時可以重建環境
  • NAS 上 500GB 私密資料的加密異地備份
  • 一個輕量監控服務的運算資源
  • 嚴格的 GDPR 法規保護下,不會有人掃描你的備份內容

寫在最後

整個實作過程最值得分享的思路是:把不同性質的資料分開處理。

PBS 的強項是針對 VM/LXC 的去重複化備份,每次增量可能只有幾百 MB,且支援完整的還原流程。但它對 IOPS 的要求讓它必須跑在 SSD 上,不能隨便把它丟在 HDD 網路儲存。

NAS 的媒體資料正好相反,單檔體積大、壓縮率低、幾乎沒有去重率,但對 IOPS 沒什麼要求,一個便宜的 HDD 儲存服務配上 Restic 的客戶端加密就能搞定。

把這兩種需求混在一起反而會兩個都做不好,分開處理後,不只效能最佳化,成本也最低。

至於跨國傳輸速度慢的問題,開了 BBR 之後有顯著改善,但即使沒有,每週的增量備份就算多花十幾分鐘跑完,對 Homelab 的備份場景來說也完全不是問題。備份最重要的不是跑得多快,而是它確實在跑、確實跑完、而且確實能還原。

參考資料