25.2. 檔案系統層級備份

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

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

但是，有兩個限制會讓這個方法不可行，或者至少不如 pg_dump 方法：

  1. 必須關閉資料庫伺服器才能完成可用的備份。備份其間都無法操作，像是必須禁止所有連線（部分原因是 tar 和類似工具無法對檔案系統狀態進行原子快照，而且還因為伺服器內部還存在一些未儲存的資料緩衝）。 有關停止伺服器的資訊可以在第 18.5 節中找到。不用說，您也需要在還原資料之前關閉伺服器。
  2. 如果您已深入研究資料庫的檔案系統結構的詳細資訊，則可能會嘗試僅從特定檔案或目錄中備份或還原某些特定資料表或資料庫。這些都不會成功，因為沒有提交日誌檔案 pg_xact/*，其中包含所有事務的提交狀態，這些檔案中包含的資料將無法使用。資料表檔案僅可用於此資訊。當然，僅還原資料表和關聯的 pg_xact 資料也是不可能的，因為這會使資料庫叢集中的所有其他資料表失效。因此，檔案系統備份僅適用於完整資料庫叢集的完整備份和還原。

另一種檔案系統備份方法是，如果檔案系統支持該功能（並且您願意相信它已正確實作），也就是對資料目錄建立「一致性快照(consistent snapshot)」。典型的過程是製作包含資料庫 volume 的「凍結快照(frozen snapshot)」，然後將整個資料目錄（不僅僅是部分，請參閱前文）從快照複製到備份設備，然後釋放凍結快照。即使資料庫伺服器正在執行，這也能完成備份。但是，以這種方式建立的備份會將資料庫檔案保存為某種狀態，就好像資料庫伺服器未正確關閉一樣。因此，當您以備份的檔案啟動資料庫伺服器時，它將認為先前的伺服器實例崩潰了，並且將重新執行 WAL 日誌。這不會是問題；請注意這一點（並確保在備份中包含 WAL 檔案）。而您可以在拍攝快照之前執行 CHECKPOINT，以減少恢復的時間。

如果您的資料庫分散在多個檔案系統中，則可能沒有任何方法可以獲取所有 volume 完全同步的凍結快照。例如，如果資料檔案和 WAL 日誌位於不同的磁碟上，或者資料表空間位於不同的檔案系統上，則可能無法使用快照備份，因為快照必須同時進行。在這種情況下，請務必仔細閱讀檔案系統文件，然後再使用一致性快照技術。

如果不可能同時建立快照，則一種選擇是關閉資料庫伺服器足夠長的時間以建立所有凍結的快照。或者你還有一種選擇是執行連續歸檔(continuous archiving)基礎備份（第 25.3.2 節），因為此類備份在備份期間不受檔案系統變更的影響。這要求僅在備份過程中啟用連續歸檔。使用連續歸檔還原（第 25.3.4 節）來完成還原。

使用 rsync 執行檔案系統備份也是可以的。首先在資料庫伺服器執行時也執行 rsync，然後關閉資料庫伺服器足夠長的時間以執行 rsync —checksum，即可完成此操作。（—checksum 是必須的，因為 rsync 僅具有一秒的檔案修改時間顆粒度。）第二次 rsync 將比第一次更快，因為它要傳輸的資料相對較少，並且最終結果將會是一致的，因為伺服器是關閉的狀態。此方法目標在最少停機時間的情況下執行檔案系統備份。

請注意，檔案系統備份通常會比 SQL dump 要佔空間。（例如，pg_dump 不需要匯出索引的內容，只需匯出重新建立索引的指令。）但是，進行檔案系統備份可能會更快。