磁碟區陰影複製服務(VSS)的機制與實務 ── 為什麼能備份使用中的檔案

「想複製其他應用程式開啟中的檔案，結果被『處理程序無法存取檔案』擋了下來」「被要求在不停止核心系統的情況下，備份存放資料的資料夾」「備份軟體為什麼可以若無其事地複製使用中的資料庫檔案」── 不論是開發業務應用程式，還是維運檔案伺服器，遲早都會撞上這些問題。

答案的核心是磁碟區陰影複製服務(VSS: Volume Shadow Copy Service)。這是 Windows 20 多年前就已內建的機制，無論是 Windows Server Backup、系統還原，還是市面上幾乎所有的備份軟體，都建立在這個基礎之上。¹

本文要把「即使檔案使用中也能複製的機制」與「這份複製本究竟能守住多少」分開來談。讀者對象是被要求提供「使用中檔案複製功能」的業務應用程式開發者，以及負責維運檔案伺服器、業務用 PC 備份的資訊系統人員。

文章先給出結論與依目的閱讀的方式，接著依序說明 VSS 的登場角色、保存的機制、維運時的確認、開發者的判斷，以及陷阱。技術說明依據的是 2026 年 8 月時點的第一手資料。

在「Windows I/O 的深層」系列中，我們看過快取管理員與 NTFS 的內部結構。本文作為該系列的續篇，要處理的是緊貼在磁碟區之上、插進其間的「快照」這一層。

1. 先講結論

VSS 是一套機制：它與寫入器協調，讓應用程式的寫入只靜止很短的時間，再從那個時間點的複製本取得備份。光是建立了陰影複製，並不代表就不需要另一種媒體上的備份。

它是做什麼的機制

VSS 是一組 COM 介面加上協調服務，用來讓「應用程式持續寫入中的磁碟區」也能進行備份。自 Windows XP 起就已內建。²

登場角色是 3 個角色，再加上一個協調角色。要求建立陰影複製的要求者(備份軟體)、在應用程式端保證資料一致性的寫入器(SQL Server 等)，以及實際建立快照的提供者，由 VSS 服務居中協調。¹

靜止點是以「凍結寫入器(最長 60 秒)→建立快照(10 秒以內)→解凍」的流程建立的。一旦超過時間限制，建立就會中止，由要求者重來一次。¹

把保存方式與一致性的保證分開看

Windows 標準的系統提供者採用寫入時複製方式。它不複製整個磁碟區，只把快照之後會被覆寫的區塊，在覆寫前先保存到差異區(diff area)。差異區必須位於 NTFS 磁碟區上。¹

有沒有寫入器的協助，會左右複製本的品質。沒有協助所建立的快照，等同於「斷電那一瞬間的磁碟」(當機一致)；有協助時，則會先完成記錄檔輪替與快取清空，達到應用程式自身保證可以復原的一致狀態(應用程式一致)。³¹

維運與開發要確認的東西不同

維運上的確認工具是 vssadmin。用 list shadows / list writers / list shadowstorage 確認現況，用 resize shadowstorage 調整差異區的上限。差異區一旦耗盡，就會從最舊的陰影複製開始被安靜地刪除。⁴⁵¹

把 VSS 要求者整合進自行開發的應用程式，是一件大工程。它是 COM 基礎的原生 API，官方沒有提供 .NET 用的封裝。多數情況下，靠重試、調整共用模式、短暫停止就已足夠；若真的需要 VSS，把 DiskShadow 寫成指令碼才是現實可行的解法(僅限 Windows Server)。⁶⁷

陰影複製本身並不是備份。寫入時複製的差異資料依賴的是原始磁碟區上未受損的區塊，因此對於磁碟故障或遭竊這類連原始磁碟區一起失去的故障，完全無能為力。對勒索軟體也一樣，陰影複製本身可能遭到刪除(7.3)，或因大量覆寫導致差異區耗盡(7.4)，因此不能指望它。唯有搭配另一種媒體上的備份，才開始具有意義。¹

依目的與症狀選擇讀法

想理解機制的讀者可以從第 2 章依序讀下去，維運人員可以看第 5 章與第 7 章，開發者則可以從 6.2 的判斷表開始讀。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 26 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 問題設定 ── 使用中的檔案為什麼無法直接複製

先確認「打不開」的原因

