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

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

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

本文以被要求提供「複製使用中檔案功能」的業務應用程式開發者,以及負責檔案伺服器、業務用 PC 備份維運的資訊系統負責人為對象,依據 2026 年 8 月時點的第一手資料,整理 VSS 的登場角色與機制、vssadmin 的維運實務,以及「開發者該介入 VSS 到什麼程度」的判斷方式。在「Windows I/O 的深層」系列中,我們看過快取管理員與 NTFS 的內部結構,本文作為該系列的續篇,要處理的是緊貼在磁碟區之上、插入其間的「快照」這一層。

1. 先講結論

• VSS 是一套 COM 介面群與協調服務,用來讓「應用程式持續寫入中的磁碟區」也能進行備份。自 Windows XP 起就已內建。²
• 登場角色是 3 個角色再加上 1 個協調角色。負責要求陰影複製的要求者(備份軟體)、在應用程式端保證資料一致性的寫入器(SQL Server 等)、實際建立快照的提供者,由 VSS 服務居中協調。¹
• Windows 標準的系統提供者採用寫入時複製方式。不是複製整個磁碟區,而是只把快照之後會被覆寫的區塊,在覆寫前退避到差異區(diff area)。差異區必須位於 NTFS 磁碟區上。¹
• 靜止點是以「凍結寫入器(最長 60 秒)→建立快照(10 秒以內)→解凍」的流程建立的。超過限制時間,建立就會中止,由要求者重新來過。¹
• 有沒有寫入器的協助,會左右複製本的品質。沒有協助所建立的快照,等同於「斷電瞬間的磁碟」(當機一致);有協助時,則會先完成記錄檔輪替與快取清空,達到應用程式自身保證可復原的一致狀態(應用程式一致)。³¹
• 維運上的確認工具是 vssadmin。用 list shadows / list writers / list shadowstorage 確認現況,用 resize shadowstorage 調整差異區的上限。差異區一旦耗盡,就會從最舊的陰影複製開始被悄悄刪除。⁴⁵¹
• 把 VSS 要求者整合進自行開發的應用程式,是一件大工程。它是 COM 基礎的原生 API,官方沒有提供 .NET 用的封裝。多數情況下,靠重試、調整共用模式、短暫停止就已足夠;若真的需要 VSS,把 DiskShadow 寫成指令碼是現實可行的解法(僅限 Windows Server)。⁶⁷
• 陰影複製本身並不是備份。寫入時複製的差異,依賴的是原始磁碟區上未受損的區塊,因此對於磁碟故障或遭竊這類連原始磁碟區一起失去的事故,完全無能為力。對勒索軟體也一樣,陰影複製本身可能遭到刪除(7.3)或因大量覆寫而使差異區耗盡(7.4),因此不能指望它。唯有搭配另一份媒體上的備份,才具有意義。¹

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

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

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

然而,這個正確的機制,卻與備份的需求從根本上互相衝突。

• 共用違規之牆:資料庫或業務應用程式持續開啟中的檔案,原本就可能無法作為複製來源開啟。
• 一致性之牆:即使能開啟(允許讀取共用),複製也需要時間。複製過程中應用程式仍持續寫入,於是檔案前半段與後半段可能來自不同的時間點,或多個檔案(資料本體與記錄檔等)之間彼此對不上。而且正如「快取管理員」那一回所看到的,寫入動作會先落在記憶體上的快取中,因此光看磁碟上的檔案,並不保證是最新內容。
• 維運之牆:「那停止應用程式再複製不就好了」聽起來很有道理,但對 24 小時運作的業務系統或檔案伺服器來說並不可行。

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

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

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

這種角色分工的巧妙之處在於,彼此互不了解的產品也能協調合作。備份軟體(要求者)並不了解 SQL Server 的內部結構,但 SQL Server 的寫入器會以中繼資料的形式申報「應該備份的檔案群組(元件)」,並在靜止點建立前後整理好自己的資料,因此要求者只要照著做,就能取得一致的備份。¹⁹ 在 Windows 上執行的第三方備份軟體,幾乎全部都是 VSS 要求者。¹

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

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

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

聽到「快照」,一般會聯想到複製整個磁碟區,但 Windows 標準的系統提供者採用的其實是寫入時複製(copy-on-write)方式。在建立快照的當下,幾乎不會複製任何東西。之後,當原始磁碟區上的區塊被覆寫時,系統會在覆寫完成前,先把覆寫前的區塊退避到差異區(diff area,即陰影複製儲存區),才放行寫入。¹ 只有每個區塊第一次被覆寫時才需要退避,對已經退避過的區塊再次覆寫,並不會增加差異區的用量。

