下面以4個常見的場景為例，介紹如何規劃備份方案。備份方案沒有標準答案，需要根據實現情況來制定，也和管理員的個人使用習慣有很大相關性。

1 交易型數據庫備份

以銀行的交易系統為例，除了前一章節提到的關于RPO和RTO的指標外，很多企業內部或著其它相關監管也會有不同的要求。例如人民銀行對商業銀行數據備份的要求：1）有RPO要求≤4小時；2）RTO要求≤4小時。備份的策略：數據庫打開歸檔模式，分別設置全量備份、增量備份和日志備份。
1） 全量備份耗時較長，選擇在周末的業務空閑的時間段進行，每周一次。之前也接觸過一些更密集的備份頻率，3天一次全量備份，也遇到過每天1次全量備份的策略。就目前的主流備份系統性能來看，數據量在1TB以下的數據庫，基本可以保證在半小時內完成備份。結合現有的備份系統的性能，以及數據量因素，首先制定測試計劃。經過幾次測試后，最終確定全量備份的頻率。
我經歷過最大的交易型數據庫，約50TB，在數據庫服務器、存儲資源，以及備份系統性能卓越的環境下，整體備份耗時11小時，僅供參考。
2） 除全量備份執行的日期之外的日期，每天一次，在業務空閑的時間段進行增量備份。打開BCT功能，提升備份速度。
3） 按照RPO要求，4小時等間隔進行日志備份。在運行初期，不必直接設置成4小時間隔，可以從12小時開始間隔開始試運行。運行期間收集數據庫性能信息，確定日志備份對數據庫的影響。如果日志備份對數據庫性能影響較大，說明現有業務環境不能勝任4小時RPO。需要對業務系統的性能進行升級，再逐步提升日志備份的頻率。
4） 計算恢復速度
恢復速度與備份速度有很大相關性，在前幾個步驟進行備份測試的同時，也要進行恢復測試，來檢測備份計劃對應的恢復方法是否滿足RTO要求。恢復由兩部分組成，第一部分是恢復數據文件和歸檔文件，第二部分是應用歸檔日志。需要恢復的歸檔日志數據量，與整個數據文件備份的耗時相關。在前面的一致性備份章節，我們介紹過，如果要使數據庫恢復到一致狀態，最小要求是保證所有數據文件一致。如果數據文件備份耗時2小時（從每1個數據文件備份開始到最后一個數據文件備份結束），那基本上恢復的歸檔跨度也大約是2小時。根據不同的業務情況，歸檔的數據量變化范圍較大，不能推算時間，必須進行測試。
舉例說明：一套數據庫全量約5TB，在工作時間段每小時的歸檔量約10GB，其它時間段歸檔每小時約1GB。采用的策略是每周日一次全量備份，每天進行增量備份（共6次），時間都在每天的零點，在些基礎上每4小時一次歸檔備份（滿足RPO4小時要求）。全量備份耗時約2小時；增量備份耗時約15分鐘，歸檔日志備份耗時約20分鐘。一次全量數據文件恢復需要2.5小時，一次增量數據文件需要20分鐘，恢復4小時的歸檔大約需要20分鐘。按照最嚴重的情況來計算，假設周六增量備份結束后的晚上10點發現故障，需要全庫恢復到最新的時間點，耗時計算如下：
一次全量恢復，約2.5小時；六次增量恢復約2小時；22小時的歸檔恢復+應用約1小時；整體耗時約5.5小時。顯然這超出了RTO要求的4小時。我們按照最嚴重的情況來計算，當然我們也必須要按照最嚴重的情況來計算，因為RTO指標就是要求在任何情況下都能滿足。所以我們要對備份方案進行優化。
總體恢復時間的5.5小時，這里面歸檔的恢復和應用耗時1小時，可提升的空間不大，這是由業務特性決定的，所以要優化的就是全量和增量的恢復速度。全量恢復要2.5小時，需要通過系統環境綜合分析。限制恢復速度的因素包括：參數設置、數據庫磁盤性能、備份存儲性能、網絡傳輸速度。除了參數設置的調整外，其它因素都和成本相關。不必疑惑，RTO和RPO本來就是決定著備份系統成本的關鍵因素，在做架構設計的時候就應該考慮到這些問題。但是成本問題在短期內往往無法解決，我們可以把焦點放到其它層面，分析是否可以暫時地解決問題，給成本問題的徹底解決贏得更多時間。
1） 方法一：增量可以使用積累方式，這樣不論是恢復哪一天的數據，最多只需要恢復一次增量備份數據。修改后，增量的恢復速度從20分鐘到1小時不等。在上述的場景下，恢復速度可從5.5小時降低到4.5小時。
2） 方法二：備份周期由一周縮短為3天，即一次全量備份，后續2天進行增量備份。在相同的場景中，恢復速度可從5.5小時降低到4小時以下。這肯定是可以滿足RTO≤4小時要求，但是也帶來了新的問題，就是每三天一次全量備份，這會增大備份對系統的性能影響。是否選擇這個方案，要考慮每天凌晨是否有大量的業務交易。如果每天凌晨的交易量都很小，選擇這個方案是可以滿足要求的。貌似這個方法可以滿足需求，其實還存在很大的風險。方案雖然滿足了4小時恢復的要求，但是不具備擴展能力，沒有預留緩沖的時間。并且，數據量如果繼續增長，后續將很難滿足要求。
3） 方法三：目前恢復耗時大的首要因素是數據量大，關鍵是要設計出方案來提升速度，或者減少數據量，才能更可靠的滿足要求。
提升速度的辦法：
恢復的過程，是數據從備份存儲讀出，寫入數據庫生產存儲中。以目前的存儲技術，生產庫后端的設備寫速度完全可以滿足5TB/小時，特別是目前SSD作為主流的時代。備份的存儲，即便是普通的NAS，也能滿足5TB/小時的讀速度。因此，速度的瓶頸肯定在于網絡。從單純的帶寬計算來看，至少要滿足2條萬兆鏈路才能滿足5TB/小時的要求。考慮到交換機層面的問題，如果數據庫部署了4條萬兆，網絡資源是足夠使用的。但是有些企業對于硬件資源的調整阻力較大，優化網絡帶寬可能短期無法實現。我們可以考慮其它方法，利用現有資源。例如，數據庫連接生成存儲通常會使用多條SAN鏈路，這些鏈路僅是為了高可用（MPIO）設計，帶寬消耗其實不高，可以用于備份服務。一些主流的備份軟件，支持數據庫通過SAN網絡連接備份設備，數據流不通過LAN網絡，大大提升備份速度。
減少數據量的辦法：
這聽起來不現實，難道有些數據不備份了嗎？事實是極有可能的，特別是在大數據量場景下。交易型數據，如果數據量大很有可能是存在大量的歷史數據。最佳實踐是要求交易庫和歷史庫分離的，但是現實中很多場景由于各種原因，特別是歷史原因、責任原因沒有進行分離，導致數據庫越來越大。我曾經遇到過交易庫50T，支持多套應用，并且有超過40T是歷史數據。改造的邏輯很簡單，首先盡可以為應用部署獨立的數據庫（或者盡量少的應用共享一套數據庫）；其次，部署單獨的數據倉庫來保存歷史數據。這樣改造的結果，每個交易庫的數據量控制在2、3T，備份將無壓力。但是改造方案阻力很大，有歷史原因，也有責任劃分原因。
在我看來，方法三才是解決問題的根本辦法，其它方法只能是過渡。