出發點是 Windows 的檔案共用模式。在 Windows 中開啟檔案時(CreateFile)，會以共用模式(dwShareMode)宣告「自己開啟期間，允許其他處理程序做什麼」。只要有處理程序以不允許讀取共用的方式開著檔案，之後想以讀取方式開啟的處理程序就會因為共用違規(ERROR_SHARING_VIOLATION，錯誤 32)而失敗。⁸ 在 .NET 中，這會以 IOException(「處理程序無法存取檔案，因為檔案正由另一個處理程序使用中」)的形式出現，是大家都很熟悉的錯誤。

重要的是，這不是臭蟲，而是為了保護資料所設計的正確機制。如果檔案在寫入過程中途被讀取，讀取端拿到的就會是「寫到一半的半成品狀態」。互斥控制的設計，正如「檔案整合的互斥控制基礎知識」中詳細討論過的，是應用程式之間協作的基礎。

然而，這個正確的機制，卻與備份從根本上互相衝突。這裡存在 3 道各自不同的牆。

第 1 道牆：共用違規讓複製來源打不開

資料庫或業務應用程式一直開著的檔案，原本就可能無法當成複製來源開啟。

第 2 道牆：就算打得開，複製出來的內容也不一致

就算打得開(對方允許讀取共用)，複製還是需要時間。複製期間應用程式仍持續寫入，於是檔案的前半段與後半段可能來自不同的時間點，或是多個檔案(資料本體與記錄檔等)之間彼此對不上。

而且正如「快取管理員」那一回所看到的，寫入會先落在記憶體上的快取中，因此光看磁碟上的檔案，並不保證就是最新的內容。「讀得到」與「能以一致的狀態複製下來」，是兩個不同的問題。

第 3 道牆：不能為了複製而長時間停機

「那停掉應用程式再複製不就好了」聽起來很有道理，但對 24 小時運作的業務系統或檔案伺服器來說並不可行。

換句話說，需求是「不停止應用程式，想要某一瞬間、狀態一致的複製本」。要個別應用程式自行解決，負擔太重，因此才有了作業系統層級的機制 VSS。VSS 是以 COM 介面構成的框架，用來讓應用程式即使持續寫入磁碟區，也能對該磁碟區進行備份。²

3. VSS 的登場角色 ── 要求者、寫入器、提供者

VSS 的組成，可以整理成 3 種角色，再加上居中協調的服務。¹

備份軟體與應用程式分擔角色

這種角色分工的巧妙之處在於，彼此互不了解的產品也能協調合作。備份軟體(要求者)並不了解 SQL Server 的內部結構。即使如此，依照下面的分工，還是能取得一致的備份。¹⁹

1. SQL Server 的寫入器會以中繼資料的形式，申報「應該備份的檔案群(元件)」。
2. 寫入器在建立靜止點的前後，把自己的資料整理好。
3. 要求者依照這份申報與協調，執行備份。

在 Windows 上執行的第三方備份軟體，幾乎全部都是 VSS 要求者。¹

出問題時，也用這 3 種角色決定該查哪裡

在資訊系統的實務中，會意識到這 3 種角色的場合，就是疑難排解。備份軟體失敗，究竟是要求者(軟體端)的問題、特定寫入器(應用程式端)的問題，還是提供者、差異區(基礎架構端)的問題，要查的地方完全不同(第 5 章、第 7 章)。

4. 快照的機制 ── 寫入時複製與「靜止點」

4.1. 寫入時複製 ── 不複製磁碟區，也能保存「那一瞬間」

只把覆寫前的區塊保存起來

聽到「快照」，一般會聯想成整個磁碟區的複製，但 Windows 標準的系統提供者採用的是寫入時複製(copy-on-write)方式。在建立快照的當下，幾乎不會複製任何東西。

之後，當原始磁碟區上的區塊被覆寫時，系統會在覆寫完成之前，先把覆寫前的區塊保存到差異區(diff area，也就是陰影複製儲存區)，才放行寫入。¹ 只有每個區塊第一次被覆寫時才需要保存，對已經保存過的區塊再次覆寫，並不會增加差異區的用量。

讀取時把原始磁碟區與差異區合成起來

想讀取「那一瞬間的磁碟區」時，未變更的區塊從原始磁碟區讀取，變更過的區塊則從差異區讀取，再合成起來。因為只複製有變更的部分，所以建立只要一瞬間，消耗的容量也只有差異的部分。

