QNAP HDP for Business Beta 實測：一台 x86 NAS 當企業備份中心，不可變備份與開機驗證加影片

QNAP 日前公告 HDP for Business 進入公開測試（Public Beta），免費、不需授權金鑰，可直接從 App Center 安裝在既有的 x86 NAS 上。這套軟體把過去分散在 Hyper Data Protector、NetBak PC Agent 等應用中的備份能力收攏到單一主控台，並補上企業備份市場近幾年最常被拿來比較的幾項功能：不可變備份、備份開機驗證、即時還原、Airgap+ 排程離線與多站台集中管理。

CyberQ 先前已報導過 HDP for Business 的發表與備份市場趨勢，本文的重點則放在實際部署和實測。這次 CyberQ 用一台 TS-855X 當管理伺服器、一台 TS-673A 當第二台備份伺服器，接上 Proxmox VE 叢集、VMware 與數台 Windows 11 桌機，從安裝、建站、虛擬機備份，一路測到不可變備份能否被管理員刪除、開機驗證影片錄了什麼、即時還原要等多久、異地副本的 Object Lock 是否真的鎖得住，以及 Airgap+ 到底怎麼讓伺服器關機又開機。

Beta 測試版本的定位是「先用、先回饋給官方和社群」，因此本文把遇到的錯誤、官方文件彼此矛盾之處，以及我們自己操作失誤後才發現的問題，都一併記錄下來。文中資料均來自本次實測，並留下 NAS 日誌。

一、HDP for Business 是什麼，和既有的 HDP 家族有何關係

QNAP 已將旗下備份應用整合到 HDP（Hyper Data Protection）品牌之下，目前分為四個成員。

依 QNAP 社群公告，HDP for PC/VM 仍是每一台備份伺服器上的備份引擎，HDP for Business 則是架在上面的集中管理層。我們拆開實際運作後看到的分工是這樣的，HDP for PC/VM 內含 Bareos 24.0.10，負責排程與從 Hypervisor 讀取資料，HDP for Business 另外帶了一份 restic（0.18.0-dev）做去重與壓縮儲存，異地副本則以 MinIO 用戶端寫入 S3 相容儲存。

已經在跑 HDP for PC/VM 的 NAS，初始化 HDP for Business 時會自動執行 Take Over 接手所有 HDP for PC/VM 的任務，既有備份工作變成 Workload，備份原則與排程變成 Protection Policy，Hypervisor 連線直接沿用，Windows 端點上的 HDP PC Agent 也會升級為 HDP for Business Agent。接管後，該台 NAS 上的 HDP for PC/VM 轉為唯讀檢視，若要交還控制權可在 Settings 的 Application Management 中執行 Return。

Proxmox VE 支援僅限 HDP for Business，HDP for PC/VM 並不支援，支援版本為 Proxmox VE 8.x 至 9.x。

二、系統需求與 Beta 限制

以下條件整理自 QNAP 產品頁 FAQ、社群公告、發行說明與官方教學。

硬體與作業系統

僅支援 x86 架構 NAS，ARM 機型無法擔任任何角色。

管理伺服器與備援伺服器需 4 核心 CPU 與 8 GB 記憶體以上，未達門檻的 x86 機型仍可作為備份伺服器加入站台。

Beta 階段需要 QuTS hero h6.0.2 以上，QTS 6.1.0 與 QTS／QuTS hero 5.2.x 後續才會支援。

不可變備份需要備份伺服器運行 QuTS hero。

即時還原與備份驗證需要備份伺服器安裝 Virtualization Station。即時還原至少需 2 GB 可用記憶體，備份驗證至少需 4 GB。

Beta 範圍

單一站台最多 4 台伺服器，含管理伺服器。正式版將以授權機制擴充可管理數量。

Beta 不支援 Microsoft 365 與 Google Workspace，SaaS 備份請用 HDP for SaaS。

管理伺服器故障時的切換由管理者手動執行，並非自動容錯移轉。

授權與費用

QNAP 英文新聞稿提到，「HDP for Business offers unlimited device protection without per-node fees. … The only paid component is the Centralized Management License.」中文新聞稿的說法是「本方案唯一付費項目僅為多站台集中管理授權」。Beta 期間免費、不需授權金鑰。正式版集中管理授權的價格與級距，截至 2026 年 9 月 30 日官方尚未公布，產品頁的價格欄位仍是空白。

版本資訊

本文實測版本如下，HDP for Business 目前只有這一版，發布日期為 2026 年 9 月 17 日，同日也發布了配套的 HDP for PC/VM 與 Virtualization Station。

三、實測環境

測試過程中，時間點以 HDP 自己的日誌為準。

環境資訊擷取指令（於 NAS SSH 執行），QuTS hero h6 之後請看 /etc/os-release，getcfg System Version 會回傳升級前的舊版號。

