將快照當作資料保護策略使用的常見問題之一、就是「真實」資料和快照資料位於同一個磁碟機上。遺失這些磁碟機將會導致主要資料和備份遺失。

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

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

使用 ONTAP Snapshot 複本保護資料有許多選項、快照是許多其他 ONTAP 功能的基礎、包括複寫、災難恢復和複製。快照技術的完整說明不在本文件的範圍內、但以下各節提供一般概觀。

建立資料集快照的主要方法有兩種：

資料集的損毀一致備份是指在單一時間點擷取整個資料集結構。如果資料集儲存在單一 NetApp FlexVol Volume 中、則程序很簡單；您可以隨時建立 Snapshot 。如果資料集橫跨多個磁碟區、則必須建立一致性群組（ CG ）快照。建立 CG 快照有多種選項、包括 NetApp SnapCenter 軟體、原生 ONTAP 一致性群組功能、以及使用者維護的指令碼。

當備份點還原足夠時、主要會使用損毀一致的備份。當需要更精細的恢復時、通常需要應用程式一致的備份。

「應用程式一致性」一詞通常是錯誤的。例如、將 Oracle 資料庫置於備份模式稱為應用程式一致的備份、但資料並未以任何方式保持一致或停止。資料會在整個備份過程中持續變更。相反地、大部分的 MySQL 和 Microsoft SQL Server 備份確實會在執行備份之前先將資料關閉。VMware 可能會或可能不會使某些檔案一致。

術語「一致性群組」是指儲存陣列將多個儲存資源視為單一映像來管理的能力。例如、資料庫可能包含 10 個 LUN 。陣列必須能夠以一致的方式備份、還原及複寫這 10 個 LUN 。如果 LUN 的映像在備份時不一致、則無法還原。複寫這 10 個 LUN 需要所有複本彼此完全同步。

討論 ONTAP 時、「一致性群組」一詞並不常使用、因為一致性一向是 ONTAP 內 Volume 和 Aggregate 架構的基本功能。許多其他儲存陣列會將 LUN 或檔案系統視為個別單元進行管理。接著可選擇性地將它們設定為「一致性群組」、以保護資料、但這是組態中的額外步驟。

ONTAP 一向能夠擷取一致的本機和複寫資料映像。雖然 ONTAP 系統上的各種磁碟區通常並未正式描述為一致性群組、但這就是它們的名稱。該磁碟區的快照是一致性群組映像、該快照的還原是一致性群組還原、 SnapMirror 和 SnapVault 都提供一致性群組複寫。

一致性群組快照（ CG 快照）是基本 ONTAP Snapshot 技術的延伸。標準快照作業可在單一磁碟區內建立所有資料的一致映像、但有時必須在多個磁碟區甚至跨多個儲存系統建立一致的快照集。結果是一組快照、其使用方式與只有一個個別磁碟區的快照相同。它們可用於本機資料還原、複寫以進行災難恢復、或複製為單一一致的單元。

CG 快照的最大已知用途是資料庫環境、其大小約為 1PB 、跨越 12 個控制器。在此系統上建立的 CG 快照已用於備份、恢復和複製。

大多數情況下、當資料集跨越磁碟區且必須保留寫入順序時、所選管理軟體會自動使用 CG 快照。在此情況下、無需瞭解 CG 快照的技術詳細資料。然而、在某些情況下、複雜的資料保護需求需要對資料保護和複寫程序進行詳細控制。自動化工作流程或使用自訂指令碼來呼叫 CG 快照 API 是其中的一些選項。若要瞭解最佳選項和 CG-snapshot 的角色、需要更詳細的技術說明。

建立一組 CG 快照是兩個步驟：

寫入隔離是連續建立的。這表示當隔離程序在多個磁碟區之間設定時、寫入 I/O 會依序凍結在第一個磁碟區上、因為它會繼續提交到稍後出現的磁碟區。這可能一開始就違反了保留寫入順序的要求、但這僅適用於非同步在主機上發出的 I/O 、不需仰賴任何其他寫入。

例如、資料庫可能會發出許多非同步資料檔案更新、並允許作業系統重新排序 I/O 、並根據其本身的排程器組態完成這些更新。這類 I/O 的順序無法保證、因為應用程式和作業系統已釋出保留寫入順序的要求。

以計數器為例、大部分的資料庫記錄活動都是同步的。在確認 I/O 之前、資料庫不會繼續進行記錄寫入、而且必須保留這些寫入的順序。如果記錄 I/O 到達圍籬式磁碟區、則不會予以確認、應用程式會在進一步寫入時加以封鎖。同樣地、檔案系統中繼資料 I/O 通常是同步的。例如、檔案刪除作業不得遺失。如果具有 xfs 檔案系統的作業系統刪除了檔案、而更新 xfs 檔案系統中繼資料的 I/O 則會移除位於圍籬磁碟區上的該檔案參照、則檔案系統活動就會暫停。這可確保 CG 快照作業期間檔案系統的完整性。