反過來說，寫入越多的磁碟區，差異區消耗得越快。是什麼決定消耗量，會在 7.4 詳細說明。差異區會放在與原始資料相同機器的 NTFS 磁碟區上。¹

支撐這套機制的，是系統提供者的組成檔案 swprv.dll，以及插進磁碟區 I/O 的驅動程式 volsnap.sys。¹ 如果對「如何插進 I/O 堆疊」有興趣，也可以看看「篩選驅動程式與迷你篩選驅動程式」。

另外，方式還有分離鏡像的完整複製，以及把變更寫到另一個磁碟區的寫入時重新導向，硬體提供者則會在儲存裝置端使用最適合的方式。¹

4.2. 建立靜止點的流程 ── 凍結 60 秒、建立 10 秒的協調運作

如果說寫入時複製回答的是「怎麼保存」，那麼 VSS 真正的本領在於「保存哪個時間點的狀態」，也就是靜止點的建立方式。陰影複製的建立會依照下列流程進行。¹

flowchart TB
    R["要求者提出建立要求<br/>列舉寫入器並收集中繼資料"] --> M["各寫入器以 XML 申報<br/>備份對象(元件)"]
    M --> P["各寫入器準備資料<br/>輪替記錄檔、清空快取等<br/>整理成可復原的一致狀態"]
    P --> F["凍結寫入器的寫入 I/O<br/>(可以讀取。最長 60 秒)"]
    F --> FS["VSS 清空檔案系統緩衝區<br/>並凍結檔案系統"]
    FS --> C["提供者建立陰影複製<br/>(10 秒以內。此期間寫入 I/O 保持凍結)"]
    C --> T["釋放檔案系統 → 解凍(thaw)寫入器<br/>應用程式恢復寫入"]
    T --> B["要求者從陰影複製<br/>花時間執行備份"]

圖 1：陰影複製建立的流程。停下來的只有數秒到數十秒，備份本體是針對快照執行的

停下來的時間，與備份花的時間是兩回事

重點有 3 個。

1. 應用程式停下來的，只有建立靜止點的那一瞬間。凍結規定在 60 秒以內，提供者的建立(提交)規定在 10 秒以內，超過就會中止建立，由要求者重來一次。¹ 耗時數小時的備份本體，是針對已經建好、唯讀的陰影複製執行的，期間應用程式照常運作。
2. 凍結期間仍然可以讀取。停下來的只有寫入 I/O。¹
3. 檔案系統也會被凍結。VSS 會先清空檔案系統緩衝區再凍結，因此原本留在快取中的寫入內容，以及檔案系統的中繼資料，都會以一致的順序反映到快照中。¹

4.3. 當機一致與應用程式一致

這裡出現了一個左右備份品質的重要區別。

沒有寫入器：和從突然停機中復原是同一種狀態

沒有寫入器協助所建立的陰影複製，在 Microsoft 的術語中稱為當機一致(crash consistent)狀態。官方定義是「等同於系統遭遇讓它突然關機的災難性故障之後，所發現的磁碟狀態」，而從那裡還原則「等同於突然關機後的重新啟動」。³ 就檔案系統而言並沒有損壞，但從應用程式的角度來看，這就是「寫入過程中被拔掉電源的那一瞬間」。具備交易記錄檔復原機制的資料庫多半能夠復原，但前提是必須經過復原處理。

有寫入器：由應用程式準備好可復原的一致狀態

有寫入器協助的話，各個寫入器會在靜止點的前一刻輪替交易記錄檔、清空快取，整理成應用程式自身保證「從這裡可以正確復原」的一致狀態。¹ 這就是應用程式一致，也是寫入器這套機制存在的理由。

要注意的是，寫入器保證的是「就應用程式而言一致、可以復原的狀態」，並不會擅自把執行中的交易提交完成。未提交的作業會在還原時被回復(rollback)，這和資料庫平常的復原行為相同。寫入器實現這份品質保證的方式，是不停止應用程式，只靠數十秒的凍結就完成。

備份軟體的設定中之所以會有「使用 VSS」「保證應用程式一致性」這類選項，正是這個區別的體現。如果只是檔案伺服器上單純的檔案群，即使是當機一致也幾乎不成問題；但對於承載資料庫或郵件儲存區的伺服器來說，對應的寫入器是否正常，本身就等於備份的品質。

5. 維運指令的實務 ── vssadmin 與「舊版」

