創建一致（時間點）備份的原則
就我的經驗而言，為了創建有用且一致的備份，必須涉及處理要備份的數據的應用程序。我想與其他系統管理員一起驗證我的發現。
考慮這樣一種情況，即應用程序打開了一個文件以進行 R/W，並且在保持打開狀態時，一個單獨的備份程序會讀取該文件。（並且被允許這樣做——如果我們使用羊群和強制性羊群而不是那種建議，那麼無論如何我們都必須讓應用程序參與進來）。應該普遍認為，為此打開文件創建的備份可能不一致。
在文件系統級別使用快照並不能完全緩解這種情況；因為我們不能保證在快照時間點t所有應用程序都已將一致的文件寫入磁碟（假設在t我們能夠刷新所有緩衝區）。
因此，在創建適當的備份計劃時，必須始終牢記哪些應用程序寫入數據，以及它們是如何進行的——並確保它們在拍攝快照/備份之前將一致的文件寫入磁碟。
你同意我的觀點，還是我在思考這個問題時犯了根本性的錯誤？
（請不要用任何具體的 HOWTO 來回答這個問題，因為這是關於一般的“高級”原則。另外，為了確保這不是關於 DB，因為問題已經在那裡解決了）。
您似乎對這些問題有很好的理解。
我見過的標準快照方法是關閉將寫入文件系統的服務，中斷快照並重新啟動服務。備份未寫入的一面。
另一種方法是能夠從應用程序中導出時間點數據集。然備份份導出的數據。這是數據庫可以使用的一種方法。數據可能會在導出過程中進行轉換，因此可能需要額外的步驟來導入數據。
我在數據庫中使用的另一種方法是在復製文件時將文件標記為正在備份。這可能會在備份執行時推遲更新，或者可能允許稍後重播更改。這需要更改日誌，也需要備份。
我通常從標準備份中排除數據庫文件，並使用一種替代方法從數據庫中獲取時間點數據。
在恢復數據庫之前仔細計劃。我很少需要將完整的數據庫恢復到某個時間點。冷備份（數據庫關閉）可能適用於訓練中使用的數據庫。我很遺憾為測試數據庫提供類似的回滾。