另一種備份策略是直接複製 PostgreSQL 用於儲存資料庫檔案的檔案； 第 18.2 節 解釋了這些檔案的位置。您可以使用任何您喜歡的檔案系統備份方法；例如
tar -cf backup.tar /usr/local/pgsql/data
然而，有兩個限制，這使得這種方法不切實際，或者至少不如 pg_dump 方法 第 25.2.1 節
為了獲得可用的備份，資料庫伺服器必須關閉。半途而廢的方法，例如禁止所有連線，將不起作用（部分原因是 tar 和類似工具無法對檔案系統狀態進行原子快照，也因為伺服器內部存在緩衝）。有關停止伺服器的資訊可以在 第 18.5 節 中找到。不用說，在恢復資料之前您也需要關閉伺服器。
如果您深入研究了資料庫的檔案系統佈局的細節，您可能會嘗試僅從各自的檔案或目錄備份或恢復特定的單個表或資料庫。這不起作用，因為這些檔案中的資訊在沒有提交日誌檔案 pg_xact/* 的情況下是無法使用的，這些檔案包含所有事務的提交狀態。表文件僅與此資訊一起可用。當然，這也無法僅恢復一個表以及相關的 pg_xact 資料，因為那樣會讓資料庫叢集中的所有其他表都變得無用。因此，檔案系統備份僅適用於整個資料庫叢集的完整備份和恢復。
另一種檔案系統備份方法是製作資料目錄的“一致快照”，如果檔案系統支援該功能（並且您願意相信它已正確實現）。典型的過程是製作包含資料庫的卷的“凍結快照”，然後將整個資料目錄（不是部分，見上文）從快照複製到備份裝置，然後釋放凍結快照。即使在資料庫伺服器執行時，這也能正常工作。但是，以這種方式建立的備份會以資料庫伺服器未正確關閉的狀態儲存資料庫檔案；因此，當您在備份的資料上啟動資料庫伺服器時，它會認為之前的伺服器例項崩潰了，並會重放 WAL 日誌。這不成問題；只需注意這一點（並確保將 WAL 檔案包含在備份中）。您可以在拍攝快照之前執行 CHECKPOINT 以縮短恢復時間。
如果您的資料庫分佈在多個檔案系統上，可能無法獲得所有卷的完全同時的凍結快照。例如，如果您的資料檔案和 WAL 日誌在不同的磁碟上，或者表空間在不同的檔案系統上，則可能無法使用快照備份，因為快照必須是同時的。在這種情況下，在信任一致性快照技術之前，請非常仔細地閱讀您的檔案系統文件。
如果無法進行同時快照，一種選擇是關閉資料庫伺服器足夠長的時間以建立所有凍結快照。另一種選擇是執行連續歸檔基礎備份（第 25.3.2 節），因為這類備份在備份過程中不受檔案系統更改的影響。這需要在備份過程中啟用連續歸檔；恢復使用連續歸檔恢復（第 25.3.5 節）。
另一種選擇是使用 rsync 執行檔案系統備份。這可以透過先在資料庫伺服器執行時執行 rsync，然後關閉資料庫伺服器足夠長的時間以執行 rsync --checksum 來完成。（--checksum 是必需的，因為 rsync 僅具有一秒的檔案修改時間粒度。）第二次 rsync 將比第一次更快，因為它需要傳輸的資料相對較少，並且由於伺服器已關閉，最終結果將是一致的。這種方法允許以最小的停機時間執行檔案系統備份。
請注意，檔案系統備份通常比 SQL 轉儲更大。（例如，pg_dump 不需要轉儲索引的內容，只需重建它們的命令。）但是，進行檔案系統備份可能會更快。
如果您在文件中看到任何不正確的內容、與您對特定功能的實際體驗不符的內容或需要進一步澄清的內容，請使用 此表單 報告文件問題。