在資訊系統的實務中，用來確認 VSS 狀態的工具是 vssadmin，要在具管理員權限的命令提示字元中執行。請先用清單確認狀態，差異區的上限變更則要先確認必要性與消失風險再動手。

確認對象與指令的適用範圍

目前的指令參考文件把 list shadows / list writers / delete shadows / resize shadowstorage 整理為用戶端與伺服器都能使用。⁴ Windows Server 系列的參考文件則另外記載了 create shadow / list shadowstorage / list providers 等。⁵ 另外，vssadmin 能管理的，只有系統提供者所建立的陰影複製。¹

分辨狀態確認指令與上限變更指令

如果 list writers 的結果顯示寫入器處於錯誤狀態，該懷疑的不是 VSS 本體，而是提供該寫入器的應用程式端。請確認該應用程式的服務狀態，以及應用程式/系統事件記錄檔(第 7 章)。

上限變更要與確認指令分開看待

resize shadowstorage 的 /maxsize 可以用 KB/MB/GB 等單位指定上限，不指定的話就沒有限制。要注意的是，官方文件明確指出變更儲存區上限(尤其是縮小)這件事本身，就可能造成陰影複製消失。¹⁰ 對於想保留世代的磁碟區，不能輕易縮小它的上限。

5.1. 與「舊版」的關係

在檔案伺服器上啟用「共用資料夾的陰影複製(Shadow Copies of Shared Folders)」後，系統會定期保留共用上檔案在某個時間點的複製本，使用者可以不必借助管理員之手，自行從「舊版」還原被刪除或覆寫的檔案。¹ 這是 VSS 最貼近日常的應用，能確實減少服務台的工作量。

不過這有上限。系統提供者的陰影複製，每個磁碟區最多 512 個，其中共用資料夾的陰影複製功能預設維持的數量是 64 個(可透過登錄檔的 MaxShadowCopies 機碼變更)。¹

而且如同下一章之後所述，差異區不足時就會從最舊的世代開始自動刪除。安全的理解方式是，「能保留幾個世代」並不是由設定的世代數決定，而是由寫入量與差異區的大小決定。

6. 開發者該如何介入 ── 自行開發的應用程式需要 VSS 嗎

接下來換成開發者的視角。當被要求「請加上連使用中檔案也能複製的備份功能」時，應該如何與 VSS 打交道呢？

請先用 6.2 的判斷表看清楚是不是真的需要 VSS，之後再選擇實作方式。6.1 談的是提出複製要求的「要求者」，6.3 談的是為了讓別人取得自家應用程式資料的「寫入器」。

6.1. 自行開發要求者是一件大工程

VSS 的 API，無論是要求者還是寫入器，都是以 COM 與 C++ 介面的形式提供的(要求者的核心是 IVssBackupComponents)。⁶ 官方並沒有提供 .NET 用的封裝，而且從寫入器中繼資料的收集，到快照集的管理、發生錯誤時的善後處理，都必須正確實作，因此不是能輕易當成業務應用程式的一項功能就整合進去的東西。我們在委外開發的報價中，也會把「自行開發 VSS 要求者」當成獨立的開發項目來處理。

先考慮現成軟體，Windows Server 上則考慮 DiskShadow

現實可行的解法有兩個。第一，交給既有的支援 VSS 的備份軟體處理。第二，如果是 Windows Server，可以從指令碼呼叫 DiskShadow。

DiskShadow 是作業系統內建的 VSS 要求者，除了互動模式之外還有指令碼模式(diskshadow /s script.txt)，可以用一支指令碼寫出建立陰影複製、公開為磁碟機代號(expose)、執行負責複製處理的批次檔(exec)，一直到善後清理的全部流程。⁷¹ 「建立陰影複製 → 從中用自行開發的複製處理擷取檔案 → 刪除」這樣的流程，可以在完全不寫一行 COM 程式碼的情況下組出來。

不過DiskShadow 僅限 Windows Server 使用，用戶端作業系統並未內建。¹ 如果需求也涵蓋用戶端 PC，那麼到這一步就會傾向採用既有的備份軟體。

6.2. 究竟需不需要 VSS ── 判斷表

根據經驗，關於「複製使用中檔案」的諮詢，大多數都能在不使用 VSS 的情況下解決。請先看清楚需求的層級，再選擇工具。

6.3. 自行開發的應用程式該不該註冊寫入器