2 大型數據庫（VLDB）備份

當數據量到達幾十TB后，備份耗時會很長，通常可以達到10到20小時（取決于備份系統環境的性能），恢復速度比備份速度會更長，用戶很難接受。必須使用更為優化的方式提升備份速度。目前，已經使用的比較成熟的方式是借助存儲快照。
這里需要先介紹一下數據庫的BACKUP MODE。首先，它不需要關閉數據庫，應用可正常寫入數據庫。開啟BACKUP MODE，數據庫會進行一次Checkpoint，將全部數據寫入到數據文件。此后，應用寫入的數據只保存到REDO日志中，并不會寫入數據文件，數據文件始終處于一致狀態。
打開BACKUP MODE，對數據文件在存儲層對應的卷進行快照。快照完成后，關閉BACKUP MODE，數據庫恢復正常運轉。還需要手工備份控制文件。將存儲快照掛載到數據庫服務之外的操作系統中（此步驟是避免備份對數據庫服務器性能產生影響），將數據文件進行備份。由于是在BACKUP MODE狀態下拷貝的數據，因此它們具備一致性。操作過程舉例，
1） 打開備份模式

RMAN> alter database begin backup;

2） 創建存儲快照
在存儲設備，或操作系統中對數據卷進行快照。
3） 關閉備份模式

RMAN> alter database end backup;

4） 備份控制文件
控制文件需要使用RMAN來備份

RMAN> backup format ‘/bk/ctrl_%U’ current controlfile;

5） 備份參數文件

RMAN> backup format ‘/bk/spfile_%U’ spfile;

