資料的災難復原情境

Last reviewed 2024-08-05 UTC

本文是探討 Google Cloud中災難復原 (DR) 的系列文章第三部分。本單元討論備份與復原資料的情境。

本系列包含以下單元：

簡介

您必須在災難復原計畫中指定如何避免災難期間發生資料遺失的情形。這裡的「資料」一詞涵蓋兩種情境。備份並復原資料庫、記錄資料及其他資料類型符合下列其中一個情境：

  • 資料備份：光是資料備份作業，就牽涉將個別資料量複製到其他位置。備份作業是做為復原計畫的一部分，可從損毀資料復原，以便直接在實際工作環境中還原到已知的良好狀態，或是在實際工作環境當機時於 DR 環境中還原資料。一般來說，資料備份具有低度到中度的 RTO 以及低度 RPO。
  • 資料庫備份：資料庫備份稍微複雜，因為備份作業通常需要復原至特定時間點。因此，除了考量如何備份與還原資料庫備份，並且確保復原資料庫系統反映實際工作環境設定 (相同版本、鏡像磁碟設定) 之外，您也需要考量如何備份交易記錄。在復原期間，您在還原資料庫功能之後，必須套用最新的資料庫備份，然後套用上次備份之後已備份的復原交易記錄。由於資料庫系統固有的複雜因素 (例如必須比對實際運作和復原系統之間的版本)，採用高可用性優先的方法，盡量縮短從資料庫伺服器無法使用的情況中復原的時間，有助於達成較小的 RTO 和 RPO 值。

在 Google Cloud上執行實際工作環境工作負載時，您可以採用全球分散式系統，以在某一地區發生問題時讓應用程式繼續提供服務，即使該應用程式並未在全球提供。基本上，該應用程式會叫用其 DR 計劃。

本文的其餘部分將探討一些範例，瞭解如何為資料與資料庫設計特定情境來達到 RTO 與 RPO 目標。

實際工作環境是內部部署環境

在此情境中，實際工作環境是內部部署環境，且災難復原計畫需要使用 Google Cloud 做為復原站點。

資料備份與復原

您可以採取各種策略來佈建備份程序，將內部部署的資料定期備份至 Google Cloud。本節主要說明兩種最常見的解決方案。

解決方案 1：使用排程工作備份至 Cloud Storage

這個模式使用下列 DR 構成要素：

  • Cloud Storage

備份資料的其中一個方法，是建立能夠執行指令碼或應用程式的排程工作，將資料移轉至 Cloud Storage。您可以使用 gcloud storage Google Cloud CLI 指令，或使用其中一個 Cloud Storage 用戶端程式庫，自動化備份到 Cloud Storage 的程序。舉例來說，下列 gcloud storage 指令會將所有檔案從來源目錄複製到指定值區。

gcloud storage cp -r SOURCE_DIRECTORY gs://BUCKET_NAME

將 SOURCE_DIRECTORY 替換為來源目錄的路徑，並將 BUCKET_NAME 替換為您選擇的 bucket 名稱。名稱必須符合值區名稱規定。

以下步驟概述如何使用 gcloud storage 指令實作備份與復原程序。

  1. 在要上傳資料檔案的內部部署機器上安裝 gcloud CLI。
  2. 建立值區做為資料備份的目標位置。
  3. 建立服務帳戶。
  4. 建立 IAM 政策，限制可存取值區和物件的對象。請納入專為這項作業所建立的服務帳戶。如要進一步瞭解 Cloud Storage 的存取權限，請參閱 gsutil 指令的 IAM 權限。gcloud storage
  5. 使用服務帳戶模擬功能，為本機 Google Cloud使用者 (或服務帳戶) 提供存取權，模擬您稍早建立的服務帳戶。或者，您也可以專門為此建立新使用者。
  6. 進行測試，確認您可以在目標值區中上傳與下載檔案。
  7. 使用 Linux crontab 和 Windows 工作排程器等工具，為用於上傳備份的指令碼設定排程。
  8. 設定使用 gcloud storage 指令的復原程序，將資料還原至 Google Cloud的復原 DR 環境。

您也可以使用 gcloud storage rsync 指令，在資料和 Cloud Storage bucket 之間執行即時增量同步。

