2022.05.18

【図解】Google Cloud（GCP）でVM のバックアップを取る方法をわかりやすく解説！

Cloud
VM
バックアップ

Google Cloud（GCP）は、「マシンイメージ」というバックアップ方法を提供しています。AWS クラウドのAMI（Amazon Machine Image）と類似の仕組みですが、これにより、VM（仮想マシン）のバックアップ、復元等の方法がシンプルになり、管理に費やす時間を削減できます。

本ブログでは、VM のバックアップを例に、メリットとデメリット、具体的な手順を解説します。

Google Cloud（GCP）とは？

Google Cloud（GCP）は、Google 社の技術をベースに提供されるクラウドサービスです。

等の多くのサービスがラインナップされ、そのビジョンや実行能力は、競合の多いクラウドマーケットにおいても高い評価を受けています。

（Google が 2021 年の Gartner マジッククアドラントで Cloud Infrastructure and Platform Services のリーダーに再び選出 | Google Cloud Blog）

特に、マーケットのトップを走るAWS クラウドと比較しても、コスト割引率やメンテナンス時も止まりにくいこと、読みやすい公式ドキュメント、BigQuery に代表されるビッグデータ分析ツールとの連携等のたくさんの優位性があります。

何よりそのオープンな設計思想は、オープンソースとの強い親和性があり、コンテナ業界標準のKubernetes や誰でも機械学習に参加できるTensorFlow 等のさまざまな価値を生み出しています。

GCPについて詳しく理解したい方は以下の記事をご覧ください。

Google Cloud Platform™ （GCP）とは？

VMとは？

「VM」とは、Google Cloud（GCP）のコンピューティングインフラがホスティングする仮想マシンのことで、「VM インスタンス」または「インスタンス」と呼ばれることもあります。

Google Cloud（GCP）では、Linux やWindows server 等のOS のイメージ（公開イメージ）を提供しており、それらを使用してVM を作成することができます。

他にも、ユーザー自身が独自にカスタマイズしたイメージ（カスタムイメージやマシンイメージが選択できる）を利用することもできます。各イメージについては、後述します。

Google Cloud（GCP）でVMのバックアップを取る理由

障害対策としてのバックアップ取得

Google Cloud（GCP）で作成されたVM のバックアップは、下記のような場面の対策に必要になります。

VM で稼働しているOS がクラッシュしてしまった（誤ってOSの重要なファイルを削除してしまった等も含みます）
ソフトウェアをバージョンアップもしくはパッチをあてたら、その後の動きがどうもおかしい

予期せぬ不具合や、操作ミスを回復させたい。ソフトウェアの挙動を元に戻したい。こうした場面は不定期に（往々にして納期間際に）訪れますが、VM のバックアップ対策をとることで、これらの障害に時間をかけず、確実に回復できます。

ただし、下記のような場面については、本ブログで解説するVM 、ディスク単位のバックアップ方式ではなく、ファイル単位、DB単位のバックアップが向いています。

作業中のデータファイルを削除してしまった（ごみ箱からも消してしまった）
データベースの中のテーブルを誤って削除してしまった（復旧コマンドも間に合わなかった）

ファイル単位、DB単位でのバックアップは以下の記事で詳しく解説しておりますので、あわせてご覧ください。

バックアップの種類からGoogle Cloudでデータのバックアップを行う方法を徹底解説！

バックアップからの復旧にあたっては、詳細に計画する場合、下記観点を整理します。

①　RPO（目標復旧時点）
②　RTO（目標復旧時間）
③　完全復旧までの残作業

まず、①と②は、「どの時点の状態」に「いつまでに」戻すか、という観点です。

例えば、少なくとも「昨日の12:00の状態」には戻せるようにバックアップを毎日12:00にとると決めることが①。

それらのバックアップデータを使って、「2時間以内」に「昨日の12:00の状態」に戻せるよう準備するのが②となります。

Google Cloud（GCP）のバックアップは、①②のコスト、時間を簡単に削減することができます。

ただし、「昨日の12:00の状態」から障害が起きた今日の時点までに作成、更新されたデータについては、ある程度手動で復旧作業が必要で、この場合はファイルバックアップ等の方法を併用します。これが③で、ここまで完了すると完全復旧となります。

同一環境を作成するためのバックアップ取得

VM はクローンを作成することができます。例えば、開発者チームに、新規メンバーがジョインした際、既存メンバーと同等のVM を使ってもらいたい場面があると思います。

こうした場面では、既存メンバーが使っているVM のマシンイメージを取得し、クローンを作成し、新規メンバーに提供できます。（既存メンバーA のVM と同一環境を、新規メンバーB に提供できる）

あるいは、OSに必要なディスクを追加し、開発に利用するソフトウェアのインストールや初期設定を完了させた時点で、マシンイメージを取得しておき、ここから開発メンバーにクローンを提供します。

このようなマシンイメージは、ゴールデンイメージとも呼ばれます。（既存メンバーのVM のマシンイメージを利用するケースと比較して、新規メンバーにとって不要なデータが含まれていない）

Google Cloud（GCP）で取得できる3つのバックアップ

gcp-vm-backup-1

スナップショット

スナップショットとは、VM の個々の永続ディスク（VM を停止してもデータが消えない）のバックアップを取得できます。VM には、複数のディスクがアタッチされていることがあります。（例：Windows のCドライブ、Ｄドライブ等）

これらのディスクを指定してバックアップをとる場合は、スナップショットを利用します。

スナップショットは、1回目はディスクのフルバックアップを取得しますが、2回目以降は、前回バックアップからの増分データのみを取得できるため、データ量や取得時間を削減できます。