想讀取「那一瞬間的磁碟區」時,未變更的區塊從原始磁碟區讀取,變更過的區塊則從差異區讀取,再合成起來。因為只複製有變更的部分,所以建立幾乎是一瞬間,消耗的容量也只有差異的部分。反過來說,寫入越頻繁的磁碟區,差異區消耗得越快(這是第 7 章的伏筆),而差異區必須放在與原始資料相同機器的 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["釋放檔案系統 → 解凍寫入器<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.1. 自行開發要求者是一件大工程

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

現實可行的解法有兩個。第一,交給既有的支援 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 等資料庫中,就不需要。DB 端的寫入器會負責保證一致性。¹
• 單純的檔案保存,應該先從保存處理端的設計來解決。只要設計成先完整寫入暫存檔,再以重新命名的方式替換這種原子性保存,即使是當機一致的快照,也不會留下「損壞的保存檔案」。
• 值得考慮註冊寫入器的,僅限於擁有跨越多個檔案的自訂資料儲存區,且需要在靜止點上彼此保持一致的應用程式。也許更應該先重新檢討的,是要不要用自訂格式來承載這種規模的資料。

7. 陷阱 ── 維運上真正會踩到的 4 個

7.1. VSS 本身並不是備份

這是最重要的陷阱。系統提供者的陰影複製,是位在與原始資料相同機器磁碟上的差異資料。一旦差異區遺失,就無法合成出完整內容,因此對磁碟故障、機器遭竊遺失、整個磁碟區被加密等情況,完全起不到任何保護作用。Microsoft 的文件也明確區分陰影複製與備份:「把陰影複製的內容複製到磁帶等媒體上的,才是備份,複製完成後可以刪除陰影複製本身。」¹ 陰影複製是靜止點,是從誤操作快速復原的手段,並不能取代異地、異媒體的備份。

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

當備份軟體因「VSS 錯誤」而失敗時,首先要用 vssadmin list writers 確定是哪一個寫入器失敗。由於寫入器的實體是應用程式(或 Windows 組成元件)端的元件¹,原因調查的主戰場,是負責該應用程式的服務狀態與事件記錄檔。如果被「備份軟體的錯誤」這個表象牽著走,一直只調查備份軟體那一端,就會繞遠路。排查的一般做法,如同「接手了沒有原始碼也沒有規格書的系統」中所討論過的,是「從能觀察到的事實逐步縮小嫌疑範圍」的套路。

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

這是防禦一方應該知道的事實。既然「舊版本」可以還原,是不是即使遭勒索軟體加密,也能靠它復原呢──雖然會這樣期待,但眾所周知,許多勒索軟體會在加密前後刪除陰影複製,先斷掉這條復原路徑。因為只要有管理員權限,刪除陰影複製就能用正規指令執行,所以它成不了阻止入侵後攻擊者的最後防線。因此,對策的重點在於:(1)把陰影複製定位成「有的話能快一點」的程度,而不是「復原計畫的一部分」;(2)另外準備攻擊者觸及不到的離線、異地備份;(3)不要把日常操作用的帳號賦予管理員權限。涵蓋備份到加密、廢棄處理的整個 PC 生命週期防禦,也請一併參考「BitLocker 實務指南」「PC 廢棄檢查清單」。

7.4. 差異區一旦耗盡,就會從舊世代開始悄悄消失

正如第 4 章所見,寫入時複製會消耗差異區,是在快照取得之後,每個區塊第一次被覆寫的時候。已經退避過的區塊再怎麼被覆寫,消耗量都不會增加,因此消耗量並非取決於「寫入次數」,而是取決於「保留中的快照之後,被覆寫的區塊範圍有多廣」。而差異區一旦達到上限,該磁碟區的陰影複製就會從最舊的開始依序刪除。¹ 由於不會對互動中的使用者發出任何通知,因此常常是在「應該可以還原到上週的版本」卻無法還原時才第一次發現。不過並非完全無聲無息,系統記錄檔中會記錄 volsnap 來源的事件(例如因無法確保差異區而遭刪除時的 25,或因擴充失敗、達到上限而中止時的 35/36 等)。除了定期確認之外,把這些 volsnap 事件也納入監控與警示的對象,就能及早察覺消失的情況。大量檔案更新、批次轉換、重組磁碟這類「大範圍撫過整個磁碟區」的處理,之所以會一口氣吃光差異區,正是因為這種「由覆寫範圍決定消耗量」的特性。請定期確認保留世代是否符合業務需求(「誤刪最長要幾天後才會被發現」),以及 vssadmin list shadowstorage 的使用量,必要時擴大上限。⁵¹⁰

8. 總結

• 使用中的檔案之所以無法直接複製,是共用違規與一致性的問題,而這是保護資料的正確機制。「不停止就想要一致的複製本」這個需求,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 標準的系統提供者所建立的陰影複製,是以寫入時複製(copy-on-write)方式產生的差異資料,並非另外持有「當下時間點的完整複製本」,而是依賴原始磁碟區上尚未被覆寫的區塊。即使把差異區(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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。