在目標磁碟區之間設定寫入屏障之後、就可以開始建立快照。由於磁碟區的狀態會從相關寫入點凍結、因此不需要同時精確建立快照。為了防範建立 CG 快照的應用程式中的瑕疵、初始寫入屏障包含可設定的逾時時間、 ONTAP 會在定義的秒數後自動釋放隔離功能並繼續寫入處理。如果所有快照都是在逾時期間發生之前建立的、則產生的一組快照是有效的一致性群組。

以快照為基礎的備份主要有兩種方法：

資料庫的損毀一致備份是指在單一時間點擷取整個資料庫結構、包括資料檔案、重做記錄和控制檔。如果資料庫儲存在單一 NetApp FlexVol Volume 中、則程序很簡單；您可以隨時建立 Snapshot 。如果資料庫橫跨磁碟區、則必須建立一致性群組（ CG ）快照。建立 CG 快照有多種選項、包括 NetApp SnapCenter 軟體、原生 ONTAP 一致性群組功能、以及使用者維護的指令碼。

當備份點還原足夠時、主要會使用損毀一致的 Snapshot 備份。在某些情況下可以套用歸檔記錄檔、但如果需要更精細的時間點還原、則最好使用線上備份。

快照型線上備份的基本程序如下：

此程序會產生一組快照、其中包含備份模式中的資料檔案、以及在備份模式中產生的重要歸檔記錄。這是恢復資料庫的兩項需求。控制檔等檔案也應受到保護、以方便使用、但唯一的絕對需求是保護資料檔案和歸檔記錄。

雖然不同的客戶可能有非常不同的策略、但幾乎所有這些策略最終都是以下列相同原則為基礎。

在設計 Oracle 資料庫的 Volume 配置時、第一個決定是是否使用 Volume NetApp SnapRestore （ VBSR ）技術。

Volume 型 SnapRestore 可讓磁碟區立即還原至較早的時間點。由於磁碟區上的所有資料都已還原、因此 VBSR 可能不適用於所有使用案例。例如、如果整個資料庫（包括資料檔案、重做記錄和歸檔記錄）儲存在單一磁碟區上、且此磁碟區使用 VBSR 還原、則資料會遺失、因為較新的歸檔記錄和重做資料會被捨棄。

還原不需要 VSR 。許多資料庫都可以使用檔案型單一檔案 SnapRestore （ SFSR ）來還原、或只是將檔案從快照複製回作用中的檔案系統。

當資料庫非常大或必須盡快恢復時、最好使用 VBSR 、而使用 VSR 需要隔離資料檔案。在 NFS 環境中、指定資料庫的資料檔案必須儲存在專用的磁碟區中、而這些磁碟區不會受到任何其他類型的檔案污染。在 SAN 環境中、資料檔案必須儲存在專用 FlexVol 磁碟區上的專用 LUN 中。如果使用 Volume Manager （包括 Oracle 自動儲存管理 [AS] ）、則磁碟群組也必須專用於資料檔案。

以這種方式隔離資料檔案、可讓檔案還原至較早的狀態、而不會損壞其他檔案系統。

對於 SAN 環境中具有 Oracle 資料的每個 Volume percent-snapshot-space 應設為零、因為在 LUN 環境中保留快照空間並不實用。如果百分比保留設為 100 、則具有 LUN 的磁碟區快照需要在磁碟區中有足夠的可用空間、但不包括快照保留空間、以吸收所有資料 100% 的營業額。如果將百分比保留設為較低的值、則需要相對較小的可用空間、但它一律會排除快照保留。這表示 LUN 環境中的快照保留空間會被浪費。

在 NFS 環境中、有兩個選項：

使用第一個選項、 percent-snapshot-space 設為非零值、通常約 20% 。然後、使用者就會隱藏此空間。不過、此值並不會限制使用率。如果具有 20% 保留的資料庫擁有 30% 的營業額、則快照空間可能會超出 20% 保留空間的範圍、並佔用無保留空間。

將保留設定為 20% 等值的主要優點是驗證某些空間永遠可供快照使用。例如、保留 20% 的 1TB 磁碟區只允許資料庫管理員（ DBA ）儲存 800GB 的資料。此組態保證至少有 200GB 的空間可供快照使用。

何時 percent-snapshot-space 設為零、則使用者可以使用磁碟區中的所有空間、以提供更好的可見度。DBA 必須瞭解、如果他 / 她看到 1TB 的磁碟區運用快照、則這 1TB 的空間會在使用中資料和 Snapshot 週轉之間共享。

終端使用者之間的選項 1 和選項 2 之間沒有明確的偏好設定。

Oracle Doc ID 604683.1 說明第三方快照支援的需求、以及備份與還原作業的多種選項。

第三方廠商必須保證公司的快照符合下列要求：

ONTAP 和 NetApp Oracle 管理產品符合這些要求。