上記メリットがありますが、スナップショットは、ディスク単位のバックアップであり、ファイル単位の細かなバックアップはできません。また、CドライブとDドライブにまたがるようなデータがある場合、データの整合性を注意しながらスナップショットを取得する必要があります。VM目線ではなく、個々のディスク目線でバックアップ計画を立てる際に採用される方式です。

カスタムイメージ

カスタムイメージも、ディスク目線のバックアップですが、取得対象はブートディスク（例：Windows のCドライブ）を指定します。それによって作成されたものが、カスタムイメージと呼ばれ、このイメージを使って、VM を新規作成できます。

事前にソフトウェアを導入（例：Cドライブに各種アプリケーションをインストール）した上で、カスタムイメージを作成すれば、Google Cloud（GCP）が提供している素のOSイメージである公開イメージからVM を作り直す必要はなくなります。

ただ、その範囲はブートディスクのみであり、VM 構成の一部分しかイメージ化できませんでした。

この不満を解消したのが、2020年3月に発表されたマシンイメージです。
マシンイメージで Compute Engine インスタンスを簡単に作成 | Google Cloud Blog

マシンイメージ

マシンイメージは、カスタムイメージの不満を解消したバックアップといえるもので、「VMに接続されたすべてのディスク」について整合性※をとりながら、状態や属性情報（プロパティ、メタデータ等）というVM 構成の大部分を取得できます。

なお、メモリ内のデータやコンピュータ名、IPアドレス等、固有のデータはバックアップ対象から除外されます。これはVM のクローンを作成しやすくするためでもあります。

AWS クラウド経験者の方には、AMI（Amazon Machine Image）と類似の仕組みというのが、わかりやすいかと思います。

※各ディスクのスナップショットを同一タイミングで取得するが、アプリケーションレベルの整合性の保証はない点に注意（アプリケーションレベルの整合性保証は、OS機能等との合わせ技が必要）

Google Cloud（GCP）で取得できる3つのバックアップの比較

下表のとおり、カスタムイメージは差分バックアップによるコスト削減もないため、VM バックアップの場面では、マシンイメージに置き換えられるものと考えられます。

スナップショットについては、個々のディスク単位でバックアップがとれるため、ディスクバックアップの場面で利用が継続されます。

バックアップ・シナリオ	マシンイメージ	スナップショット	カスタムイメージ
単一ディスクのバックアップ	〇	〇	〇
複数ディスクのバックアップ	〇	×	×
差分バックアップ	〇	〇	×
インスタンスのクローン作成	〇	×	〇

出典：Google Cloud ドキュメント

VM バックアップにマシンイメージが最適な3つ理由

環境管理がシンプル

VM を複数ディスク、状態、属性情報ごと、まるっとバックアップ取得できるため、個々のディスクを意識して管理する必要がなくなります。
このため、どのバックアップを使って復元するかという管理にかける時間が削減できます。

ゴールデンイメージとして

OS にソフトウェアやアプリケーションを導入し、チームやプロジェクトの基本イメージとして位置づけることが可能です。これにより、新規メンバーへのVM クローン提供や、VM が不足したシステムに対し迅速に追加VM を提供できます。

プロジェクト間の共有が可能

特定のプロジェクトで作成したマシンイメージは、他のプロジェクトにも共有することができます。

これにより、マシンイメージを管理するメンバーと、マシンイメージを使うメンバーを分離することができ、チームごとにマシンイメージを管理することも避けられます。

マシンイメージ利用のデメリット3つ

デメリットはどのようなものがあげられるでしょうか。

バックアップ取得に時間がかかる

基本的に、2回目以降のマシンイメージ取得は、差分バックアップとなり、バックアップ取得時間は削減できます。

ただ、仕組みとして、差分のデータサイズが大きくなればなるほど、取得時間は増加していきます。

マシンイメージはVM を無停止で取得できますが、ソフトウェアやアプリケーションの安定を考えると、VM を停止して取得すべきなので、差分データ量が大きいVM については、取得時間増加について注意が必要です。

部分的なバックアップができない

前述のとおり、ファイルやデータベースを指定したバックアップには対応できません。取得したいデータに応じたバックアップ方式を選択する必要があります。

費用が割高になる

Google が提供する公開イメージの保管費用はGoogle 負担となりますが、マシンイメージの保管費用はユーザー負担となり、費用はサイズと保管場所（リージョン）によって異なります。

東京リージョンに保管することを例に試算してみます。2022年2月時点のマシンイメージの保管費用は下記のとおりです。

マシンイメージ（GB 単位/月）　$0.065

出典：Google Cloud ドキュメント（マシンイメージの費用）

1USドル=120円とすると、40GBのマシンイメージの場合、年間約 3744円（税別）かかります。

不要なマシンイメージは削除していく管理が必要になります。

実際にマシンイメージを取得してみよう

それでは、マシンイメージの取得を試してみましょう。今回はGUI のGoogle Cloud コンソールから操作してみます。

トップページのナビゲーションメニューから Compute Engine を選択します。
Compute Engine のナビゲーションメニューから、VM インスタンスを選択し、マシンイメージを取得したいインスタンスを確認します。（ここでは「vm1」とします※1）
Compute Engine のナビゲーションメニューから、マシンイメージを選択し、表示された画面上段にある「マシンイメージを作成」を選択します。
マシンイメージの作成画面では、名前、説明、ソースVMインスタンス（ここでは「vm1」となります）、ロケーション（ここでは東京リージョンを指定しています）を入力します。名前、説明はバージョン管理ができる名称がおすすめです。
その他はデフォルト値のままとし、「CREATE」ボタンを選択します。

※1 マシンイメージはVM が起動していても取得できますが、通常、シャットダウン（ステータスが「このインスタンスは停止しています」の状態）して、バックアップの静止点をとります。

gcp-vm-backup-2