使用備份功能保護資料

本頁面說明 AlloyDB Omni 標準可用性參考架構，該架構使用備份提供資料保護。

用途

這項參考架構支援下列情境：

  • 您的資料庫可以容忍自上次備份以來的部分停機時間和資料遺失。
  • 您想保護 AlloyDB Omni 資料庫，避免資料庫層級發生使用者錯誤、損毀或實體故障，而非伺服器或 VM 映像檔快照。
  • 您想在原地或遠端復原資料庫，可能需要復原到特定時間點。

參考架構的運作方式

標準可用性參考架構涵蓋 AlloyDB Omni 資料庫的備份與復原。

雖然標準可用性是基本實作，且可盡量減少所需的額外硬體或服務，但復原時間目標 (RTO) 會隨著資料庫變大而增加。要備份的資料越多，還原及復原資料庫所需的時間就越長。資料遺失情況取決於備份類型。如果只定期備份資料檔案，還原時就會遺失上次備份後的資料。

縮短 RPO

PostgreSQL 的持續封存功能可讓您達成低復原點目標 (RPO)，並透過備份啟用時間點復原功能。這項程序包括封存預寫記錄檔 (WAL) 和串流 WAL 資料，可能需要傳送至遠端儲存空間位置。

如果 WAL 檔案只有在填滿或特定時間間隔才會封存，則完整的資料庫遺失 (包括目前的 WAL 檔案) 會將復原作業限制在最後一個封存的 WAL 檔案，這表示 RPO 必須考量潛在的資料遺失。相反地，持續移轉 WAL 資料可將潛在資料遺失降到最低。

設定持續備份後，即可復原至特定時間點。時間點復原功能可讓您將資料庫還原至發生錯誤前的狀態，例如不小心刪除資料表或批次更新錯誤。不過，除非您使用臨時輔助資料庫，否則這種復原方法會同時影響 RPO 和 RTO。就地還原整個資料庫會復原未受影響資料表上的後續交易，並讓資料庫離線，而還原至暫時輔助資料庫則可讓您僅複製復原的資料。

備份策略

AlloyDB Omni 支援多種資料保護策略，例如定期實體備份、時間點復原、WAL 封存和串流，以及將備份儲存在不同位置。或者，如果是小型資料庫，您可以使用 pg_dump 針對單一資料庫執行邏輯備份，或使用 pg_dumpall 針對整個叢集執行邏輯備份，並使用 pg_restore 還原。

備份工具

如果是容器和 Linux 部署作業，您可以使用下列 PostgreSQL 工具排定及管理備份：

視部署選項而定，您可以設定 AlloyDB Omni，將備份儲存在本機或遠端儲存空間，例如 Cloud Storage 或任何雲端供應商提供的儲存空間選項。雖然本機儲存空間的備份和復原速度可能較快，但當整個主機或 VM 故障時，遠端儲存空間通常能更有效地處理故障。詳情請參閱圖 1，其中顯示可能的備份目的地。

AlloyDB Omni 備份選項

圖 1.AlloyDB Omni 備份選項。

您可以將備份儲存至本機或遠端儲存空間。本機備份通常較快，因為只依賴 I/O 處理量，而遠端備份通常延遲時間較長，網路頻寬較低。不過，與本機備份相比，遠端備份能更有效地防範主機和可用區故障。

您也可以將本機備份分割至本機或共用儲存空間。資料庫主機故障時，本機儲存空間不提供災難復原選項，但共用儲存空間可讓您將儲存空間重新分配到其他伺服器，並用於復原。這表示共用儲存空間可能提供更快的 RTO。

針對本機、共用和遠端儲存空間部署作業，您可以排定下列類型的備份，或視需要手動執行：

  • 完整備份：完整備份資料復原所需的所有資料庫檔案。
  • 差異備份：僅備份上次完整備份後變更的檔案。
  • 增量備份：僅備份上次備份後變更的檔案。

時間點復原

PostgreSQL WAL 檔案的連續備份支援時間點復原功能。如果故障事件發生後，WAL 檔案仍完好可用，您可以使用這些檔案復原至特定時間點，盡可能減少資料遺失。

將 WAL 資料串流至遠端位置

視備份工具 (例如 Barman) 而定，您可以設定 WAL 資料即時串流至遠端位置，盡量減少復原時的資料遺失。即使使用即時串流，仍有極低機率會遺失已提交的交易，因為串流寫入遠端位置的作業預設為非同步。不過，您可以將 WAL 串流設為使用同步模式，這樣系統就會儲存 WAL 資料，並將狀態回應傳回來源資料庫。請注意，如果交易必須等待寫入作業完成才能繼續，這種做法可能會降低交易速度。

備份排程

在多數環境中，備份作業通常會排定每週執行一次。以下是典型的每週備份排程：

  • 週日：完整備份
  • 週一、週二：增量備份
  • 星期三：差異備份
  • 週四、週五：增量備份
  • 週六：差異備份

如果採用這個典型排程，一週的滾動式復原時間範圍需要最多三個完整備份，以及必要的增量或差異備份的儲存空間。如果週日完整備份期間發生故障，且資料庫復原作業必須延伸至上週日備份開始前，這種做法可支援復原作業。

如要盡可能縮短 RTO，但 RPO 可能會提高，其他資料庫可以在連續復原模式下運作。這種模式會重播備份，並透過封存及重播新的 WAL 檔案，持續更新次要環境。實際 RPO 反映潛在資料遺失，取決於交易頻率、WAL 檔案大小和 WAL 串流的使用。

備份還原

您可以從儲存的備份還原 AlloyDB Omni 資料庫，或復原至保留期間內的特定時間點。視部署環境和復原需求而定，您可以就地還原資料，也可以將備份還原至新的資料庫執行個體或叢集。

如果是容器和 Linux 部署作業，還原 AlloyDB Omni 資料庫時，通常需要停止資料庫服務或容器，並將資料還原至現有資料目錄，或將資料還原至新位置，然後使用還原的資料啟動新的資料庫執行個體。詳情請參閱「使用 pgBackRest 還原 AlloyDB Omni 叢集」或「使用 Barman 還原 AlloyDB Omni 叢集」。

實作

選擇可用性參考架構時，請留意下列優點、限制和替代方案。

優點

  • 易於使用和管理，適合 RTO 和 RPO 寬鬆的非關鍵資料庫。
  • 幾乎不需要額外硬體。
  • 提供災難復原計畫所需的基礎備份。
  • 支援復原至復原期間內的任何時間點。

限制

  • 視保留需求而定，可能需要比資料庫本身更多的儲存空間。
  • 復原速度可能較慢，RTO 可能較高。
  • 可能會遺失部分資料，具體取決於資料庫故障後目前 WAL 資料的可用性，這可能會對 RPO 造成負面影響。

替代方案

請考慮採用強化可用性或進階可用性參考架構，以提升可用性和災難復原選項。

後續步驟