cat /etc/os-release
uname -v
grep "model name" /proc/cpuinfo | head -1
free -m
zpool list
zfs list -o name,used,refer,compressratio,mountpoint | grep -i -E "NAME|zfs21"

四、實測一，安裝與初始化

流程

App Center 搜尋 HDP for Business，安裝後開啟（需先裝 HDP for PC/VM）。

進入 Set up HDP for Business，系統先做相依性檢查，再選擇儲存空間。

按下初始化，系統會在選定的儲存池建立 HDP_Business 共用資料夾，並自動接管既有的 HDP for PC/VM。

我們在兩台 NAS 上各做了一次，TS-855X 已經裝有 HDP for PC/VM，會走接管流程，TS-673A 則是全新安裝。

實測紀錄

接管的六個模組依序是 HypervisorMgr、WorkloadMgr、TaskMgr、QPKGMgr、CmsLogMgr、SchedulerMgr，其中 WorkloadMgr 花了 3.2 秒，其餘都在 1 秒內。記憶體數字要保守看待，QuTS hero 的 ZFS ARC 會算進 used，裝 HDP for PC/VM 增加的約 2 GB 裡，有多少是它啟動的服務（內含 PostgreSQL 與 Bareos）、多少是 ARC 波動，無法從 free 分辨。

注意事項

儲存空間一旦初始化就不能更改。已超過警示門檻或加密的儲存空間會反灰無法選取。

HDP_Business 共用資料夾在解除安裝後仍會保留。我們在 TS-673A 上解除安裝再重裝時，初始化精靈會把原本那個儲存池標示為「已有備份資料夾」，並回報可重新連結（relinkable）。

HDP_Business 本身是一個 QuTS hero 的 WORM 共用資料夾，模式為 Enterprise、保留期 1 天。這一點第八節會再談。

五、實測二，站台管理與備援切換

流程

管理伺服器進入 Site Management，按 Generate Invite Key，取得 Server URL 與 Invite Key。Invite Key 只能用一次，5 分鐘後失效。

要加入的備份伺服器同樣進入 Site Management，選 Join Site，輸入 URL 與 Key。

管理伺服器端會看到裝置狀態依序經過 Connecting、Syncing、Online。

在 Add Failover Server 區域選一台備份伺服器作為備援。

切換用 Manage 中的 Switch Over 執行。

實測紀錄

這組數字是兩台都正常時的計畫性切換，速度很快。它不等於管理伺服器當機時的災難切換，主控台文字說明，若無法連到對方，切換會以「The peer server is unreachable」失敗，而連線中斷期間，備份伺服器上已排程的工作會照常自動執行，但無法建立、修改或刪除任務。管理伺服器突然斷電時能否從備援端單方面接手，這次沒有測試到。

六、實測三，虛擬機備份（Proxmox VE 與 VMware）

Proxmox VE 以 SSH 22 埠連線，加入任一節點即可帶入整個叢集。VMware 走 443 埠，支援獨立 ESXi 與 vCenter。Hyper-V 走 5985 埠。

加入 Proxmox VE 後，HDP 會在節點上放一支 /opt/HDP/hdp-proxmox-cli，備份時以 NBD 匯出虛擬機磁碟，再由 Bareos 讀取。

流程

Hypervisor 頁面點 Add，選平台，填入主機 IP、埠、帳號密碼。

Workloads 中的 Virtual Machine 頁面，手動勾選虛擬機，或建立 Auto Protection Rule，日後加入該資料夾的虛擬機自動納管。

建立 Protection Policy。內建兩個原則不可刪除，Default Policy 每天 09:00 執行，Default Manual Policy 只能手動觸發，兩者預設保留 30 個版本。

測試虛擬機規格與資料量

第一次完整備份

這組數字有三個重點：

完整備份讀的是配置容量，不是實際使用量

32 GB 的虛擬磁碟只用了 5 GB，HDP 仍然讀滿 32 GB，兩顆幾乎全空的 ESXi 磁碟共 160 GiB，照樣讀了 171.8 GB、花了 27 分鐘。對 thin provisioning 的虛擬機來說，完整備份的時間取決於磁碟開多大，而不是裝了多少資料。

儲存端的去重與壓縮效果很好

讀進來的 171.8 GB 最後只佔 2.23 GB，零區塊沒有浪費空間。

主控台回報的佔用只算 restic 儲存庫

測試 VM 完整備份後，主控台顯示實際佔用 2.60 GB，但 ZFS 資料集實際增加了約 7 GB。差額在 Bareos 那一側：每次完整備份會在 HDP/HDP_Business/data/ 下留下一個 rd_ 開頭的目錄，測試 VM 的那一個就有 6.9 GB。規劃容量時，請以 ZFS 的實際用量為準，不要只看主控台的數字。