反過來的問題，「自行開發的業務應用程式該不該提供 VSS 寫入器」，在此也一併整理。只要寫了寫入器，不論客戶使用哪一款備份軟體，自家應用程式的資料都能以應用程式一致的品質被取得。

簡易寫入器不會讓寫入靜止

還有一種比一般寫入器更簡易的機制，叫做簡易寫入器(IVssExpressWriter)，但它只是登錄「哪些檔案該納入／排除」這種中繼資料宣告而已。⁶

由於不會收到凍結／解凍等通知，因此無法配合快照的建立讓應用程式的寫入靜止下來。只有在保存設計本身「即使在寫入途中被擷取也不會損壞(當機一致就已足夠)」的情況下，才適合搭配使用簡易寫入器；如果需要在靜止點上進行協調，就必須實作一般的寫入器。

是否需要自行開發寫入器，從保存方式來判斷

判斷的基準很單純。

• 如果資料放在 SQL Server 等資料庫中，就不需要。資料庫端的寫入器會保證一致性。¹
• 單純的檔案保存，先從保存處理端的設計來解決。只要設計成先完整寫入暫存檔，再以重新命名的方式替換這種原子性保存，即使是當機一致的快照，也不會留下「損壞的保存檔案」。
• 值得考慮註冊寫入器的，僅限於擁有跨越多個檔案的自訂資料儲存區，且需要在靜止點上彼此保持一致的應用程式。也許更該先重新檢討的，是要不要用自訂格式來承載這種規模的資料。

7. 陷阱 ── 維運上真正會起作用的 4 個

不只要確認「靜止點做出來了沒有」，還要確認「會不會不見」「品質能不能用來還原」。以下 4 點在維運時必須分開來考量。

7.1. VSS 本身並不是備份

這是最重要的陷阱。系統提供者的陰影複製，是位在與原始資料相同機器磁碟上的差異資料。它並不是另外持有一份完整的複製本，而是把原始磁碟區上尚未被覆寫的區塊與差異區合成起來讀取。

因此，對於磁碟故障、機器遭竊遺失這類連原始磁碟區一起失去的狀況，完全無法因應。就算只把差異區放在另一個磁碟區，這層依賴關係也不會改變。差異區本身遺失時，同樣也無法再合成出來。

對於會把整個磁碟區加密的勒索軟體，也不能指望陰影複製。加密的寫入動作本身確實會把覆寫前的內容保存起來，但在實際的攻擊中，陰影複製會因為遭到刪除，或因大量覆寫導致差異區耗盡而消失。這一點會在 7.3 與 7.4 處理。

Microsoft 的文件也明確區分陰影複製與備份：「從陰影複製複製到磁帶等媒體上的內容才是備份，複製完成後可以刪除陰影複製。」¹ 陰影複製是靜止點，是從誤操作快速復原的手段，並不能取代另一種媒體、另一個據點上的備份。

7.2. 寫入器的錯誤是應用程式端的問題

當備份軟體因「VSS 錯誤」而失敗時，請依照下列順序確認。

1. 用 vssadmin list writers 確定是哪一個寫入器失敗。
2. 確認提供該寫入器的應用程式或 Windows 組成元件的服務狀態。
3. 確認應用程式/系統事件記錄檔，調查該應用程式端的原因。

寫入器的實體是應用程式(或 Windows 組成元件)端的元件。¹ 如果被「備份軟體的錯誤」這個表象牽著走，一直只調查備份軟體那一端，就會繞遠路。釐清原因的一般做法，如同「接手了沒有原始碼也沒有規格書的系統」中所討論過的，是「從能觀察到的事實逐步縮小嫌疑範圍」的套路。

7.3. 勒索軟體會來刪除陰影複製

這是防禦一方應該知道的事實。既然「舊版」可以還原，是不是即使遭勒索軟體加密也能靠它復原呢──雖然會這樣期待，但眾所周知，許多勒索軟體會在加密前後刪除陰影複製，先斷掉這條復原路徑。因為只要有管理員權限，刪除陰影複製就能用正規指令執行，所以它成不了阻止入侵後攻擊者的最後防線。因此，對策的主軸有下列 3 點。

• 把陰影複製定位成「有的話能快一點」的程度，而不是「復原計畫的一部分」。
• 另外準備攻擊者觸及不到的離線、異地備份。
• 不要把日常維運用的帳號賦予管理員權限。

涵蓋備份到加密、廢棄處理的整個 PC 生命週期防禦，也請一併參考「BitLocker 實務指南」「PC 廢棄檢查清單」。

