Storware Backup and Recovery 8.0：OpenStack、Nutanix 與 Kubernetes 的重大更新

Proxmox 備份策略：後 VMware 時代的生存指南

Proxmox 在企業中的崛起

Proxmox VE 過去只侷限於 Reddit 上的家庭實驗室 (homelab) 討論，如今在 2026 年已成為逃離 VMware 的中階市場企業的首選。其吸引力顯而易見：它提供熟悉且類似 vSphere 的操作體驗、強大的高可用性 (HA)、無縫的即時遷移，以及最關鍵的一點——沒有基於核心數的授權費用。在 Broadcom 近期徹底改變授權模式而疏遠許多組織的情況下，這樣的成本優勢是無庸置疑的。

然而，儘管 Proxmox 在處理基礎虛擬化元素方面表現出色，但當您審視周邊的企業級工具時，就會發現其中的落差。最關鍵的缺口就在於備份架構。

評估 Proxmox 備份伺服器 (PBS)

PBS 是 Proxmox VE 原生的開源配套產品。對於較小規模的部署或開發環境來說，它是一個可靠且功能強大的工具。

PBS 的優勢所在：

• 儲存效率：它採用了優異的重複資料刪除 (deduplication) 模型，相同的資料區塊只會儲存一次。
• 核心功能：它提供可靠的永久增量 (incremental-forever) 備份、內建排程與保留原則。
• 即時還原：您可以立即啟動虛擬機 (VM)，同時其磁碟在背景進行還原——這在勒索軟體復原過程中簡直是救命稻草。
• 成本：它是開源的 (AGPLv3) 且免費使用，並提供選購的付費支援層級。

PBS 的 6 大企業級缺口

PBS 是為社群而建立的，而非針對需要處理嚴格合規要求、複雜多租用戶環境或異質基礎架構的企業。

1. 缺乏真正的氣隙防護 (Air-Gap)：雖然 PBS 可以寫入遠端儲存，但它缺乏能與受損生產網路完全隔離的真正邏輯或實體氣隙（如 NIS2 和 DORA 等法規越來越強制要求這一點）。
2. 基於設定的不可變性：WORM (一寫多讀) 合規性依賴於底層儲存層 (如 ZFS 快照)，而不是由備份軟體本身在架構上強制執行。如果儲存層遭到破壞，不可變性就會被打破。
3. 薄弱的多租用戶架構：PBS 缺乏大型組織所需之精細度、MSP 等級的租用戶隔離。要在不暴露整個系統的情況下，將特定的保留與還原權限委派給個別業務單位，實際上是不可能的。
4. 僅限 Proxmox 的涵蓋範圍：PBS 無法保護 VMware、Nutanix、Hyper-V 或其他任何平台。如果您運行的是混合環境，您將被迫管理多個備份工具，從而使您的維運負擔成倍增加。
5. 基本的應用程式一致性：它依賴於通用的 qemu-guest-agent。對於複雜的交易型資料庫 (如 MS SQL 或 Oracle)，與專門打造的應用程式代理程式相比，這種方法顯得力有未逮。
6. 有限的稽核與報表：PBS 僅提供基本的日誌。複雜的 SLA 追蹤、多叢集儀表板與合規稽核匯出，都需要手動建立自訂的報表層。

企業級替代方案：Storware Backup and Recovery

對於需要受規範、具可擴展性保護的組織而言，選擇並不多。Storware Backup and Recovery 正是這少數的選擇之一，它專門解決了 PBS 所遺留的缺口。

維運邏輯很簡單：如果您正從 VMware 轉移，或維護著混合虛擬機管理程式 (mixed-hypervisor) 環境，在所有系統中管理單一、通用的備份平台，絕對優於在多個各自為政的工具之間手忙腳亂。

Storware 如何與 Proxmox 整合