增量備份（在虛擬機內寫入 2,048 MiB 亂數資料後再跑一次）

增量備份靠 QEMU 的 dirty bitmap（CBT）追蹤變更區塊，準確度幾乎沒有浪費。但這套機制有個前提：官方 FAQ 說明，raw 或 vmdk 格式的虛擬機若在兩次備份之間關過機，CBT 資訊就會遺失，下一次一定是完整備份。

Cyberq 實測驗證了這一點，測試 VM 關機再開機後，下一次備份的類型自動變成 full，重新讀了一次 32 GB，耗時 343 秒。

Hypervisor 端擷取指令（以 Proxmox VE 為例）

qm list
qm config <vmid> | grep -E "scsi|virtio|ide|sata|efidisk"
vmstat -t 10
# 製造增量變更
dd if=/dev/urandom of=/data/incr-2g.bin bs=1M count=2048 status=none && sync

NAS 端擷取指令

zfs list -o name,used,refer,compressratio zpool1/zfs21
du -sk /share/ZFS21_DATA/HDP_Business/HDP /share/ZFS21_DATA/HDP_Business/backup_repository
# Bareos 的工作摘要（含讀取量與速率）
grep -A20 "Bareos bareos-dir" /share/ZFS530_DATA/.qpkg/HyperDataProtector/logs/services/bareos_dir.log | grep -E "JobId|Elapsed|FD Bytes|Rate|Termination"

七、實測四，Windows 端點備份與社群回報的問題

Windows PC 與 Server 走 HDP for Business Agent，支援 Windows 10 64 位元 1607 以上、Windows 11，以及 Windows Server 2016 至 2025，不支援 ARM64 Windows，首次安裝時需要能連上網際網路。

安裝方式的實測結果

QNAP 同時提供 .exe 與 .msi 兩種安裝檔（1.0.0.1889）。企業大量部署通常會用 MSI 靜默安裝，但實測結果是：

msiexec /i QNAP_HDP_for_Business_Agent-1.0.0.1889.msi /qn 無法靜默完成。 這個 MSI 只是一層包裝（EXEMSI），內部會執行一支不帶任何參數的 installer.exe，後者是 NSIS 安裝程式，會停在看不見的安裝畫面等待操作。我們等了 620 秒，最後手動結束，msiexec 回傳 1603。

直接執行 QNAP_HDP_for_Business_Agent-1.0.0.1889.exe /S 可以靜默安裝，耗時 33 秒。

安裝後會出現服務 QNAP_NetBak_PC_Agent，主程式 TimeBackAgent.exe 常駐約 108 MB 記憶體。Agent 會在所有網路介面的 TCP 11172 埠開一個 HTTPS 服務，憑證檔的密碼直接寫在 appsettings.json 裡。這個埠在企業網路中是否需要對外開放，建議用 Windows 防火牆限縮到管理伺服器的位址。

Agent 附有一支 TimeBackAgentCLI.exe，但它只提供 --login、--authenticate、--upload、--export-report、--uninstall 等指令，沒有輸入 Join Key 的命令列參數。Join 只能在圖形介面裡完成，這對大量部署會是一個門檻，期待之後正式版可以納入大量部署的腳本或容易給 IT 人員部署用的程式碼。

Join 的第一個錯誤：伺服器位址要帶埠號，錯誤訊息卻指向 TLS

Agent 顯示「無法與 NAS 建立 HTTPS 連線」，並建議改用 TLS 1.3 之前的版本（位址與加入金鑰已遮蔽）

第一次在 Agent 的「連線至管理伺服器」畫面，伺服器位址只填了 NAS 的 IP，沒有帶埠號，按下一步後出現上圖的錯誤：「無法與 NAS 建立 HTTPS 連線。NAS 所使用的可能是 TLS 1.3 版，請前往 NAS 的控制台，並選取 1.3 版之前的 TLS 版本。」

這個建議稍微會誤導使用者，CyberQ 的 NAS 其實把管理介面改在非預設埠，所以 HDP Agent 在沒有埠號時會去連 443，而那個埠上的服務不論用 TLS 1.3 或強制 TLS 1.2 都回應 internal error。真正的管理埠用 TLS 1.3 可以正常協商，之後 Agent 也是用 TLS 1.3 連上的。解法是照 Join Key 視窗「複製 URL 與金鑰」給的完整位址（含 https:// 與埠號）填入，不需要去改 NAS 的 TLS 設定，照著錯誤訊息把 TLS 1.3 關掉，反而會白白降低整台 NAS 的加密強度，所以請記得這邊不要去改 TLS 到 1.2 之類的喔。

Join 失敗：Windows 11 的「智慧型應用程式控制」會擋下備份元件

改填完整位址後，畫面換成另一個錯誤：「無法建立目錄清單，錯誤代碼 -1」。追查兩端日誌後，事情的經過是這樣的：

