PostgreSQL備份與恢復

PostgreSQL備份與恢復

官方文檔（英文）：http://www.postgresql.org/docs/9.4/static/backup.html

官方文檔（中文）：http://58.58.27.50:8079/doc/html/9.3.1_zh/backup.html

邏輯備份：

1.SQL轉儲（pg_dump,pg_dumpall）

  SQL轉儲不包括索引，能夠自定義要備份的對象及其內容，將備分內容生成不一樣的格式。能夠經過pg_restore還原備份。

  是pg_dump的輸出一般能夠從新載入到PostgreSQL新版本， 然而文件級別備份和連續歸檔都限於原服務器版本。pg_dump是將數據庫傳輸到另外一臺機器體系結構工做時惟一的方法， 如從32位變到64位服務器。

  由pg_dump建立的備份在內部是一致的， 也就是說，pg_dump轉儲的pg_dump開始運行時的數據庫快照。pg_dump工做的時候並不阻塞其它的對數據庫的操做 (可是會阻塞那些須要排它鎖的操做，好比多數形式的ALTER TABLE)。

Important: 若是你的數據庫結構依賴於OID(好比說用作外鍵)， 那麼你必須告訴pg_dump把OID也導出來。要導出OID， 可使用-o命令行選項。 

物理備份：

1.文件系統備份

    文件系統級別備份，就是直接copy數據庫目錄，必須關閉服務，這沒法在提供24小時不間斷服務的Web上應用。

    須要注意的是文件系統備份每每比SQL轉儲大。 好比pg_dump不用導出索引， 只是建立它們的命令。然而，文件系統備份也可能會更快。

2.連續歸檔和基於時間點恢復PITR(Point In Time Recovery)

  基於時間點恢復可參考：http://my.oschina.net/Kenyon/blog/58112 

     在任什麼時候候，PostgreSQL都在集羣的數據目錄的pg_xlog/ 子目錄裏維護着一套預寫日誌(WAL)。 這些日誌記錄着每一次對數據庫的修改細節。這些日誌存在是爲了防止崩潰： 若是系統崩潰，數據庫能夠經過"重放"上次檢查點以來的日誌記錄以恢復數據庫的完整性。可是，日誌的存在讓它還能夠用於第三種備份數據庫的策略： 咱們能夠組合文件系統備份與WAL文件的備份。若是須要恢復，咱們就恢復備份，而後重放備份了的WAL文件，把備份恢復到當前的時間。這個方法對管理員來講，明顯比之前的方法更復雜，可是有很是明顯的優點：

• 在開始的時候咱們不須要一個很是完美的一致的備份。 任何備分內部的不一致都會被日誌重放動做修改正確 (這個和崩潰恢復時發生的事情沒什麼區別)。所以咱們不須要文件系統快照的功能， 只須要tar或者相似的歸檔工具。

• 由於咱們能夠把無限長的WAL文件序列鏈接起來， 因此連續的備份簡化爲連續地對WAL文件歸檔來實現。 這個功能對大數據庫特別有用，由於大數據庫的全備份可能並不方便。

• 咱們可沒說重放WAL記錄的時候咱們必須重放到結尾。咱們能夠在任意點中止重放，這樣就有一個在任意時間的數據庫一致的快照。所以，這個技術支持即時恢復： 咱們能夠把數據庫恢復到你開始備份以來的任意時刻的狀態。

• 若是咱們持續把WAL文件序列填充給其它裝載了一樣的基礎備份文件的機器， 咱們就有了一套熱備份系統：在任何點咱們均可以啓動第二臺機器， 而它擁有近乎當前的數據庫拷貝。

Note: pg_dump和 pg_dumpall沒有產生文件系統級別備份，而且不能做爲 連續歸檔解決方案的一部分。好比備份是符合邏輯的而且不包含 WAL重放使用的足夠信息。