第一篇：ORACLE數據備份與數據恢復方案論文.

ORACLE 數據備份與數據恢復方案 學號: 11129149 姓名:文明藝 1 引 言

目前, 數據已成為信息系統的基礎核心和重要資源, 同時也是各單位的寶貴財富, 數據 的丟失將導致直接經濟損失和用戶數據的丟失, 嚴重影響對社會提供正常的服務。另一方面, 隨著信息技術的迅猛發展和廣泛應用, 業務數據還將會隨業務的開展而快速增加。但由于系 統故障,數據庫有時可能遭到破壞,這時如何盡快恢復數據就成為當務之急。如做了備份, 恢復數據就顯得很容易。由此可見, 做好數據庫的備份至關重要。因此,建立一個滿足當前 和將來的數據備份需求的備份系統是必不可少的。傳統的數據備份方式主要采用主機內置或 外置的磁帶機對數據進行冷備份, 這種方式在數據量不大、操作系統種類單

一、服務器數量 有限的情況下, 不失為一種既經濟又簡明的備份手段。但隨著計算機規模的擴大, 數據量幾 何級的增長以及分布式網絡環境的興起, 將越來越多的業務分布在不同的機器、不同的操作平臺上,這種單機的人工冷備份方式越來越不適應當今分布式網絡環境。