管理伺服器接受了註冊，並在 HDP for PC/VM 建立了這台電腦的目錄（inventory），名稱自動加上 _1 字尾。

接著 NAS 把一個 hdp-agent.zip 擴充套件推送到 Windows 端安裝，內含 QNAP HDP Agent 與 QNAP HDP Backup Service 兩個服務，後者就是 Windows 版的 Bareos 檔案常駐程式 bareos-fd.exe。

bareos-fd.exe 本身有 QNAP 的數位簽章，但它載入的 zlib1.dll 沒有簽章。這台電腦開著 Windows 11 的「智慧型應用程式控制」（Smart App Control，強制模式），Code Integrity 直接擋下載入，事件記錄為 3033／3077，程式結束代碼 0xC0E90002（STATUS_SYSTEM_INTEGRITY_POLICY_VIOLATION）。

服務因此每次都在 30 秒後啟動逾時（系統事件 7009／7000），NAS 端的安裝工作回報 -1，Agent 畫面就只剩一句「錯誤代碼 -1」。

CyberQ 逐一檢查了 Agent 安裝後的所有執行檔與 DLL，共有 123 個沒有數位簽章，其中 15 個屬於 Bareos 元件（包括 zlib1.dll、libcrypto-3-x64.dll、libssl-3-x64.dll、lzo2.dll 等）。新買的 Windows 11 辦公室商用電腦，智慧型應用程式控制常是預設開啟的，在 QNAP 補齊簽章之前，這類電腦無法使用 HDP for Business Agent，而錯誤訊息完全沒有提示原因。智慧型應用程式控制一旦關閉就無法再開啟，除非重灌或重設 Windows，企業在評估時要把這一點算進去。

我們在這台電腦上關閉智慧型應用程式控制後，登錄檔隨即顯示為關閉，但 Code Integrity 仍持續擋下載入，直到重新開機才生效。重開後 QNAP HDP Backup Service 正常啟動並在 TCP 11173 埠監聽，再輸入一次 Join Key 就成功了，管理伺服器端出現以電腦名稱加上 _1 字尾命名的 Workload，狀態為 connected，並自動套用 Join Key 綁定的保護原則。

需要特別驗證的問題

QNAP 社群公告下方的回覆之一（rolandrat，2026-09-25）回報 Windows 用戶端不穩定，他說第一次備份成功後，後續備份全部失敗，錯誤訊息只有「無法備份磁碟 X」，唯一解法是刪除重建。同一則回報也提到筆電喚醒或開機的觸發事件似乎沒有作用。這位使用者同時肯定 QNAP 這個新版備份軟體的努力，筆電備份第一次就能成功還原成虛擬機。

依此為了驗證他這個問題，CyberQ 建立了一個每 10 分鐘執行一次、並啟用「開機時觸發」的原則，刻意重現這兩個情境。

實測紀錄

觸發事件其實有送出，是被「最大頻率」擋掉的

表面上看，睡眠喚醒與開機都沒有觸發備份，和社群回報一致。但成功 Join 之後，Agent 的記錄檔（C:\ProgramData\QNAP\HDP\TimeBack\Agent\logs\main.log）開始有內容，裡面記得很清楚：

2026-09-30 13:35:26.442 [INF] OnPowerEvent: ResumeSuspend
2026-09-30 13:35:57.057 [INF] Start the backup job '...' triggered by event 'PowerOn'.
2026-09-30 13:35:57.362 [ERR] System.Exception: [400] {"return_code": -1, "detail": "The job cannot be started due to trigger interval setting.", ...}

喚醒後 31 秒，Agent 就以 PowerOn 事件要求 NAS 開始備份，重開機的情況則是在登入後約 2.5 分鐘送出。兩次都被 NAS 以「trigger interval setting」拒絕。這個設定在原則精靈裡叫做「最大頻率」，選項只有 1、2、3、4 小時，距離上一次備份未滿這段時間，事件觸發一律被擋下。我們的原則每 10 分鐘就跑一次排程，上一次備份永遠在一小時內，所以觸發永遠不會成功。

CyberQ 觀察，觸發事件本身是會動的，但先被一小時起跳的頻率限制擋住，就算通過了，下一段會看到另一個問題。對筆電使用者來說，如果排程與事件觸發同時開著，或者在一小時內重複開關機，就會看起來像觸發沒作用。社群回報的現象，CyberQ 認為這很可能有一部分是這個原因。

為了確認觸發本身能不能成功，我們把原則改成只手動執行（避免排程不斷重置計時），最大頻率維持 1 小時，等上一次備份（15:00:57）過了一小時後，在 16:05:47 重新開機。這一次 Agent 在 16:08:59 送出 PowerOn 觸發，沒有被拒絕，Bareos 端隨即跑了一趟增量備份（JobId 34，16:09:04 至 16:09:40，2.012 GB，Backup OK）。

