QNAP 於 2026 年 11 月 9 日同時發布 Qsync Central 5.3.0.4（適用 QTS／QuTS hero 6.1.0 以上）與 5.2.0.7（適用 QuTS hero h6.0.x）。兩版的修正項目相同，5.3.0.4 另外修正特定 ARM64 機種的安裝相容性問題。發行說明列出的重點包括：備份任務的穩定性與版本控制準確度、File Station 與 Qsync 的同步問題、Qfile 的搜尋與搬移行為、Windows 用戶端大量檔案批次傳輸的效能，以及多項安全更新。
筆者在一台正式運作中的 TS-855X 上，以原本就安裝的 5.3.0.3 作為對照組，先完成一輪基準測試，再升級到 5.3.0.4 重跑同樣的項目，並把兩版安裝包解開逐檔比對。測試心得如下：
- 安全修補確實，上傳端點、密碼儲存與偵錯包都有明確改動，值得升級。
- 備份任務的版本控制改成「每個任務各自一份設定」，行為與舊版不同，管理者要知道。
- 同步速度有加快，實務上可以多觀察系統狀態。
測試環境
| 項目 | 內容 |
|---|---|
| NAS | QNAP TS-855X（Intel Atom C5125、64 GB RAM），QuTS hero h6.1.0.3656 |
| Qsync Central | 5.3.0.3（build 20260916）升級至 5.3.0.4（build 20261104） |
| 用戶端 | Qsync Client 6.1.0.0831，Windows 11，同一個區網 |
| File Station | File Station 6（6.3.1.8276） |
這台 NAS 平時還同時執行虛擬機、容器與 HDP for Business 的排程備份，負載會起伏。這對功能測試影響不大，但部分效能數字會受干擾，後文會說明。
測試全部在新建的資料夾進行，一組同步配對（NAS 共用資料夾中，開新資料夾對應用戶端的獨立資料夾），以及一個即時備份任務。用戶端原本的其他同步配對沒有動。
升級過程
用官方安裝包升級，61 秒完成。Qsync Central 的版本控制設定（同步與備份各自的版本上限、保留天數）都完整保留。用戶端在服務重啟時偵測到斷線，約一分半鐘內自動重新連上，之後新增的檔案立即可以同步，不需要重新登入或重建配對。
升級時，備份任務資料庫會自動新增一張 TASK_VERSIONING 表，這是後面逐任務版本設定的基礎。另外，新版的啟動腳本不再強制把版本庫搬回套件所在的磁碟區。舊版會這麼做，等於使用者刻意把版本庫移到較大的資料磁碟區後，每次升級都會被搬回去。
備份任務與版本控制
發行說明的第一項是改善備份任務的穩定性與版本控制準確度，包含任務建立／移除、版本保留設定，以及大量檔案與版本刪除的處理。這部分 5.3.0.4 的改動最大，而且有一個行為上的改變。
5.3.0.3 的基準
在 5.3.0.3 上，備份任務的版本表現大致正確：
- 同一個檔案改寫 11 次，產生 11 個版本。
- 把全域版本上限從 32 改成 3，多出來的版本立即被修剪。
- 300 個檔各改寫 5 次，兩次測試都得到剛好 1,500 個版本。把上限從 5 降到 1，7 到 8 秒內修剪完成。
移除備份任務並選擇「一併刪除 NAS 上的資料」時，任務紀錄與中央版本庫內的版本都立即刪除，目的地資料夾先被改名為 <裝置>_deleting_<編號>，再整批移到該共用資料夾的資源回收筒，共 901 個檔。版本庫裡則留下一個同名的空目錄。
5.3.0.4 的改變：版本設定跟著任務走
升級後重建同一個備份任務，有兩個明顯差異。
第一，版本的存放位置變了
舊版所有備份版本都集中放在系統的版本庫目錄；5.3.0.4 新建的任務則把版本放在備份目的地底下的 .@qsync_versioning 隱藏目錄。好處是移除任務時，版本會跟著目的地資料一起處理。實測移除任務後，目的地的 3,000 個檔（其中 2,400 個是版本檔）一起被移到資源回收筒，中央版本庫沒有新增殘留。
第二，版本上限改成在任務建立時寫定
建立任務當下，全域備份版本上限剛好是 1，這個值就被寫進該任務的設定。之後在 Qsync Central 把全域上限改成 5，再對 300 個檔各寫 5 次，每個檔仍只保留 1 個完整版本（外加一個只有設定檔、沒有內容的版本目錄）。也就是說，在 5.3.0.4 調整 Qsync Central 的全域備份版本上限，不會套用到既有的任務。
這可能正是發行說明所謂的「版本保留設定」修正，讓每個任務的保留策略不會被全域設定意外改掉。但對習慣在管理端統一調整的管理者來說，這是需要重新認識的行為變動。本次測試在升級前已移除舊任務，因此沒有驗證升級前就存在的任務在新版的實際上限，有既有任務的環境，升級後建議管理員要再進行確認。
另外，從 5 版降到 1 版的修剪，在 5.3.0.4 約需 90 秒，是逐步清除的，舊版是 8 秒內完成。實際結果一樣正確，只是速度不同。
移除任務時也發現，任務本身的紀錄已刪除，但 TASK_VERSIONING 裡該任務的設定列還留著。程式中有清除孤兒設定的函式，可能會在之後的維護排程中自動處理。
File Station 與版本歷史
在 File Station 6 中，只有家目錄 Qsync 資料夾裡的檔案，右鍵選單才會出現以前的版」。同步配對資料夾與備份目的地沒有這個選項，兩版相同。
版本歷史的數量兩版都正確，差別在「裝置」欄位：
5.3.0.4 會辨識 File Station 網頁上傳使用的分塊上傳（chunked upload）暫存路徑，把來源標成「Qsync-File Station」。不過用 File Station 的另一種一般上傳 API，或直接在 NAS 上改檔，仍然顯示「Qsync Device」。這個新標示字串在 5.3.0.3 的程式中並不存在，但當時沒有在舊版做分塊上傳的對照，所以只能說這是新版新增的辨識邏輯。
最近開啟清單方面，兩版表現相同
開啟家目錄 Qsync 資料夾的檔案後，清單中的路徑顯示正常（/home/.Qsync），未觀察到差異。
Qfile 相關修正
發行說明中 Qfile、Qfile iOS 與 Android 的搜尋、搬移與重新命名、檔案大小顯示修正，用 File Station API 對家目錄 Qsync 資料夾做了搜尋、重新命名、搬移與大小查詢，兩版的回應完全相同，相關修正主要在 App 端。
Windows 用戶端批次同步效能
這是發行說明中最容易量化的一項。CyberQ 本次的測試方法，是在用戶端先產生好檔案，再一次搬進同步資料夾，從搬入那一刻起，計時到 NAS 端檔案數全部處理好的時間。
| 輪次 | 版本 | 檔案 | 耗時 | 每秒檔數 | 開跑前 NAS 負載 |
|---|---|---|---|---|---|
| A1 | 5.3.0.3 | 20,000 個 8 KB | 2,539 秒 | 7.9 | 2.2 |
| A2 | 5.3.0.3 | 5,000 個 8 KB | 612 秒 | 8.2 | 12.7 |
| B1 | 5.3.0.4 | 20,000 個 8 KB | 893 秒 | 22.4 | 1.7 |
| B2 | 5.3.0.4 | 5,000 個 8 KB | 692 秒 | 7.2 | 13.3 |
| B3 | 5.3.0.4 | 5,000 個 8 KB | 840 秒 | 6.0 | 2.9（中途撞上排程備份） |
| B4 | 5.3.0.4 | 20,000 個 8 KB | 2,523 秒 | 7.9 | 3.9（執行中 8 到 12） |
B1 比 A1 快了約 2.8 倍，前兩分鐘之後一直維持每秒約 27 個檔。B1 執行時 NAS 相對清閒，B4 則遇上其他工作負載，差異很可能來自環境，而不是版本。
大檔方面，500 個 4 MB 檔（共 2 GB）舊版 171 秒、新版 154 秒，差距約一成，同樣在雜訊範圍內。用戶端日誌會節流，數字只能參考，實務上體感確實有加快。
安全更新：拆開安裝包看到什麼
發行說明只寫套用了多項安全更新，截至 11 月 10 日，QNAP 資安通報頁也沒有對應 Qsync Central 的公告。CyberQ 把兩版安裝包解開比對，可以確認的改動如下：
- 上傳端點拒收網頁可執行檔：Qsync 的上傳程式改為拒收
.php、.phtml、.cgi、.pl、.asp、.aspx、.jsp、.shtml、.htaccess等副檔名，連name.php.jpg這種夾在中間的形式也擋。 - 修補上傳流程的符號連結競態：舊版先把檔案寫到最終位置再設定擁有者、權限與時間，中間若被換成符號連結，後續動作可能作用到別的檔案。新版改成在暫存檔上完成所有設定，再一次改名到位。
- 錯誤訊息不再外洩工作階段代碼：上傳驗證失敗時，舊版會把內部檢查網址（含 sid）回傳給用戶端，新版已移除。
- 密碼處理收緊：管理頁不再把已儲存的 SMTP 寄件密碼解碼後填回表單。中央控管模式的管理密碼改以 PBKDF2 雜湊儲存，舊的可逆格式會在下次驗證時自動轉換。
- 偵錯包只收摘要：一鍵匯出的偵錯包不再打包設定檔與日誌，深入診斷改為需經同意後以 SSH 進行。
- 其他還有關機時的快速停止流程，以及資料庫無法啟動時的自動修復機制。至於OpenSSL、curl 等第三方程式庫，則由韌體提供。
有開發者問，第一項會不會讓開發者的程式碼資料夾同步不上去？實測在同步資料夾放入 .php、.cgi、.pl、.phtml、.aspx 與 photo.php.jpg，5.3.0.4 都正常同步到 NAS，只是檔案權限與一般檔案不同，看得出走了另一條上傳路徑。唯一沒有出現在 NAS 上的是 .htaccess。
新版的副作用：/tmp 會越堆越多
測試過程中發現一個新版才有的問題。5.3.0.4 為了在版本歷史標示上傳來源，每處理一次上傳請求，就在 /tmp/qsyncsrv/device_hint 底下寫一個以行程編號（PID）命名的小檔，內容只有十幾個位元組。
但如果像是我們這樣一次傳了幾萬個檔案在做測試，問題就會出這些檔案沒有顯著的清理機制。/tmp 是只有 128 MB 的記憶體檔案系統，每個小檔至少占用 4 KB。最早的一個檔案時間，正好是升級完成的那一刻，經過 5 萬多次上傳，這個目錄累積了 19,901 個檔、約 78 MB，/tmp 使用率升到 73%，清掉這些檔案後回到 13%。
這台 NAS 的 PID 上限是 32,768，檔名只會在相同 PID 重複出現時被覆蓋，所以理論上限約 32,768 × 4 KB = 128 MB，剛好是整個 /tmp 的大小。Qsync Central 每天的兩個維護排程與啟動腳本都沒有處理這個目錄，只有重新開機會清空。
一般使用者每天同步的檔案數遠少於測試量，短期內不會遇到。但若是大量檔案同步、長時間不重開機的環境，/tmp 一旦被塞滿，影響的會是整台 NAS。暫時的處理方式是定期刪除該目錄下較舊的檔案（這些檔案只用於標示來源，舊檔已無作用），或在發現 /tmp 使用率異常時重新開機，重開機就會清除。這次在測試結束後刪除了 10 分鐘以前的檔案，/tmp 回到 13%。
結論與升級建議
Qsync Central 5.3.0.4 是一個以安全修補為主的版本。上傳流程與密碼處理的改動都很具體，修補的又是對外服務的上傳端點，值得升級。
升級本身很平順，設定保留、用戶端自動重連。升級後有三件事建議留意：
- 備份版本上限改為逐任務設定。在 Qsync Central 調整全域上限，不會改到既有任務。升級後請確認各備份任務實際保留的版本數是否符合預期。
- 觀察
/tmp使用率。大量同步的環境，可以定期查看/tmp/qsyncsrv/device_hint的檔案數，在 QNAP 修正之前先自行清理。
本文所有數字的原始紀錄（計時輪詢檔、版本清單、API 回應、套件差異）均已保存，若 QNAP 後續發布修正版本，CyberQ 會再補測 /tmp 的問題。
