數據庫PostrageSQL-文件系統級別備份

25.2. 文件系統級別備份

另一種備份策略是直接複製PostgreSQL用於存儲數據庫中數據的文件，Section 18.2解釋了這些文件的位置。你能夠採用任何你喜歡的方式進行文件系統備份，例如：

tar -cf backup.tar /usr/local/pgsql/data

可是這種方法有兩個限制，使得這種方法不實用，或者說至少比pg_dump方法差：

1. 爲了獲得一個可用的備份，數據庫服務器必須被關閉。例如阻止全部鏈接的半路措施是不起做用的（部分緣由是tar和相似工具沒法獲得文件系統狀態的一個原子的快照，還有服務器內部緩衝的緣由）。關於中止服務器的信息能夠在Section 18.5中找到。不用說，在恢復數據以前你也須要關閉服務器。
2. 若是你已經深刻地瞭解了數據庫的文件系統佈局的細節，你可能會有興趣嘗試經過相應的文件或目錄來備份或恢復特定的表或數據庫。這種方法也不會起做用，由於包含在這些文件中的信息只有配合提交日誌文件（pg_xact/*）纔有用，提交日誌文件包含了全部事務的提交狀態。一個表文件只有和這些信息一塊兒纔有用。固然也不可能只恢復一個表及相關的pg_xact數據，由於這會致使數據庫集簇中全部其餘表變得無用。所以文件系統備份值適合於完整地備份或恢復整個數據庫集簇。

另外一種文件系統備份方法是建立一個數據目錄的「一致快照」，若是文件系統支持此功能（而且你相信它的實現正確）。典型的過程是建立一個包含數據庫的卷的「凍結快照」，而後從該快照複製整個數據目錄（如上，不能是部分複製）到備份設備，最後釋放凍結快照。

即便在數據庫服務器運行時，這種方式也有效。可是，以這種方式建立的備份保存的文件看起來就像數據庫沒有被正確關閉時的狀態。所以，當你從備份數據上啓動數據庫服務器時，它會認爲上一次的服務器實例崩潰了並嘗試重放WAL日誌。這不是問題，只是須要注意（當
然WAL文件必需要包括在備份中）。你能夠在拍攝快照以前執行一次CHECKPOINT以便節省恢復時間。

若是你的數據庫跨越多個文件系統，可能沒有任何方式能夠對全部卷得到徹底同步的凍結快照。例如，若是你的數據文件和WAL日誌放置在不一樣的磁盤上，或者表空間在不一樣的文件系統中，可能沒有辦法使用快照備份，由於快照必須是同步的。在這些狀況下，必定要仔細閱讀你的文件系統文檔以瞭解其對一致快照技術的支持。

若是沒有可能得到同步快照，一種選擇是將數據庫服務器關閉足夠長的時間以創建全部的凍結快照。另外一種選擇是執行一次連續歸檔基礎備份（Section 25.3.2），由於這種備份對於備份期間發生的文件系統改變是免疫的。這要求在備份過程當中容許連續歸檔，恢復時使用連續歸檔恢復（Section 25.3.4）。

還有一種選擇是使用rsync來執行一次文件系統備份。其作法是先在數據庫服務器運行時執行rsync，而後關閉數據庫服務器足夠長時間來作一次rsync --checksum （–checksum是必需的，由於rsync的文件修改 時間粒度只能精確到秒）。第二次rsync會比第一次快，由於它只須要傳送相對不多的數據，因爲服務器是中止的，因此最終結果將是一致的。這種方法容許在最小停機時間內執行一次文件系統備份。

注意一個文件系統備份一般會比一個SQL轉儲體積更大（例如pg_dump不須要轉儲索引的內容，而是轉儲用於重建索引的命令）。可是，作一次文件系統備份可能更快.

本文同步分享在 博客「cwl_java」（CSDN）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。