但這趟備份在 HDP for Business 主控台裡找不到，工作清單最新一筆仍是 15:00 的排程，Workload 的「上次備份時間」停在 15:00，版本清單裡也沒有 16:09 這個版本。HDP 的事件日誌只留下「Started backing up C:\」與「Completed backup C:\」兩行。也就是說，事件觸發的備份確實在引擎端完成了，但主控台既不顯示、也沒有可供還原的版本入口，這個問題應該會在正式版有新的說明或機制來避免此種情境出現，順道解決這個小問題。

Windows 端的記錄檔位置

預設記錄層級是 Warning，Join 成功前多數檔案都是 0 位元組，成功後常用的是下列幾個：

八、實測五，不可變備份能不能被管理員刪掉

這是本文最想驗證的一項，根據 QNAP 官方網站的說法，「備份一寫入就鎖定，期限到之前誰都改不了、刪不掉，即使是管理員」。建立 Protection Policy 時選 Immutable Protection Policy，保留期限只能以天數設定，原則類型建立後不能更改。前提是備份伺服器要跑 QuTS hero。

底層機制：restic 儲存庫加 QuTS hero 的 WORM

先看一下它是怎麼鎖的，後面的測試結果才好解讀。

HDP_Business 共用資料夾是一個 QuTS hero 的 WORM 資料夾：wormtype=enterprise、wormtrigger=readonly、wormretention=0y0m1d。

不可變原則的備份完成後，HDP 會把這個版本相關的 restic 檔案改成唯讀，並把檔案的 atime 設成保留期限到期的時間。這是 WORM 的「唯讀即鎖定」觸發方式，概念與 NetApp SnapLock 相同。

被鎖住的只有這個版本新寫入的檔案，它的 snapshot 檔、index 檔，以及它新產生的 2 個資料 pack。儲存庫裡其餘 404 個 pack 仍是一般可寫檔案，雖然這個版本透過去重引用了其中一部分。

測試方法

建立保留期限 1 天的 Immutable Protection Policy，指派給測試 VM，跑一次備份。

以主控台（API）嘗試解除鎖定、修改原則、刪除原則。

以 root 身分 SSH 進 NAS，直接對被鎖住的檔案執行刪除、改名、改權限、清空內容與改時間戳記。

從主控台刪除整個 Workload。

等保留期限過後，確認版本是否能正常清除。

實測紀錄

# 以 root 嘗試修改被鎖定的 snapshot 檔（路徑中的儲存庫名稱每台不同）
R=/share/ZFS21_DATA/HDP_Business/backup_repository/<儲存庫名稱>
ls -la $R/snapshots/
rm -f $R/snapshots/<snapshot-id>        # rm: can't remove ...: Operation not permitted
mv $R/snapshots/<snapshot-id> /tmp/     # mv: can't rename ...: Operation not permitted
touch -a -d "2026-09-30 03:00" $R/snapshots/<snapshot-id>   # Operation not permitted
stat -c "%A %x" $R/snapshots/<snapshot-id>   # -r--r----- 2026-10-01 02:52:29
zfs get wormtype,wormtrigger,wormretention zpool1/zfs21

怎麼解讀這些結果 ?

在檔案層級，QuTS hero 的 WORM 確實擋得住 root，這比只是應用程式不讓你按刪除，要紮實得多。但防護有兩個邊界值得注意：

鎖定的範圍只到該版本新寫入的檔案

兩個不可變版本合計只鎖住 4 個資料 pack，共 0.6 MB，儲存庫裡其餘 405 個 pack（6,993 MB）都是一般可寫檔案。其中 04:07 的不可變版本是增量備份，邏輯大小 34.4 GB，新傳輸的資料只有 1.9 MB，也就是說它幾乎所有的資料都放在未鎖定的 pack 裡。我們以 root 對其中一個 pack（該 VM 03:52 完整備份寫入的 8.7 MB 檔案）執行 mv，指令直接成功（rc=0），之後立即搬回，md5 比對一致。HDP 的 restic 密碼以它自己的金鑰加密保存，這次當然就沒有取出，因此沒有用 restic 實際跑一次「缺 pack 後的完整性檢查」，但 CyberQ 認為，若依 restic 的去重設計，這類 pack 一旦被刪，引用它的不可變版本即使 snapshot 檔還在，也無法完整還原。

主控台允許刪除整個 Workload

刪除之後，受保護的資料雖然還在磁碟上，但失去了主控台的入口。對勒索軟體情境來說，資料沒被刪掉是好事，但若是管理員誤刪，要如何重新取回這些孤立的版本，主控台沒有提供路徑。

