透過快照可為虛擬機器建立還原點，應用十分方便，但必須謹慎使用與管理，避免衍生額外問題

對於VMware虛擬平臺的用戶來說，快照（Snapshot）是個十分方便的工具，可為虛擬機器（VM）建立多個還原點，並在必要時將VM倒回指定的還原點狀態。

因此許多用戶都把快照作為一種VM備份手段，例如在為VM的Guest OS進行重大更新之前，先利用快照建立還原點，以備之後VM出現問題時可以倒回到更新前狀態。VMware還有許多服務或功能也都是透過快照作為中介，如VCB與VADP備份機制、Storage vMotion，與VMware Lab Manager軟體等。

VMware環境下的快照運作方式
VMware的快照屬於Copy-on-Write類型，執行快照時，系統會建立一個稱為delta.vmdk的新檔案（實際檔名通常是vmname-00001.vmdk），接下來包括新增或異動在內的所有VM寫入I/O，都會被導入到新建立的delta.vmdk檔案中，不再寫回原始vmdk檔，原始vmdk檔被轉為唯讀狀態。

每當執行一次快照，就會建立一個新的delta.vmdk檔案，並將前一次快照的delta.vmdk檔轉為唯讀，然後依靠新的delta.vmdk檔來接受VM的新寫入資料。

建立快照時，可選擇是否啟用兩個附屬功能：（1）連同VM的記憶體一同進行快照；（2）配合虛擬機器Guest OS檔案系統的靜止（Quiesce）功能。

若勾選連同VM的記憶體一同快照（如果快照時VM處於開機狀態，這選項是預設開啟），ESX主機會將VM記憶體中的資料Dump下來寫到vmdk檔中，缺點是會拉長快照執行時間。記錄VM狀態的vmsn檔案也會變得更大些。

如果要啟動另一種靜止快照，則須搭配安裝在VM上的VMware Tools使用，勾選後，VMware Tools的Sync驅動程式會讓VM的檔案系統進入靜止狀態（或者說是凍結狀態），停止應用程式對檔案系統的寫入，並將緩衝區或快取記憶體區域內的資料寫回磁碟，以得到確保資料一致性、用於備份作業的快照。

利用快照還原VM狀態的程序
要將VM倒回某個快照狀態，可有兩種操作方式：

一是在VM上按右鍵，然後從Snapshot選單中選擇的Revert to Current Snapshot項目，不過只能將VM還原到最近一次快照的狀態。第二種方法，則是利用Snapshot選單中的Snapshot Manager功能，可從展開的樹狀圖中選擇任何要回復到的快照，然後按下Go to按鈕即可。

執行倒回程序後，接下來VM將改為在所選擇的快照上執行，也就是在被選上的那個delta.vmdk檔上執行寫入動作，並捨棄當前的VM狀態。

快照操作的困難點：刪除快照

快照雖然帶來許多方便，但卻是「請神容易送神難」。由於Copy-On-Write類型的快照之間形成鎖鏈關係、彼此相依，因此不能任意刪除快照，否則就有導致其他快照不可用的問題。以VMware來說，執行快照以後，VM接下來所新增或異動的資料，都寫入在新增的快照檔案中，如果不做任何處理而直接刪除快照檔案，那也就會失去這些新增與異動資料，這顯然是不可接受的。

所以VMware雖然有刪除快照功能，但實際上被刪除的是「還原點」，而不是真的刪除那份快照檔案內所包含的資料。執行刪除動作後，只是少了那個快照還原點而已，但那份快照所包含的資料，會先被合併（Consolidate）到前一份快照中，而不是真的消失了。因此在執行刪除快照功能時，實際上進行的是「先合併、再刪除」的作業，以確保VM資料的完整性與可用性。

假設先後為VM建立了snap1、snap2與snap3等三份快照，如果選擇刪除snap2，系統會先把snap2的資料合併到snap1中，然後再刪除snap2。如果選擇刪除VM的所有快照，ESX主機就會依序將後續快照合併到前一份快照中，待預定刪除的快照資料併入原始vmdk以後，再刪除全部的快照檔案。

但這種程序也衍生出兩個問題：
● 合併作業耗時
建立快照後，如果很長一段時間都不刪除，隨著新增與寫入資料的增加，快照檔案將會變得越來越大，刪除快照時所執行的合併動作將會耗去相當多時間，甚至達數小時之譜。

● 暫存空間需求過大
刪除快照過程需要足夠的暫存磁碟空間，如果要刪除snap2，要等到snap1+snap2的程序完成後，原來的snap2檔案才會刪除，需要的最小暫存空間便等同於snap2大小。如果對VM做了多次快照，那執行刪除所有快照時，需要等系統按照由新而舊的順序，以倒推的順序進行合併後，才會實際刪除快照，累積的暫存空間非常大，甚至可能超過datastore可用空間，導致刪除失敗。

更糟的是，在ESX 4.x以前，執行刪除快照後，快照資訊便會從Snapshot Manager中移除，即使刪除失敗，也無法從vSphere Client管理介面得知。用戶常以為快照已被刪除，VM已回到原始vmdk上執行，但實際上由於快照刪除失敗，VM仍是在最後一版的快照上執行，往往等到快照變得很大、導致datastore空間大量消耗後，才發現問題，此時要解決，將會變得非常麻煩（有時得將VM遷移到有足夠空間的新datastore，然後重新執行刪除與合併）。

要避免這個問題有兩個方法，一是不要使用「刪除所有快照」功能，改為手動方式逐一刪除個別快照，如此每份快照將在合併後便行刪除，需要暫存空間大幅減少，不過操作程序也更繁瑣。

第二種方法是將系統更新到ESX 4.0 Update 2以後版本，新版的快照合併作業經過改進，首先，不是採用倒推的順序合併（從最後一份快照開始逐一往前合併），而是採用正向的合併順序，從最早的一份快照開始合併。其次，每份快照合併後便會立即刪除，因此需要的暫存空間也就大幅減少。

另外從vSphere 4.x起，就可在vCenter裡設定一個警告訊息，使vSphere Client提醒用戶當前的VM是在快照上執行，而非在沒有快照的原始vmdk上，避免過往的忽略快照刪除失敗問題。

vSphere 5.0又有所改進，新增了快照移除失敗警示功能，還在快照選單新增一個Consolidate選項，可在快照刪除失敗後，重新執行快照合併作業。

相較於正規備份作業，快照執行起來相對快速，而且還不用另外部署，十分方便，因此一些用戶有時會以快照來替代備份的角色，但VMware的快照並無法作為真正的備份使用。

首先，快照只能因應VM層次或Guest OS層級的故障，由於快照與VM位於同一臺實體設備上，如果發生實體設備層級故障，快照將與VM一同失效。而真正的備份產品，則是將備份複本保存在獨立的儲存裝置上，可應付實體設備失效的情況。

其次，備份的目的，是要相對長期的保存原始資料在多個不同時間點下的複本，一般情況每天至少要執行一次備份，其中一些備份複本往往要保存數個月甚至更長時間。若以快照充當備份使用，而讓快照保留過久、或建立過多版本的快照，將會衍生出許多麻煩的問題，包括快照占用datastore空間過大，日後刪除快照困難等。

因此較好的做法，是把快照當作臨時性的建立還原點手段，另外部署專門的備份產品來因應備份需求。

文⊙張明德