7.4. 差異區一旦耗盡，就會從最舊的世代開始安靜地消失

決定消耗量的不是寫入次數，而是範圍

正如第 4 章所見，寫入時複製會消耗差異區，是在快照取得之後，每個區塊第一次被覆寫的時候。已經保存過的區塊再怎麼被覆寫，消耗量都不會增加，因此消耗量並不是取決於「寫入的次數」，而是取決於「保留中的快照之後，被覆寫的區塊範圍有多廣」。

消失的世代也要在系統記錄檔中確認

差異區一旦達到上限，該磁碟區的陰影複製就會從最舊的開始依序刪除。¹ 由於不會對互動中的使用者發出任何通知，因此常常是在「應該可以還原到上週的版本」卻還不了原時才第一次發現。不過並非完全無聲無息，系統記錄檔中會記錄 volsnap 來源的事件(例如因無法確保差異區而遭刪除時的 25，或因擴充失敗、達到上限而中止時的 35/36 等)。除了定期確認之外，把這些 volsnap 事件也納入監控與警示的對象，就能及早察覺消失的情況。

把需要的保留期間與差異區的使用量對照起來

大量檔案更新、批次轉換、重組磁碟這類「大範圍撫過整個磁碟區」的處理，之所以會一口氣吃光差異區，正是因為這種「由覆寫範圍決定消耗量」的特性。

請定期確認保留世代是否符合業務需求(「誤刪最長要幾天後才會被發現」)，以及 vssadmin list shadowstorage 的使用量，必要時擴大上限。⁵¹⁰

8. 總結

要理解 VSS，可以分成「要整理什麼」「怎麼保存」「怎麼維運」這 3 件事來看。

要整理什麼：即使在使用中也要做出一致的靜止點

使用中的檔案之所以無法直接複製，是共用違規與一致性的問題，而這是保護資料的正確機制。「不停止就想要一致的複製本」這個需求，VSS 就是作業系統層級給出的答案。

VSS 是由 VSS 服務居中協調要求者(提出要求)、寫入器(保證一致性)、提供者(建立)這 3 種角色的框架，讓彼此互不了解的備份軟體與業務應用程式也能協調合作。

怎麼保存：在短時間內做出靜止點，另外進行備份

系統提供者採用寫入時複製方式，靜止點是以「凍結寫入器(最長 60 秒)→建立(10 秒以內)→解凍」的方式建立。沒有寫入器協助是當機一致，有協助則是應用程式一致。

陰影複製並不是備份。它只是依賴原始磁碟區上未受損區塊的差異資料，對磁碟故障這類原始磁碟區的喪失完全無能為力，對勒索軟體也可能因陰影複製遭刪除或差異區耗盡而無法指望。請務必搭配離線、異地的備份。

怎麼維運：確認狀態，只在必要範圍內介入

維運確認用 vssadmin(list shadows / list writers / list shadowstorage)。寫入器的錯誤要懷疑應用程式端，差異區的使用量要定期查看。

開發者應先用判斷表確認能否靠重試、共用模式、停止時間、協作設計來解決，只有在真正需要時才轉向 VSS。比起自行實作，DiskShadow 指令碼(僅限 Server)或既有軟體才是現實的解法。

相關文章

• 檔案整合的互斥控制基礎 - 檔案鎖與原子性 claim 的最佳實務
• Windows I/O 的深層(第 4 回) ── 快取管理員：你的 WriteFile 究竟何時送達磁碟
• Windows I/O 的深層(第 5 回) ── NTFS 的內部結構：從 MFT 理解檔案系統
• 接手了沒有原始碼也沒有規格書的系統 ── 不停機維運的實務步驟
• BitLocker 實務指南 ── 從回復金鑰的管理開始建立磁碟機加密
• 廢棄 Windows PC 前該做的事 ── 資料清除、帳戶解除、備份的實務檢查清單

相關諮詢領域

合同會社小村軟體承接的工作，包括含「使用中檔案的複製、備份功能」在內的業務應用程式設計與開發，檔案協作周邊的共用違規或備份失敗(VSS 寫入器錯誤)的原因調查，以及檔案伺服器備份、世代管理的維運整理。從「這究竟是不是真的需要 VSS 的需求」的釐清開始也沒問題。

• Windows 應用程式開發
• 缺陷調查・原因分析
• 技術諮詢・設計審查
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