舉例來說，下列 gcloud storage rsync 指令會複製任何遺失的檔案或物件，或是資料已變更的檔案或物件，讓 Cloud Storage 值區中的內容與來源目錄中的內容相同。如果連續備份工作階段之間變更的資料量，相較於來源資料的總量而言很小，則使用 gcloud storage rsync 會比使用 gcloud storage cp 指令更有效率。使用 gcloud storage rsync 可實作更頻繁的備份排程，並達成較低的 RPO。

gcloud storage rsync -r SOURCE_DIRECTORY gs:// BUCKET_NAME

詳情請參閱gcloud storage 指令，瞭解如何轉移較小的內部部署資料。

解決方案 2：使用 Transfer Service for On Premises Data 備份至 Cloud Storage

這個模式使用下列 DR 構成要素：

  • Cloud Storage
  • Transfer Service for On Premises Data

透過網路傳輸大量資料時，通常需要仔細規劃及完善的執行策略。開發可擴充、可靠且可維護的自訂指令碼並不容易。自訂指令碼通常會導致 RPO 值降低，甚至增加資料遺失的風險。

如需將大量資料從內部部署位置移至 Cloud Storage 的指引，請參閱從內部部署儲存空間移動或備份資料。

解決方案 3：使用合作夥伴閘道解決方案備份至 Cloud Storage

這個模式使用下列 DR 構成要素：

  • Cloud Interconnect
  • Cloud Storage 分層儲存空間

內部部署應用程式通常會與第三方解決方案整合，作為資料備份與復原策略的一部分。這些解決方案通常採用分層儲存模式，在較快的儲存空間儲存最新的備份，並將較舊的備份緩慢遷移至較便宜 (緩慢) 的儲存空間。使用 Google Cloud 做為目標時，您可以使用多個儲存空間類別選項，做為對應的緩慢分層。

實作這個模式的其中一個方法，是在內部部署儲存空間與 Google Cloud 之間使用合作夥伴閘道，加快資料移轉到 Cloud Storage 的速度。下圖顯示的配置具有管理從內部部署 NAS 設備或 SAN 進行移轉的合作夥伴解決方案。

架構圖：顯示透過專屬互連網路連結內部部署資料中心與 Google Cloud 。

發生失敗時，您需要將備份的資料復原到 DR 環境。DR 環境會用於提供實際工作環境流量，直到您能夠還原為實際工作環境。達成目標的方式將取決於您的應用程式、合作夥伴解決方案及其架構 (DR 應用程式說明文件將會討論部分端對端情境)。

您也可以使用受管理 Google Cloud 資料庫做為 DR 目的地。 舉例來說，SQL Server 適用的 Cloud SQL 支援匯入交易記錄。您可以從地端 SQL Server 執行個體匯出交易記錄，然後上傳至 Cloud Storage，並匯入 Cloud SQL for SQL Server。

如需將內部部署的資料移轉至Google Cloud的進一步指引，請參閱將大數據資料集移轉至 Google Cloud。

如要進一步瞭解合作夥伴解決方案，請參閱 Google Cloud 網站上的合作夥伴頁面。

資料庫備份與復原

您可以採取許多策略來佈建一套專用的程序，將內部部署的資料庫系統復原至 Google Cloud。本節主要說明兩種最常見的解決方案。

第三方資料庫包含的各種內建備份與復原機制不在本文的探討範圍之內。本節僅就本文探討的解決方案提供實作的一般指引。

解決方案 1：在 Google Cloud上使用復原伺服器進行備份與還原

  1. 使用資料庫管理系統的內建備份機制建立資料庫備份。
  2. 連線內部部署網路與 Google Cloud 網路。
  3. 建立 Cloud Storage bucket 做為資料備份的目標。
  4. 使用 gcloud storage gcloud CLI 或合作夥伴閘道解決方案，將備份檔案複製到 Cloud Storage (請參閱先前在「資料備份與復原」一節中探討的步驟)。詳情請參閱「遷移至 Google Cloud：轉移大型資料集」。
  5. 將交易記錄複製到 Google Cloud上的復原站點。備份交易記錄有助於維持低 RPO 值。