• 無代理程式連線：Storware 使用安全權杖透過 Proxmox API 進行連線。標準備份不需要在 VM 內部安裝任何代理程式。
• 集中式原則管理：根據 VM 標籤、叢集或個別機器來定義排程、保留、加密與重複資料刪除。
• 靈活的儲存目標：將備份發送至本機儲存、任何與 S3 相容的物件儲存、磁帶或 Storware Cloud。
• 進階災難復原 (DR)：利用預先配置的復原計畫進行有序的容錯移轉，並使用「即時還原」直接從備份目標開機 VM，同時在背景進行資料遷移。

常見問題解答 (FAQ)

下一步

想要強化您的 Proxmox 環境嗎？Storware 解決方案架構師提供針對您特定基礎架構、合規需求與當前防護缺口量身打造的範圍內 Proxmox 備份評估。

預約 Proxmox 備份評估

如需關於脫離 VMware 的全面指南，請閱讀我們的核心文章：VMware 遷移：2026 年異質環境教戰手冊 (VMware Migration: The 2026 Playbook for Heterogeneous Environments)。

博通的 VMware：2026 年技術長決策框架

在過去十八個月裡，我與基礎架構架構師們的對話，開場白如出一轍：「我們需要談談我們的 VMware 續約問題。」接下來的話則各有不同。有時是一個數字——4 倍、6 倍，在我印象最深刻的一個案例中是 11 倍。有時是一個期限。越來越多的情況是，兩者皆有。

這些對話的重點已不再是是否要離開 VMware，而是探討該去哪裡、速度該有多快，以及如果專案拖延超過續約日期會有什麼後果。戰略層面的問題早在 2024 年就由博通 (Broadcom) 拍板定案了。現在剩下的，就是執行。

這篇文章是寫給負責執行的專業人士。這不是廠商推銷——雖然 Storware 剛好也涉足這個領域，但無論你最終選擇哪種備份或遷移工具，以下的框架都適用。我試著寫出當我們的客戶開始問我們這些問題時，我希望當時就存在的那份文件。

用白話文說，到底改變了什麼

多數關於博通變革的報導都會用「地震級」、「顛覆性」、「史無前例」等形容詞。但現實情況更為枯燥，也更具永久性。具體發生了四件事：

1. 永久授權已於 2024 年初終止。所有客戶都轉為訂閱制，期限為一年、三年或五年。
2. 產品目錄大幅縮減，從 160 多個 SKU 縮減為四個主要組合包——VCF、VVF、vSphere Standard、vSphere Enterprise Plus。獨立的 vSAN、NSX 和 Aria 不再作為單一產品銷售。
3. 從 2025 年 4 月 10 日起，最低授權購買量從每個產品線 16 核心提高到 72 核心。對於執行小型或邊緣伺服器的企業來說，你現在購買的是物理上不存在的容量。
4. 延遲續約將面臨 20% 的罰款。如果你錯過了週年紀念日，第一年的訂閱價格將會追溯加上這筆漲幅。

整體的價格影響因人而異。公佈的數字從 150% 到超過 1,000% 不等，受打擊最嚴重的是中端市場的企業，他們以前執行 vSphere Essentials Plus——該產品已停產，取而代之的是包含了他們從未要求的功能的組合包。據報導，AT&T 的續約提案漲幅為 1,050%，這是個吸睛的數字，但這並非中位數。

根據我的經驗，中位數大約是 3 到 6 倍。這足以為一個嚴肅的遷移專案提供資金，但不足以讓你採取五年的觀望態度。

戰略層面的問題早在 2024 年就由博通 (Broadcom) 拍板定案了。現在剩下的，就是執行。

我最常看到技術長犯的錯誤

在這些對話中，最常見的錯誤不是選錯了目標平台，而是先選了目標平台。

供應商很喜歡這種框架，因為這讓他們能以自己的產品為主導。「遷移到 Nutanix。」「遷移到 OpenStack。」「遷移到 Proxmox。」對正確的工作負載來說，這些都是合理的歸宿——但「正確的工作負載」這個部分往往被跳過了。