另外，HDP_Business 是 Enterprise 模式的 WORM 資料夾，而非 Compliance 模式。Enterprise 模式原本允許管理員刪除整個共用資料夾，QuTS hero h6.0.2.3591 的發行說明寫明新增了 Secure Deletion，刪除 Enterprise WORM 共用資料夾時需要事先建立的 USB 金鑰檔。我們沒有實際測試刪除整個資料夾。換句話說，整批清除仍然有路，但要多過一道實體金鑰。異地副本則不同，第十一節會看到它用的是 S3 Object Lock 的 Compliance 模式。

九、實測六，備份驗證與開機影片

這個可說是 QNAP HDP Business 最重要的功能之一，備份驗證在 Protection Policy 的 Advanced Settings 中啟用。每次備份完成後，系統在備份伺服器的 Virtualization Station 上以臨時虛擬機開機並錄影。影片長度預設 120 秒，範圍 30 至 600 秒。

實測紀錄

影片存放在 HDP_Business/verification_repository/<儲存庫>/<Workload ID>/<任務 ID>.webm，可以直接下載，放進稽核底稿很方便。

十、實測七，即時還原與轉為永久虛擬機

即時還原直接在備份伺服器的 Virtualization Station 上，把備份開成虛擬機。實作上，HDP 以 FUSE 把備份掛成唯讀的磁碟映像，再疊一層 overlay 檔案承接寫入。還原精靈有 General、Convert、Storage、Network、Summary 五個步驟。

第一個陷阱：網路卡 MAC

精靈預設會產生一組新的 MAC 位址。我們的測試 VM 是 Debian cloud image，cloud-init 產生的網路設定綁定原本的 MAC，因此第一次即時還原出來的虛擬機，15 秒內就開到登入畫面，卻完全沒有網路。改用原本的 MAC 重做一次，網路才正常。這不是 HDP 的錯，但在真的要救火時很容易卡住。使用原 MAC 的前提是原虛擬機已經停機，否則會在區網上撞 MAC，而且只要 Virtualization Station 上還留著用同一組 MAC 的虛擬機（即使已關機），HDP 就會拒絕建立，錯誤為「MAC address … is already in use」。

實測紀錄

幾點說明：

預設的 IDE 匯流排是最大瓶頸

同一個備份，改選 VirtIO 後隨機 IOPS 提高 3.3 倍。精靈的選項裡有 VirtIO，救火時請記得改。

即使用 VirtIO，也只有原環境的約 15%

這符合官方「IO 效能受限」的說明，即時還原適合先讓服務恢復，不適合長期上線。

循序讀取的數字不列入比較

臨時虛擬機內的 1 MB 循序讀取測試數值為 1,845 MB/s，但那是 fio 剛寫入的測試檔，命中了 NAS 主機端的快取，並不代表從備份讀取的速度。

轉換後效能沒有改善

因為磁碟匯流排沿用 IDE。轉換完成後若要長期使用，應在 Virtualization Station 裡把磁碟改成 VirtIO。

轉換後的虛擬機歸 Virtualization Station 管理，無法再從 HDP for Business 刪除。

臨時虛擬機內的效能測試指令（Linux 虛擬機）。請務必加 --direct=1，否則測試到的是客體系統的頁面快取。

fio --name=randrw --ioengine=libaio --direct=1 --rw=randrw --bs=4k --size=1G --numjobs=1 --iodepth=16 --runtime=60 --time_based --group_reporting
fio --name=seqread --ioengine=libaio --direct=1 --rw=read --bs=1M --size=2G --numjobs=1 --iodepth=8 --runtime=60 --time_based --group_reporting

十一、實測八，異地副本與 Object Lock

任何原則都可以在 Backup Copy 步驟啟用異地副本，目標支援 QuObjects、myQNAPcloud Object、Amazon S3、Wasabi 與 S3 相容儲存。只有啟用 Object Lock 的 Bucket 才能被選取。

CyberQ 在 TS-673A 上安裝 QuObjects 2.5.721 當作異地目標，過程中有三個需要注意的地方：

QuObjects 的 Bucket 要啟用 Object Lock，所在的儲存空間必須開啟 WORM，而且 Bucket 要開版本控制。 在未開 WORM 的儲存空間建立 Object Lock Bucket，API 直接回 400。

HDP 的端點欄位不能帶 https://。 寫成 https://主機:8010 會得到「Endpoint url cannot have fully qualified paths」，要寫成 主機:8010。錯誤訊息透露 HDP 是用 MinIO 用戶端連線。

QuObjects 的 Access Key ID 格式是「儲存空間名稱:金鑰」，而且使用者必須被設為該儲存空間的管理者，S3 用戶端才認得。

實測紀錄

