從 GCP/GCE 快照恢復邏輯卷

我最近在使用 Centos 7 作業系統的 Google Compute Engine VM 上進行了恢復測試。VM 有五個由 LVM 管理的分區磁碟。伺服器已經存在了一段時間，所以大約有十個文件系統分佈在磁碟上。這些快照都是在凌晨時分在一兩秒內創建的。

看起來復甦進展順利，df輸出看起來像我預期的那樣。

我只是幸運嗎？

從表面上不同步的快照中恢復時，我通常會遇到麻煩。

我想知道：我是否需要使用“適當的”邏輯卷感知備份系統來確保恢復的文件系統的一致性？或者如果失敗了，我應該確保每個文件系統都在自己的單個磁碟上嗎？還是我不必要地擔心？

GCP 建議將每個文件系統放在自己的單個磁碟上。

如果您使用單個文件系統且沒有分區表來格式化永久磁碟，則可以節省時間並獲得最佳性能。

從標準系統管理員的角度來看，考慮到可以附加到實例的磁碟數量是有限的，這可以看作是一種資源浪費，但是管理備份更容易。

• 具有共享核心機器類型的實例最多只能有 16 個永久性磁碟。
• 對於具有至少 1 個 vCPU 的自定義機器類型或預定義機器類型，您最多可以附加 128 個永久性磁碟。
• 每個永久性磁碟的大小最高可達 64 TB，因此無需管理磁碟陣列來創建大型邏輯卷。每個實例只能附加有限的總永久性磁碟空間和有限數量的單個永久性磁碟。預定義機器類型和自定義機器類型具有相同的永久磁碟限制。
• 大多數實例最多可以有 128 個永久性磁碟和最多 257 TB 的總永久性磁碟空間。實例的總永久磁碟空間包括啟動磁碟的大小。
• 共享核心機器類型限制為 16 個永久性磁碟和 3 TB 的總永久性磁碟空間。

如果我理解正確，您將 5 個單獨的磁碟附加到您的實例並繼續創建 PV、VG、LV 和 FS。最後，您幾乎同時為每個磁碟拍攝了快照

您似乎沒有在快照之間對磁碟進行更改，但我不建議將此架構用於數據庫等敏感應用程序，因為我會擔心數據一致性。如果您在磁碟快照之間重複該實驗並遇到數據一致性問題，我不會感到驚訝。

我建議您查看快照最佳實踐和計劃快照

引用自：https://serverfault.com/questions/998136