在討論目標平台變得有意義之前，必須先回答四個問題。這些問題沒有一個是關於目標平台的。

問題 1：工作負載分佈為何？

一個通用的 Linux 網頁層、一個具有多路徑 FC 儲存的狀態 Oracle 資料庫、一個 2014 年遺留下來且沒人想碰的 Windows 單體應用，以及一個具有 GPU 直通的 HPC 叢集，它們都需要不同的目標平台。如果一個遷移計畫把這些都當作可以互換的虛擬機器來處理，那麼簡單的部分會成功，困難的部分會失敗——而且通常是在生產環境中，以非常引人注目的方式失敗。

這裡的原則是，在任何供應商展示之前，將每個虛擬機器歸類到三個類別之一：

• 原封不動遷移 (Lift-and-shift) 的候選者：大多數通用的 Linux 和 Windows 工作負載。遷移是機械化的——磁碟格式轉換、驅動程式注入、網路重新對應。這些構成了資產的大部分。
• 重構 (Refactor) 的候選者：那些已經接近生命週期結束或適合容器化的應用程式，遷移是改變架構的好時機。這個類別比人們最初想像的要小。
• 特殊處理案例：硬體直通、vGPU、NSX 特定的網路、僅限 vSAN 的儲存功能、對延遲敏感的交易型工作負載。這些需要個別處理。有時它們根本不會被遷移——它們會等待硬體更新或重新架構。

在我看過的大多數環境中，比例大約是 70/15/15。這 70% 決定了你的平台決策。另外的 30% 決定了你的特殊處理預算。

問題 2：你的維運團隊已經具備哪些技能？

在紙面上最便宜的目標平台，在考慮了重新培訓、招募以及陡峭學習曲線帶來的生產力成本後，很少會是真正最便宜的。這是供應商的推銷中不會包含的成本，因為供應商不用付這筆錢。根據我自己的觀察，一個粗略的經驗法則是：

如果你的團隊規模很小，而你的 VMware 環境規模卻很大，那麼授權成本最低的平台，幾乎肯定不是三年內總擁有成本 (TCO) 最低的平台。

問題 3：法律上允許你的資料存放在哪裡？

這是總部位於美國的供應商最常跳過的問題，因為對他們來說，這個問題通常沒有一個乾淨俐落的答案。

對於歐洲組織而言，有三條線索很重要。GDPR 是底線——個人資料必須在歐盟管轄區或同等制度下進行處理。NIS2 於 2024 年 10 月起在歐盟成員國生效，提高了事件通報和供應鏈安全的標準，且適用的組織範圍比其前身更廣。DORA 將於 2025 年 1 月生效，對金融服務實體施加具體的維運彈性要求，並賦予主管機關對關鍵 ICT 第三方供應商（包括資料保護供應商）的直接監督權。

覆蓋在這三者之上的是《雲端法案》(CLOUD Act)，該法案為美國當局提供了法律依據，可以迫使總部位於美國的供應商提供保存在世界任何地方的資料。這與 GDPR 第 48 條產生了明文衝突，歐盟監管機構對此也越來越明確。

具體來說：如果你退出 VMware 的時機，也是你更廣泛地重新評估對美國供應商依賴的時機，那麼與新平台並行運作的資料保護供應商也是該決策的一部分。如果主權對你的組織不重要，請忽略本節。如果重要，這不是一個軟性因素——它是一個限制條件。

如果你的團隊規模很小，而你的 VMware 環境規模卻很大，那麼授權成本最低的平台，幾乎肯定不是三年內總擁有成本 (TCO) 最低的平台。

問題 4：你的續約日期何時到來？

20% 的延遲續約罰款改變了專案計畫的計算方式。你的遷移時間表不是由你的專案計畫決定的。它是由你的續約週年紀念日決定的。

