ここで取り上げるワークロードに対し、Google Cloud では 4 つの一般的なネイティブバックアップ方法を提供しています。Persistent Disk のスナップショットはディスクを保護します。Backup and DR Service は、バックアップボールトを通じて VM や、いくつかのデータベースおよびファイルワークロードを保護します。Backup for GKE は Kubernetes ワークロードを保護します。また、Cloud SQL は独自の標準的なバックアップ機能を提供しています。
まず、利用するワークロードによって利用可能な選択肢が絞り込まれます。そこから、最も重要な質問の一つは、「バックアップデータをどこに、どのように保存したいか」ということです。
この質問によって、リカバリの選択肢、コンプライアンスの状況、そして請求額の大部分が決まります。
Googleが標準で提供している機能
| サービス | 保護 | バックアップの保存場所 | イミュータブル |
| Persistent Diskのスナップショット | Compute Engineのディスク | Googleが管理するバックアップ保管庫 | ネイティブロックなし |
| バックアップとDRサービス | Compute Engine, Cloud SQL, AlloyDB, Filestore (console); VMware Engine, Oracle, SQL Server (appliance) | Googleが管理するバックアップ保管庫 | 不変で、消去不可能なもの |
| Backup for GKE | GKE クラスタとボリューム | Google管理 | 削除ロックの有無は選択可能；最長90日間 |
| Cloud SQL標準バックアップ | Cloud SQLインスタンス | Googleが管理しており、インスタンスの削除後もバックアップを保持することができます。 | NO |
出典：GoogleのBackup Vaultに関するドキュメント
Persistent Diskのスナップショット
スナップショットは増分形式であるため、後続のスナップショットにはディスクの完全なコピーではなく、変更されたデータのみが保存されます。課金対象となるのは、ソースディスクの割り当て済み容量全体ではなく、スナップショットとして実際に使用されたストレージ容量です。スナップショットはプロジェクトに関連付けられ、IAMの権限によって管理されます。また、デフォルトではグローバルスコープであるため、復元先を制限しない限り、他のリージョンでディスクを作成するために使用できます。
ただし、スナップショットには保持ロック機能がありません。スナップショットの削除権限を持つユーザーなら誰でも削除できるため、攻撃者がユーザーの認証情報を入手しているランサムウェア攻撃のシナリオでは、これが大きな問題となります。
スナップショットのスケジュール機能は自動化に対応しています。ただし、それだけではアプリケーションの一貫性は保証されず、復元された VM が接続するために必要なネットワークを再構築することもありません。
バックアップおよび DR サービス
これは、Google が 2020 年に買収した Actifio の技術に基づいて構築された、Google のマネージドバックアップ製品です。重要な設計上の決定事項は、バックアップ・ヴォールトです。
バックアップ・ヴォールト（Vault）とは、Googleが管理する隔離されたストレージリソースであり、リージョン単位、またはサポート対象のワークロードの場合はマルチリージョン単位で構成可能です。ここに書き込まれたバックアップは不変（変更不可）かつ不可消去（保持期間が満了するまでは削除不可）であり、強制される最低保持期間はヴォールトの作成時に設定されます。ヴォールトの強制される最低保持期間は最大99年まで設定可能ですが、サポートされる範囲はワークロードによって異なります。
これはまさに強力なランサムウェア対策と言えます。その代償として、ストレージ層に対する制御権が制限されます。バックアップ・ヴォールトのストレージは、顧客管理型のスナップショットやCloud Storageリソースとして公開されるのではなく、Googleによって運用・隔離されます。
ヴォールト自体は依然としてGoogle Cloudプロジェクト内に存在し、Google Cloud IAMを通じて制御されます。バックアップを顧客管理型のストレージリソース内に保持することが具体的に要件となっている場合、このヴォールト・モデルでは要件を満たせない可能性があります。
対応するワークロードは2つに分かれます。Compute Engineのインスタンスとディスク、Cloud SQL、AlloyDB、Filestoreは、Cloudコンソールから管理されます。VMware EngineのVM、Oracle、SQL Serverは、管理コンソールアプライアンスを通じて管理されます。
GKE および Cloud SQL のバックアップ
Backup for GKE は、バックアップ計画に従って Kubernetes リソースの設定および永続ボリュームのデータを取得します。Cloud SQL は自動バックアップとオンデマンドバックアップをサポートしており、保持期間は選択したバックアップオプションによって異なります。標準バックアップではインスタンス削除後の保持期間を設定できますが、拡張バックアップでは Cloud SQL を Backup および DR バックアップ・ヴォルトと統合します。
実際に重要な4つの判断
データがどこに保存されるか。 あなたのプロジェクトか、それともGoogleのものか。これが他のすべての要素を左右するものであり、多くの比較記事が見落としがちな唯一の視点です。
削除可能かどうか。 PDスナップショットは削除可能です。バックアップ・ヴォルト(vault )の内容は、保存期間が満了するまでは削除できません。ランサムウェア復旧計画を策定する場合、この違いこそが計画の要となります。
コピーがどの程度遠くまで移動するか。 同一リージョン内のコピーでは、リージョン全体の障害から身を守ることはできません。リージョン間の保護により、地理的な隔離が図られます。また、権限が適切に分離されていれば、プロジェクト間の隔離により、侵害された本番プロジェクトの影響範囲を縮小することも可能です。
実際に支払っている費用。 実際に支払っている費用はサービスによって異なります。スナップショットやVaultのストレージ料金、サービス固有の管理料、アーカイブスナップショットの取得手数料、データがロケーション間を移動する際のネットワーク転送料などが適用される場合があります。料金の内訳では、具体例を用いてこれらの構成要素について解説しています。
サードパーティ製バックアップの適応場面
GCPのみの環境において、ワークロードのカバー範囲、分離、およびストレージ管理の要件がGoogleのネイティブサービスで満たされる場合、ネイティブツールは妥当なデフォルトの選択肢となります。
通常、以下のいずれかの要件が生じた場合、チームは他のソリューションを探し始めます：
- 主権や契約上の理由から、バックアップを顧客が所有するストレージに保管する必要がある
- 単一のコンソールからクラウドを横断して、GCPに加えAWSやAzureもカバーする単一のバックアップポリシーが必要である
- クロスクラウドのコピーがエアギャップ要件であり、GCPのネイティブ機能ではこれを満たせない
N2WSは、バージョン5.0よりGCPにおいて最初の2つの要件に対応しています。このソフトウェアは顧客自身のGCPプロジェクト内で動作するため、スナップショットはマネージド・ヴォールトではなく顧客のアカウント内に保存され、GCP Compute EngineのVMやディスクは、顧客のAWSおよびAzureワークロードと同じコンソールおよびポリシーモデルで管理されます。
Cloud SQL、GKE、Filestoreは対象外であるため、GCP環境がCompute Engine以外にも広がっているユーザーには、Googleのネイティブサービスの方が適しています。スナップショットのコピーは、単一のソースからリージョンをまたいで実行され、保存するための 2 つ目のコピーは生成されません。バージョン 5.0 では、VM は元のリージョンに復元されますが、個別に保護されたディスクは任意の場所に復元可能です。
N2WS は、すでにネイティブのスナップショットスケジュールが設定されている Compute Engine ディスクも識別するため、請求書に反映される前に重複保護が実施されます。
RSSフィードを取得する