設定這個備份拓撲後，您必須確保可以復原至 Google Cloud上的系統。這個步驟除了將備份檔案還原至目標資料庫之外，通常還會重播交易記錄以取得 RTO 最小值。復原順序通常為：

  1. 在 Google Cloud上建立資料庫伺服器的自訂映像檔。資料庫伺服器映像檔上的設定應與內部部署資料庫伺服器相同。
  2. 實作將內部部署備份檔案與交易記錄檔複製到 Cloud Storage 的程序。有關實作範例請參見解決方案 1。
  3. 從自訂映像檔啟動最低限度大小的執行個體，並且附加所需的任何永久磁碟。
  4. 將永久磁碟的自動刪除標記設為 false。
  5. 按照資料庫系統對於復原備份檔案的操作說明，套用先前複製到 Cloud Storage 的最新備份檔案。
  6. 套用已複製到 Cloud Storage 的最新交易記錄檔組合。
  7. 將最低限度大小的執行個體替換為能夠接受實際工作環境流量的較大執行個體。
  8. 切換用戶端以指向 Google Cloud上的復原資料庫。

如果您在實際工作環境下運作並能夠支援實際工作負載時，則必須反向執行操作步驟以容錯移轉至Google Cloud 復原環境。返回實際工作環境的順序通常為：

  1. 備份在 Google Cloud上執行的資料庫。
  2. 將備份檔案複製到實際工作環境。
  3. 將備份檔案套用到實際工作環境的資料庫系統。
  4. 防止用戶端連線至Google Cloud中的資料庫系統，例如停止資料庫系統服務。 從這時開始到您完成還原實際工作環境之前，應用程式將無法使用。
  5. 將任何交易記錄檔複製並套用到實際工作環境。
  6. 將用戶端連線重新導向至實際工作環境。

解決方案 2：複製到 Google Cloud上的待命伺服器

如要達成極低的 RTO 與 RPO 值，其中一個方法是即時複製 (不只是備份) 資料與 (在特定情況下) 資料庫狀態到資料庫伺服器的副本。

  1. 連線內部部署網路與 Google Cloud 網路。
  2. 在 Google Cloud上建立資料庫伺服器的自訂映像檔。資料庫伺服器映像檔上的設定應與內部部署資料庫伺服器相同。
  3. 從自訂映像檔啟動執行個體，並且附加所需的任何永久磁碟。
  4. 將永久磁碟的自動刪除標記設為 false。
  5. 按照資料庫軟體的專屬操作說明，在內部部署資料庫伺服器與 Google Cloud 上的目標資料庫伺服器之間設定複製作業。
  6. 在正常作業下設定用戶端以指向內部部署的資料庫伺服器。

設定這個複製拓撲後，切換用戶端以指向在 Google Cloud 網路上執行的待命伺服器。

如果您已備份實際工作環境，並且能夠支援實際工作負載時，則必須使用Google Cloud 資料庫伺服器來重新同步處理實際工作環境資料庫伺服器，然後切換用戶端以指回實際工作環境。

實際工作環境是 Google Cloud

在此情境中，實際工作環境與災難復原環境都是在 Google Cloud上執行。

資料備份與復原

常見的資料備份模式是使用分層儲存模式。如果實際工作負載位於 Google Cloud，則分層儲存系統會如下圖所示。由於不太可能會需要存取備份資料，因此您可以將資料移轉至儲存費用較低的分層。

這個模式使用下列 DR 構成要素：

顯示將資料從永久磁碟移轉至 Nearline 再到 Coldline 來降低成本的概念圖。

由於 Nearline、Coldline 和 Archive 儲存空間級別主要用於儲存不常存取的資料，因此您在擷取這些儲存空間級別內的資料或中繼資料時，系統會向您收取其他相關費用。另外，系統也會向您收取最短儲存時間的額外費用。

資料庫備份與復原

使用自行代管的資料庫 (例如已在 Compute Engine 執行個體上安裝 MySQL、PostgreSQL 或 SQL Server 時)，跟管理實際工作環境的內部部署資料庫一樣有操作考量，但您不再需要管理其中的基礎架構。

備份和災難復原服務是集中式雲端原生解決方案，可備份及還原雲端和混合式工作負載。可快速復原資料，協助您迅速恢復重要業務營運。

如要進一步瞭解如何使用備份和災難復原服務，在 Google Cloud上進行自我管理的資料庫情境，請參閱下列內容：