有三種情況。你要麼續約（伴隨價格上漲）。你要麼在續約前遷移（這意味著專案有一個硬性期限）。或者你續約，並在下一個訂閱窗口期間遷移（這是大多數大型企業最終選擇的路徑，因為考慮到庫存的複雜性，替代方案是不切實際的）。

無論你採取哪種立場，請深思熟慮地做出決定。最糟糕的結果是意外錯過續約日期，並且還要為你原本不想要的訂閱支付額外的罰款。

三種遷移方法，以及它們分別適合哪種環境

一旦回答了上述四個問題，技術對話就變得容易處理了。VMware 到任何平台的遷移主要由三種架構模式主導。這些取捨是真實存在的。

• 冷遷移 (Cold migration)：最簡單也最通用：關閉虛擬機器的電源，匯出磁碟映像，如果需要則轉換格式，再匯入到目標平台。像 virt-v2v 和 qemu-img 這樣的工具可以處理這些工作。每個工作負載的停機時間以小時計算，而不是分鐘。適用於長尾的低重要性工作負載，不適用於任何面向客戶的服務。
• 暖遷移 (Warm migration)：使用 VMware 的異動區塊追蹤 (Changed Block Tracking) 在來源端運作時進行大部分的資料傳輸，然後進行短暫的切換以傳輸增量資料。大多數獨立的商業遷移工具都屬於此類——Coriolis、Hystax，以及特定供應商的工具包。缺點是，在遷移窗口期間，你需要購買和維運一個獨立的產品，然後在遷移結束後將其停用，或者將其作為另一個堆疊元件進行維護。
• 備份即遷移 (Backup-as-migration)：這是我自己公司採用的架構方法，在描述它之前，我會公開聲明這一點。已經在備份 VMware 環境的同一個資料保護引擎，可以將這些備份還原到不同的 Hypervisor 類型上。備份就是遷移來源。目錄保持不變。你用於備份的產品，同時也是你用於遷移的產品——沒有第二個 SKU。

這第三種方法有三個在討論中常被低估的結構性優勢。首先，在遷移之前、期間和之後，你的保護覆蓋是不中斷的——專案期間沒有空窗期。其次，架構本身就包含了回復路徑：如果遷移後的工作負載在目標平台上運作不正常，原始備份仍在目錄中，可以透過相同的機制還原回 VMware。第三，遷移後的維運模式與你之前擁有的模式相同——相同的 WebUI、相同的策略、相同的 RBAC (角色基礎存取控制)、相同的團隊。你保護的平台改變了；保護層則沒有。

但這裡有一個（也是真實的）前提條件——備份即遷移只有在你的資料保護供應商確實將來源和目標都視為具有功能對等的一等平台時才有效。大多數供應商並非如此。這是一個供應商選擇的問題，而不是一個架構問題。

值得明確指出的兩個錯誤

我最常看到的兩種失敗模式：

如果我坐在那個位子上，我會怎麼做

把上述四個問題當作第一週的工作成果。將資產清單歸入三個類別。誠實評估維運成熟度。記錄主權限制。將續約日期貼在牆上。

然後，針對原封不動遷移 (lift-and-shift) 類別中最具代表性的工作負載執行範圍限定的概念驗證 (PoC)——不要選最簡單的，也不要選最難的，選最能代表整體情況的。測量它實際花費的時間、需要哪些人工介入、什麼東西損壞了。將這個數字乘以考慮了合理批次假設的總環境規模，這就是你的專案工期。它幾乎總是比供應商最初的估計還要長。

將你的保護策略和遷移策略視為一個決策來處理，而不是兩個。如果它們必須是不同的工具，請接受這一點並為此編列預算。如果它們可以是同一個工具，那這就是一個值得追求的結構性簡化。

然後開始行動。這些專案最困難的部分不是技術問題。而是克服一個已經順利運作了十五年的環境所帶來的慣性。

如果您想針對自己的環境討論上述任何內容，可以透過 storware.eu/book-meeting/ 聯繫 Storware 技術團隊。

