- 哦，沒有任何避難所能夠承受隕石的撞擊。 但你和其他人一樣，都有儲備，所以你不必擔心。
斯坦尼斯拉夫·萊姆《安靜的伊瓊的明星日記》
備份是指將資料副本保存在其主儲存位置之外的某個位置。
備份的主要目的是在資料遺失後恢復資料。 在這方面，您經常聽說如果您有資料庫副本，則可以隨時從中恢復數據，並且不需要備份。 事實上，備份至少可以解決三個使用副本無法解決的問題，如果沒有備份副本，副本就無法初始化。
首先，備份允許您在發生邏輯錯誤後還原資料。 例如，會計師刪除了一組事務或資料庫管理員破壞了表空間。 從資料庫的角度來看，這兩個操作都是完全合法的，並且複製過程將在副本資料庫中重現它們。
其次，現代資料庫管理系統是非常可靠的軟體系統，但內部資料庫結構偶爾會損壞，之後資料存取就會遺失。 尤其令人反感的是，這種違規行為通常發生在高負載或安裝某種更新時。 但高負載和定期更新都表明該資料庫絕不是測試資料庫，其中儲存的資料是有價值的。
最後，第三個任務（其解決方案需要備份副本）是資料庫克隆，例如用於測試目的。
資料庫備份是基於以下兩個原則之一的一種或另一種方式：
- 資料採樣並隨後以自訂格式儲存；
- 資料庫檔案的快照和保存日誌。
讓我們仔細看看這些原則以及實現它們的工具。
上傳數據
任何 DBMS 隨附的實用程式集都必須包含用於上傳和載入資料的工具。 資料以文字格式或特定於特定 DBMS 的二進位格式儲存。 下表提供了此類工具的清單：
二進位格式
文字格式
神諭
數據泵導出/數據泵導入
導出/導入
SQL*Plus/SQL*載入器
PostgreSQL的
pg_dump、pg_dumpall/pg_restore
pg_dump、pg_dumpall/psql
微軟SQL Server
BCP
BCP
DB2
卸載/裝載
卸載/裝載
MySQL的
mysqldump、mysqlpump/mysql、mysqlimport
MongoDB的
mongodump/mongorestore
蒙戈出口/蒙戈進口
卡桑德拉
節點工具快照/sstableloader
cqlsh
文字格式的好處是它可以由外部程式編輯甚至創建，而二進位格式則很好，因為它可以透過節省格式轉換資源來更快地上傳和下載資料。
儘管下載資料的想法簡單明了，但這種方法很少用於備份載入的工業資料庫。 以下是卸載不適合完整備份的原因：
- 卸載過程會對來源系統造成很大的負載；
- 卸載需要花費大量時間——當卸載完成時，它將不再相關；
- 在高負載下執行整個資料庫的協調卸載幾乎是不可能的，因為 DBMS 被迫在卸載開始時儲存其狀態的快照。 自上傳開始以來完成的交易越多，快照的大小就越大（PostgreSQL中的不相關資料副本、Oracle中的undo空間、Microsoft SQL Server中的tempdb等）；
- 卸載保留了資料的邏輯結構，但不保留其實體結構—表、索引等實體儲存的參數。
不過，上傳也有其優點：
- 高選擇性：您可以下載單一表格、單一欄位甚至單一行；
- 下載的資料可以載入到另一個版本的資料庫中，如果以文字格式下載，則載入到另一個資料庫。
因此，上傳主要用於備份小表（例如目錄）或隨下一個應用程式版本分發資料集等任務。
資料庫備份最常見的方法是複製資料庫檔案。
資料庫檔案的冷存儲
顯而易見的想法是停止資料庫並複製其所有文件。 此備份稱為“冷”備份。 此方法極為可靠且簡單，但有兩個明顯的缺點：
- 從「冷」備份中，您只能還原資料庫關閉時的狀態； 資料庫重新啟動後進行的交易將不會包含在「冷」備份副本中；
- 並非每個資料庫都有可以停止資料庫的技術視窗。
如果「冷」備份適合您，您需要記住這一點
- 冷拷貝有時必須包括日誌。 對於每個 DBMS，確定應進入「冷」副本的日誌的方法是不同的。 例如，在Oracle中，即使資料庫正確停止，也需要複製所謂的線上重做，也就是在特殊目錄中複製固定數量的日誌檔案。 在 PostgreSQL 中，您必須保存從包含最後一個檢查點的日誌開始的所有日誌，有關該檢查點的資訊包含在控制檔中。
- 資料庫目錄可能包含臨時表空間文件，這些文件足夠大，不需要包含在備份中。 順便說一句，這句話對於熱備份來說也是如此。
熱文件保存
大多數現代資料庫備份是透過在不停止資料庫的情況下複製資料庫檔案來執行的。 這裡有幾個問題：
- 當複製開始時，資料庫的內容可能與檔案的內容不一致，因為某些資訊位於快取中且尚未寫入磁碟。
- 在複製過程中，資料庫的內容可能會發生變化。 如果使用可變資料結構，文件的內容會發生變化，而當使用不可變結構時，文件集會發生變化：新文件出現，舊文件被刪除。
- 由於向資料庫寫入資料和讀取資料庫檔案不以任何方式同步，因此備份程式可能會讀取錯誤的頁面，其中一半來自舊版本的頁面，另一半來自新版本的頁面。
為了讓備份保持一致，每個 DBMS 都有一個命令來通知備份過程已經開始。 從語法上講，此命令可能看起來有所不同：
- 在 Oracle 中，這是一個單獨的指令 ALTER DATABASE/TABLESPACE BEGIN BACKUP；
- 在 PostgreSQL 中 – 函式 pg_start_backup();
- 在 Microsoft SQL Server 和 DB2 中，備份準備工作是在執行 BACKUP DATABASE 指令期間隱含執行的；
- 在 MySQL Enterprise、Cassandra 和 MongoDB 中，準備工作分別由外部公用程式 mysqlbackup、OpsCenter 和 Ops Manager 隱含執行。
儘管語法上存在差異，但準備備份的過程看起來是相同的。
這就是具有可變磁碟結構的 DBMS（即所有傳統磁碟關係系統）中備份準備工作的情況：
- 備份開始的那一刻就會被記住； 從此時起，備份將需要包含資料庫日誌。
- 執行檢查點，即將記住的時刻之前資料頁中發生的所有變更都刷新到磁碟。 這可確保在復原期間備份開始之前不需要任何日誌。
- 啟用一種特殊的日誌記錄模式：如果資料頁在從磁碟加載後第一次發生更改，則資料庫不會將頁面更改寫入日誌，而是將整個頁寫入其中。 執行準備過程時，所有頁面都會刷新到磁碟，因此第一次進行更改時，整個區塊將始終寫入日誌。 但是，如果在備份過程中該頁面再次被逐出到磁碟，則對其進行下一次更改也會導致該頁面的完整副本出現在日誌中。 這確保瞭如果複製資料檔案時頁面不正確，應用程式日誌將使其再次正確。
- 資料檔案頭的變更會被阻止，即其變更不會反映在日誌中的部分。 這可確保正確複製標頭，然後將日誌正確套用到資料檔案。
完成上述所有過程後，您可以使用作業系統工具 - cp、rsync 等複製資料檔案。 啟用備份模式會降低資料庫的效能：一是日誌量增加，二是如果備份模式突然故障，由於資料檔案頭沒有更新，復原時間會更長。 備份完成得越快，對資料庫越好，因此使用檔案系統快照或磁碟陣列中的打破鏡像（BCV）等工具比較合適。 一些 DBMS（Oracle、PostgreSQL）讓管理員有機會獨立選擇複製方法，其他 DBMS（Microsoft SQL Server）則提供一個接口，用於將自己的備份實用程式與檔案系統或儲存機制整合。
備份完成後，您需要將資料庫還原到正常狀態。 在 Oracle 中，這是透過 ALTER DATABASE/TABLESPACE END BACKUP 命令完成的，在 PostgreSQL 中是透過呼叫 pg_stop_backup() 函數來完成的，在其他資料庫中是透過對應命令或外部服務的內部例程來完成的。
備份過程時間表如下圖所示：
- 準備備份需要時間，有時需要相當長的時間。 即使使用鏡像磁碟區或支援快照的檔案系統，備份過程也不會是即時的。
- 與資料檔案一起，從開始準備備份到資料庫恢復正常狀態期間，都需要保存日誌。
- 您可以從此備份還原 當底座恢復正常狀態時。 恢復到較早的點是不可能的。
對於使用不可變資料結構（記憶體快照、LSM 樹）的資料庫，情況更簡單。 準備備份包括以下步驟：
- 記憶體中的資料被刷新到磁碟。
- 記錄備份副本中包含的文件清單。 在備份過程完成之前，資料庫禁止刪除這些文件，即使不再需要它們。
當發出備份完成的訊號時，具有不可變結構的資料庫可以再次刪除不必要的檔案。
恢復到點
備份副本可讓您將資料庫的狀態還原到從備份模式傳回指令完成時的狀態。 然而，需要恢復的事故隨時都可能發生。 在任何時刻恢復資料庫狀態的任務稱為「時間點復原」。
為了確保這是可能的，您應該從備份結束時開始保存資料庫日誌，並在復原過程中繼續將日誌套用到復原的副本。 在複製完成時從備份副本恢復資料庫後，資料庫的狀態（檔案和快取頁）保證是正確的，因此不需要特殊的日誌記錄模式。 透過在正確的時刻套用日誌，您可以及時取得資料庫在任何時間點的狀態。
雖然恢復備份的速度僅受磁碟頻寬的限制，但應用程式日誌的速度通常受處理器效能的限制。 如果變更在主資料庫中並行發生，則在復原期間，所有變更都會依序執行 - 依照從日誌中讀取的順序。 因此，復原時間線性取決於復原點距備份終點的距離。 因此，有必要經常進行完整備份 - 對於交易負載較小的資料庫至少每週一次，對於高負載資料庫則最多每天進行一次備份。
增量備份
為了加快復原速度，我希望能夠盡可能頻繁地執行備份，但同時不佔用額外的磁碟空間，也不用備份任務載入資料庫。
解決該問題的方法是增量備份，即只複製那些自上次備份以來發生變化的資料頁。
增量備份僅對使用可變資料結構的 DBMS 有意義。
增量可以從完整備份（累積副本）或任何先前的副本（差異副本）中計算。
不幸的是，沒有統一的術語，不同的製造商使用不同的術語：
微分
累計
神諭
高頻差動式測試棒
累積的
PostgreSQL
增量
微軟SQL Server
高頻差動式測試棒
IBM DB2
三角洲
增量
如果存在增量副本，恢復到一點的過程如下：
- 恢復之前所做的最後一次完整備份；
- 增量副本在完整副本之上恢復；
- 日誌從備份起始點匯總到復原點。
擁有累積副本可以加快恢復過程。 所以，例如要將資料庫的狀態恢復到T3和T4之間的某個點，就需要恢復兩個增量副本，而恢復到T4之後的某個點，則只需恢復一個。
顯然，一個累積副本的大小小於多個差異副本的大小，因為某些頁面已更改多次，並且每個增量副本都包含該頁面的不同版本。
建立增量副本有以下三種方式：
- 建立完整副本並計算與先前完整副本的差異；
- 解析日誌，建立已更改頁面的清單並備份清單中包含的頁面；
- 查詢資料庫中更改的頁面。
第一種方法雖然節省了磁碟空間，但並不能減輕資料庫的負載。此外，如果已經有了完整備份，將其轉換為增量備份就毫無意義，因為恢復完整備份比恢復先前的完整備份和增量備份都要快。因此，最好將節省磁碟空間的任務委託給具有內建重複資料刪除機制的專用元件。這些元件可以是專用儲存系統（例如 EMC DataDomain、HPE StorageWorks VLS 和整個 NetApp 產品線），也可以是軟體產品（例如 ZFS、Veritas NetBackup PureFile 等）。 Windows Server 數據去重）。
第二種和第三種方法的差異在於確定已更改頁面清單的機制。 解析日誌更加耗費資源，而且要實現它，您需要了解日誌檔案的結構。 最簡單的方法是詢問資料庫本身哪些頁面已更改，但為此 DBMS 核心必須具有區塊更改追蹤功能。
增量備份功能首先在 Oracle Recovery Manager (RMAN) 軟體中引入，並在 Oracle 8i 版本中引入。 Oracle立即實現了對更改區塊的跟踪，因此無需解析日誌。
PostgreSQL 不追蹤修改的區塊，因此由俄羅斯公司 Postgres Professional 開發的 pg_probackup 實用程式透過分析日誌來確定修改的頁面。 不過，該公司還提供 PostgresPro DBMS，其中包括追蹤頁面更改的 ptrack 擴充功能。 當 pg_probackup 與 PostgresPro DBMS 一起使用時，該實用程式會從資料庫本身請求更改的頁面 - 與 RMAN 完全相同。
Microsoft SQL Server 與 Oracle 一樣，會追蹤變更的頁面，但 BACKUP 指令只允許您進行完整備份和累積備份。
DB2 具有追蹤更改頁的能力，但預設情況下它是禁用的。 一旦啟用，DB2 將允許完整備份、差異備份和累積備份。
本節中描述的工具（pg_probackup 除外）和檔案備份工具之間的一個重要區別是它們從資料庫請求頁面映像，而不是從磁碟本身讀取資料。 這種方法的缺點是底座上的額外負載較小。 然而，頁面讀取始終正確這一事實足以彌補這一缺點，因此無需在備份期間啟用特殊的日誌記錄模式。
請再次注意，增量副本的存在並不能消除將日誌還原到任意時間點的要求。 因此，在工業資料庫中，日誌不斷地被重寫到外部介質，並按計劃建立完整和/或增量備份。
目前增量備份概念的最佳實作是零資料遺失復原設備 (Zero Data Loss Recovery Appliance)，它是一個軟硬體系統（用 Oracle 的術語來說，是一個工程化系統）－Oracle 專門用於備份自身資料庫的解決方案。該系統是一個集群。 服務器 ZDLRA 擁有大容量磁碟，並執行修改版的 Recovery Manager 軟體。它不僅可以與 Oracle 的其他硬體和軟體系統（例如資料庫一體機、Exadata、SPARC 超級叢集）配合使用，還可以與運行在傳統基礎架構上的 Oracle 資料庫協同工作。與「常規」RMAN 不同，ZDLRA 實現了「永久增量備份」的概念。系統只需建立一次完整的資料庫副本，之後僅建立增量副本。此外，還可以使用 RMAN 模組合併副本，從而從增量副本建立新的完整副本。
值得俄羅斯開發者稱讚的是，應該注意的是 pg_probackup 還可以合併增量副本。
與許多類似的問題不同，「哪種備份方法更好」這個問題有一個明確的答案 - 最好的選擇是所使用的 DBMS 本身的實用程序，它提供增量備份的能力。
對於資料庫管理員來說，更重要的是選擇備份策略並將資料庫備份工具整合到企業基礎架構中的問題。 但這些問題超出了本文的範圍。
來源： www.habr.com
