[[185406]]

某日，接到一個CASE，說數據庫兩臺服務器電源同時損壞，已經不能使用，要求在第二天上班前恢復所有的數據庫，趕到現場已經晚上12點了，首先了解了一下該學校的數據庫情況：

1. 數據庫的操作系統為Solaris的操作系統。
2. 數據庫的備份只有Rman的備份，并且放在存儲上。

萬幸的是現場有一臺可供恢復的小型機并且有識別該小型機的光纖卡。

首先在可供恢復的小型機上接上光纖存儲卡并且可以認到存儲上數據庫rman備份，然后安裝好數據庫軟件后，將數據庫的數據恢復，在將數據庫打開。整個過程大概用時5小時以上。

根據上述的案例，下面我就來跟大家討論一下備份方案的制定：

1、最早希望恢復到什么時間點

對于用戶，用戶只關注數據庫當前狀態是否正常，至于數據曾經做過什么操作，什么時間做的并不重要;也有些業務類型可能會由于特殊的需求，希望看到之前曾經做過的操作，甚至要將數據庫恢復到之前的某個時間點。這兩種需求主要與備份的保留策略有關。對于前者，一般建議選擇基于冗余數量的備份保留策略，如果只希望保證數據庫穩定運行，那么可視數據規模的大小，適當保存幾份最近的備份即可。

為什么要保存最近的幾份，一份不就行了嗎?

備份本身就是在做冗余，那么從可靠的角度考慮，對于備份當然也要有冗余，至少要保證有兩份備份嘛，這樣即使由于某些原因損壞了一份，還能有個替補的。像上述案例中一樣，只有一份的備份其實是很危險的，如果出現異常情況，萬一數據不能恢復，那造成的損失就無法估量了。當然，份數的多少決定需要的磁盤空間會成倍增加，需要根據磁盤的容量大小來決定所需要保留的備份份數。

如果不僅要看到，還要能將數據恢復到之前的某個時間點，那么就必須要保證存在目標時間點(或之前)創建的備份，以及相關的歸檔文件。基于這類需求建議選擇基于冗余時間的備份保留策略，備份的保留時間設置為最早恢復到的時間即可。

2、系統什么時間比較空閑

由于系統需要涉及大量數據的讀寫，這期間必然會占用較多的系統資源，如果在數據庫繁忙時段執行備份任務，那么不僅僅備份需要花費較長時間，還有可能對正常運行的業務系統造成影響。

我們目前通常的做法都是將備份的任務放到凌晨兩點執行，對于大多數業務，這個時間系統的訪問量最少，當然個別學校如果對于自己的數據庫使用情況了解的話，可以提出要求在某一時刻進行備份。

3、數據庫的數據規模有多大

雖然前面說不考慮硬件因素，不過備份操作本身，考慮到執行效率的因素，想完全忽略硬件是不可能的，備份所需的時間還是建立在用戶使用獨立存儲的性能基礎上的。按照磁盤讀寫大概每秒百M的速率計算，200GB左右數據執行備份操作需要半個小時左右(對應的恢復操作也差不多是這個時間，一般會更長，因為恢復時還需要應用重做日志)，就備份操作來說，每天在系統不繁忙的時間分配幾個小時專門執行，這個時間對于大多數應用都還可以接受。所以我們給一般學校制定的備份策略為每周六進行一次全備份，每天對歸檔日志進行備份，當每周六進行全備后，刪除以前備份的歸檔日志。

4、預估可能給予的恢復操作時間

一般情況下正常的系統不會執行恢復操作，當需要對數據庫系統做恢復操作時就代表著系統中出現了問題，雖然說出現的問題可能是偶發性的，但處理問題所需要的時間有可能是確定的，比如數據量確定的情況下，恢復數據文件和應用日志的時間是可以估算出來的。

對于某些核心的業務系統，任何無公告通知的短暫停止服務甚至都是災難，那么這種情況下，一旦出現重大問題，僅依靠RMAN想做到快速恢復是不可能的。所以需要數據庫管理員通過其他途徑確保系統的高可用性(例如在存儲層做鏡像或者做數據庫災備等)，而不能僅僅是依靠備份。

而有些非核心的業務系統，可能每周甚至每個月只有某個時段需要用到(如選課系統)，對于這類數據庫系統，由于其執行恢復的時間非常富裕，相對來說制訂備份策略時也就可以更寬松。比如并不需要每天都創建備份，而僅在有數據修改發生時執行備份任務。

備份和恢復之間絕對不是各自孤立存在，恢復依賴于備份，備份策略基本上也就決定了恢復方式、能恢復的數據及恢復的效率等。因此備份策略的制訂要視你的恢復需求，以及恢復策略而定。

5、總結：

對于如何制定數據庫的備份，我的建議是如果條件允許的情況下，可以在數據庫服務器本地與存儲上做一個Rman備份，如果是小型機系統，建議除了做Rman備份(rman只能適用于同平臺之間的恢復)外，還需要做一個邏輯方面的備份并且將這個備份放置在遠程端。備份完成后，需要每隔一段時間(一般三個月)就要做一次全庫的恢復性測試以保證數據庫備份文件的可用。