因此迫切需要建立一個集中的、自動在線的企業級備份系統。備份的內容應當包括基于 業務的業務數據,又包括 IT 系統中重要的日志文件、參數文件、配置文件、控制文件等。本文以 ORACLE 數據庫為例,結合金華電信的幾個相關業務系統目前正在實施的備份方案, 介紹 ORACLE 數據庫的備份與恢復。ORACLE數據備份與數據恢復方案 2.1 導出和導入(Export/Import 利用 Export 可將數據從數據庫中提取出來,利用 Import 則可將提取出來的數據送回到 Oracle 數據庫中去。

1、簡單導出數據(Export和導入數據(Import

Oracle 支持三種方式類型的輸出:(1表方式(T方式 ,將指定表的數據導出。

(2用戶方式(U方式 ,將指定用戶的所有對象及數據導出。(3全庫方式(Full方式 ,瘵數據庫中的所有對象導出。

數據導入(Import的過程是數據導出(Export的逆過程, 分別將數據文件導入數據庫和將 數據庫數據導出到數據文件。

2、增量導出 /導入

增量導出是一種常用的數據備份方法,它只能對整個數據庫來實施,并且必須作為

SYSTEM 來導出。在進行此種導出時,系統不要求回答任何問題。導出文件名缺省為 export.dmp ,如果不希望自己的輸出文件定名為 export.dmp ,必須在命令行中指出要用的文 件名。

增量導出包括三種類型:(1“ 完 全 ” 增 量 導 出(Complete即 備 份 三 個 數 據 庫 , 比 如 :exp system/manager inctype=complete file=040731.dmp。

(2“ 增 量 型 ” 增 量 導 出 備 份 上 一 次 備 份 后 改 變 的 數 據 , 比 如 :exp system/manager inctype=incremental file=040731.dmp。

(3“ 累積型 ” 增量導出累計型導出方式是導出自上次 “ 完全 ” 導出之后數據庫中變化了的 信息。比如:exp system/manager inctype=cumulative file=040731.dmp。

數據庫管理員可以排定一個備份日程表,用數據導出的三個不同方式合理高效的完成。比如數據庫的被封任務可以做如下安排:

星期一:完全備份(A 星期二:增量導出(B 星期三:增量導出(C 星期四:增量導出(D 星期五:累計導出(E 星期六:增量導出(F 星期日:增量導出(G。

如果在星期日,數據庫遭到意外破壞,數據庫管理員可按一下步驟來回復數據庫:第一步:用命令 CREATE DATABASE 重新生成數據庫結構;第二步:創建一個足夠大的附加回滾;第三步:完全增量導入 A :imp system/manager inctype=RESTORE FULL=y FILE=A 第四步:累計增量導入 E :imp system/manager inctype=RESTORE FULL=Y FILE=E 第五步:最近增量導入 F :imp system/manager inctype=RESTORE FULL=Y FILE=F 2.2 冷備份

冷備份發生在數據庫已經正常關閉的情況下, 當正常關閉時會提供給我們一個完整的數 據庫。冷備份時將關鍵性文件拷貝到另外的位置的一種說法。對于備份 Oracle 信息而言, 冷備份時最快和最安全的方法。冷備份的優點是:

1、是非?？焖俚膫浞莘椒?只需拷文件;

2、容易歸檔(簡單拷貝即可;

3、容易恢復到某個時間點上(只需將文件再拷貝回去;

4、能與歸檔方法相結合,做數據庫 “ 最佳狀態 ” 的恢復;

5、低度維護,高度安全。但冷備份也有如下不足:

1、單獨使用時,只能提供到 “ 某一時間點上 ” 的恢復;

2、再實施備份的全過程中,數據庫必須要作備份而不能作其他工作。也就是說,在冷 備份過程中,數據庫必須是關閉狀態;

3、若磁盤空間有限,只能拷貝到磁帶等其他外部存儲設備上,速度會很慢;

4、不能按表或按用戶恢復。

如果可能的話(主要看效率 , 應將信息備份到磁盤上, 然后啟動數據庫(使用戶可以工作 并將備份的信息拷貝到磁帶上(拷貝的同時,數據庫也可以工作。冷備份中必須拷貝的文件 包括:

1、所有數據文件。

2、所有控制文件。

3、所有聯機 REDO LOG文件。

4、Init.ora 文件(可選。

值得注意的使冷備份必須在數據庫關閉的情況下進行, 當數據庫處于打開狀態時, 執行 數據庫文件系統備份是無效的。

下面是作冷備份的完整例子:(1 關閉數據庫;sqlplus /nolog sql>connect /as sysdba sql>shutdown normal;(2 用拷貝命令備份全部的時間文件、重做日志文件、控制文件、初始化參數文件 sql>cp。

(3 重啟 Oracle 數據庫 sql>startup。2.3 熱備份

熱備份是在數據庫運行的情況下,采用 archivelog mode方式備份數據庫的方法。所以, 如果你有昨天夜里的一個冷備份而且又有今天的熱備份文件, 在發生問題時, 就可以利用這 些資料恢復更多的信息。熱備份要求數據庫在 Archivelog 方式下操作, 并需要大量的檔案空 間。一旦數據庫運行在 archivelog 狀態下,就可以做備份了。熱備份的命令文件由三部分組 成: 1.數據文件一個表空間一個表空間的備份:(1設置表空間為備份狀態;(2備份表空間的數據文件;(3回復表空間為正常狀態。2.備份歸檔 log 文件:(1臨時停止歸檔進程;(2log下那些在 archive rede log目標目錄中的文件;(3重新啟動 archive 進程;(4備份歸檔的 redo log文件。

3.用 alter database bachup controlfile命令來備份控制文件: 熱備份的優點是: 1.可在表空間或數據庫文件級備份,備份的時間短。2.備份時數據庫仍可使用。

3.可達到秒級恢復(恢復到某一時間點上。4.可對幾乎所有數據庫實體做恢復。

5.恢復是快速的,在大多數情況下愛數據庫仍工作時恢復。熱備份的不足是: 1.不能出錯,否則后果嚴重;2.若熱備份不成功,所得結果不可用于時間點的恢復;3.因難于維護,所以要特別仔細小心,不允許 “ 以失敗告終 ”。3 系統數據庫備份策略

數據庫運行在歸檔模式下, 利用 Veritas 軟件模塊調用數據庫的備份接口進行在線的熱 備份, 可以在備份時,對備份數據保存在不同的存儲對象中, 以滿足客戶容災的要求, 可以 利用 Veritas 的多線程的數據遷移、利用多個磁帶驅動器同時讀寫提高其數據備份的效率。針對數據庫的總數據量和增量數據量大小, 我們可以利用數據庫的多級的增量備份機制, 結 合 Veritas 強大的備份數據追蹤尋址能力和介質管理功能,制定靈活的備份策略,實現全 自動的備份數據的全生命周期管理。

4備份系統數據庫恢復策略

通過本地的 Veritas Server結合 Veritas for Databases利用備份數據進行數據恢 復?；謴蜁r, Veritas 可以實現多線程的數據恢復,利用 Veritas 獨特的磁帶分類集中存 放技術,減少磁帶的就位時間,提高數據恢復的效率。

先用最近一次的全備份恢復＋恢復最近一次的增量備份＋增量備份到斷點的 ARCHIVE LOG 來恢復（要求數據庫在 ARCHIVE LOG 模式下工作）。這種恢復方式比全部用 ARCHIVE LOG 恢復要快。如果兩份冗余的最近一次增量備份都不可用，可以追溯再上次的增量備份來恢復，然后 用增量備份到斷點的 ARCHIVE LOG 恢復。如果最近一次的全備份恢復都不可用,則利用上個周期的全備份＋上個周期的最后一次 增量備份＋本周期的最近一次增量備份＋增量備份到斷點的 ARCHIVE LOG 來恢復。如果增量備份都不可用，那么用全備份＋ARCHIVE LOG 來恢復。5 數據庫恢復可以分為以下兩類： 5.1 實例故障的一致性恢復 當實例意外

地（如掉電、后臺進程故障等）或預料地（發出 SHUTDOUM ABORT 語句）中 止時出現實例故障，此時需要實例恢復。實例恢復將數據庫恢復到故障之前的事務一致狀態。如果在在線后備發現實例故障，則需介質恢復。在其它情況 Oracle 在下次數據庫起動時（對 新實例裝配和打開），自動地執行實例恢復。如果需要，從裝配狀態變為打開狀態，自動地 激發實例恢復，由下列處理：

（1）

為了解恢復數據文件中沒有記錄的數據，進行向前滾。該數據記錄在在線日志，包括對回滾段的內容恢復。所指定的操作。

（2）回滾未提交的事務，按步 1 重新生成回滾段

（4）

（3）釋放在故障時正在處理事務所持有的資源。

解決在故障時正經歷一階段提交的任何懸而未決的分布事務。5.2 介質故障或文件錯誤的不一致恢復 介質故障是當一個文件、一個文件的部分或磁盤不能讀或不能寫時出現的故障。文件錯 誤一般指意外的錯誤導致文件被刪除或意外事故導致文件的不一致。這種狀態下的數據庫都 是不一致的，需要 DBA 手工來進行數據庫的恢復，這種恢復有兩種形式，決定于數據庫運行 的歸檔方式和備份方式。（1）完全介質恢復可恢復全部丟失的修改。一般情況下需要有數據庫的備份且數據庫 運行在歸檔狀態下并且有可用歸檔日志時才可能。對于不同類型的錯誤，有不同類型的完全 恢復可使用，其決定于毀壞文件和數據庫的可用性。（2）不完全介質恢復是在完全介質恢復不可能或不要求時進行的介質恢復。重構受損 的數據庫，使其恢復介質故障前或用戶出錯之前的一個事務一致性狀態。不完全介質恢復有 不同類型的使用，決定于需要不完全介質恢復的情況，有下列類型：基于撤消、基于時間和 基于修改的不完全恢復。

基于撤消(CANCEL恢復：在某種情況，不完全介質恢復必須被控制，DBA 可撤消在指定 點的操作。基于撤消的恢復地在一個或多個日志組（在線的或歸檔的）已被介質故障所破壞，不能用于恢復過程時使用，所以介質恢復必須控制，以致在使用最近的、未損的日志組于數 據文件后中止恢復操作。

基于時間(TIME和基于修改(SCN的恢復：如果 DBA 希望恢復到過去的某個指定點，是 一種理想的不完全介質恢復，一般發生在恢復到某個特定操作之前，恢復到如意外刪除某個 數據表之前。

6結 語 數據庫的備份和恢復的主要工作就是為數據做了一份拷貝，防止出現故障時導致數據的 丟失。數據庫受破壞一般是由于兩種情況引起，其一為系統（軟件）故障，如掉電、Server SQL 錯誤、操作系統錯誤、非正常關機等引起。其二為磁盤（介質）故障，由磁盤受破壞引起。若出現介質故障（如磁盤崩潰），當且僅當對數據庫及事務日志做了定期備份，才能恢復數 據庫。在實際應用中，應根據具體的情況，采納一切可以用的方法，制定切合實際的備份和 恢復方案，明確在各種故障情況中數據可恢復的程度是否滿足了應用的需要。為了保證數據 存儲的可管理性，減少管理的復雜性，建立一個異地集中、在線的備份系統是必不可少的。采用先進的備份技術和先進的備份系統軟件，采用統一的管理機制，保證大數據量的一致性 備份和高速切換。從而提供高效的存儲設備的管理能力和可靠的數據備份功能。

第二篇：ORACLE數據備份與數據恢復方案

ORACLE數據備份與數據恢復方案

摘 要

結合金華電信IT系統目前正在實施的備份與恢復策略，重點介紹電信業務計算機管理系統(簡稱97系統)和營銷支撐系統的ORALCE數據庫備份和恢復方案。

Oracle數據庫有三種標準的備份方法，它們分別是導出／導入（EXP/IMP）、熱備份和冷備份。要實現簡單導出數據（Export）和導入數據（Import），增量導出／導入的按設定日期自動備份，可考慮，將該部分功能開發成可執行程序，然后結合操作系統整合的任務計劃，實現特定時間符合備份規劃的備份應用程序的運行，實現數據庫的本級備份，結合ftp簡單開發，實現多服務器的數據更新同步，實現數據備份的異地自動備份。

關鍵字：數據庫 遠程異地 集中備份

I

ORACLE數據備份與數據恢復方案

目 錄

一、前 言 ··························· 1

二、金華電信ORACLE數據庫的備份與恢復方案 ······· 2

2.1 備份系統數據庫備份策略································································································· 3 2.2 備份系統數據庫恢復策略···················· 3 2.3 金華電信97系統及營銷支撐系統的系統狀況 ··········· 3 2.4 金華電信97系統、營銷支撐系統及備份系統總體結構圖 ······ 4 2.5 備份系統結構圖說明······················ 4

三、金華電信97系統的數據庫備份和恢復 ········ 6

3.1 備份方法··························· 6 3.2 備份策略··························· 6 3.3 恢復策略··························· 6 3.4 性能影響··························· 6

四、金華電信營銷支撐系統的備份與恢復········· 7

4.1 備份方法··························· 7 4.2 備份策略··························· 7 4.4 性能影響··························· 7

五、RMAN CATALOG 數據庫的備份 ············ 8

II

ORACLE數據備份與數據恢復方案

六、結 語 ······················ 9

III

ORACLE數據備份與數據恢復方案

一、前 言

目前，數據已成為信息系統的基礎核心和重要資源，同時也是各單位的寶貴財富，數據的丟失將導致直接經濟損失和用戶數據的丟失，嚴重影響對社會提供正常的服務。另一方面，隨著信息技術的迅猛發展和廣泛應用，業務數據還將會隨業務的開展而快速增加。但由于系統故障，數據庫有時可能遭到破壞，這時如何盡快恢復數據就成為當務之急。如做了備份，恢復數據就顯得很容易。由此可見，做好數據庫的備份至關重要。因此，建立一個滿足當前和將來的數據備份需求的備份系統是必不可少的。傳統的數據備份方式主要采用主機內置或外置的磁帶機對數據進行冷備份，這種方式在數據量不大、操作系統種類單

一、服務器數量有限的情況下，不失為一種既經濟又簡明的備份手段。但隨著計算機規模的擴大，數據量幾何級的增長以及分布式網絡環境的興起，將越來越多的業務分布在不同的機器、不同的操作平臺上，這種單機的人工冷備份方式越來越不適應當今分布式網絡環境。

因此迫切需要建立一個集中的、自動在線的企業級備份系統。備份的內容應當包括基于業務的業務數據，又包括IT系統中重要的日志文件、參數文件、配置文件、控制文件等。本文以ORACLE數據庫為例，結合金華電信的幾個相關業務系統目前正在實施的備份方案，介紹ORACLE數據庫的備份與恢復。

ORACLE數據備份與數據恢復方案

二、金華電信ORACLE數據庫的備份與恢復方案

由于金華電信IT系統以前只采用邏輯備份方式進行數據庫備份，速度較慢并且數據存儲管理都很分散，甚至出現備份數據不完整的現象。為了提高備份數據的效率，提供可靠的數據備份，完善備份系統，保證備份數據的完整性，降低數據備份對網絡和服務器的影響，對每個IT系統的備份數據進行集中管理，我們對備份工作進行了改進，將邏輯備份與物理備份相結合，在遠程建立了一個異地集中、自動在線的備份系統即網絡存儲管理系統。（這里用到的物理備份指熱備份）其具備的主要功能如下：(1)集中式管理 :網絡存儲備份管理系統對整個網絡的數據進行管理。利用集中式管理工具的幫助，系統管理員可對全網的備份策略進行統一管理，備份服務器可以監控所有機器的備份作業，也可以修改備份策略，并可即時瀏覽所有目錄。所有數據可以備份到同備份服務器或應用服務器相連的任意一臺磁帶庫內。(2)全自動的備份: 對于大多數機房管理人員來說,備份是一項繁重的任務。每天都要小心翼翼,不敢有半點閃失,生怕一失足成千古恨。網絡備份能夠實現定時自動備份，大大減輕管理員的壓力。備份系統能根據用戶的實際需求，定義需要備份的數據，然后以圖形界面方式根據需要設置備份時間表，備份系統將自動啟動備份作業，無需人工干預。這個自動備份作業是可自定的,包括一次備份作業、每周的某幾日、每月的第幾天等項目。設定好計劃后，備份作業就會按計劃自動進行。(3)數據庫備份和恢復: 數據庫系統已經相當復雜和龐大，不能用文件的備份方式來備份數據庫。企業級的備份系統能夠對數據庫在不中斷業務、不停頓數據庫的情況下對數據進行聯機的自動備份，包括可以進行數據庫備份、日志備份、完全備份、增量備份等。(4)歸檔管理: 用戶可以按項目、時間定期對所有數據進行有效的歸檔處理。提供統一的數據存儲格式從而保證所有的應用數據由一個統一的數據格式來作永久的保存，保證數據的永久可利用性。(5)有效的媒體管理: 備份系統對每一個用于作備份的磁帶自動加入一個電子標簽，同時在軟件中提供了識別標簽的功能，如果磁帶外面的標簽脫落，只需執行這一功能，就會迅速知道該磁帶的內容。(6)滿足系統不斷增加的需求:備份軟件必須能支持多平臺系統，當網絡連接其它的應用服務器時，對于網絡存儲管理系統來說，只需在其上安裝支持這種服務器的客戶端軟件即可將數據備份到磁帶庫或光盤庫中。

ORACLE數據備份與數據恢復方案

2.1 備份系統數據庫備份策略

數據庫運行在歸檔模式下，利用Veritas軟件模塊調用數據庫的備份接口進行在線的熱備份，可以在備份時，對備份數據保存在不同的存儲對象中，以滿足客戶容災的要求，可以利用Veritas的多線程的數據遷移、利用多個磁帶驅動器同時讀寫提高其數據備份的效率。

針對數據庫的總數據量和增量數據量大小，我們可以利用數據庫的多級的增量備份機制，結合Veritas 強大的備份數據追蹤尋址能力和介質管理功能，制定靈活的備份策略，實現全自動的備份數據的全生命周期管理。

2.2 備份系統數據庫恢復策略

通過本地的Veritas Server結合Veritas for Databases利用備份數據進行數據恢復?；謴蜁r，Veritas 可以實現多線程的數據恢復，利用Veritas 獨特的磁帶分類集中存放技術，減少磁帶的就位時間，提高數據恢復的效率。

先用最近一次的全備份恢復＋恢復最近一次的增量備份＋增量備份到斷點的ARCHIVE LOG來恢復（要求數據庫在ARCHIVE LOG模式下工作）。這種恢復方式比全部用ARCHIVE LOG恢復要快。

如果兩份冗余的最近一次增量備份都不可用，可以追溯再上次的增量備份來恢復，然后用增量備份到斷點的ARCHIVE LOG恢復。

如果最近一次的全備份恢復都不可用,則利用上個周期的全備份＋上個周期的最后一次增量備份＋本周期的最近一次增量備份＋增量備份到斷點的ARCHIVE LOG來恢復。

如果增量備份都不可用，那么用全備份＋ARCHIVE LOG來恢復。

2.3 金華電信97系統及營銷支撐系統的系統狀況

金華電信經過這么多年的信息系統建設，目前已經運行著多個系統，除計費系統有較為完善的備份系統外，其他系統的備份系統都需要完善。其中97系統的機器型號IBM 7040-61R，操作系統 AIX5.2，數據庫類型ORALCE8.1.7.4，數據量120G；營銷支撐系統機器型號IBM xseries440，操作系統Red Flag Linux Server 4.0,數據庫類型ORACLE9.2.0.1,數據量150G。以前,這兩個系統的數據備份都是通過邏輯備份(exp)實現并且備份數據管理是分散的，然而一個完善的備份系統必須包含物理備份和邏輯備份兩種方式。因此，我們正在實施一個遠程

ORACLE數據備份與數據恢復方案

異地在線集中的高效的備份系統，將邏輯備份和物理備份（熱備份）相結合，設置了專門的備份服務器。由于97、營銷支撐操作系統采用AIX及Red Flag，我們在備份服務器上安裝了第三方備份軟件Veritias NBU。

2.4 金華電信97系統、營銷支撐系統及備份系統總體結構圖

對于具體的備份環境和結構,我們結合了Oracle備份技術和LAN環境的SAN備份結構.該系統的結構如下圖所示（以97系統與營銷支撐系統為例）

備份系統總體結構圖

2.5 備份系統結構圖說明

此在線存儲系統采用了基于SAN（存儲區域網絡）的結構，SAN是一種高速

ORACLE數據備份與數據恢復方案

網絡或子網絡，提供在計算機與存儲系統之間的數據傳輸。存儲設備是指一張或多張用以存儲計算機數據的磁盤設備。一個 SAN 網絡由負責網絡連接的通信結構如光交換機、負責組織連接的管理層、存儲部件以及計算機系統構成，從而保證數據傳輸的安全性和力度。由于整個SAN系統的數據量比較大，所以備份系統采用SAN結構，將磁盤陣列直接連接到SAN的交換機上，和備份服務器、多臺服務器均通過SAN相互連接，利用SAN的高性能來提高備份速度、降低數據備份對網絡和服務器的影響。備份系統結構圖說明如下:(1)Veritas 服務器(即備份服務器):備份系統是數據安全的關鍵系統，而備份服務器是備份系統的核心，因此從安全可靠的角度，采用專用的備份服務器，在這臺服務器上安裝VERTIAS Server端軟件，集中管理控制磁帶庫、定制備份策略、管理備份作業、管理磁帶等，同時安裝oracle catalog庫。(2)備份方案:對97系統購買IBM VERTIAS 備份軟件，將數據備份至磁盤陣列上面，備份數據走光纖通道。對營銷支撐系統，我們從SAN存儲的FATA盤上劃部分空間直接掛到系統中，然后直接采用RMAN做備份，以降低成本。之所以采用FATA盤的目的是為了避免和FC盤有IO沖突。(3)M300磁盤陣列:在我們的方案當中，我們采用磁盤陣列來代替一貫采用的磁帶庫。磁盤陣列具有性能高，可靠性高，維護方便等優點。本方案中采用專業存儲廠商富士通的中高端存儲ETERNUS3000 M300，作為一種面向開放系統的存儲系統，ETERNUS3000在性能、容量及連通性等方面將世界標準提高到一個新層次。M300的容量為6T的FC盤，10T的FATA盤。在FC盤上保留所有系統的一份全備，其他的備份在白天定期轉移到FATA盤。在FATA盤上保留1-2份全備，其他的定期轉移到3583磁帶庫中。(3)光纖交換機:為了使整個系統具有良好的擴展性，我們在數據中心采用了被評為最優秀的網絡存儲產品博科的16口的光纖交換機，在新大樓備份中心采用博科的8口的光纖交換機。(4)磁帶庫:本方案中的磁帶庫采用的是原先計費系統所用的3583磁帶庫。我們定期將FATA盤上的備份自動轉移到該磁帶庫上，做更久的保留。(5)邏輯備份服務器:為了充份利用舊有的設備來提高異地集中備份系統的穩定性，安全性，我們利用舊有設備IBM 7044-170小型機和IBM 3542陣列來搭建一個邏輯備份系統。所有的邏輯備份都放到該機器上面來，使得邏輯備份和物理備份在物理上開離。這樣一來避免了IO沖突，二來提高了備份系統的可靠性。

ORACLE數據備份與數據恢復方案

三、金華電信97系統的數據庫備份和恢復

3.1 備份方法

采用Veritas NBU物理備份加EXP邏輯備份。Exp邏輯備份在服務器上直接備份，定期轉移到邏輯備份服務器。

3.2 備份策略

備份策略:(1)每周進行一次數據庫全備份操作，并定期將FC盤上面的物理備份定期轉移到FATA盤上，同時將FATA盤陣上面的物理備份定期轉移到磁帶庫上，至少保存 3 個全備份；全備份時間選擇在每周星期六凌晨12：00 開始。(2)數據庫采用Archive Log 模式，每天晚上12：00 開始進行增量備份。(3)與數據庫的邏輯備份相配合，我們每天進行一次數據的exp備份，即每天做一個完整的數據庫EXPORT 備份；備份時間選擇在每天凌晨1：00 開始。Exp備份還是備到本機，定期將其ftp到邏輯備份服務器上。

3.3 恢復策略

恢復策略:(1)數據文件損壞或磁盤陣列損壞：針對這種情況可以采用Veritas NBU從FC磁盤陣列中恢復。(2)誤操作或對象級邏輯上的損壞：針對這種情況可以從exp備份中采用imp恢復。

3.4 性能影響

數據庫采用歸檔模式對97數據庫性能將產生一定的影響。因為在歸檔模式下，oracle需要將歸檔日志歸檔到歸檔目錄(也就是copy)。在IO資源不成為瓶頸的情況下，對系統影響將可以不予考慮。97系統目前的瓶頸在于內存這一塊。所以對97系統的性能影響可以不加以考慮。

ORACLE數據備份與數據恢復方案

四、金華電信營銷支撐系統的備份與恢復

4.1 備份方法

采用物理備份加EXP邏輯備份。物理備份考慮到VERTIAS 的成本，及該系統的重要程度，我們從SAN存儲上劃一部分空間掛接至該系統OS上面，然后直接采用RMAN備份。這樣備份的好處是成本低，缺點是不便于管理和維護，消耗主機的資源，在主機無法啟動的情況下，備份文件無法訪問，但備份數據還是完好如初的。

4.2 備份策略

備份策略:(1)每周進行一次數據庫全備份操作，采用循環覆蓋的方式，共保存 2個全備份；備份時間可以選擇在周日晚上11：00進行(由于其采用的是FATA盤，與其他的物理備份不會造成IO沖突)。(2)數據庫采用Archive Log 模式，每天晚上12：00 增量備份。(3)與數據庫的邏輯備份相配合，我們每周進行一次數據的exp備份，即每天做一個完整的數據庫EXPORT 備份；備份時間選擇在每天凌晨1:00 開始。

4.3 恢復策略

恢復策略:(1)數據文件損壞或磁盤陣列損壞：針對這種情況可以采用RMAN從磁盤中恢復。(2)誤操作或對象級邏輯上的損壞：針對這種情況可以從exp備份中采用imp恢復。

4.4 性能影響

數據庫采用歸檔模式對營銷支撐系統數據庫性能產生的影響也是由于歸檔進程需要對歸檔日志進行歸檔。同時改成歸檔模式還需要注意的一個問題就是歸檔目錄空間的問題，該系統空間足夠。如果該系統的IO資源較為充裕的話，則不會對性能產生很大的影響。

ORACLE數據備份與數據恢復方案

五、RMAN Catalog 數據庫的備份

RMAN Catalog庫是整個備份系統當中最重要的信息之一。是在物理備份（Veritas）服務器上建立的一個ORACLE數據庫，記錄了所有備份的數據庫數據文件。如果丟失了Catalog信息的話，恢復將非常麻煩，因此我們也需要對RMAN Catalog庫做定期備份。RMAN Catalog庫采用邏輯備份，每天直接備份到邏輯備份服務器上。

ORACLE數據備份與數據恢復方案

六、結 語

數據庫的備份和恢復的主要工作就是為數據做了一份拷貝，防止出現故障時導致數據的丟失。數據庫受破壞一般是由于兩種情況引起，其一為系統（軟件）故障，如掉電、SQL Server錯誤、操作系統錯誤、非正常關機等引起。其二為磁盤（介質）故障，由磁盤受破壞引起。若出現介質故障（如磁盤崩潰），當且僅當對數據庫及事務日志做了定期備份，才能恢復數據庫。在實際應用中，應根據具體的情況，采納一切可以用的方法，制定切合實際的備份和恢復方案，明確在各種故障情況中數據可恢復的程度是否滿足了應用的需要。為了保證數據存儲的可管理性，減少管理的復雜性，建立一個異地集中、在線的備份系統是必不可少的。采用先進的備份技術和先進的備份系統軟件，采用統一的管理機制，保證大數據量的一致性備份和高速切換。從而提供高效的存儲設備的管理能力和可靠的數據備份功能。

第三篇：數據備份方案

浪擎官網：http://www.tmdps.cn/

浪擎容災案例

浪擎-北京航空航天大學-構建統一備份方案

北京航空航天大學文件服務器存儲著大量檔案資料，一旦服務器存儲發生故障，就會造成相當大的損失.此外，北京航空航天大學的PC和筆計本的數量很龐大，而且分散在不同的區域，文件數據容易丟失和損壞，造成很大的安全隱患，同時，文檔數據分散存儲，造成了信息和數據孤立，大大降低了信息的整體利用率。

需求及建設目標：

1）建立統一的、自動的文件備份機制，提高文件存儲安全，減輕維護工作量

定時將文件服務器中數據備份到存儲服務器，減輕系統管理員的維護工作。在文件服務器因意外導致數據丟失時，則可從備份存儲中快速恢復。

2）高頻高效的備份，盡量減少計劃或意外情況下導致的數據損失

可靈活的配置系統備份計劃，盡量減小數據備份窗口（如以每天或每半天甚至每小時為一個周期進行備份）

3）充分利用現有硬件設備，保護投資，降低系統總體擁有成本

浪擎備份無需特殊硬件需求，而且對配置要求甚低，系統操作維護簡單，降低系統總體擁有成本。

4）數據安全

為桌面文檔建立安全統一的備份機制，系統應支持各種格式的辦公文檔和業務數據備份。備份數據在存儲端不可視，保證只有文件主人才有權查看備份文件。

5）文件共享

便捷共享，系統應提供脫機共享方式，以提高備份系統的利用效果。用戶可將已備份至服務器上的數據授權共享給他人瀏覽，同時可查看他人共享信息。

病毒防范，系統在實現共享的同時應防止病毒主動傳播

6）使用要求

簡捷易用，應提供方便的自動和計劃備份方式。便于管理人員的日常管理與維護，可通過Web方式查看用戶的備份情況，可通過備份策略進行強制備份或幫助終端用戶進行重要文檔的備份。

浪擎官網：http://www.tmdps.cn/

浪擎容災案例

浪擎服務器備份及桌面備份解決方案

1）浪擎?服務器備份系統

浪擎?服務器備份系統實現應用系統的存儲備份，對備份服務器硬件和網絡等無特殊要求，可實現低成本、高保障的熱備份和熱容災

浪擎?服務器備份系統備份客戶端安裝在源服務器上，備份服務器軟件安裝在目標服務器上，管理員可以在任意一臺計算機通過Web遠程管理備份服務器和監控兩臺服務器的運行狀態。

2）浪擎?終端備份系統

浪擎?終端備份系統為桌面計算機提供了一套完整的數據備份、安全保護及高效利用的解決方案。

浪擎?終端備份系統由備份客戶端、備份服務器和基于WEB的備份管理界面三部分構成。

備份代理安裝在需要備份的計算機上；備份服務器軟件安裝在存儲服務器上，負責用戶管理、備份數據、存儲空間；管理員可通過Web遠程管理備份服務器和監控整個運行狀態。

第四篇：Oracle數據庫備份和恢復論文

摘要：本文從Oracle的體系結構開始，由原理到實踐，論述了Oracle數據庫備份的方式和策略。包括IMp/EXp，RMAN，OS備份等。

Abstract: Starting from the architecture of ORACLE, this paper discusses the backup method and strategy of database Oracle, including IMp/EXp, pMAN and OS theoretically and practically.關鍵字：Oracle, 備份, 恢復, RMAN

Keywords: Oracle;Backup;Restoration;RMAN

概述

在大型軟件運行系統中，存在著很多備份策略，如RAID技術，CLUSTER技術等等。很多時候，這些系統的備份就能夠解決數據庫備份的問題。但是，這種備份成本很高。同時，硬件的備份有時根本滿足不了現實的需要，如果用戶不小心誤刪了一個表，又想恢復的時候，數據庫的備份就變的重要了。

Introduction: In the running system of some big software, there exist many backup strategies such as RAID technology and CLUSTER technology etc.In most cases, these system backup strategies can fulfill the database backup.However the cost is rather high.At the same time, hardware backup sometimes is far from the actual requirement.The database backup becomes very important when a table is deleted by accident and needs to be restored.Oracle的運行方式

Oracle數據庫有兩種運行方式：一是歸檔方式（ARCHIVELOG），歸檔方式的目的是當數據庫發生故障時最大限度恢復數據庫，可以保證不丟失任何已提交的數據；二是不歸檔方式(NOARCHIVELOG)，只能恢復數據庫到最近的回收點（冷備份或是邏輯備份）。根據數據庫的高可用性和用戶可承受丟失的工作量的多少，對于實時性要求高的數據庫，強烈要求采用為歸檔方式；不歸檔方式只用在那些開發和調試的數據庫等。

如何改變數據庫的運行方式，在創建數據庫時，作為創建數據庫的一部分，就決定了數據庫初始的存檔方式。一般情況下為NOARCHIVELOG方式。當數據庫創建好以后，根據我們的需要把需要運行在歸檔方式的數據庫改成ARCHIVELOG方式。操作如下。

1.關閉數據庫，備份已有的數據，改變數據庫的運行方式是對數據庫的重要改動，所以要對數據庫做備份，對可能出現的問題作出保護。

2.修改初試化參數，使能自動存檔。

修改（添加）初始化文件init[SID].ora參數：

log_archive_start=true #啟動自動歸檔

log_archive_format=ARC%T%S.arc #歸檔文件格式

log_archive_dest=/archdir/arch #歸檔路徑

在8i中，可以最多有五個歸檔路徑，并可以歸檔到其它服務器，如備用數據庫(standby database)服務器。

3.啟動Instance到Mount狀態，即加載數據庫但不打開數據庫。

$> svrmgrl

SVRMGRL> connect internal

SVRMGRL> startup mount

SVRMGRL> alter database archivelog;// 使數據庫運行在歸檔方式

SVRMGRL> alter database open;

Oracle的備份方案

按照備份的方式，可以分為邏輯備份、冷備份（脫機備份）、熱備份（聯機備份），其中冷備份與熱備份又可以合稱為物理備份。按照備份的工具，可以分為EXp/IMp備份、操作系統備份、RMAN、第三方工具備份，如VERITAS等。下面分別介紹Oracle本身提供的幾種備份工具和操作。

1.EXp/IMp備份（邏輯備份）

EXp/IMp屬于邏輯備份的范疇，邏輯備份是指只備份數據庫中的數據但不記錄數據物理位置的一種備份。導出為數據庫作一個二進制的備份，并且這個備份只能由其姊妹程序imp（import）來讀取。具體的使用方法如下。（因為EXp和IMp使用上參數基本相同，所以只以EXp為例。）

EXp的命令格式和參數

格式:KEYWORD=value 或 KEYWORD=(value1,value2,...,valueN)

例程: EXp SCOTT/TIGER GRANTS=Y TABLES=(EMp,DEpT,MGR)

USERID 必須是命令行中的第一個參數

關鍵字 說明（默認）關鍵字 說明（默認）

USERID 用戶名/口令 FULL 導出整個文件(N)

BUFFER 數據緩沖區的大小 OWNER 所有者用戶名列表

FILE 輸出文件(EXpDAT.DMp)TABLES 表名列表

COMpRESS 導入一個范圍(Y)RECORDLENGTH IO記錄的長度

GRANTS 導出權限(Y)INCTYpE 增量導出類型

INDEXES 導出索引(Y)RECORD 跟蹤增量導出(Y)

ROWS 導出數據行(Y)pARFILE 參數文件名

CONSTRAINTS 導出限制(Y)CONSISTENT 交叉表一致性

LOG 屏幕輸出的日志文件 STATISTICS 分析對象(ESTIMATE)

DIRECT 直接路徑(N)TRIGGERS 導出觸發器(Y)

FEEDBACK 顯示每 x 行(0)的進度 FILESIZE 各轉儲文件的最大尺寸

QUERY 選定導出表子集的子句

注：可以通過exp －help命令查看exp的使用方法；imp-help命令查看imp的使用方法.2.操作系統備份（冷備份和熱備份）

操作系統備份有兩類，冷備份（Cold backup）和熱備份（Hot backup）。操作系統備份和上面的邏輯備份有本質的區別，它將拷貝整個的數據文件。

冷備份

在文件級備份開始前數據庫必須徹底關閉。關閉操作必須用帶有normal、immediate、transaction選項的shutdown來執行。

數據庫使用的每個文件都被備份下來，這些文件包括： 所有數據文件、所有控制文件、所有聯機重做日志文件和INIT.ORA文件(建議)。

作冷備份一般步驟是：

1)正常關閉要備份的實例(instance);

2)備份整個數據庫到一個目錄

3)啟動數據庫

即：

SVRMGRL>connect internal

SVRMGRL >shutdown immediate

SVRMGRL >!cp

or

SVRMGRL >!tar cvf /dbbak/fullbk.tar /u01/oracle/oradata/dbname

SVRMGRL >startup

熱備份

熱備份是當數據庫打開時的操作系統備份。熱備份只能用于ARCHIVELOG方式的數據庫。熱備份沒有必要備份聯機日志，但必須是歸檔狀態，在實例恢復的時候，可能需要用到歸檔日志。當前聯機日志一定要保護好或是處于鏡相狀態，當前聯機日志的損壞，對于數據庫的損壞是巨大的，只能以數據的丟失來進行數據庫的恢復工作。對于臨時表空間，存放的是臨時信息，在熱備份是也可以考慮不用備份，如果臨時文件發生故障，可以刪除該數據文件與表空間，重建一個臨時表空間。

熱備份備份的內容和冷備份備份的內容一樣，操作一般步驟是：

1)備份的表空間通過使用ALTER TABLESpACE …… BEGIN BACKUp使表空間進入熱備份方式。

2)用類似冷備份的操作系統命令對組成表空間的數據文件進行拷貝。

3)使用ALTER TABLESpACE …… END BACKUp命令使表空間脫離熱備份方式。

4)使用ALTER DATABSE …… BACKUp CONTROLFILE命令備份控制文件。

即：

SVRMGRL>connect internal;

SVRMGRL>alter tablespace User begin backup;

SVRMGRL>!cp /u01/oradata/dbname/user01.ora /dbbak/user01.ora

SVRMGRL>alter tablespace User end backup;

SVRMGRL>alter database backup controlfile to ;

or

SVRMGRL>alter database backup controlfile to trace;

注意：因為熱備份的時候，用戶還在操作數據庫，所以最好是讓每個表空間處于備份狀態的時間最短，這樣就要求一個表空間一個表空間的備份，不要一起使表空間處于備份狀態而同時拷貝數據文件。

3.RMAN

Recovery Manager（RMAN）是一個使DBA能很方便地對數據庫執行備份和恢復任務的Oracle應用工具，能夠提供DBA對企業數據庫備份與恢復操作的集中控制。RMAN只能用于ORACLE8或更高的版本中。它能夠備份整個數據庫或數據庫部件，其中包括表空間、數據文件，控制文件和歸檔文件。RMAN可以按要求存取和執行備份和恢復。

RMAN支持六種不通的類型的備份，經常用到的有兩種：

FULL 數據庫全備份，包括所有的數據塊。

INCREMENTAL 增量備份，是指只備份在同級別或更低級別上進行的前一次備份之后的作過改動的那些數據塊。這其中需要一個0級的增量作為增量的基礎，它備份包括全部曾經被數據庫使用過的數據塊（但不是完全數據庫備份）。RMAN共可以支持7級增量。

BACKUp，RESTORE，RECOVER是RMAN最基本的三個命令，分別可以進行數據庫的備份，復原以及恢復操作。restore命令用于恢復來自備份集或映像拷貝的數據文件、控制文件或歸檔重做日志。recovery命令用于進行介質恢復應用重做日志文件。

RMAN的備份信息一般保存在恢復目錄中，恢復目錄也是一個數據庫，只不過這個數據庫用來保存備份信息，一個恢復目錄可以用來保存多個數據庫的備份信息。RMAN也可以在沒有恢復目錄(NOCATALOG)下運行，這個時候備份信息保存在控制文件。這種情況比較危險，因為一旦控制文件被破壞，將導致所有數據庫備份信息的丟失和恢復的失敗，而且，沒有恢復目錄，很多RMAN的命令將不被支持。所以對于重要的數據庫，建議創建恢復目錄。

創建恢復目錄一般有以下步驟。（例子數據庫為db）

1)為目錄創建一個單獨的表空間

SQL>create tablespace tsrman datafile ’/dbbak/rman/rsrman.dbf’ size 50M;

2)創建RMAN用戶

SQL>create user rman identified by rman default tablespace rsrman temporary tablespace temp;

3)給RMAN授予權限

SQL>grant connect, resource, recovery_catalog_owner to rman;

4)打開RMAN

$rman

5)連接恢復目錄數據庫

RMAN>connect catalog rman/rman@db

6)創建恢復目錄

RMAN>create catalog tablespace tsrman 在對某個數據庫進行備份之前，必須先在恢復目錄上注冊該數據庫，這一過程操作如下（假定目標數據庫連接字符串為db100）。

1)連接到恢復目錄數據庫

$rman rman/rman@db

2)在RMAN中連接到目標數據庫（即要進行備份的數據庫）

RMAN>connect target sys/change_on_install@db100

3)注冊數據庫

RMAN>register database;

注冊完數據庫后，就可以進行數據庫的備份了。有完全數據庫備份、表空間備份、控制文件備份、和歸檔日志備份等。操作分別如下。

1)完全數據庫備份

要求：ARCHIVELOG模式，在DB OpEN的情況下進行數據庫完全備份。

RMAN>run{

allocate channel c1 type=disk;

backup database;

release channel c1;

}

2)表空間備份

要求：ARCHIVELOG模式

RMAN>run{

allocate channel c1 type=disk;

backup tablespace “ts_users” filesperset 3 format ‘aatst_%t%s.%p’;

release channel c1;

}

3)控制文件備份

RMAN>run{

allocate channel c1 type=disk;

backup current controlfile tag=weekly_sat_backup;

release channel c1;

}

在對數據庫進行完全備份時，控制文件自動包含其中。也可以在表空間或數據文件的備份中包含一個控制文件。

RMAN>run{

allocate channel c1 type=disk;

backup tablespace “ts_users”

filesperset 3 format ‘aatst_%t%s.%p’;

include current controlfile;

release channel c1;

}

4)歸檔日志備份

通過查詢數據字典表V$ARCHIVED_LOG獲取要備份的日志序列號，然后執行命令：

RMAN>run{

allocate channel c1 type=disk;

backup archivelog low logseq 3 high logseq 10 thread 1;

release channel c1;

}

Oracle的備份策略

正確的備份策略不僅能保證數據庫服務器的24*7的高性能的運行，還能保證備份與恢復的快速性與可靠性。我們將以RMAN的多級增量備份作為一個備份策略的例子來討論。采用多級備份就是為了減少每天備份所需要的時間，而又保證系統有良好的恢復性?；謴蜁r間與備份時間要有一個權衡。比如只要進行一個數據庫的全備份，然后就只備份歸檔也可以保證能把數據庫恢復到最新的狀態，但是這樣的恢復時間將是不可容忍的。多級備份也正是為了解決這種問題，結合某些應用的特點，可以采用如下的備份策略：

每個月做一個數據庫的全備份（包括所有的數據和只讀表空間）；

每個星期一做一次零級備份（不包含只讀表空間）；

每個星期三做一次一級備份；

每天做一次二級備份。

每天做一次恢復目錄的熱備份。

任何數據庫的更改需要重新同步CATALOG目錄并重新備份（如添加數據文件）或重新備份（如修改表空間為只讀）。

每次備份后都可以備份歸檔日志或定期備份歸檔日志。如果可能，可以直接備份到磁帶上。

Oracle的恢復

下面的操作約定恢復目錄存儲在db118中，目標數據庫是db100。

1.數據庫恢復

1)啟動SQL*pLUS，使用正確的init.ora文件，使用NOMOUNT選項啟動目標數據庫實例。

2)啟動RMAN并連接到恢復目錄，如下：

$rman catalog rman/rman@db118

恢復管理器: Release 9.2.0.1.0production

Copyright(c)1995, 2002, Oracle Corporation.All rights reserved.連接到恢復目錄數據庫

RMAN>

3)連接到目標數據庫

RMAN>connect target internal/oracle@demo.oracle

連接到目標數據庫: db(DBID=1142471523)

4)一旦連接到目標數據庫，執行restore命令恢復控制文件

RMAN>run{

2>allocate channel c1 type disk;

3>restore controlfile;

4>}

小結

保證Oracle數據庫的安全是系統安全的重要組成部分，必須要設計完善的數據庫備份和恢復方案。Oracle提供的各種工具結合起來使用能夠使數據庫的備份和恢復變得簡單。在實際的Oracle數據庫的備份和恢復中，會有許多不通的和復雜的情況出現，針對不同的情況，要本著使數據具有最大的可恢復性和恢復時間最短的原則去進行數據庫的恢復，這需要大量的實踐和經驗積累。

參考文獻

[1] Oracle8i Backup and Recovery Guide Oracle Document

[2] Oracle8i Recovery Manager User’s Guide and Reference Oracle Document

[3] Oracle9i：A Beginner’s Guide(美)Michael Abbey Michael Corey Ian Abramson 2002.3 機械工業出版社

[4] Oracle8i備份與恢復手冊(美)Rama Velpuri Anand Adkoli 蔣蕊 王磊等譯 2001.9 機械工業出版社

第五篇：數據備份和恢復管理規范

數據備份和恢復管理規范

第一章 總 則

第一條 為規范、統一全集團范圍內重要系統的數據備份及管理工作，明確各系統數據備份及恢復的角色和職責，確保備份介質的安全和按時、順利恢復系統和數據，并確保有關責任人員熟練掌握系統和數據的備份、歸檔和恢復流程，特制定本辦法。

第二條 備份和恢復管理的范圍包括：確定關鍵系統的備份和恢復方針及原則；系統、應用等軟件及業務、配置等數據的備份和恢復；備份介質的存放、歸檔管理；系統及數據恢復演練；備份和恢復流程的評估和維護；歸檔數據的查詢；備份和恢復所需存儲、磁帶庫等硬件工具/設備的監控和管理。不包括：硬件、網絡的備份和恢復（屬于業務連續性管理）；業務系統的在線數據冗余（屬于業務可用性管理）。

第三條 關鍵系統定義： ERP、研發、SCM、CRM、財務、HR和其他多個單位通用的業務系統；MIP、郵件、公共網站等IT基礎應用系統；單個單位使用的核心業務系統。

第四條 集團數據備份和恢復工作由集團備份管理員負責組織、協調，并按照既定計劃和策略督促相關人員執行。

第二章 數據備份、歸檔和恢復原則

第五條 備份和恢復時間、性能應符合各系統服務級別的規定，各系統服務級別由系統所在單位與系統主要使用部門商議。

第六條 應考慮主機系統（操作系統、工具軟件、數據庫系統軟件、應用等）變化的頻率，全備份的頻率應與業務系統變化頻率成正比。

第七條 當主機系統發生較大更改時，應馬上對主機系統進行一次全備份。第八條 應考慮全備份的容量，全備份的頻率應與其備份容量成反比。第九條 系統全備份方式適用于使用小型機設備的系統，使用PC服務器的系統建議采用克隆系統應急盤方式。

第十條 對應用軟件等程序文件：當系統配置數據發生變動時，應馬上備份，備份介質保留至下一次系統全備份。當生產環境中的應用軟件將發生變動時，應對變動前的應用軟件進行備份。該種情況下的備份一般情況下由各系統管理員自行準備資源完成。

第十一條 對Oracle等數據庫進行在線備份的系統，原則上要求周日為0級備份（冷備份）。對有數據長期保留需求的系統，只進行系統的0級備份的歸檔，以確保數據有效性和可恢復性。

第十二條 歸檔數據一般包括程序文件、數據文件，一般不包括數據庫歸檔日志、邏輯備份數據（如在線備份）。

第十三條 歸檔數據完整性的基本原則：進行數據恢復后，系統在簡單配置后可直接使用。

第十四條 對業務數據備份：在網絡帶寬和存儲設備允許的前提下，可以采用集中備份和恢復管理的方式，否則采用分布備份和恢復管理方式。在數據庫故障時能夠快速恢復數據是選擇備份方式的一個重要因素。應該采用多種備份方式（如采用塊方式和文本方式等），以保證除了使用備份系統進行恢復外，還可以在本地備份機上直接恢復應用，如特別關鍵應用，建議考慮增加異地的恢復方式。除了用于恢復外，備份介質還應該方便存檔數據查詢、恢復演練、新系統測試、審計檢查等使用。重點保留月末、季末、年末、結息日、新系統切換等重點時間的數據。

第十五條 對Oracle數據庫備份：為了保護最近產生的數據，必須連續備份數據庫邏輯日志。在業務數據的兩次連續0級備份之間，應該進行業務數據邏輯日志的備份。

第十六條 應該根據數據容量/備份持續時間來決定采用每日0級備份，或定期0級備份+每日增量備份方式（增量備份分為對上次0級備份的增量、對上次增量的增量兩種）。如果每日0級備份的備份和恢復時間符合要求，建議采用每日0級備份方式；否則采用每周0級備份+每日增量備份方式。備份介質保留一個備份周期。

第十七條 區別維持關鍵業務運行的數據（如，僅僅包含賬戶數據、客戶信息、交易數據，不含歷史數據），并每日單獨備份，剩余數據同樣單獨備份。考慮到是快速恢復數據，故該類數據不宜過大。另外考慮到其使用目標是僅僅是應急，故其備份介質都是短期保留。

第十八條 要使用腳本來進行備份和恢復，盡量避免手工操作；盡量安排在非工作時間備份。

第十九條 在備份和恢復操作流程發生變動時，應該對操作人員進行培訓；進行恢復演練的頻率與流程變化的頻率成正比；進行實際恢復演練的頻率與恢復失敗的頻率（考核指標之一）成正比。

第二十條 所有對生產系統和數據的恢復都要預先得到批準；對存檔備份介質的調閱需要登記，并且只能拷貝不能外借。

第二十一條 所有的備份介質都要貼上清晰的標簽，標簽應包含介質編號（或序號）、備份內容、備份日期時間、備份人員等內容；數據備份在制作、傳遞、轉移過程中，必須填寫《數據備份登記表》或《數據轉移保存登記表》，詳細記錄備份數據制作、傳遞、轉移的全部過程與責任人；數據備份的存放處必須符合防火、防水、防磁的安全要求；保存期在一年以上的備份磁帶應半年進行重寫或重繞處理；長期保存的磁帶應記錄使用次數，保證介質在規定的次數內使用；歸檔數據備份介質應該實施異地存放，建議存放至銀行保險箱或檔案室（必須和主機房不在同一建筑物內，如分支機構辦公場所）。

第三章 存儲、備份設備及相關設備管理

第二十二條 存儲設備：集團中央數據存儲系統、集團中央備份存儲系統；備份管理員負責：每天檢查存儲設備控制器產生的信息，每周至少一次現場檢查存儲設備及相關部件運行狀況，并將檢查記錄包含在周報中；存儲設備Lun的調整和新Lun的分配，磁盤Raid策略調整等資源使用管理；

第二十三條 備份設備：STK SL500磁帶庫、LTO3數據磁帶、LTO3清洗帶；磁帶庫設備要求制定驅動器自動清洗策略，備份管理員負責：定期檢查策略執行執行是否正常，每周至少一次現場檢查磁帶庫及相關部件運行狀況，并將檢查記錄包含在周報中；根據備份策略或用戶需求調整，及時調整磁帶庫設備的資源分配。

第二十四條 相關設備：光纖通道交換機及光纖通道接口等部件、主機HBA卡；備份管理員負責：每周至少一次現場檢查光纖通道交換機及相關部件運行情況，并將檢查記錄包含在周報中；每月協助系統管理員對主機HBA卡運行情況進行檢查，包括雙通道、負載均衡功能是否正常以及操作系統是否出現類似光纖通道報警信息；交換機Zooning調整、劃分及相關資源調配。

第二十五條 備份管理員負責以上設備的日常維護和故障報修。維護和報修流程見本規范第二十九條第2款。

第四章 備份和恢復相關人員職責

第二十六條 集團備份管理員由集團IT管理部任命和管理；二級備份管理員由二級管理平臺IT部門任命和管理，在備份業務上配合集團備份管理員。增加二級備份管理員的調整須提前知會集團IT管理部。系統管理責任人由系統所在平臺的IT部門確定，業務管理責任人由系統所在平臺的關鍵業務部門確定。

第二十七條 集團備份管理員職責：作為集團數據備份和恢復工作的總體計劃制

定和工作協調者，負責備份系統管理和日常維護；負責備份數據在磁帶、光盤等可移動存儲介質上克隆、遷移和本地存放；參與備份系統建設、改造項目；協助二級備份管理員和各系統管理員進行數據覆蓋和災難恢復工作；定期組織二級備份管理員及相關人員進行備份數據有效性驗證；負責組織集團本部相關系統管理員進行備份數據的有效性驗證工作；負責備份系統客戶端程序的異常處理，但不含客戶端程序的管理；有義務和責任對系統管理員制定的備份策略提出合理建議；根據各系統恢復演練要求，制定總體恢復演練工作計劃。

第二十八條 二級備份管理員職責：作為二級平臺及下屬單位數據備份和恢復工作詳細計劃的制定和協調者，協助備份管理員維護工作；組織相關系統管理員進行備份系統客戶端的日常維護；協助備份管理員定期組織相關人員進行備份數據的有效性驗證；參與備份系統建設、改造項目；負責平臺管理范圍內系統進行數據覆蓋和協助集團備份管理員完成災難恢復工作；負責制定該平臺及下屬單位的系統恢復演練詳細計劃，并負責該平臺及下屬單位數據從備份系統的導出。

第二十九條 系統技術管理責任人職責：簡稱系統管理員。是系統管理責任部門指定的系統日常維護人員，作為數據備份策略的制定者和恢復工作的實際執行者，按照《備份系統維護指引》要求，負責對備份系統客戶端的維護；根據業務系統數據安全需求，負責制定合理、有效的備份策略(系統管理員只能負責提出策略和有效性審核，策略的合理性應由集團備份管理員完成)；在集團備份管理員或二級備份管理員的協助下，負責進行責任系統的備份數據有效性驗證；根據災難演練計劃，建立系統詳細恢復操作文檔，并負責具體系統的搭建、恢復工作，同時負責組織相關人員對恢復系統的有效性進行測試并提交相關報告。（各個應用系統需要確定主要維護責任部門，由責任部門提出對系統的維護要求和指標）

第三十條 系統業務管理責任人職責：作為數據備份和恢復工作的用戶方或負責業務維護的項目組，負責確認系統數據備份和恢復的時間、性能等指標。ERP、SCM、CRM等類系統業務責任部門為系統所在單位財務部門，研發類系統業務責任部門為系統所在單位研發部門，集團HR系統業務責任部門為集團人力資源部，MIP、郵件等基礎應用系統業務責任部門為集團IT部。其他系統由系統管理的責任單位IT部門確定系統業務責任部門。

第五章 運維管理流程

第三十一條 數據備份異常的預警機制：對于連續兩次備份失敗的系統，集團備份管理員應以郵件、短信或電話方式知會二級備份管理員或相關系統管理員及該管理平臺IT部門負責人，系統管理員應積極采取相關措施，二級備份管理員及集團備份管理員應配合，確保當天晚上數據備份成功，連續三次備份失敗，集團備份管理員應將該信息抄送至系統責任單位財務負責人、集團IT總監。

第三十二條 系統日常維護流程：備份系統的服務器端操作，由備份管理員負責，客戶端操作由相關責任人負責，備份管理員協助完成。

1.備份情況通報流程：集團備份管理員每天上午10點前將前一天晚上數據備份情況在MIP上公布（周六備份情況在周一通報），每周備份管理員將一周備份情況進行總結并發布至MIP，內容包括但不限于：本周備份數據量、備份有效性總結、故障處理情況；每月進行一次系統運行情況總結，上報至基礎管理中心高級經理，內容包括但不限于：本月備份有效性情況、故障處理匯總及分析、系統運行趨勢分析及系統改進合理化建議等。對于備份失敗的系統，以郵件、短信或電話方式通知二級備份管理員及其上級領導并給出初步診斷結果和建議操作；二級備份管理員應立即聯系相關系統管理員，系統管理員應在當天配合備份管理員查找問題。若數據連續兩天沒有備份成功，第三天需要系統管理員與備份管理員一起確定系統的備份方式，若為數據庫的在線備份失敗，應采取冷備份，若因數據庫沒有正確啟停，需系統管理員在策略中約定的時間手工啟停數據庫，保證當晚數據備份成功。如二級備份管理員及系統管理員對備份失敗問題一天內查不出原因，集團備份管理員應協調相關資源協助處理。

2.備份系統日程運維管理流程：包括備份系統及相關設備日常檢查及故障處理。備份管理員每天對備份系統軟件日志進行查看，如系統出現的報警或故障信息，當天反饋至技術后臺支持經理，如超過2天不能解決，應上報至基礎運維管理中心高級經理，并聯系相關外部技術支持人員。如超過4天不能解決，應上報至集團IT總監。3.備份和恢復策略初次申請流程：由系統管理員提出備份和恢復策略并填寫《備份和恢復需求》、《系統備份信息表》、《備份和恢復策略和原則》，系統業務責任人對《備份和恢復需求》進行確認，二級平臺備份管理員審查，集團備份管理員審核，并在備份系統中實施，備份管理員直屬領導及基礎運維管理中心負責人備案。

4.備份和恢復策略變更流程：由系統管理員提出變更后的備份和恢復策略并填寫《備份和恢復需求》、《系統備份信息表》、《備份和恢復策略和原則》，系統業務責任人對《備份和恢復需求》進行確認，二級平臺備份管理員審查，集團備份管理員審核，并在備份系統中實施，備份管理員直屬領導及基礎運維管理中心負責人備案。5.備份數據常規恢復流程：常規恢復指數據的測試環境覆蓋、恢復演練等要求下進行數據恢復。不允許在凌晨進行數據恢復，如需進行數據，需要以郵件方式發送請求至集團備份管理員，由備份管理員安排恢復時間和協助恢復。如系統管理員自行恢復，導致正常備份工作受到影響，將追究相關管理員責任。

6.系統和數據災難恢復流程：系統管理員提交系統和數據恢復申請，系統管理員直屬領導進行審核，系統業務責任部門審批，根據系統故障類型，二級備份管理員或集團備份管理員準備恢復的介質，系統管理員進行系統和數據恢復，系統業務責任人對恢復數據正確性進行驗證，確認恢復成功后，由系統管理部門對外發出《系統恢復通知》。

7.日常備份和歸檔管理流程：集團備份管理員進行日常備份和歸檔，提交《備份介質存放登記表》，并在MIP上發布當日備份信息，備份管理員直屬領導對歸檔進行審核和數據抽查，基礎運維管理中心負責人備案。

8.備份介質存放管理流程：集團備份管理員對歸檔的備份介質（目前為磁帶）進行異地存放，并填寫《數據轉移保存登記表》，備份管理員直屬領導審查，基礎運維管理中心負責人備案。

第三十三條 系統和數據恢復演練流程：包括所有非災難恢復性質的數據恢復流程。集團或二級平臺備份管理員提交《系統和數據恢復演練計劃》，同時準備好演練的環境和介質，系統管理員將系統和數據恢復至預定位置，并進行系統和數據恢復結果進行驗證，并填寫《系統和數據恢復演練反饋表》。

第三十四條 存檔數據查詢流程：由存檔數據查詢人提交《存檔數據查詢申請表》，系統業務責任人審核，系統管理員準備恢復所需硬件、軟件等資源，二級備份管理員或集團備份管理員準備恢復環境和備份介質，系統管理員進行數據恢復對恢復系統和數據進行可用性確認，系統業務責任人對恢復系統和數據進行正確性驗證，并通知查詢人進行數據查詢。

第六章 懲罰措施

第三十五條 如集團備份管理員已通知相關系統管理員備份失敗信息，而系統管理員沒有及時處理，導致兩次以上的數據備份失敗情況發生，系統管理員應承擔數據安全管理不善責任，并在MIP上通報批評，如造成數據丟失等嚴重后果，按照相關單位規定進行處罰。

第三十六條 因集團備份管理員維護不到位，出現同一套系統數據備份失敗情況，且沒有及時知會相關系統管理員進行應急處理，導致系統備份失敗情況連續發生三天以上（含三天），集團備份管理員將承擔系統管理不善責任，并在MIP上通報批評，如由此造成的數據丟失或其他嚴重后果，按照集團相關規定進行處罰。連續三個月未出現因備份管理員維護不力而出現備份異常情況，由集團IT管理部給予××獎勵。

第三十七條 因相關系統管理員未及時處理，而導致連續三天以上備份失敗（含三天），系統管理員承擔系統維護不善的責任，并在MIP上通報批評，如因此造成的數據丟失或其他嚴重后果，按系統管理員所在單位相關規定進行處罰。

第三十八條 如無特殊原因，連續三個月內都未組織二級備份管理員及相關系統管理員進行系統災難恢復演練工作，集團備份管理員應承擔系統維護不力責任，并在MIP上通報批評。

第三十九條 二級備份管理員不配合集團備份管理員組織系統災難恢復演練工作，導致演練工作無法開展，將追究相關責任人責任并在MIP上通報批評。

第四十條 相關系統管理員不服從備份管理員組織，連續三個月內都未進行系統災難恢復演練工作，將追究相關責任人責任并在MIP上通報批評，因此出現備份數據恢復無效而導致數據丟失情況，由系統管理員及所在部門責任人承擔數據安全的全部責任。

第四十一條 本《規范》由集團IT管理部負責修改和解釋。第四十二條 此規范自下發之日起執行。

2006年4月9日