QNAP 在 2026 年 10 月 30 日發布 HDP for PC/VM（原名 Hyper Data Protector）2.4.2.1195。這是 9 月 17 日 2.4.1.1084 之後的維護版，官方發行說明只有六行，一項「強化了幾項安全措施」，加上五項錯誤修正，其中兩項與 Hyper-V 有關，兩項與裸機還原（BMR）有關，一項與 HDP PC Agent 的更新流程有關。
六行字看不出升級的急迫性，也看不出風險。本文用兩台 QNAP NAS 與一台 Proxmox VE 主機實測，先把一台 NAS 降回 2.4.1 當對照組，逐項重現發行說明裡的問題，再原地升級到 2.4.2 確認是否修好，同時把兩個版本的官方安裝包解開比對，找出「安全措施」實際換掉的元件。
CyberQ 實測的心得是，裸機還原到 4K 實體磁區硬碟這一項，2.4.1 確實會卡死，2.4.2 確實修好了，而且修法看得出來是把分割區對齊到目標磁碟的實體磁區。安全更新主要是整批更新內建的開源元件。
一、發行說明原文
2.4.2.1195（2026/10/30）的內容如下：
- [安全更新] 強化了幾項安全措施，進一步提高應用程式安全性。
- 修正 Hyper-V 虛擬機器的檔案搬移或匯入至其他資料夾後，備份可能在傳輸任何資料前就失敗的問題。
- 修正 Hyper-V 重新整理清單時，可能因 WinRM 偶發錯誤而失敗的問題。
- 修正來源磁碟的分割區配置未對齊目標磁碟的實體磁區大小時，裸機還原（BMR）可能在建立分割區階段失敗的問題。
- 修正 PC Agent 更新失敗後，無法再從「清單（Inventory）」的更新按鈕重新觸發更新的問題。
- 修正系統碟執行裸機還原後，設定自訂備份範圍的實體裝置後續備份皆失敗並顯示錯誤代碼 11001 的問題。
二、實測環境
| 角色 | 設備與版本 |
|---|---|
| 對照組與受測機 | TVS-h877AX，QuTS hero h6.1.0.3656，HDP for PC/VM 先裝 2.4.1.1084，測完原地升級 2.4.2.1195 |
| 升級回歸檢查 | TS-855X，QuTS hero h6.1.0.3656，HDP for PC/VM 經 App Center 由 2.4.1.1084 升級到 2.4.2.1195，並已由 HDP for Business 集中管理 |
| 虛擬化平台 | Proxmox VE 9.2，Intel Core 系列處理器、62 GB 記憶體，開啟巢狀虛擬化 |
| Hyper-V 主機 | Windows 11 Enterprise 評估版（組建 26300）虛擬機，啟用 Hyper-V，內含兩台 2 GB 的第二代測試虛擬機 |
| PC Agent 端點 | 同版 Windows 11 虛擬機，HDP PC Agent 1.5.1.1862，系統碟 64 GB，含 C 槽與一個 2 GB 資料分割區 |
| BMR 目標 | 兩台空白虛擬機：一台磁碟回報邏輯 512、實體 4096 位元組（512e），一台維持 512／512 當對照 |
| 還原媒體 | HDP Recovery Media Creator 1.1.0.359 產生的 ISO（WinPE 10.1.26100.9457） |
兩台 NAS 在我們開始測試前都已經被升級到 2.4.2。為了取得對照組，我們先把 TVS-h877AX 上 2.4.2 的設定與資料庫完整備份，移除後重新安裝官方的 2.4.1.1084 安裝包。TS-855X 上的 HDP for PC/VM 已被 HDP for Business 接管，平時在跑 Proxmox VE 的自動保護，沒有動它，只拿來檢查升級後既有設定是否保留。
三、拆開安裝包：安全強化實際換了哪些元件
兩個版本的安裝包都從官方下載點取得，zip 內的 QPKG 都帶有 QNAP 的 S/MIME 簽章。QPKG 本身是一段 shell 標頭加上 tar 封裝，不必執行就能用標頭裡寫明的位移量解出內容。解開後，HDP for PC/VM 由三個容器根目錄組成，API 服務（Alpine Linux 加 Python 3.12）、備份引擎（Bareos，Debian 系）與 PostgreSQL。2.4.1 共 24,589 個檔案，2.4.2 為 24,765 個，雜湊不同或增刪的檔案有 3,951 個，其中 2,633 個在 API 容器。
| 元件 | 2.4.1.1084 | 2.4.2.1195 |
|---|---|---|
| API 容器基底 Alpine | 3.22.0 | 3.24.3 |
| OpenSSL（API 容器） | 3.5.8 | 3.5.9 |
| Python | 3.12.10 | 3.12.16 |
| libcurl | 8.14.1 | 8.23.0 |
| SQLite | 3.49.2 | 3.53.4 |
| cryptography | 48.0.0 | 50.0.2 |
| PyJWT | 2.11.0 | 2.15.1 |
| urllib3 | 2.6.3 | 2.8.0 |
| pyOpenSSL | 26.2.0 | 26.4.0 |
| certifi（CA 憑證包） | 2026.7.22 | 2026.10.23 |
| PostgreSQL | 16.8 | 16.8（未變） |
所謂「強化安全措施」，從檔案層面看主要是整批更新相依元件，Alpine 跨兩個次版本、OpenSSL 與 Python 各補到新的修補版、curl 一口氣跳了九個次版本，處理 JWT、TLS 與 HTTP 的 Python 套件也全部換新。HDP 自己的程式碼裡，與驗證有關的改動只有一處，hdp/auth/jwt.py 解碼存取權杖時，原本只攔截格式錯誤、簽章錯誤與過期三種例外，2.4.2 改為攔截 PyJWT 所有的 InvalidTokenError。在 2.4.1，簽發者不符或尚未生效的權杖會落到通用的例外處理，請求同樣被拒絕，但回的是一般 API 錯誤並在記錄檔留下完整堆疊；2.4.2 則一律回 401。這是錯誤處理的收斂，不是驗證被繞過的漏洞。
對外的網路面沒有變化。兩個版本在 NAS 上監聽的連接埠相同：Bareos 儲存服務 9103 對所有介面開放（PC Agent 與虛擬化主機要直接把資料送進來），API 9104、Bareos Director 9106、檔案服務 9102 與通知代理 9107 都只綁 127.0.0.1，網頁介面透過 QTS 的反向代理掛在 /vmbackup/。PostgreSQL 停在 16.8 沒有更新，這一點值得留意。
發行說明沒提，但安裝包看得出來的改動還有幾項，可以從 VM 備份工作中單獨刪掉一台 VM（API 新增 instance_id 參數），被 HDP for Business 接管後，會一併刪除「前一個工作結束就觸發下一個」的連動排程，避免繞過集中排程。
Proxmox 帳號開了雙因素驗證時會給出明確錯誤，Proxmox 密碼改掉後，清單狀態不再一直顯示已連線。還原媒體與 PC Agent 端的外掛也一起更新，timeback 外掛由 3.2.0.133 升到 3.2.1.138，其中負責磁碟操作的 diskutil 多了「無法辨識在某位移量建立的分割區」這類新訊息，對應的正是 BMR 建立分割區的修正。
四、升級過程與既有設定
TS-855X 在 App Center 升級，系統事件記錄顯示 23:09:18 開始安裝，23:09:54 完成，HDP for Business 的綁定、兩個存放庫、Proxmox VE 與 VMware 清單全部保留，HDP for Business 的自動保護規則在升級後也照常偵測並加入新的虛擬機。
TVS-h877AX 在 2.4.1 跑完所有對照測試後，用官方簽章的 2.4.2 安裝包原地升級，耗時 76 秒，API 在升級完成 9 秒後恢復回應。升級前後用 API 匯出的清單、工作、存放庫識別碼完全一致。
升級後有兩個細節值得注意。第一，HDP 每次啟動都會刪除並重建 Bareos 的設定目錄，備份工作的設定檔要等背景工作「RefreshJobConfigs」跑完才會補回來，這段空窗在 CyberQ 的機器上約兩分鐘。空窗內手動啟動備份會直接失敗，API 回傳 -1，記錄檔只看得到 bconsole 執行失敗。升級或重新啟動 HDP 後，建議等兩三分鐘再手動觸發備份。
第二，啟動時的資料庫清理會把先前 BMR 留下的暫時清單刪掉，連帶對同一台裝置下「強制取消註冊」，結果剛被裸機還原過的那台 PC 從 HDP 的角度變成未註冊，重新整理清單時回 500。CyberQ 在 PC 端用 TimeBackAgentCLI.exe --login 重新登入後恢復。這段清理邏輯在 2.4.1 與 2.4.2 完全相同，不是新版造成，但只要做過 BMR 又重啟過 NAS 或 HDP，就可能碰到。
五、修正逐一實測
1. BMR 在建立分割區階段失敗：2.4.1 重現，2.4.2 修正
我們在 PC Agent 端點的系統碟上，刻意用 diskpart 的 align=1 建出一個 2 GB 資料分割區，起始位移是 64,560,825,344 位元組，除以 4096 餘 1024，也就是沒有對齊 4K。寫入 40 個隨機檔案並記錄雜湊後做一次完整備份，再用 HDP Recovery Media Creator 產生 ISO，讓兩台空白虛擬機從 ISO 開機做整機還原。
| 目標磁碟 | 2.4.1.1084 | 2.4.2.1195 |
|---|---|---|
| 512 邏輯／4096 實體（512e） | 停在「準備中」，NAS 記錄「Failed to create partitions on disk “0”」與「Failed to restore」 | 約 10.5 分鐘完成，Windows 正常開機 |
| 512／512（對照） | 約 13.5 分鐘完成，Windows 正常開機 |
還原完成後檢查分割區表，可以看出修法，2.4.2 把資料分割區的起點從 64,560,825,344 往前挪到 64,560,824,320，剛好對齊 4096，大小則多加 4 KB 補回來。40 個測試檔案的雜湊全部相符，只是磁碟機代號從 T 變成 D，這是 Windows 對新磁碟區的正常行為，還原後要自己改回來。
如果貴公司的 PC 或伺服器要從 512 位元組磁區的舊硬碟搬到 4K 實體磁區的新 SSD 或新主機，這一項就是升級的主要理由。
2. 系統碟 BMR 後，自訂範圍的備份失敗：症狀在我們的情境下仍存在
發行說明說的是「設定自訂備份範圍的實體裝置，在系統碟 BMR 之後後續備份全部失敗，錯誤代碼 11001」。我們的備份工作只選了 C 槽與資料分割區，屬於自訂範圍。2.4.1 上 BMR 完成、讓還原後的機器接回原本的網路位置後，原工作立刻失敗，3 秒結束、傳輸 0 位元組，記錄寫著「could not back up volume … The volume was invalid」。原因很清楚，BMR 會產生新的磁碟區 GUID，工作設定卻還指向舊的 GUID。
從原始碼比對可以找到 2.4.2 的修正位置，還原完成後負責更新磁碟對應的 DiskInfoUpdater，在 2.4.1 只要發現磁碟唯一識別碼沒變就直接返回，從不記錄磁碟區 GUID 的變化，2.4.2 改成無論磁碟識別碼有沒有變，都會寫入磁碟區對應表並更新工作設定。
但我們在 2.4.2 上重做一次 BMR（同一個還原點，目標是 4K 那台），再跑原工作，結果一樣失敗。記錄檔顯示更新程式寫著「Skip updating the newly added disk#0」，BMR 的目標在 HDP 眼中是一個暫時的「BMR（IP）」清單，它的磁碟被當成新加入的磁碟而略過，新的對應邏輯根本沒有執行到。換句話說，在「整機還原到新硬碟」這個情境下，2.4.2 還沒有自動接回自訂範圍的工作。另外要提醒，在 2.4.1 時代做過 BMR 而壞掉的工作，升級到 2.4.2 也不會自動修好。
由於從頭到尾沒看到 11001 這個代碼，無法排除 QNAP 修的是另一條路徑，例如還原到原機原磁碟。實務上，BMR 之後請直接在 PC 端的 HDP PC Agent 重新編輯備份工作、重新勾選磁碟區。NAS 端的網頁介面對 PC Agent 的工作沒有編輯按鈕，只能從 PC 端改。
3. Hyper-V 虛擬機搬移或匯入後備份失敗：2.4.1 多數情境沒有重現，2.4.2 錯誤訊息明顯改善
我們在 Hyper-V 主機上準備兩台測試虛擬機，先各做一次完整備份，再用五種方式改變它們的位置，每次改完立刻備份：
| 情境 | 2.4.1.1084 | 2.4.2.1195 |
|---|---|---|
| Move-VMStorage 搬到同一磁碟區的其他資料夾 | 成功（增量 217 KB） | 未重測 |
| Export 再 Import（保留原 ID）到其他資料夾 | 成功（自動改做完整備份） | 未重測 |
| Move-VMStorage 搬到另一個磁碟區 | 成功（增量 217 KB） | 成功（增量 126 KB） |
| 只複製 VHDX 並改掛載路徑 | 成功（自動改做完整備份） | 未重測 |
| Export 後刪除原機，再以新 ID 匯入 | 失敗，0 位元組，原因不明 | 失敗，但 2 秒內給出明確原因 |
前四種情境在 2.4.1 都沒有失敗，我們無法重現發行說明描述的問題。第五種情境本來就是一台新的虛擬機，舊工作找不到它是合理的，差別在錯誤訊息，2.4.1 只說「An unexpected error occurred in inventory “HDPLAB-A”. Role: Inventory Agent.」，2.4.2 則在備份開始前直接查詢 Hyper-V 主機上現存的虛擬機，回報「VM does not exist or has been removed」。原始碼也印證這點，2.4.2 新增 vm_presence.py 與 get_vm_presence.ps1，在備份前即時確認虛擬機是否還在，不再只信任每五分鐘更新一次的清單快照。
4. Hyper-V 清單重新整理因 WinRM 偶發錯誤失敗：沒有重現
我們對 Hyper-V 清單連續重新整理 40 次，再兩條連線同時各打 10 次，2.4.1 全部成功，NAS 端記錄也沒有任何 WSMan 錯誤。2.4.2 上同樣做連續 20 次加上兩條連線各 10 次，40 次也全部成功。從原始碼看，2.4.2 針對的是開 WinRM 殼層時撞上「使用者設定檔登錄機碼還在卸載」的競態（錯誤碼 0x3FA 與 0x80040154），開殼層失敗時最多重試三次、間隔一秒。這種競態跟主機負載與殼層開關頻率有關，我們的單機測試環境沒有觸發，但修法本身很保守，只重試開殼層，不會重複執行指令。
五、實測中順手發現的問題
- HDP Recovery Media Creator 會自己安裝 ADK：工具需要 .NET 10 桌面執行環境，並會下載安裝 Windows ADK 與 WinPE 外掛，若電腦上已經裝過 ADK，必須先移除。WinPE 外掛約 3.8 GB，我們在虛擬機內透過安裝程式下載只有每秒約 170 KB，直接下載同一個檔案卻有每秒 10 MB，事先準備好檔案可以省下大量時間。
- HDP for Business 的自動保護會把新虛擬機一併納入：TS-855X 上的 HDP for Business 設有 Proxmox VE 自動保護規則，我們為了測試建立的四台 Windows 虛擬機，都在建立後不久被自動加入保護。對正式環境是好事，但做測試時要記得排除，否則下一次排程會把測試機整台備份進去。
六、該不該升級
- 要做硬體汰換或跨磁碟 BMR 的單位：建議立刻升級。 512 位元組磁區搬到 4K 實體磁區新硬碟的整機還原，在 2.4.1 會卡在建立分割區，2.4.2 修好了，我們實測資料完整。
- 只用 HDP for PC/VM 備份 VMware、Proxmox VE 的單位：可以升級。 安全更新以元件換新為主，升級保留所有設定，耗時一兩分鐘，風險低。升級後等兩三分鐘再手動觸發備份。
- 用 PC Agent 做自訂範圍備份的單位：升級無妨，但不要期待 BMR 之後工作會自己接回來。BMR 之後請到 PC 端重新編輯工作、重選磁碟區，並確認下一次備份成功。
- Hyper-V 環境：新版在虛擬機被搬走或重新匯入時，錯誤訊息清楚得多，排錯省時間，值得升級。
整體來說，2.4.2 是一個名實相符的維護版，發行說明裡最具體的 BMR 修正確實到位，安全更新是常規的元件換新，沒有改動對外的網路面，建議 QNAP 往後至少註明修正對應的情境與錯誤代碼出現的位置。
資料來源
- QNAP App 發行說明：HDP for PC/VM（Hyper Data Protector）2.4.2.1195，2026/10/30
- QNAP 官方安裝包 HDPforPCVM_2.4.1.1084_x86_64.zip、HDPforPCVM_2.4.2.1195_x86_64.zip
- QNAP HDP PC Agent 1.5.1.1862、HDP Recovery Media Creator 1.1.0.359
- 本站實測記錄（2026/10/30 至 10/31）