「五年前，稽核員想看的是您理論上的安全控制措施；今天，他們想看的是您上一次成功復原測試中，可被驗證的時間戳記與測得的吞吐量。」

— Paweł Mączka，Storware 首席技術長（CTO）

---

法規範式重塑：將「系統性入侵」視為必然

現代合規性框架——特別是金融服務業的《數位營運韌性法案》（DORA）以及跨關鍵基礎設施產業的《NIS2 指令》——皆已放棄了「預防性防禦邊界即足夠」的假設。這些授權明文假定關鍵入侵終將發生，並將稽核焦點轉移至組織在危機期間「維持營運的實證能力」。

這一法規轉變改變了成功風險管理的衡量標準：

• 實證復原優於防禦性宣告： 組織必須主動展示持續、具備文件記錄的還原週期，而非僅指向靜態的防火牆配置。
• 遭遇侵害時的營運連續性： 資安維運中心花費數小時隔離威脅，這在程序上執行得完全正確；然而，若核心系統在這數小時內遭到加密且復原需要數週，該實體在合規基準上依然宣告失敗。
• 具防禦力的資料韌性： 備份架構已演變成企業能否承受持續性營運壓力的決定性證明。

視為基礎設施架構師的網路保險

在經歷連續數期的歷史性理賠支出後，網路保險的核保市場已不再將資料保護視為一個簡單的勾選框。保險公司正主動干預基礎設施架構，要求在簽發保單前必須做出技術承諾。現代核保指南通常要求：

1. 邏輯與網路實體隔離（Air-Gapping）： 次級資料儲存庫在常態營運下必須完全隔離，且在生產環境的路由表中不可觸及。
2. 不可變的保留鎖定（Immutable Retention Locks）： 在檔案系統層或物件儲存層強制執行儲存結構鎖定，阻止資料被竄改或刪除，防止管理員權限（Token）惡意縮短保留窗口。
3. 獨立的驗證邊界： 在備份管理主控台上直接部署多因素驗證（MFA），與企業身分識別供應商（IdP）完全解耦，以抵禦集中式身分系統淪陷的風險。
4. 復原前的惡意軟體分析： 在將歷史資料掛載回生產環境之前，以程式化方式掃描其是否存在入侵指標（IoC），防止在復原過程中造成二次自我感染。

虛擬化技術獨立性：航向後 VMware 時代

Broadcom 對 VMware 的收購徹底改變了企業基礎設施的地景。各組織正積極將其部分虛擬資產遷移至其他平台，以規避授權的不穩定性。較小規模的架構正轉向 Proxmox VE 或 XCP-ng，而大型企業環境與託管服務供應商（MSP）則開始大規模部署 OpenStack 架構。

這種遷移層給傳統備份工具帶來了嚴峻的整合挑戰，因為這些工具過往大多專為 VMware 環境而建。真正的資料安全需要一個能夠跨越個多個異質虛擬化架構、同時交付原生且無代理程式（Agentless）防護的平台，在複雜的基礎設施轉型期間，維護來源端與目的端架構的持續性資料保護。

虛擬化架構	架構特徵概況	資料保護需求
VMware vSphere	傳統企業基準；高度標準化與結構化。	維護歷史備份基準，同時支援安全的資料匯出路徑。
OpenStack	高度靈活、不綁定廠商的雲端框架；儲存與網路路徑多變。	需要動態資源發現能力，以清晰對應客製化的 Cinder、Neutron 與 Ceph 配置。
Proxmox VE / XCP-ng	針對分散式現代基礎設施的新興開源虛擬化替代方案。	需要原生、無代理程式的防護串流，避免耗費資源的客體作業系統（Guest OS）代理程式。

 

加固的 Linux：消滅架構上的立足點

由於大約 95% 鎖定企業的漏洞利用都聚焦於 Windows 環境，將資料保護引擎託管在基於 Windows 的伺服器上會使組織面臨不必要的系統性風險。將備份軟體直接建立在專屬、加固的 Linux 發行版之上，可直接消除整層常見的漏洞利用向量。

