許多中小企業依靠 NAS 儲存公司重要資料,例如財務文件、專案資料、共享檔案以及部門文件。然而,單一 NAS 即使搭配 RAID,也只能避免硬碟故障,無法避免主機損壞、主機板故障、勒索病毒或人為誤刪造成的服務中斷。本文將介紹如何利用兩台 QNAP TS-473A / TS-673A 建立低成本 QNAP 雙 NAS 備援架構,透過 HBS3(Hybrid Backup Sync)、Snapshot 快照與手動接手機制(Manual Failover),打造適合預算有限中小企業使用的 Disaster Recovery(DR)方案。
NAS(Network Attached Storage)是企業常見的網路儲存設備,可提供檔案共享、備份與權限管理功能。如果您還不了解 NAS 的基本功能與應用方式,可以參考: NAS 是什麼?新手入門教學+用途+優缺點完整解析(2026) 。
為什麼中小企業需要 Disaster Recovery(DR)架構
許多企業在建置 NAS 時,第一個想到的是 RAID。RAID 可以透過多顆硬碟提供資料容錯能力,例如 RAID 1 或 RAID 5 可以避免單顆硬碟損壞造成資料遺失。但是 RAID 保護的是「硬碟層級」,並不能保護整台 NAS 設備發生故障。
許多企業認為 NAS 已經有 RAID 保護,因此資料就安全,但 RAID 只能降低硬碟損壞造成的風險,無法避免設備故障、人為誤刪或勒索病毒攻擊。
關於企業 NAS 安全性與備份策略,可以參考: NAS安全嗎?企業NAS勒索病毒風險與備份架構完整解析(2026資安指南) 。
例如 NAS 主機板故障、電源供應器損壞、系統更新失敗、勒索病毒加密共享資料夾,甚至管理者誤刪大量檔案,都可能造成 NAS 無法正常提供服務。因此企業需要另一台獨立 NAS 作為備援設備,建立 Disaster Recovery(DR)架構。
對大型企業而言,可能會採用真正的 HA(High Availability)高可用架構,例如雙控制器儲存設備或叢集系統。但對多數中小企業來說,HA 建置成本高、維護複雜,因此更實際的方法是利用兩台相同型號 QNAP NAS,建立「平時同步、故障快速接手」的 DR 架構。
需要注意的是,本文介紹的架構並不是真正自動 HA,而是 Manual Failover(手動接手機制)。當 NAS_A 發生故障時,由管理者依照標準流程將 NAS_B 切換成主要服務設備。雖然需要人工操作,但對於人數固定、預算有限的中小企業而言,可以用較低成本達到接近企業備援的效果。
| 架構 | 說明 |
|---|---|
| RAID | 保護單台 NAS 內部硬碟故障,不提供主機故障保護。 |
| Backup | 主要目的是資料保存,需要還原流程。 |
| Disaster Recovery(DR) | 除了資料備份外,也考慮服務快速恢復。 |
| HA | 自動切換服務,成本與建置複雜度較高。 |
QNAP TS-473A / TS-673A 雙 NAS 備援架構設計
建立 QNAP 雙 NAS 備援架構時,建議使用相同型號以及相同容量硬碟配置。例如企業使用一台 QNAP TS-473A 作為主要 NAS,另一台相同規格 TS-473A 作為備援 NAS。這樣可以降低未來切換時遇到硬體相容性或效能差異問題。
不同企業在 NAS 選擇上,需要依照使用人數、資料量、硬碟槽數量以及未來擴充需求評估。如果尚未決定 NAS 型號,可以參考: NAS 推薦(2026)家用/公司完整選購指南+廠牌比較 。
架構設計的核心概念是:NAS_A 作為 Production NAS(正式服務主機),所有使用者日常存取都連線到 NAS_A;NAS_B 作為 Standby NAS(待命備援主機),平時透過 HBS3 接收 NAS_A 的資料同步。
QNAP DR 架構
使用者
|
|
v
NAS_A
名稱:QNAP-NAS-A
IP:192.168.10.10
角色:Production NAS
|
|
| HBS3 單向同步
|
v
NAS_B
名稱:QNAP-NAS-B
IP:192.168.10.11
角色:Standby NAS
這種設計最大的重點是 NAS_B 平常必須保持與 NAS_A 接近一致,包含 Shared Folder 名稱、資料內容、使用者帳號、群組設定以及 ACL 權限。只有做到這些條件,NAS_A 發生故障時,NAS_B 才能快速接手,而不是重新設定一台新的 NAS。
NAS_A 與 NAS_B 的角色規劃與管理原則
在 QNAP 雙 NAS 備援架構中,最重要的管理原則是建立「唯一管理來源(Source of Truth)」。也就是所有企業環境設定,都必須以 NAS_A 作為唯一來源,NAS_B 只負責接收同步與維持備援狀態。
許多中小企業在建置雙 NAS 時容易犯一個錯誤,就是兩台 NAS 都讓管理者自由建立使用者、資料夾與權限。短時間看似方便,但長期下來會造成兩台 NAS 設定逐漸不同,真正需要切換時才發現 NAS_B 缺少帳號、資料夾或權限。
因此建議採用以下管理方式:
NAS_A:
負責所有日常管理,包括新增員工帳號、建立共享資料夾、修改群組權限、調整 ACL 設定。
NAS_B:
維持 Standby 狀態,只接受 NAS_A 的資料同步,以及管理者手動匯入的帳號與設定。
| 項目 | NAS_A | NAS_B |
|---|---|---|
| 角色 | 正式使用 NAS(Production) | 備援 NAS(Standby) |
| 使用者建立 | 主要建立來源 | 透過匯入同步 |
| Shared Folder | 主要建立來源 | 手動建立相同名稱 |
| 資料同步 | 提供資料 | 接收資料 |
| 員工日常使用 | 正常使用 | 平時不提供服務 |
NAS_B 必須維持哪些內容一致?
要讓 NAS_B 在故障時快速接手,不能只同步檔案內容。完整的 DR 架構需要維持以下項目一致:
- 相同 Shared Folder:兩台 NAS 必須具有相同共享資料夾名稱,例如 Finance、Project、Public、Department。
- 相同資料:透過 HBS3 將 NAS_A 的資料同步至 NAS_B,確保備援 NAS 具有最新版本。
- 相同使用者:NAS_A 新增員工後,需要將使用者資料匯出,再匯入 NAS_B。
- 相同群組:例如 Finance、HR、Engineering 等群組必須保持一致。
- 相同 ACL 權限:共享資料夾權限必須依照同步設定或人工設定保持一致。
- 相同資料夾名稱:Windows 使用者通常透過 SMB 路徑存取,例如 \\QNAP-NAS-A\Project,因此資料夾名稱不能不同。
需要特別注意的是,QNAP HBS3 主要負責資料同步,並不會自動同步 NAS 系統內所有設定。例如新增使用者、新增群組、新增共享資料夾,通常需要管理者另外處理。因此企業必須建立固定 SOP,確保 NAS_A 發生任何設定變更時,NAS_B 都能同步更新。
Shared Folder、User、Group 與 ACL 同步管理
在雙 NAS DR 架構中,最容易被忽略的是「系統設定一致性」。很多企業只注意資料是否同步,卻忽略使用者帳號與權限。如果 NAS_A 損壞後,NAS_B 雖然有完整資料,但員工無法登入或無法存取資料,仍然無法真正接手。
因此建議企業建立變更管理制度,只要 NAS_A 有以下變更,就必須同步更新 NAS_B:
| NAS_A 變更項目 | NAS_B 是否需要處理 | 說明 |
|---|---|---|
| 新增使用者 | 需要 | 匯出 NAS_A 使用者,再匯入 NAS_B。 |
| 刪除使用者 | 需要 | 避免備援 NAS 保留無效帳號。 |
| 新增群組 | 需要 | 兩台 NAS 群組架構需一致。 |
| 新增 Shared Folder | 需要 | NAS_B 必須先建立同名資料夾。 |
| 修改 ACL 權限 | 需要確認 | 依同步方式確認權限是否同步。 |
案例一:新增員工帳號
假設公司新增一位工程師,需要存取「Project」共享資料夾。正確流程不是直接在兩台 NAS 建立帳號,而是只在 NAS_A 建立,確認權限正常後,再將帳號資訊同步至 NAS_B。
# 範例流程(GUI 操作,不使用命令列)
NAS_A
↓
Control Panel
↓
Users
↓
Create User
↓
加入 Engineering Group
↓
設定 Project Folder 權限
NAS_B
↓
匯入 NAS_A 使用者設定
↓
確認帳號存在
案例二:新增共享資料夾
假設公司新增「Marketing」部門資料夾,由於 HBS3 不會自動建立 NAS_B 的共享資料夾,因此必須先在 NAS_B 建立相同名稱的 Shared Folder,再修改同步工作。
NAS_A
建立 Shared Folder
名稱:
Marketing
設定:
- 使用者權限
- 群組權限
- ACL
NAS_B
建立相同 Shared Folder
名稱:
Marketing
修改 HBS3 同步工作
加入:
Marketing
案例三:修改部門權限
例如財務部門新增一位主管,需要增加 Finance 資料夾權限。此時應先修改 NAS_A ACL,再確認 NAS_B 權限同步狀態,避免故障切換後造成權限錯亂。
HBS3 同步與 Snapshot 快照策略
在 QNAP 雙 NAS 災難復原(Disaster Recovery)架構中,HBS3(Hybrid Backup Sync)負責 NAS_A 與 NAS_B 之間的資料同步,是整個備援架構的核心功能。不過需要先理解,HBS3 的角色是「資料同步工具」,並不是完整的系統設定同步工具。
因此企業在設計 DR 架構時,必須將工作拆成兩個部分:第一部分是透過 HBS3 維護檔案資料一致性;第二部分則是透過管理制度維護 User、Group、Shared Folder 與 ACL 權限一致性。
建議採用單向同步模式:
NAS_A(正式環境)
↓
HBS3 單向同步
↓
NAS_B(備援環境)
不建議讓 NAS_A 與 NAS_B 進行雙向同步,原因是雙向同步容易產生版本衝突。例如員工誤刪 NAS_A 檔案,雙向同步可能將刪除動作同步到 NAS_B,降低備援資料保護能力。
| 同步項目 | 建議設定 | 原因 |
|---|---|---|
| 方向 | NAS_A → NAS_B | 避免雙向修改造成衝突。 |
| 頻率 | 依公司需求設定 | 重要資料可提高同步頻率。 |
| 版本管理 | 搭配 Snapshot | 避免誤刪或勒索病毒同步。 |
| 同步範圍 | 依 Shared Folder 管理 | 避免不必要資料同步。 |
HBS3 建立同步工作的建議流程
建立 HBS3 任務時,建議先確認 NAS_A 與 NAS_B 的 Shared Folder 名稱一致,再建立同步工作。若 NAS_B 尚未建立相同名稱資料夾,後續接管時容易發生資料路徑不一致問題。
案例一:建立正式資料同步
NAS_A
HBS3
↓
建立同步工作
↓
來源:
Project
目的:
NAS_B / Project
↓
設定排程
↓
啟用同步
備註:
此流程由 NAS_A 提供資料,
NAS_B 作為備援保存。
案例二:新增部門資料夾後修改同步
新增:
NAS_A
Marketing
↓
NAS_B
建立 Marketing
↓
HBS3
編輯同步工作
↓
加入 Marketing
↓
重新執行同步
備註:
HBS3 不會自動建立新的 Shared Folder。
案例三:確認同步狀態
QNAP GUI:
HBS3
↓
同步工作
↓
檢查:
- 最後同步時間
- 成功狀態
- 錯誤記錄
備註:
定期確認同步狀態,
不要等 NAS_A 故障才發現同步失敗。
Snapshot 快照設計與勒索病毒防護
單純使用 HBS3 同步並不足以完整保護企業資料。例如員工誤刪大量檔案,或 NAS_A 被勒索病毒感染,若同步工作正常執行,錯誤資料也可能被同步到 NAS_B。
因此建議 NAS_A 與 NAS_B 都啟用 Snapshot 快照功能,利用時間點版本保存資料。
Snapshot 的目的不是取代備份,而是在資料發生錯誤時,可以快速回復到過去正常版本。
| 設備 | Snapshot 建議 | 用途 |
|---|---|---|
| NAS_A | 每 15 分鐘~1 小時 | 保護日常操作錯誤。 |
| NAS_B | 每天或依容量調整 | 提供第二層資料保護。 |
Snapshot 實務案例
例如員工星期一刪除 Project 資料夾內大量檔案,HBS3 可能會將刪除同步到 NAS_B。此時管理者可以透過 Snapshot 找回刪除前版本,而不是重新從備份慢慢還原。
案例:
時間:
星期一 10:00
員工誤刪:
Project\2026文件
處理:
NAS_A
↓
Snapshot Manager
↓
選擇:
星期一 09:45 快照
↓
還原資料
結果:
恢復誤刪前版本。
NAS_A 故障後快速接手機制(Manual Failover)
本文架構採用 Manual Failover(手動接手機制),並非真正自動 HA。當 NAS_A 發生硬體故障或系統問題時,需要由管理者依照 SOP 將 NAS_B 切換為主要服務設備。
在實際環境中,NAS 故障可能包含無法登入、IP 找不到、網路服務異常或管理密碼問題。在啟動災難復原流程前,可以先確認基本 NAS 故障排除方式:
NAS 無法連線與故障排除完整教學(2026)|Synology / QNAP 登入、IP、密碼修復
切換目標:
1. 確認 NAS_B 資料完整。
2. 停止同步避免資料衝突。
3. 讓 NAS_B 使用 NAS_A 原本的服務名稱或 IP。
4. 恢復 SMB / NFS 等檔案服務。
5. 使用者重新連線即可工作。
Failover 前置檢查
| 檢查項目 | 確認內容 |
|---|---|
| 同步狀態 | 確認 NAS_B 已收到最新資料。 |
| Snapshot | 確認最近快照正常。 |
| User | 確認帳號已匯入。 |
| Shared Folder | 確認資料夾名稱一致。 |
NAS_B GUI 接手流程
當確認 NAS_A 已無法提供服務,管理者可以開始進行 NAS_B 接手。整個流程建議完全透過 QNAP Web 管理介面操作,不建議使用 SSH 或修改系統內部設定檔,避免造成系統服務異常。
步驟一:停止同步工作
首先登入 NAS_B 管理介面,開啟 HBS3,將 NAS_A 到 NAS_B 的同步任務暫停。
目的:
避免 NAS_A 後續恢復時,舊資料與新資料互相覆蓋。
同時確保 NAS_B 目前資料狀態固定,作為正式服務來源。
步驟二:確認 NAS_B 資料與共享資料夾
登入 NAS_B 後,透過 File Station 檢查重要資料夾:
- 確認所有 Shared Folder 存在。
- 確認最新同步時間。
- 確認重要專案資料是否完整。
- 確認 Snapshot 是否可正常使用。
步驟三:修改 NAS_B 電腦名稱與網路設定,接手 NAS_A 服務身份
當 NAS_A 發生故障後,NAS_B 需要正式接替 NAS_A 成為主要檔案服務設備。由於中小企業通常沒有部署真正的 HA(High Availability)自動切換機制,因此採用 Manual Failover(手動接手)方式。
此步驟的重點不是將兩台 NAS 交換,而是讓備援 NAS_B 暫時繼承 NAS_A 原本的服務身份,包含:
- 相同的 NAS 主機名稱(Server Name)。
- 相同的 IP 位址。
- 相同的 Shared Folder 名稱。
- 相同的使用者與權限設定。
如此員工原本使用的網路磁碟路徑,例如:
\\QNAP-NAS-A\Project
或
\\192.168.10.10\Project
在切換完成後,不需要重新修改所有員工電腦設定,即可繼續存取公司資料。
原始正常運作架構
主要 NAS(Production)
NAS_A
主機名稱:
QNAP-NAS-A
IP 位址:
192.168.10.10
用途:
- 員工日常使用
- 建立使用者
- 建立共享資料夾
- 管理權限
- 提供 SMB 檔案服務
備援 NAS(Standby)
NAS_B
主機名稱:
QNAP-NAS-B
IP 位址:
192.168.10.11
用途:
- 接收 HBS3 同步資料
- 保存 Snapshot 快照
- 平時不提供主要服務
NAS_A 故障後接手架構
NAS_A
狀態:
故障
停止提供服務
--------------------------------
NAS_B
修改前:
主機名稱:
QNAP-NAS-B
IP:
192.168.10.11
修改後:
主機名稱:
QNAP-NAS-A
IP:
192.168.10.10
角色:
由 Standby NAS
變更為
Production NAS
操作流程(全部使用 QNAP GUI)
以下操作皆在 NAS_B 上執行,不需要修改 NAS_A。
1. 確認 NAS_A 已離線
- 確認 NAS_A 已關機或無法提供網路服務。
- 確認網路內沒有其他設備使用 192.168.10.10。
- 避免兩台設備同時使用相同 IP 或主機名稱,造成網路衝突。
2. 修改 NAS_B 主機名稱
- 登入 NAS_B QTS 管理介面。
- 開啟「控制台」。
- 進入「系統」→「一般設定」。
- 找到「伺服器名稱(Server Name)」。
- 將:
原本:
QNAP-NAS-B
修改為:
QNAP-NAS-A
修改完成後,NAS_B 的網路識別名稱就會與原本 NAS_A 相同。
3. 修改 NAS_B IP 位址
- 開啟「控制台」。
- 進入「網路與虛擬交換器」。
- 選擇 NAS_B 使用的 LAN 網路介面。
- 修改 IPv4 設定。
- 將 IP 修改為 NAS_A 原本使用的位址。
修改前:
NAS_B
IP:
192.168.10.11
修改後:
NAS_B
IP:
192.168.10.10
4. 確認網路服務重新啟動
修改 IP 與主機名稱後,QNAP 可能需要重新啟動網路服務或重新開機,讓新的設定正式生效。
確認項目:
✓ NAS_B 可以正常登入
✓ IP 已變更為 192.168.10.10
✓ 主機名稱變更為 QNAP-NAS-A
✓ SMB 檔案服務正常
✓ Shared Folder 可以正常存取
切換完成後員工使用方式
若公司員工原本使用 NAS 名稱連線:
原本:
\\QNAP-NAS-A\Project
切換後:
\\QNAP-NAS-A\Project
因為 NAS_B 已經接手 NAS_A 的名稱與 IP,所以員工通常不需要重新設定網路磁碟。
若員工使用 IP 連線:
原本:
\\192.168.10.10\Project
切換後:
\\192.168.10.10\Project
同樣不需要修改設定。
注意事項
- NAS_A 與 NAS_B 不可同時存在相同 IP。
- NAS_A 故障未確認前,不可讓 NAS_B 使用 NAS_A 的 IP。
- 切換前應確認 HBS3 最後同步時間。
- 切換後 NAS_B 成為新的主要 NAS,後續所有新增使用者與資料夾變更,都必須以新的 Production NAS 為管理來源。
步驟四:確認檔案服務
完成 IP 接手後,需要確認使用者常用服務是否正常。
| 服務 | 確認項目 |
|---|---|
| SMB | Windows 網路磁碟是否可以正常連線。 |
| NFS | Linux 或 VMware 掛載是否正常。 |
| Shared Folder | 資料夾名稱與權限是否正確。 |
步驟五:使用者測試
建議不要直接通知所有員工使用,而是先使用測試帳號確認:
- 可以登入 NAS。
- 可以看到原本共享資料夾。
- 新增檔案權限正常。
- 刪除與修改權限符合預期。
NAS_A 修復後如何重新切回正式環境
許多企業只考慮 NAS 壞掉如何切換,卻忽略設備修復後如何恢復。錯誤的切換方式可能造成資料覆蓋,因此 NAS_A 修復後不能立即重新啟用同步。
建議採用以下流程:
NAS_A 修復
↓
確認硬體正常
↓
更新 QNAP 系統
↓
建立 Storage Pool
↓
建立 Shared Folder
↓
匯入 User / Group
↓
確認 ACL 權限
↓
建立 HBS3 同步
↓
NAS_B → NAS_A
反向同步
↓
確認資料一致
↓
切回 NAS_A
回切注意事項
在 NAS_A 回復前,必須先確認目前 NAS_B 是否已經成為最新資料來源。如果直接讓 NAS_A 與 NAS_B 同時修改資料,可能造成版本衝突。
因此建議:
- 回切前先停止使用者大量寫入。
- 確認最後同步時間。
- 先完成資料同步。
- 測試權限。
- 最後才恢復正式使用。
雙 NAS DR 架構日常維護 Checklist
災難復原架構最重要的是平時維護。如果沒有定期檢查,即使建立雙 NAS,也可能在真正故障時無法使用。
| 檢查項目 | 建議頻率 |
|---|---|
| 確認 HBS3 同步成功 | 每日 |
| 確認 Snapshot 狀態 | 每週 |
| 比對 User / Group | 每月 |
| 確認 Shared Folder | 每月 |
| DR 接手演練 | 每半年 |
中小企業雙 NAS DR 架構總結
利用兩台 QNAP TS-473A 或 TS-673A 建立 Disaster Recovery(DR)架構,是中小企業在有限預算下提升資料安全性的實用方案。雖然此架構不是自動 HA,但透過 HBS3、Snapshot、標準化管理流程以及 Manual Failover,可以在 NAS_A 發生故障時快速恢復服務。
成功的雙 NAS 備援架構並不只是同步資料,而是維持完整的一致性,包括 Shared Folder、User、Group、ACL 與管理流程。只要建立正確 SOP,即使沒有昂貴企業級 HA 設備,中小企業也能建立可靠的災難復原環境。
FAQ 常見問題
QNAP 雙 NAS 備援架構可以取代真正 HA 嗎?
不可以。QNAP 雙 NAS 備援架構主要屬於 Disaster Recovery(DR),透過 HBS3 同步資料,故障時由管理者手動切換。真正 HA 需要自動偵測與自動切換機制,通常成本更高。中小企業若預算有限,此架構可以提供較低成本的快速接手能力。
QNAP HBS3 會自動同步使用者與共享資料夾嗎?
不會。HBS3 主要負責資料同步,不會自動建立 NAS 使用者、群組或新的 Shared Folder。因此企業必須建立管理 SOP,當 NAS_A 新增使用者或共享資料夾時,需要手動在 NAS_B 建立或匯入相關設定。
為什麼 NAS_B 必須保持相同 Shared Folder?
因為 Windows 使用者通常透過 SMB 路徑存取 NAS,例如共享資料夾名稱不同會造成連線失敗。此外故障接手時,NAS_B 必須提供相同資料結構,才能讓員工快速恢復工作。
QNAP Snapshot 可以取代備份嗎?
不可以。Snapshot 主要用於快速回復資料版本,例如誤刪檔案或勒索病毒事件。完整備份仍需要另一份獨立保存。最佳策略是同步、Snapshot 與備份三層防護。
中小企業是否適合建立 QNAP 雙 NAS DR 架構?
適合。若公司無法負擔企業級 HA 設備,但又需要避免 NAS 故障造成長時間停工,雙 NAS DR 架構是一種成本與可靠性平衡方案。
NAS_A 故障時 NAS_B 接手需要多久?
時間取決於資料量與管理流程。若平時已維持 User、Group、Shared Folder 與同步狀態一致,通常只需要完成檢查、IP 切換與服務確認即可快速恢復。
