人們普遍反對使用快照做為資料保護策略、因為「真實」資料和快照資料位於同一個磁碟機上。遺失這些磁碟機將會導致主要資料和備份遺失。

這是一項有效的考量。本機快照是用於日常備份與還原需求、在這方面、快照是備份。在 NetApp 環境中、將近 99% 的還原案例都仰賴快照來滿足最嚴苛的 RTO 需求。

然而、本機快照不應是唯一的備份策略、因此 NetApp 提供 SnapMirror 複寫等技術、可快速有效地將快照複寫至一組不同的磁碟機。在架構正確的解決方案中、快照加上快照複寫功能可將磁帶的使用降至最低、甚至是每季歸檔、或完全消除。

一致性群組備份包括在單一時間點擷取資料集（或多個資料集）的狀態。例如、這包括所有資料庫元件、例如資料檔案、記錄檔、以及與資料庫直接相關的其他檔案。這幾乎適用於所有關聯式資料庫產品、包括 Oracle RDBMS 、 Microsoft SQL Server 、 SAP HANA 、 PostgreSQL 、 MySQL 和 MariaDB 。使用一致性群組備份來保護 VMware 組態的做法類似、也就是在單一時間點內擷取所有的資料存放區、以及可能的 ESX 開機 LUN 。

建立這樣的一致性群組快照、基本上就是模擬當機、這就是為什麼這類備份經常稱為損毀一致的備份。有時候、對於支援恢復案例有疑慮、但請務必瞭解、通常不需要任何恢復程序。當應用程式在還原一致性群組備份之後啟動時、會執行一般的記錄還原程序、檔案系統日誌重新播放、以及其他工作、以重播備份點正在執行中的任何 I/O 。然後應用程式會照常啟動。

基本上、任何能夠承受停電或伺服器當機而不毀損資料的應用程式、都能以這種方式受到保護。許多不同廠商的同步與非同步鏡射產品、可保護大量應用程式、也能證明這項工作的成效。如果災難突然發生在主要站台、則複本站台會在發生災難時、包含原始環境的一致映像。再一次、不需要特殊的恢復程序。

此方法的 RPO 通常僅限於備份點。一般而言、單一磁碟區快照的最小 RPO 是一小時。例如、 48 小時快照加上 30 天夜間快照是合理的、不需要保留過多的快照。不到一小時的 RPO 就變得更難達成、建議您先諮詢 NetApp 專業服務部門、瞭解環境、規模及資料保護需求。

RTO 通常可在數秒內測量。應用程式會關閉、磁碟區會還原、應用程式也會重新啟動。

最簡單的方法是將所有檔案或 LUN 放在單一磁碟區一致性群組中、以便直接在 ONTAP 中排程快照建立。如果資料集必須跨越多個磁碟區、則需要一致性群組快照（ CG-snapshot ）。這可以使用系統管理員或 RESTful API 呼叫來設定、而且 SnapCenter 能夠在已定義的磁碟區清單上建立簡單的一致性群組快照。

本節說明遠端資料保護、將資料複寫到遠端站台、以保護異地儲存和災難恢復的安全。請注意、這些表格並未解決同步鏡射資料保護問題。如需此需求、請參閱 NetApp MetroCluster 文件、包括"MetroCluster"和"SnapMirror 主動同步"

災難恢復 RPO 受限於可用的網路頻寬和受保護資料的總大小。建立初始基準傳輸之後、更新僅以變更的資料為基礎、這通常是資料佔用空間總量的低百分比、但確實存在例外情況。

例如、每週變更率為 10% 的 10TB 資料庫、在總變更中、平均每小時約為 6GB 。10 Gb 的連線能力、此資料庫需要大約六分鐘的時間才能傳輸。變更率會因資料庫變更率的波動而異、但整體而言、 15 分鐘的更新間隔、因此應可達成 15 分鐘的 RPO 。如果有 100 個這樣的資料庫、則需要 600 分鐘才能傳輸資料。因此、一小時的 RPO 是不可能的。同樣地、單一資料庫的複本、每週變更率為 10% 、大小為 100TB 、無法在一小時內可靠地更新。

其他因素可能會影響複寫作業、例如複寫作業的額外負荷和限制。不過、單一磁碟區複寫策略的整體規劃可根據可用頻寬進行、複寫 RPO 一般可達一小時。不到一小時的 RPO 變得更難達成、只能在諮詢 NetApp 專業服務之後才能執行。在某些情況下、 15 分鐘的時間是可行的、因為站台對站台網路連線能力非常好。不過、整體而言、當需要一小時以下的 RPO 時、多重 Volume 記錄重播架構會產生更好的結果。

災難恢復案例中的 RTO 與一致性群組複寫功能非常出色、通常從儲存點算起、以秒為單位。最直接的方法是中斷鏡射、資料庫已準備就緒、可以開始運作。資料庫啟動時間通常約為 10 秒、但有大量記錄交易的大型資料庫可能需要幾分鐘的時間。

判斷 RTO 的最重要因素不是儲存系統、而是執行 RTO 的應用程式和主機作業系統。例如、複寫的資料可在一秒或兩秒內提供、但這只代表資料。此外、還必須有正確設定的作業系統、並具備應用程式二進位檔、才能使用資料。

在某些情況下、客戶已預先準備好災難恢復執行個體、並在作業系統上預先探索到儲存設備。在這些情況下、啟動災難恢復案例只需要中斷鏡射並啟動應用程式即可。在其他情況下、作業系統和相關應用程式可能會與資料庫一起鏡射、做為 ESX 虛擬機器磁碟（ VMDK ）。在這些案例中、 RPO 是由客戶投資多少自動化來快速啟動 VMDK 、以便啟動應用程式所決定。

保留時間部分由快照限制控制。例如、 ONTAP 中的磁碟區限制為 1024 個快照。在某些情況下、客戶會使用多工複寫來增加限制。例如、如果需要 2000 天的備份、則可以將來源複寫到兩個磁碟區、並在其他日期進行更新。這需要增加所需的初始空間、但與傳統的備份系統相比、它仍然是更有效率的方法、而傳統的備份系統則需要多個完整備份。