支援的版本:目前版本 (17) / 16 / 15 / 14 / 13
開發版本:devel
不支援的版本:12 / 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1 / 8.0 / 7.4 / 7.3 / 7.2 / 7.1

25.2. 檔案系統層級備份 #

另一種備份策略是直接複製 PostgreSQL 用來儲存資料庫中資料的檔案;第 18.2 節說明了這些檔案的位置。您可以使用您喜歡的任何方法來進行檔案系統備份;例如

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

但是,有兩個限制使得此方法不切實際,或者至少不如 pg_dump 方法

  1. 資料庫伺服器必須關閉才能獲得可用的備份。 禁止所有連線之類的中途措施不會起作用(部分原因是 tar 和類似的工具不會取得檔案系統狀態的原子快照,而且還因為伺服器內部的緩衝)。 關於停止伺服器的資訊可以在第 18.5 節中找到。 不用說,您還需要在還原資料之前關閉伺服器。

  2. 如果您深入研究了資料庫的檔案系統佈局的細節,您可能會想嘗試僅從其各自的檔案或目錄備份或還原某些單獨的表格或資料庫。 這不會起作用,因為這些檔案中包含的資訊在沒有提交日誌檔案 pg_xact/* 的情況下是無法使用的,這些檔案包含所有交易的提交狀態。 表格檔案只有在此資訊的情況下才可用。 當然,也不可能僅還原表格和相關的 pg_xact 資料,因為這會使資料庫叢集中的所有其他表格無用。 因此,檔案系統備份僅適用於完整備份和還原整個資料庫叢集。

另一種檔案系統備份方法是建立資料目錄的一致性快照,如果檔案系統支援該功能(並且您願意相信它已正確實作)。 典型的程序是建立包含資料庫的磁碟區的凍結快照,然後從快照將整個資料目錄(而不僅僅是部分,請參閱上文)複製到備份裝置,然後釋放凍結的快照。 即使資料庫伺服器正在執行,這也有效。 但是,以這種方式建立的備份會將資料庫檔案儲存在資料庫伺服器未正確關閉的狀態;因此,當您在備份的資料上啟動資料庫伺服器時,它會認為先前的伺服器實例已崩潰,並將重新執行 WAL 日誌。 這不是問題;請注意這一點(並確保將 WAL 檔案包含在您的備份中)。 您可以在建立快照之前執行 CHECKPOINT 以減少還原時間。

如果您的資料庫分散在多個檔案系統中,則可能無法獲得所有磁碟區的精確同步凍結快照。 例如,如果您的資料檔案和 WAL 日誌位於不同的磁碟上,或者如果表格空間位於不同的檔案系統上,則可能無法使用快照備份,因為快照必須是同步的。 在這種情況下,在信任一致性快照技術之前,請仔細閱讀檔案系統文件。

如果無法使用同步快照,一種選擇是關閉資料庫伺服器足夠長的時間,以建立所有凍結的快照。 另一種選擇是執行連續歸檔基本備份(第 25.3.2 節),因為此類備份不受備份期間檔案系統變更的影響。 這需要僅在備份過程中啟用連續歸檔;使用連續歸檔還原進行還原(第 25.3.5 節)。

另一個選項是使用 rsync 執行檔案系統備份。方法是先在資料庫伺服器運作時執行 rsync,然後關閉資料庫伺服器,時間長度足以執行 rsync --checksum。(--checksum 是必要的,因為 rsync 的檔案修改時間粒度只有一秒。)第二次執行 rsync 會比第一次快,因為需要傳輸的資料相對較少,並且由於伺服器已關閉,因此最終結果將保持一致。此方法允許以最短的停機時間執行檔案系統備份。

請注意,檔案系統備份通常會比 SQL 傾印檔案更大。(例如,pg_dump 不需要傾印索引的內容,只需要重建它們的指令。)但是,進行檔案系統備份可能會更快。

提交更正

如果您在文件中發現任何不正確、與您使用特定功能的經驗不符或需要進一步澄清的地方,請使用此表單報告文件問題。