Windows Server 2008 R2 上的 Postgresql 9.0.8 物理備份導致“訪問被拒絕”
我已經按照 PostgreSQL 9 Administration Cookbook (Riggs/Krosing) 中的“獨立熱物理數據庫備份”配方建構了一個腳本來執行 Postgresql 9.0.8 數據庫的物理備份，但我將它改編為 Windows Server 2008 R2 .
對於配方的第 4 步，它使用 rsync 複製所有數據文件（不包括 pg_xlog 目錄），我使用的是 robocopy.exe（因為 rsync 是一個 *nix 實用程序並且我使用的是 Windows）。問題是，通常無法複製其中一個文件並導致“訪問被拒絕”。在備份腳本失敗很長時間後，手動複製文件失敗並顯示“訪問被拒絕” - 所以這不是一些可以重新嘗試的間歇性問題。只有在重新啟動 PostgreSQL 程序後才能複制該文件。它總是一個不同的文件。最後一天是 %PGDATADIR%\5432\base\24609\38122 。
我想听聽您是否經歷過這種情況以及您為解決此問題所做的工作。我正在考慮：
- 在備份之前重新啟動 PostgreSQL 伺服器（我承認這是一個 hack）
- 使用某種可以複製打開文件的實用程序，例如 VSHADOW、DISKSHADOW 和 hobocopy（注意：不是 robocopy）
- 也許有一些方法可以指示 PostgreSQL 釋放所有鎖？
- $$ added $$見下文 - 看起來像添加正常“真空”消除症狀
好的，首先要做的就是收好你的食譜。相反，請閱讀Postgres 手冊中有關備份的部分。閱讀整章——它並不長。
（你可能會注意到這本書和本書之間的一些相似之處——大多數 Postgres 書籍只是手冊的美化版本——但你應該始終將手冊作為你的主要參考。）。
我將在下面使用的所有術語都來自手冊（因此，如果您認為可以跳過閱讀作業，則不能-如果這樣做，您可能會感到非常困惑）。
現在針對您的實際問題——Unix 解決方案通常不能直接移植到 Windows，這是其中一種情況：*nix 系統會很高興地抓取一個正在被操作的文件——Windows 會拋出你所看到的錯誤。
你如何處理這取決於你正在做什麼樣的備份。
文件系統級備份
如果您正在執行“文件系統級備份”，則必須關閉伺服器。句點，討論結束，沒有其他選擇。必須完全關閉數據庫才能使該類型的備份可靠（如果您獲得的備份不可靠，那有什麼意義呢？）。
連續存檔/時間點恢復和從屬伺服器
如果您將基礎備份作為設置時間點恢復和日誌傳送的一部分，您有兩種選擇：
- 無論如何都要關閉伺服器。
- 使用可以複製打開文件的工具（您問題中的選項（2））
然後，您按照時間點恢復/日誌傳送的其余文件繼續操作，創建從屬伺服器。
當您想將數據庫伺服器複製到磁碟時，只需停止從屬伺服器，備份它，然後重新啟動它 - 世界一直在打開您的主伺服器，從屬伺服器將在重新啟動時趕上它錯過的內容。
您還可以使用基本備份以及通常發送到從屬伺服器的滾動事務日誌作為可靠的數據庫備份。這似乎是您在問題中試圖實現的最接近的事情，但我會推薦我描述的從屬備份——更多的好處（你有一個熱備用）和更少的主伺服器工作（沒有額外的檢查點來滾動備份的事務日誌）。
別的東西
如果以上都不吸引您，那麼您幾乎無法使用SQL Dumps。
有缺點：Postgres 必須在每個表被轉儲時鎖定它（這意味著對數據庫的寫入將被阻塞），並且 SQL 轉儲比其他選項慢。
如果您的數據庫具有任何實際大小，我不建議使用這種方法。