或者，您可以使用適當的 DR 構成要素功能進行 HA 設定，以維持低 RTO。您可以將資料庫設定設計為可輕鬆復原到最接近災難發生前的狀態；這有助維持低 RPO 值。 Google Cloud 為這個情境提供多種選項。

本節將探討針對 Google Cloud 上自行代管的資料庫，設計資料庫復原架構最常見的兩個方法。

在沒有同步處理狀態的情況下復原資料庫伺服器

常見的模式是啟用不需要透過最新待命副本同步處理系統狀態的資料庫伺服器復原功能。

這個模式使用下列 DR 構成要素：

  • Compute Engine
  • 代管執行個體群組
  • Cloud Load Balancing (內部負載平衡)

下圖說明能解決這個情境的範例架構。透過實作這個架構，您將設置能夠自動回應失敗而無需手動復原的 DR 計畫。

顯示從特定區域的永久磁碟擷取的永久磁碟映像檔的架構圖

以下步驟概述如何設定這個情境：

  1. 建立虛擬私人雲端網路。

  2. 執行下列操作，建立與資料庫伺服器一併設定的自訂映像檔：

    1. 進行伺服器設定，讓資料庫檔案與記錄檔寫入到附加的標準永久磁碟。
    2. 從連結的永久磁碟建立快照。
    3. 設定開機指令碼以從快照建立永久磁碟及掛接磁碟。
    4. 建立開機磁碟的自訂映像檔。

  3. 建立使用映像檔的執行個體範本。

  4. 使用執行個體範本設定代管執行個體群組，將目標大小設為 1。

  5. 使用 Cloud Monitoring 指標設定健康狀態檢查。

  6. 使用代管執行個體群組設定內部負載平衡。

  7. 設定排程工作，定期建立永久磁碟快照。

在需要替換資料庫執行個體時，這個設定將會自動執行下列工作：

  • 在同一可用區中提供另一個正確版本的資料庫伺服器。
  • 將具有最新備份與交易記錄檔案的永久磁碟，連結到剛建立的資料庫伺服器執行個體。
  • 儘可能避免重新設定為回應事件而與資料庫伺服器進行通訊的用戶端。
  • 確保套用到實際工作環境中資料庫伺服器的 Google Cloud 安全控管 (身分與存取權管理政策或防火牆規則) 也會套用到經過復原的資料庫伺服器。

由於替代執行個體是從執行個體範本建立，原本套用的控制設定也會套用到替代執行個體。

在這個情況下，系統將會採用Google Cloud提供的某些 HA 功能。您不需要啟動任何容錯移轉步驟，因為這些步驟會在發生災難時自動執行。內部負載平衡器可確保即使需要替代執行個體，資料庫伺服器也會使用相同的 IP 位址。執行個體範本和自訂映像檔，可確保替代執行個體的設定與被替換的執行個體完全相同。透過定期擷取永久磁碟的快照，您可確保從快照重新建立磁碟並連結至替代執行個體時，替代執行個體會根據快照頻率指示的 RPO 值使用復原的資料。在此架構中，系統也會自動復原寫入永久磁碟的最新交易記錄檔。

代管執行個體群組提供深度的 HA，可以提供相關機制，以便在應用程式或執行個體層級發生失敗時做出回應，因此，在發生這些情境時，您不需要手動介入。將目標大小設為 1，可確保您永遠都只會有一個執行個體在代管執行個體群組中執行，並提供流量。

標準永久磁碟為區域磁碟，所以如果發生區域失敗，則需使用快照來重新建立磁碟。您也可以跨地區使用快照，將磁碟還原到其他地區，就像在同一地區還原一樣輕鬆。

這項設定的變化是使用地區永久磁碟而非標準永久磁碟。在此情況下，您不需要在復原步驟中還原快照。

您的選擇取決於您的預算及 RTO 與 RPO 值。

從部分損毀的超大型資料庫中復原

永久磁碟非同步複製提供低 RPO 和低 RTO 的區塊儲存空間複製功能，適用於跨區域主動-被動式災難復原。這個儲存空間選項可讓您在基礎架構層級管理 Compute Engine 工作負載的複製作業，而非在工作負載層級管理。

如果使用的資料庫能夠儲存 PB 規模的資料量，則資料庫服務中斷可能會影響到部分資料，但不至於全部資料都受影響。在此情況下，您應該盡量減少需要還原的資料量；您不需要 (也不會想要) 為了還原部分資料而復原整個資料庫。