有了陰影複製，就不需要備份了嗎？

不會因此就不需要備份。Windows 標準的系統提供者所建立的陰影複製，是寫入時複製方式產生的差異資料，並不是另外持有「當下那個時間點的完整複製本」，而是依賴原始磁碟區上尚未被覆寫的區塊。就算把差異區(diff area)配置在其他磁碟區，只要原始磁碟區遺失就一樣無法還原，對於磁碟故障、PC 遭竊遺失這類連原始磁碟區一起失去的狀況，完全無能為力。對勒索軟體也一樣：加密的寫入動作本身，確實會把覆寫前的區塊先保存到差異區，但在實際的攻擊中，陰影複製會因為遭到刪除，或因大量覆寫導致差異區耗盡而一併消失，因此不能指望它。Microsoft 的文件也明確區分兩者：從陰影複製把資料複製到磁帶等媒體上的，才叫做備份，複製完成後可以刪除陰影複製本身。陰影複製是「為了取得備份而建立的靜止點」，也是「從輕微誤操作快速復原的手段」，並不能取代另一種媒體、另一個據點上的備份。

想用自行開發的業務應用程式複製使用中的檔案，應該使用 VSS 嗎？

現實的做法，是先找出不必動用 VSS 也能解決的路。VSS 的要求者必須用 COM 基礎的原生 API(IVssBackupComponents 等)撰寫，官方也沒有提供 .NET 用的封裝，因此要整合進自行開發的應用程式，會是相當吃重的工作。如果需求只是「其他處理程序正在寫入的檔案，晚一點讀得到就好」，用重試就夠了；如果「對方允許讀取共用」，只要用相符的共用模式開啟即可。如果能讓應用程式短暫停止，在業務的空檔複製是最單純也最確實的做法。只有「要把無法停止的應用程式的整組資料，以一致的狀態複製下來」這個需求才輪得到 VSS 上場，而即使是這種情況，也請先考慮採用支援 VSS 的備份軟體，或把 DiskShadow 寫成指令碼，而不是自行實作。

用 vssadmin list writers 查看，發現寫入器處於錯誤狀態，該怎麼辦？

基本原則是把它當成提供該寫入器的應用程式端問題來調查。vssadmin list writers 會列出已註冊的寫入器並附上狀態，所以首先要確定是哪一個寫入器失敗。寫入器是由 SQL Server 這類應用程式，或登錄檔等 Windows 組成元件所提供，因此錯誤的原因多半不在 VSS 本體，而在負責該寫入器的應用程式服務狀態，或是記錄在應用程式/系統事件記錄檔中的錯誤。請重新啟動相關服務、釐清重現條件，若仍未解決，再確認該應用程式的支援資訊。備份軟體因 VSS 錯誤而失敗時的初步釐清，步驟也完全相同。

陰影複製在不知不覺間消失了，這是為什麼？

最典型的原因是差異區(陰影複製儲存區)容量不足。在寫入時複製方式下，取得快照後每個區塊第一次被覆寫時，覆寫前的內容都會先保存到差異區，因此被覆寫的範圍越廣，消耗的差異區就越多。一旦達到配置的上限，Windows 就會從最舊的陰影複製開始依序刪除，以騰出空間。由於不會通知互動中的使用者，而是安靜地消失，所以常常是以「以為可以用舊版回復到上週的版本，結果卻沒有」的形式才被發現(系統記錄檔中會留下 volsnap 來源的事件 25 等，把它列入監控對象就能及早察覺)。請用 vssadmin list shadowstorage 確認使用量與上限，必要時再用 vssadmin resize shadowstorage 擴大上限。不過也請注意，變更上限(尤其是縮小)這件事本身，就可能造成陰影複製消失。

檔案總管的「舊版」和 VSS 是什麼關係？

「舊版」是用來從 VSS 建立的陰影複製中取出過去檔案的入口之一。在檔案伺服器上啟用「共用資料夾的陰影複製」(Shadow Copies of Shared Folders)後，系統會定期建立陰影複製，使用者可以在共用資料夾上的檔案按右鍵，自行從舊版還原。優點是不必借助管理員之手，就能修正刪除、覆寫的失誤。不過它的實體就是陰影複製，因此能保留的世代數有上限，差異區不足時就會從最舊的世代開始消失。「因為有舊版，所以不需要備份」這種說法並不成立，這一點正文中已經說明。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。