# 以 AWS CLI 對 QuObjects 驗證 Object Lock（Access Key ID 為「儲存空間:金鑰」）
aws --endpoint-url https://<QuObjects 主機>:8010 s3api get-object-lock-configuration --bucket <bucket>
aws --endpoint-url https://<QuObjects 主機>:8010 s3api get-object-retention --bucket <bucket> --key <object-key>
# {"Retention": {"Mode": "COMPLIANCE", "RetainUntilDate": "2026-09-30T20:11:00+00:00"}}
aws --endpoint-url https://<QuObjects 主機>:8010 s3api delete-object --bucket <bucket> --key <object-key> --version-id <version-id>
# An error occurred (AccessDenied) when calling the DeleteObject operation: Access denied

與本機儲存庫相比，異地副本的鎖定範圍完整得多，副本裡的每一個物件都帶保留期限，不像本機只鎖住該版本新寫入的檔案。若要在勒索軟體情境下恢復資料，異地副本確實是最完整的最後防線。

十二、實測九，Airgap+ 排程離線

Airgap+ 以每週 168 個一小時格子設定，選取的時段標記為 Deny all collections，備份伺服器在該時段內關機。主控台的說明文字只寫「During the Airgap+ protection period, the backup server will be shut down」，官方文件也沒有交代時段結束後怎麼開機。

開機機制：寫入 QTS 的排程開關機

我們在 TS-673A 上設定星期三 05:00 至 06:00 為離線時段，隨即比對系統設定，發現 HDP 做了兩件事：

把 QTS 控制台「電源 > 排程開關機」（/etc/config/schedule_boot_setting）改成啟用，寫入兩個動作：每週三 05:00 關機、06:00 開機。

在 crontab 加入 0 5 * * 3 /etc/init.d/poweroff 與 0 6 * * 3 /etc/init.d/startup。

也就是說，自動開機靠的是 NAS 硬體的 RTC 排程開機，不是 Wake-on-LAN。IT 環境的管理者這邊請一定要注意兩件事，機種必須支援排程開機，而 QTS 裡原本若已有自訂的排程開關機設定，會被 Airgap+ 覆寫（我們這台原本有一筆停用中的 07:00 關機設定，套用後被取代，之後取消 Airgap+，HDP 會把排程開關機停用、移除 crontab 項目，但不會還原原本的內容）。另外，管理伺服器本身在 API 裡也有 Airgap+ 欄位，本測試沒有對管理伺服器設定離線。

實測紀錄

# 在管理端以外的主機持續監看
ping -i 15 <備份伺服器 IP> | while read l; do echo "$(date '+%F %T') $l"; done | tee airgap-ping.log
# 在備份伺服器上確認 Airgap+ 寫入的排程
cat /etc/config/schedule_boot_setting
crontab -l | grep -E "poweroff|startup"

十三、觀察與評價

以下判斷只根據本文實測到的現象，Beta 版的問題，預期 QNAP 有機會在正式版修正並強化。

做得好的部分

不可變備份在檔案層是真的鎖住了

被鎖定的 snapshot、index 與資料 pack，連 root 都刪不掉、搬不走、改不了權限與時間戳記，主控台也拒絕關閉不可變屬性、拒絕刪除套用中的原則。這是建立在 QuTS hero 的 WORM 上，不只是應用程式介面擋按鈕。

異地副本的 Object Lock 很完整

寫到 QuObjects 的每一個物件都帶 Compliance 模式的保留期限，指定版本永久刪除被拒絕，加上略過 Governance 的參數也一樣，沒開 Object Lock 的 Bucket 根本選不到。

去重與增量有效率

零區塊不佔空間，160 GiB 的空磁碟只剩 2.23 GB，Proxmox VE 的增量靠 CBT，變更 2.147 GB 就只傳 2.153 GB，Windows 端連續 5 次增量每次 42 至 53 秒完成，社群回報的「無法備份磁碟 X」沒有重現。

即時還原與轉換夠快

從按下還原到可以登入 45 秒，轉成永久虛擬機約 2 分鐘，實際多用的空間遠低於主控台預估。

Airgap+ 是真的關機

時段開始後主機確實斷電離線，結束後靠 QTS 排程開機自動回來，約 6 分鐘後主控台恢復 Online。

計畫性的備援切換很快

兩台都正常時，切換到備援伺服器約 6 秒，切回來約 4 秒，Workload 與原則都沒有遺失。

Beta 階段明顯的限制

僅支援 QuTS hero h6.0.2 以上，QTS 機型目前無法參與，單站台 4 台伺服器上，管理伺服器故障時的切換是手動的。

不可變只鎖住該版本新寫入的檔案

兩個不可變版本合計只鎖 0.6 MB，其餘 6,993 MB 的 pack 以 root 可以移動，主控台也允許刪除整個 Workload，刪了之後受保護的資料留在磁碟上，卻沒有入口可以還原。

Windows Agent 撞上智慧型應用程式控制