以下是您可以採取的幾個緩解策略。

  • 將資料按照特定時間範圍儲存於不同的資料表。這個方法可確保您只需要還原資料子集到新資料表，不用還原整個資料集。

  • 將原始資料儲存於 Cloud Storage。這樣一來，您就能建立新的資料表，並重新載入未損毀的資料。接著，您可以調整應用程式以指向新的資料表。

此外，如果 RTO 允許，您可以將應用程式設為離線來避免存取具有損毀資料的資料表，直到未損毀的資料還原到新資料表為止。

Google Cloud上的代管資料庫服務

本節探討您可以採用的一些特定方法，以針對Google Cloud上的代管資料庫服務實作適當的備份與復原機制。

代管資料庫採用可調整規模的設計，因此通常不會有傳統 RDMB 中的傳統備份與還原機制。如同自我管理資料庫，如果您採用的是能夠儲存 PB 規模資料量的資料庫，則需要儘可能減少 DR 情境中需要還原的資料量。已有針對各個代管資料庫提供各種策略來協助您達到這個目標。

Bigtable 提供 Bigtable 複製功能。複製的 Bigtable 資料庫可提供比單一叢集更高的可用性、額外的讀取總處理量、更高的耐用性，還能在出現區域性故障時提供復原能力。

Bigtable 備份是全代管服務，可讓您儲存資料表結構定義與資料的副本，日後再從備份還原至新的資料表。

您也可以將資料表從 Bigtable 匯出為一連串的 Hadoop 序列檔案。 接著，您可以將這些檔案儲存於 Cloud Storage，或用於將資料匯回 Bigtable 的其他執行個體。您可以透過非同步方式，將 Bigtable 資料集複製到 Google Cloud 地區內的各個區域。

BigQuery：如要封存資料，可利用 BigQuery 的長期儲存功能。如果資料表連續 90 天都未經編輯，系統會自動將儲存空間價格調降 50%。當系統將特定資料表的使用方式歸類為長期儲存模式時，其效能、耐用性、可用性或任何其他功能都不會降低。不過，資料表經過編輯之後，就會恢復為標準儲存價格，先前累計的 90 天閒置期也會重新開始計算。

BigQuery 會複製到單一區域中的兩個可用區，但這無法解決資料表損毀的情形。因此，您需要能夠從這個情境復原的計畫。舉例來說，您可以執行以下操作：

  • 如果是在過去 7 天內發生損毀，請查詢過去時間點的資料表，以使用快照修飾符復原損毀前的資料表。
  • 從 BigQuery 匯出資料，然後建立包含匯出資料但排除損毀資料的新資料表。
  • 將資料按照特定時間範圍儲存於不同的資料表。這個方法可確保您只需要還原資料子集到新資料表，不用還原整個資料集。
  • 在特定時間範圍內複製資料集。如果資料損毀事件發生時間超出時間點查詢可擷取的範圍 (例如超過 7 天前)，您可以使用這些副本。您也可以將資料集從一個區域複製到另一個區域，確保區域發生故障時資料仍可存取。
  • 將原始資料儲存於 Cloud Storage，這可讓您建立新的資料表並重新載入未損毀的資料。接著，您可以調整應用程式以指向新的資料表。

Firestore。代管的匯出與匯入服務可讓您使用 Cloud Storage 值區匯入與匯出 Firestore 實體。您可以藉此實作復原意外刪除資料的程序。

Cloud SQL。如果使用 Cloud SQL (全代管的Google Cloud MySQL 資料庫)，您應針對 Cloud SQL 執行個體啟用自動備份與二進位檔記錄。這個方法可讓您執行時間點復原，從備份中還原資料庫，並復原到新的 Cloud SQL 執行個體。詳情請參閱「關於 Cloud SQL 備份」和「關於 Cloud SQL 中的災難復原 (DR)」

您也可以在 HA 設定和跨區域備用資源中設定 Cloud SQL，在可用區或區域發生故障時，儘可能延長運作時間。

如果您為 Cloud SQL 啟用幾乎無須停機的預定維護作業，可以模擬 MySQL 適用的 Cloud SQL 和 PostgreSQL 適用的 Cloud SQL 執行個體，瞭解維護事件對執行個體的影響。

