# 24.2\. 文件系統級別備份 另一個備份的策略是直接拷貝PostgreSQL用于存放數據庫數據的文件。 我們在[Section 17.2](#calibre_link-976)里解釋了這些文件的位置， 你可以用自己喜歡的任何常用文件系統備份的方法， 例如： ``` tar -cf backup.tar /usr/local/pgsql/data ``` 不過，你要受到兩個限制，令這個方法不那么實用，或者至少比pg_dump的方法遜色一些： 1. 為了進行有效的備份，數據庫服務器_必須_被關閉。 像拒絕所有連接這樣的折衷的方法是_不行_的， （部分因為`tar`和類似的工具在做備份的時候并不對文件系統的狀態做原子快照。 但也因為服務器內部緩沖數據）。 有關關閉服務器的信息可以在[Section 17.5](#calibre_link-634)里面找到。 不用說，你在恢復數據之前， 同樣必須關閉服務器。 2. 如果你曾經深入了解了數據庫在文件系統布局的細節， 你可能試圖從對應的文件或目錄里備份幾個表或者數據庫。 這樣做是_沒用_的，因為包含在這些文件里的信息只是部分信息。 還有一半信息在提交日志文件`pg_clog/*`里面， 它包含所有事務的提交狀態。 只有擁有這些信息，表文件的信息才是可用的。當然， 試圖只恢復表和相關的`pg_clog`數據也是徒勞的， 因為這樣會把數據庫集群里的所有其它沒有用的表的信息都拿出來。 所以文件系統的備份只適用于一個數據庫集群的完整恢復。 另外一個文件系統備份的方法是給數據目錄做一個"一致的快照"， 條件是文件系統支持這個功能(并且你愿意相信它是實現正確的)。 典型的過程是制作一個包含數據庫的卷的"凍結快照"， 然后把整個數據庫目錄(不僅僅是部分，見上文)從快照拷貝到備份設備， 然后釋放凍結快照。這樣甚至在數據庫服務器在運行的時候都可以運轉。 不過，這樣創建的備份會把數據庫文件保存在一個沒有恰當關閉數據庫服務器的狀態下； 因此，如果你在這個備份目錄下啟動數據庫服務器， 它就會認為數據庫服務器經歷過崩潰并且重放WAL日志。 這不是個問題，只要意識到它即可(并且確信在自己的備份中包含WAL文件)。 在采用快照減少恢復時間之前，你可以執行`CHECKPOINT`。 如果你的數據庫分布在多個文件系統上， 那么可能就沒有任何方法獲取所有卷上準確的同步凍結快照。比如， 你的數據文件和WAL日志在不同的磁盤上，或者表空間在不同的文件系統上， 這種情況下就不可能使用快照，因為快照_必須_是同時的。 在你信任這樣的情況下的一致性快照的技術之前，仔細閱讀你的文件系統文檔。 如果同步快照是不可能的，該選項關閉數據庫服務器足夠長的時間來建立所有冰凍的快照。 另一種選擇是執行一個連續歸檔基礎備份([Section 24.3.2](#calibre_link-1632)) 因為這樣的備份在備份過程中免于文件系統變化。這需要在備份過程中啟動連續歸檔。 恢復是通過使用連續存檔恢復([Section 24.3.4](#calibre_link-1634))完成的。 另外一個選擇是使用rsync執行一次文件系統備份。 這是通過在數據庫服務器正在運行的時候運行第一次rsync， 然后關閉數據庫服務器一段足夠的時間長度，用于運行第二次rsync。 第二次rsync會比第一次快很多，因為它要傳輸的數據相對較少， 并且最后的結果是一致的， 因為服務器已經停止運行了。這個方法允許用很少的時間執行一次文件系統備份。 需要注意的是文件系統備份往往比SQL轉儲大。 比如pg_dump不用導出索引， 只是創建它們的命令。然而，文件系統備份可能會更快。