?
This document uses PHP Chinese website manual Release
另一個備份的策略是直接拷貝PostgreSQL用于存放數(shù)據(jù)庫數(shù)據(jù)的文件。 Section 17.2里解釋了這些文件的位置, 不過如果你想用這個方法,你應(yīng)該早就找到它們的位置了。 你可以用任何自己喜歡的方法備份文件系統(tǒng),例如:
tar -cf backup.tar /usr/local/pgsql/data
不過,你要受到兩個限制,令這個方法不那么實用, 或者至少比pg_dump的方法遜色一些:
為了進行有效的備份,數(shù)據(jù)庫服務(wù)器必須被關(guān)閉。 像拒絕所有連接這樣的折衷的方法是不行的,(一部分是因為tar和類似的工具不能對文件系統(tǒng)的狀態(tài)做原子快照, 但也會是因為服務(wù)器的內(nèi)部緩沖問題) 有關(guān)關(guān)閉服務(wù)器的信息可以在Section 17.5里面找到。 不用說,你在恢復(fù)數(shù)據(jù)之前,同樣必須關(guān)閉服務(wù)器。
如果你曾經(jīng)深入了解了數(shù)據(jù)庫在文件系統(tǒng)布局的細(xì)節(jié), 你可能試圖從對應(yīng)的文件或目錄里備份幾個表或者數(shù)據(jù)庫。 這樣做是沒用的,因為如果不提交日志文件包含在這些文件里的信息是不可用的, pg_clog/*,它包含所有事務(wù)的提交狀態(tài)。 只有擁有這些信息,表文件的信息才是可用的。 當(dāng)然,試圖只恢復(fù)表和相關(guān)的pg_clog數(shù)據(jù)也是徒勞的, 因為這樣會把數(shù)據(jù)庫集群里的所有其它沒有用的表的信息都拿出來。 所以文件系統(tǒng)的備份只適用于完整備份和一個數(shù)據(jù)庫集群的完整恢復(fù)。
另外一個文件系統(tǒng)備份的方法是給數(shù)據(jù)目錄做一個"一致的快照", 條件是文件系統(tǒng)支持這個功能(并且你愿意相信它是實現(xiàn)正確的)。 典型的過程是制作一個包含數(shù)據(jù)庫的卷的"凍結(jié)快照", 然后把整個數(shù)據(jù)庫目錄(不僅僅是部分,見上文)從快照拷貝到備份設(shè)備, 然后釋放凍結(jié)快照。這樣甚至在數(shù)據(jù)庫服務(wù)器在運行的時候都可以運轉(zhuǎn)。 不過,這樣創(chuàng)建的備份會把數(shù)據(jù)庫文件保存在一個沒有恰當(dāng)關(guān)閉數(shù)據(jù)庫服務(wù)器的狀態(tài)下; 因此,如果你在這個備份目錄下啟動數(shù)據(jù)庫服務(wù)器, 它就會認(rèn)為數(shù)據(jù)庫服務(wù)器經(jīng)歷過崩潰并且重放WAL日志。 這不是個問題,只要意識到它即可(并且確信在自己的備份中包含WAL文件)。
如果你的數(shù)據(jù)庫分布在多個文件系統(tǒng)上,那么可能就沒有任何方法獲取所有卷上準(zhǔn)確的同步凍結(jié)快照。 比如,你的數(shù)據(jù)文件和WAL日志在不同的磁盤上,或者表空間在不同的文件系統(tǒng)上, 這種情況下就不可能使用快照,因為快照必須是同時的。 在你信任這樣的情況下的一致性快照的技術(shù)之前,仔細(xì)閱讀你的文件系統(tǒng)文檔。
如果同步快照是不可能的,一個選擇就是關(guān)閉數(shù)據(jù)庫足夠長的時間以便建立所有的冰凍快照。 另一個選擇是執(zhí)行連續(xù)歸檔基礎(chǔ)備份(Section 24.3.2)這樣的備份可以避免在 備份時對文件系統(tǒng)產(chǎn)生變更。這需要在備份時啟用連續(xù)歸檔;用連續(xù)存檔恢復(fù)存儲。
另外一個選擇是使用rsync執(zhí)行一次文件系統(tǒng)備份。 這是通過在數(shù)據(jù)庫服務(wù)器正在運行的時候運行第一次rsync, 然后關(guān)閉數(shù)據(jù)庫服務(wù)器一段足夠的時間長度,用于運行第二次rsync。 第二次rsync會比第一次快很多,因為它要傳輸?shù)臄?shù)據(jù)相對較少, 并且最后的結(jié)果是一致的,因為服務(wù)器已經(jīng)停止運行了。 這個方法允許用很少的時間執(zhí)行一次文件系統(tǒng)備份。
還要說明的是,文件系統(tǒng)備份通常會比SQL轉(zhuǎn)儲大。 (比如pg_dump不用轉(zhuǎn)儲內(nèi)容索引,只是創(chuàng)建它們的命令。) 然而,讓一個文件系統(tǒng)備份可能會快點。