如果是 Cloud SQL Enterprise Plus 版本，您可以運用進階災難復原 (DR) 功能，在執行跨區域容錯移轉後，簡化復原和回復程序，且不會遺失任何資料。

Spanner。您可以使用 Dataflow 範本將資料庫完整匯出到 Cloud Storage 值區中的一組 Avro 檔案，並使用另一個範本將匯出的檔案重新匯入新的 Spanner 資料庫。

如需更多受控管的備份，您可以在 Dataflow 管道中使用 Dataflow 連接器，撰寫程式碼以讀取資料並將資料寫入到 Spanner。例如，您可以使用連接器將資料從 Spanner 複製到 Cloud Storage 作為備份目標。從 Spanner 讀取 (或寫入) 資料的速度會根據設定的節點數而有所不同。這會直接影響 RTO 值。

您可以利用 Spanner 修訂時間戳記功能，僅選取自上次完整備份後新增或修改的資料列，在執行增量備份時將可派上用場。

對於代管備份，Spanner 備份與還原可讓您建立一致的備份，最多可保留 1 年。與匯出作業相比，還原作業會直接掛接備份，而不複製資料，因此 RTO 值較低。

對於低 RTO 值，您可以設定暖待命的 Spanner 執行個體，並為其設定最低限度的必要節點數，以滿足儲存空間以及讀取與寫入總處理量需求。

Spanner 時間點復原 (PITR) 功能可讓您復原過去特定時間點的資料。舉例來說，如果運算子不慎寫入資料，或應用程式推出時損毀資料庫，您可以使用 PITR 從過去的時間點復原資料，最多可復原 7 天前的資料。

Cloud Composer：您可以使用 Cloud Composer (代管版本的 Apache Airflow) 安排多個Google Cloud 資料庫的定期備份。您可以建立有向非循環圖 (DAG)，並設定排程 (例如每日執行) 來固定將資料複製到另一個專案、資料集或資料表 (視使用的解決方案而定)，或是將資料匯出至 Cloud Storage。

有各種不同的 Cloud Platform 運算子可用來匯出或複製資料：

舉例來說，您可以建立 DAG 來執行下列任一工作：

實際工作環境為另一個雲端

在此情境中，實際工作環境採用另一個雲端服務供應商，且災難復原計畫需要使用 Google Cloud 做為復原站點。

資料備份與復原

在物件存放區之間移轉資料是 DR 情境的常見使用案例。 Storage 移轉服務與 Amazon S3 相容，建議您可以採用這個方法來將物件從 Amazon S3 移轉至 Cloud Storage。

如要設定移轉工作，請使用進階篩選器，依據檔案建立日期、檔案名稱篩選器，以及您偏好的資料移轉時間，安排從資料來源到資料接收器的週期性同步處理作業。如要達到所需的 RPO，請務必考量下列因素：

  • 變化率：在指定時間內產生或更新的資料量。變更率越高，在每個增量轉移期間，將變更轉移至目的地所需的資源就越多。

  • 轉移成效。檔案傳輸所需時間。如果是傳輸大型檔案，通常取決於來源和目的地之間的可用頻寬。不過，如果轉移作業包含大量小型檔案，QPS 就可能成為限制因素。如果是這種情況，只要有足夠的頻寬，您就可以排定多個並行工作，以提升效能。建議您使用實際資料的代表性子集，評估移轉作業的效能。

  • 頻率。備份工作之間的時間間隔。目的地資料的更新時間，與上次排定移轉工作的時間相同。因此，連續轉移作業之間的時間間隔不得超過 RPO 目標。舉例來說，如果 RPO 目標是 1 天，則轉移作業的排程必須至少每天執行一次。

  • 監控與快訊。Storage 移轉服務會在發生各種事件時提供 Pub/Sub 通知。建議您訂閱這些通知，以便處理非預期的失敗或工作完成時間異動。

資料庫備份與復原

第三方資料庫所包含的各種內建備份與復原機制，或其他雲端服務供應商使用的備份與復原技術，不在本文的探討範圍之內。如果在運算服務上執行的是非代管資料庫，您可以妥善利用實際工作環境的雲端服務供應商提供的 HA 設施。您可以延伸這些設施以將 HA 部署整合至 Google Cloud，或使用 Cloud Storage 作為資料庫備份檔案冷儲存的最終目的地。

後續步驟