123 個執行檔與 DLL 沒有簽章，開著這項功能的 Windows 11 無法 Join，錯誤訊息只有「錯誤代碼 -1」，位址少了埠號時，錯誤訊息還會誤導使用者去關閉 NAS 的 TLS 1.3，MSI 也無法靜默安裝，Join 只能在圖形介面完成。

事件觸發幾乎用不上

睡眠喚醒與開機確實會送出觸發，但距離上次備份未滿一小時就被拒絕，等滿一小時後觸發成功，引擎也完成了備份，主控台卻沒有這筆工作、沒有這個版本，同時，上次備份時間並未更新，以至於錯過的排程則不會補跑。

與市場上同類方案的比較

CyberQ 認為，QNAP 這套方案與 Synology 走了明顯不同的路線，Synology 近期推出專用備份設備，QNAP 則強調在既有 NAS 上以軟體實現。不可變備份、備份驗證、即時還原這幾項在 Veeam 等商用軟體中已是標準配備，HDP for Business 的價值在於把它們放進不按節點收費的 NAS 環境。

從這次實測看，功能清單大致都做出來了，可以再加強的是狀態回報方面需要更精緻，以及與 Windows 端的相容性，這兩項恰好是企業上線前重視的。

這套軟體方案適合誰呢?

1、已有 QuTS hero 機型、環境中有 Proxmox VE 的組織，這仍是目前 QNAP 產品線裡唯一能備份 Proxmox VE 的選擇，適合現在就開始試用與回報問題給該公司。

2、想要異地不可變副本的單位，搭配啟用 Object Lock 的 QuObjects 或 S3 相容儲存，這部分的行為已經相當扎實。

3、需要為 ITGC 或 ISO 27001 準備「備份可還原」證據的單位，暫時不要只靠驗證影片與主控台的成功率報表，應同時保留引擎端的工作紀錄或實際還原演練。

4、仍在使用 QTS、使用 ARM 機型的 NAS，建議等正式版。

十四、結論

HDP for Business Beta 的骨架是扎實的：Bareos 搬資料、restic 去重，再由 QuTS hero 的 WORM 與 S3 Object Lock 上鎖。不可變版本在檔案層連 root 都刪不掉，異地副本的每個物件都以 Compliance 模式鎖住，即時還原 45 秒可登入，Airgap+ 會真的斷電。

問題在外面那一層：主控台常把成功的備份報成失敗、驗證時好時壞、Windows Agent 過不了智慧型應用程式控制、事件觸發的備份不是被頻率限制擋掉，就是跑完了卻不進主控台，錯誤訊息又多半只有「-1」或「500」。這些都落在「備份到底有沒有成功」的判斷上。

建議先在測試環境試用，正式採用前，至少等主控台狀態與引擎一致、Windows 端補齊簽章。

資料來源

QNAP，HDP for Business 產品頁，https://www.qnap.com/zh-tw/software/hdp-for-business

QNAP，Apps 發行說明，HDP for Business，https://www.qnap.com/zh-tw/app-release-notes?app=hdppro&product-line=nas（版本清單取自該頁使用的 API：https://www.qnap.com/api/v1/app-release-notes/nas/hdppro?locale=en，查詢日期 2026-09-30）

QNAP，新聞稿：QNAP Launches HDP for Business Beta，2026-09-21，https://www.qnap.com/en/news/2026/qnap-launches-hdp-for-business-beta-transforms-nas-into-a-zero-trust-ransomware-resilient-backup-center

QNAP Community，Introducing HDP for Business (Public Beta)，2026-09-22，https://community.qnap.com/t/introducing-hdp-for-business-public-beta/7010

QNAP，How to Set Up and Use HDP for Business，2026-09-18 更新，https://www.qnap.com/en-us/how-to/tutorial/article/how-to-set-up-and-use-hdp-for-business

QNAP，How to Protect a Physical Device with HDP for Business Agent，2026-09-17 更新，https://www.qnap.com/en/how-to/tutorial/article/how-to-protect-a-physical-device-with-hdp-for-business-agent

QNAP FAQ，Why does HDP for Business start my stopped Proxmox virtual machine?，https://www.qnap.com/en/how-to/faq/article/why-does-hdp-for-business-start-my-stopped-proxmox-virtual-machine

QNAP FAQ，Why is every backup of my Proxmox VM a full backup?，https://www.qnap.com/en/how-to/faq/article/why-is-every-backup-of-my-proxmox-vm-a-full-backup

QNAP，QuTS hero h6.0.2.3591 發行說明，https://www.qnap.com/en-us/release-notes/quts_hero/h6.0.2.3591/20260819

QNAP Newsroom，QNAP at COMPUTEX 2026，2026-06-01，https://www.qnap.com/en/news/2026/qnap-at-computex-2026-driving-the-future-of-business-continuity-and-edge-ai-innovation