真正的維運加固要求剝離底層作業系統的所有通用功能靈活性。在加固的備份設備中，不必要的服務與未對映的核心級連接埠會被完全停用，且執行環境嚴禁安裝第三方軟體。透過將儲存的不可變性嵌套在 XFS 檔案系統層中，並將存取權限制在與硬體綁定的微碼驗證之後，儲存庫得以完全免疫外部配置的惡意操縱。

 

歐洲管轄權範式與資料主權

對於管理受規管國際資料集的現代組織而言，技術基礎設施的加固僅完成了合規要求的一半。資安主管還必須考慮控管其資料資產的管轄權邊界。在諸如美國《CLOUD 法案》等立法授權下，美國當局有權強迫總部位於其管轄權內的供應商提供其所持有的資料，無論其伺服器的實體地理位置是否位於歐盟境內。

為了滿足 NIS2 與 DORA 下嚴格的法規主權要求，企業需要對其雲端儲存路由擁有明確的控制權。這意味著必須具備選擇不綁定廠商、且與外部管轄權毫無資本或營運關聯之歐洲本土雲端供應商的能力。透過將這種嚴格的地理限制與自動化刪除碼（Erasure Coding）相結合，資料狀態將被系統性地拆分並分散至獨立的資料中心，確保任何單一節點的淪陷都不會向對手洩漏可還原的情報。

 

常見問答

什麼是「具備網路韌性」的備份平台？

傳統備份僅驗證磁碟上是否存在復原點。而具備網路韌性的平台則確保該復原點能夠在對手已掌握網路管理控制權的情況下存活。這種韌性是透過不可變檔案系統、自動化網路隔離、獨立的驗證邊界以及復原前的惡意軟體掃描來實現的。

DORA 與 NIS2 法規如何影響資料備份？

這兩個框架都將合規重點從純粹的預防性措施轉移到可實證的復原能力。稽核員要求提供記錄完善、帶有時間戳記的還原測試、能夠在全網淪陷中存活的隔離資料狀態，以及一個完全獨立於主要企業身分基礎設施運作的備份管理架構。

為什麼 OpenStack 給傳統備份工具帶來了挑戰？

與擁有高度僵化參考架構的標準虛擬化技術不同，OpenStack 允許系統管理員以幾乎無限種客製化組合來搭配 Cinder 驅動程式、Neutron 網路拓撲與 Ceph 備份儲存。傳統備份工具因假設了固定的基礎設施佈局而宣告失敗。韌性平台必須具備動態發現並對映這些客製化 OpenStack 環境的能力。

美國《CLOUD 法案》會影響實體儲存在歐盟資料中心內的資料嗎？

會。 《CLOUD 法案》允許外國當局強迫總部位於其管轄權內的供應商交付資料，不論實體伺服器位於何處。對資料駐留有嚴格法規要求的組織，需要一個端到端的主權技術堆疊，其軟體開發、技術支援和雲端基礎設施必須完全在外部法律邊界之外運作。

在真實壓力下評估您的維運韌性

如果您組織上一次成功的復原測試，早於最近一次董事會關於勒索軟體的討論，這項風險破口便不容忽視。歡迎與 Storware 團隊攜手，對照 DORA、NIS2 及現代核保基準的嚴格要求，深度分析您現行的基礎設施。

• 多重虛擬化技術靈活性： 透過單一介面，流暢地保護橫跨 VMware、OpenStack、Proxmox 及容器化架構中的資料。
• 可強制執行的網路隔離： 部署自動化 Isolator 模組，在備份任務完成後自動對次級資料複本執行實體隔離。
• 絕對的管轄權控制： 透過完全建基於歐洲境內的技術堆疊，維護端到端的資料主權。

面對現實世界的威脅，切勿依賴理論上的安全控制措施。歡迎立即聯絡我們的資料保護工程師，安排即時架構審查。