6） 備份數據庫
將快照卷掛載到指定的操作系統中，對數據文件進行備份。
7） 恢復操作
恢復時，首先恢復參數文件和控制文件，如果按照原路徑恢復，不需要做任何修改。如果路徑或者其它參數變更，需要修改修改參數文件后重建SPFILE；第二步將備份的數據文件拷貝到指定路徑下。
有一點需要注意的是，當打開和關閉BACKUP MODE這中間的一段時間內，如果有大量的業務寫入數據，在關閉BACKUP MODE后，會產生大量的REDO寫數據到數據文件，數據庫可能會產生性能下降的現象，持續的時間由REDO中保存的數據量決定。
既然這種備份方式速度快，是不是其它數據庫也應該使用它？這種方式有它的弊端，就是需要過多的手工介入。備份時需要手工配置存儲，拷貝文件，并記錄備份信息。恢復時，要確保備份信息存在，找到備份數據，手工配置存儲資源。人工操作的步驟越多，失誤的概率越大，因此，非必要不使用這種方法，RMAN的自動備份才是上上之選。

3 數據倉庫備份

數據倉庫保存著歷史數據，通常數據量會很大，但是它又區別前一章節提到的大型數據庫（VLDB）場景。數據庫倉庫的作用是從一個或多個交易型數據庫收集并數據，并且進行整理，最終按照業務要求展現結果，如報表等。它定時通過ETL工具寫入數據，并非實時更新。有些用戶場景中，交易庫和倉庫使用同一個數據庫，這給備份帶來很大的麻煩。這樣的場景，首先要建議用戶“拆庫”，也就是交易庫和倉庫分離，不僅是為了備份，也是數據庫廠商和應用廠商給出的最佳實踐方案。
數據倉庫備份，首先要考慮是歸檔日志問題。這里有一個矛盾點需要平衡：關閉歸檔將不支持在線備份，只能將數據庫置成MOUNT狀態進行備份，所以業務也要停止；打開歸檔，數據倉庫寫入海量數據會產生大量的歸檔日志，而備份又必須包括歸檔日志，給備份系統帶來了很大的壓力。
Oracle給出了官方的最佳實踐方法：保持數據庫處于歸檔模式，手工關閉用戶數據對應的表的歸檔，這樣即可以進行在線備份（不需要關閉數據庫），也不會產生過多的日志。這種方案有一個前提，就是需要對SQL語句進行改造，讓它跳過REDO，直接寫入數據文件。
例如,

SQL> insert /*+ APPEND */ into table2 nologging select * from table1;

看到這兒，是不是會有疑問？關閉了表的日志，那恢復的時候怎么辦？不用擔心，我們關閉的是表級的歸檔，不是數據庫級的歸檔，因此可以保護數據庫是可以恢復的。ETL軟件，按照業務邏輯從交易庫中抽取數據，寫入數據倉庫并進行加工處理，提供報表和查詢業務。數據倉庫備份作業執行，必須要避開ETL的運行時間窗口，在沒有數據寫入的時段得到數據一致性。因為數據庫級的日志是打開的，因此不用擔心數據庫不一致而無法恢復。如果在ETL運行期間，也就是有數據寫入的時候進行備份，數據庫依然可以恢復，但是表會提示有壞塊，不能恢復。
在一些用戶中，數據倉庫創建初期數據量小，因此在設計上沒有考慮歸檔的問題。后期數據量激增，加載速度和備份都暴露出問題，再回過頭來對SQL進行改造，阻力非常大。遇到過這樣的案例，每天備份的歸檔量巨大，而且歸檔日志本身就是壓縮格式，很難再進一步壓縮或消重，備份存儲資源消耗非常嚴重。數據倉庫為什么歸檔量巨大？試想一下，企業的所有交易庫，可能是10幾個，也可能是幾十上百個，每天定時抽出數據進行加工并寫入數據倉庫。這么大的數據量寫入，必須要產生巨大的歸檔數據量。有很多企業因此交易庫多，僅一套數據倉庫根本無法承擔，因此部署了多個數據倉庫。
因此，在數據倉庫初期就規劃好，這是非常重要的。后期如果想改造，會遇到很多歷史遺留問題，阻力重重。

4 容災場景備份

Oracle官方提供Data Guard工具，通過REDO的復制，創建備庫。備庫的設計，是為了解決主庫故障時可以快速切換，保證業務的最大連續性。備庫在實際使用中，也可以發揮更大的作用。例如，備庫在“只讀”狀態下提供報表功能，也可以作為備份的源，充分的利用資源，同時分擔主庫的壓力。
在Data Guard場景中，建議在備庫端進行備份，避免備份操作影響業務的性能。通過RMAN在備庫端進行備份，系統自動識別狀態，自動與主庫聯動，不需要人工進行干預，與在主庫操作備份完全相同。區別在于，從備庫創建的備份集，控制文件狀態為Standby，數據庫不能直接打開。因此，在進行恢復時，需要管理員將控制文件狀態修改為Primary，按照獨立的數據庫打開。