NetApp 快照可以用作備份嗎？
我們的商店非常依賴 NetApp 卷快照進行備份。我們對一些數據使用傳統的基於代理的磁帶備份，但總的來說，我們的大多數係統都依賴於快照。此外，我們沒有嚴格的變更控制政策或任何集中的配置管理，所以所有我們的伺服器，無論其服務提供的數據是否已備份，都需要從裸機重建（並且沒有任何真實文件）。自然地，這使得快照成為一個非常有吸引力的管理提議，因為我們可以恢復整個伺服器、使用者數據和包括的配置。我們使用 NetApp 的 Virtual Storage Console 製作基於 NFS 的 VMware 數據儲存的快照，並使用 NetApp 的 SnapDrive 製作直接呈現給來賓的原始設備映射（物理）LUN。我們將關鍵快照異地 SnapMirror 到另一個 Filer。當然，我們會定期測試我們的恢復過程。
我不禁對我們對備份快照的依賴感到不舒服。對我來說，要讓一項技術被視為足夠的備份策略，它需要滿足以下標準：
- 備份需要是原子的。也就是說，備份不能依賴其他任何東西來恢復。
- 備份需要與其備份的系統分開（帶外）。
- 備份需要復製或傳輸到遠端站點（異地）
據我了解，NetApp 快照在 Redirect-On-Write (RoW) 方法下工作。WAFL文件佈局使用一組指針（元數據？），它們實際上引用了每個可能存在的儲存塊。要製作快照，系統只需複製卷的元數據並將其儲存在該卷的保留空間中。任何寫入（創建/更改/刪除）都將重定向到新塊。這應該是使 NetApp 的 WAFL 如此出色的特殊原因，因為您無需進行讀取，然後將舊數據寫入保留空間，然後像 Copy-On-Write 快照那樣將新數據寫入舊數據。
我完全承認我可能不完全了解 NetApp 卷快照的工作原理，但如果我的理解或多或少正確，NetApp 快照無法滿足我的備份標準。
- 它們不是原子的。“快照”實際上只是一組指向原始數據的指針。如果原始數據不再存在，則元數據將毫無用處。
- 快照未與系統分離。如果有人刪除了錯誤的捲，我會失去快照。如果 NetApp Filer 爆炸成很小的小貓，我會失去備份。我可以使用 SnapMirror 將我的快照移動到另一個 Filer，但同樣，它只是移動元數據而不是實際塊。如果我失去了原始卷，我看不到將快照複製到另一個 Filer 會有什麼幫助。
有人能解釋一下如何將 NetApp 快照視為備份嗎？我正在尋找好的主觀答案，所以請用事實、參考和經驗來支持你的立場。如果我對底層技術的理解不正確，請解釋在哪里以及為什麼會改變我的結論。如果您的商店依賴 NetApp 快照作為備份，請包含足夠的上下文資訊，以便人們了解您必須滿足哪種恢復策略。
備份有兩個功能。
- 首先，它們可以讓您在數據不可用時恢復數據。從這個意義上說，快照不是備份。如果您失去了文件管理器上的數據（卷刪除、儲存損壞、韌體錯誤等），該數據的所有快照也會消失。
- 其次，更常見的是，備份用於糾正諸如意外刪除之類的日常事務。在此案例中，快照是備份。它們可以說是提供這種恢復的最佳方法之一，因為它們使使用者或其作業系統可以直接使用早期版本的數據作為 .snapshot 隱藏目錄，他們可以直接從中讀取文件。
沒有保留政策
也就是說，雖然我們有快照並廣泛使用它們，但我們仍然在 Netbackup 上對磁帶或數據域進行夜間增量。原因是快照不能可靠地支持保留策略。如果您告訴使用者他們將能夠從一周的每日粒度備份到一個月的每週粒度備份，那麼您無法通過快照來兌現承諾。
在具有快照的 Netapp 卷上，快照中包含的已刪除數據佔用“快照保留”空間。如果卷未滿並且您已以這種方式對其進行配置，您還可以推過該快照保留並讓快照佔用一些未使用的數據空間。但是，如果卷滿了，除了保留空間中的數據支持的快照之外的所有快照都將被刪除。快照的刪除僅由可用的快照空間決定，如果它需要刪除保留策略所需的快照，它會這樣做。
考慮這種情況：
- 具有正常快照和 2 周保留要求的完整捲。
- 根據正常的變化率，假設有一半的預留用於快照。
- 有人刪除了大量數據（超過快照保留），暫時大幅增加了變化率。
此時，您的快照儲備已完全使用，您允許 OnTap 用於快照的數據可用空間也已完全使用，但您還沒有失去任何快照。但是，一旦有人用數據備份卷，您將失去數據部分中包含的所有快照，這會將您的恢復點推回到大刪除之後的時間。
概括
Netapp 快照不會為您提供真實數據失去的保障。文件管理器上的錯誤刪除卷或數據失去將要求您重建數據。
它們是一種非常簡單和優雅的方式，可以進行簡單的例行恢復，但它們不夠可靠，無法取代真正的備份解決方案。大多數時候，他們會讓日常恢復變得簡單而無痛，但是當他們不可用時，你就會暴露。