【図解】バックアップの種類からGoogle Cloud（GCP）でファイルやDBのバックアップを行う方法を徹底解説！
- Cloud
- データベース
- バックアップ
データを誤って紛失してしまったり、誤操作でデータを破損してしまったりした際に、役立つバックアップ。
この記事をご覧になられている方は、その重要性について重々理解されているかと思います。
本記事では、
- バックアップを行うべき理由
- バックアップの3つの種類の説明
- バックアップの対象となるデータの説明
- Google Cloud (GCP)で実際にバックアップを行う方法
についてご紹介していきます。
実際の方法に関しては、写真も添付しておりますので、参考になるかと思います。ぜひ、最後までご覧ください。
VMのバックアップ方法に関しては以下の記事で図解で分かりやすくご紹介しております。
【図解】Google Cloud（GCP）でVM のバックアップを取る方法をわかりやすく解説！
目次
バックアップを行うべき3つの理由
ITサービスを利用するうえで欠かせないのがデータのバックアップです。もちろん、感覚的にバックアップが必要ということは理解していますが、どういったケースで必要となるのでしょうか？改めて代表的なものを整理してみましょう。
ハードウェア（ディスク）の故障
Google Cloud (GCP)などのパブリッククラウドサービスではあまり意識しないことが多くなりましたが、結局の所、クラウドサービスも世界のどこかの物理サーバーで稼働しています。サービス側でデフォルトで冗長構成（二重化）が取られていることも多くなってきましたが、データセンター単位の障害でデータをロストした、という事例も過去には存在しています。
このように、物理的な障害においてバックアップが必要となるケースがあるでしょう。クラウドサービスではデータの保存場所をリージョンという単位で選べるため、バックアップ対象の元データの利用場所と、バックアップデータを保管する場所は、可能であれば分けたほうがいいでしょう。
例えば、元データを日本でホストしている場合、バックアップデータはアメリカのデータセンターに格納する、といった形です。
サービス構築・運用中での人為的なミス
クラウド上で稼働する、しないにかかわらず、ITサービスを利用するうえで、機能の追加やメンテナンスといったことを行う必要があると思います。その際に人為的なミスにより必要なデータを削除してしまったり、書き換えてしまったりといったことが発生する可能性があります。
この場合、作業をする前のデータをバックアップしておくことで、仮に予期せぬデータの変更が発生してしまった場合でも、データの状態を元に戻すことが可能です。これには、作業をする前にはバックアップを必ずとる、という運用の取り決めもセットで必要になってくるため、ルール作りも必要となってきます。
外部からの攻撃によるデータ破壊
大規模なサービスを運営している場合などは、内部だけではなく外部からの攻撃にも気を払わなければなりません。ウィルスやマルウェアの感染などにより、データを破壊される可能性があります。
このような攻撃を受けた場合、サービスの防御とともに、影響を受けた箇所の点検、必要に応じてある前のデータ状態に状態を戻す必要性が出てきます。
バックアップの種類
バックアップには大きく分けて3つの種類があります。Google Cloud(GCP)を利用するうえでは特に意識する必要はありませんが、基礎的な知識として理解をしておくといいでしょう。
フルバックアップ
フルバックアップとは、文字通りその時点での全データをバックアップする方法です。
その時点でのバックアップをすべて取得するため、例えば上の図において木曜日時点にデータを戻したい場合は④のデータ1つを選択してバックアップをすることで、木曜日時点に戻ります。
差分バックアップ
差分バックアップとは、ある時点のフルバックアップから生じた差分データのみをバックアップする方法です。
基本的にバックアップを行う場合は、フルバックアップ＋その時点のデータを選択することとなります。一つ上の見出しのフルバックアップと同じように木曜日を例にとると、木曜日時点までデータを戻したい場合は、月曜のフル①と、木曜の差分③のデータを選択してバックアップすることとなります。
ある特定のタイミングからの差分データのみをバックアップするため、フルバックアップデータよりはバックアップデータの保存容量が少なくなります。しかし、万が一フル①のデータなどが欠損すると、全体のバックアップが行えなくなります。
増分バックアップ
増分バックアップとは、ある時点のフルバックアップから生じた増分のデータのみをバックアップする手法です。
上の図を例にとり、木曜日時点にデータを戻すと仮定してます。この時増分バックアップで必要となるデータはフル①＋増分①＋増分②＋増分③となります。データの増分だけを保存していくため、差分バックアップよりもバックアップ容量は削減されます。ただしバックアップに必要なポイントも多いため、どこか途中のデータが一つ欠損してもバックアップが行えなくなります。
このように、バックアップ方式は保存に必要な容量と、バックアップデータを損失した時のリスクとのトレードオフとなります。その点を踏まえた上での設計を行う必要があります。
バックアップの対象
バックアップの対象となるデータについて、代表的な2つを紹介します。
データベース
システムを構築するうえでデータベースの損失はあってはならないものです。Webシステムであれば顧客情報やサイトを構成するスキーマが入っていたり、AmazonのようなECサイトでは商品情報や価格、ユーザデータなどが含まれていることでしょう。
今回、Google Cloud (GCP)上で提供されているデータベースサービスとして、Cloud SQLという名称のサービスがあります。こちらはPaaS型のデータベースサービスで、「Google Cloud(GCP)でのデータベースのバックアップ方法」にて、バックアップについて取り上げます。
ファイルストレージ
ファイルストレージは、階層型にデータを整理するためのストレージです。仮想マシンにマウントすることで、共有フォルダのように活用できます。ファイルを複数人で共有するうえで必要であり、作成したドキュメントなどを保管しておくことが多いと思います。
こちらも、過去のドキュメントなどの損失を防ぐためにバックアップの対象となります。Google Cloud (GCP)ではFilestoreが代表的なファイルストレージサービスであり、「Google Cloud(GCP)でのファイルストレージのバックアップ方法」にて、バックアップについて取り上げます。
Google Cloud(GCP)でのデータベースのバックアップ方法
バックアップ方式
こちらで取り上げるバックアップは、増分バックアップとなります。
Google Cloud (GCP)の公式ドキュメントにも記載がありますので参考にしていただければと思います。
Cloud SQL のバックアップは増分バックアップです。このバックアップには、前回のバックアップの作成後に変更されたデータのみが含まれます。最も古いバックアップはデータベースと同様のサイズですが、その後のバックアップのサイズはデータの変更の割合によって異なります。最も古いバックアップが削除されると、完全なバックアップを維持するため、その次に古いバックアップのサイズが増加します。
事前準備
まずバックアップ対象となる Cloud SQL を作成します。Google Cloud Consoleにログインして、左側のブレードから「SQL」を選択し、「インスタンスの作成」をクリックします。
SQLサービスの種類が表示されますので、今回は「MySQL」を選択します。
次にインスタンスのパラメータ入力画面が表示されますので、今回は以下のようにします。
| 項目 | 設定値 |
|---|---|
| インスタンスID | test-mysql |
| パスワード | 任意の値 |
| データべースのバージョン | MySQL 5.7 |
| リージョン | us-central1（アイオワ） |
作成が終わると次のように表示されます。
画面右上の左から2番目のアイコン、「Cloud Shellをアクティブにする」をクリックします。
ブラウザの下に以下の画面が立ち上がりますので、「続行」をクリックします。
以下のようなコンソール画面が立ち上がりますので、
$ gcloud sql connect インスタンス名（今回の記事ではtest-mysql） --user=root
と入力してエンターを押してください。
すると、Cloud Shellの承認 というポップアップが立ち上がりますので、「承認」をクリックしてください。
APIを有効にするか聞かれますので、yを入力し、エンターを押すと先に進んでいきます。次に、rootのパスワードを聞かれますので、データベース作成時に設定したパスワードを入力してエンターを押します。少し待つと、
mysql>
というmysqlに接続できた後のプロンプトが返されます。これで作成したCloud SQLに接続できました。
さて、ここまででSQLへの接続が完了しましたが、Cloud SQLのバックアップを試すために、一つデータベースを作成します。デフォルトでは以下のようなデータベースが存在しています。
そこで、バックアップ機能を試すためのデータベース「backuptest」を作成します。
こちらで事前準備が完了しました。この状態でCloud SQLのバックアップ設定を行い、先ほど作成したテストデータベース「backuptest」を削除します。その後バックアップデータからバックアップした際に、このデータベース上に「backuptest」が存在していれば、正常にリストアが完了していることになります。こちらを次項以降で試していきましょう。
バックアップ設定
左側タブのバックアップ から画面中央の「＋バックアップを作成」をクリックします。
右側にタブが表示されますので、「作成」ボタンをクリックします。
バックアップが開始されますので、少々待機します。
バックアップが完了すると、画面下部に作成した時刻でのバックアップが作成され、正常に実行されていれば左側に緑色のチェックがつきます。
こちらでバックアップは完了です。
検証
バックアップが完了しましたので、まずは先ほど作成したデータベースを削除してみましょう。バックアップ後にbackuptestが復元されていれば、成功しているといえます。
先ほどとったバックアップデータから復元を行ってみましょう。画面右側の「復元」ボタンをクリックします。
確認画面が表示されます。最終確認としてインスタンス名を入力する必要があるため、「test-mysql」と入力し、「復元」をクリックします。
復元が実行中の状態になるので、少々待機します。
復元が完了すると、概要ページのインスタンス名の左横に緑色のチェックがつきます。
復元完了後に、再度データベースを確認すると、先ほど削除したデータベース「backuptest」が復元されていることがわかります。これでCloud SQLのバックアップが正常に完了しました。
次に、ファイルストレージのバックアップについて見ていきましょう。
Google Cloud(GCP)でのファイルストレージのバックアップ方法
バックアップ方式
明記はされておりませんが、バックアップの作成の記述から増分バックアップがなされていると思われます。
リージョン内のバックアップは、以前のバックアップに追加する形で作成されます。つまり、最初に作成したバックアップはファイル共有の完全なコピーですが、その後のバックアップには、前回のバックアップに含まれていない新規データまたは変更されたデータのみが含まれます。
以前のバックアップに含まれる未変更データは、新しいバックアップで参照されますが、コピーされません。古いバックアップが削除されると、その特異データが次の最新バックアップにコピーされ、すべての内部データ参照が自動的に更新されます。
事前準備
まずはバックアップ対象となるFilestoreを作成します。Google Cloud Consoleにログインして、左側のブレードから「Filestore」を選択し、「インスタンス」をクリックします。
次に、画面上部の「インスタンスを作成」を押して、インスタンスの作成画面に進みます。
インスタンスの作成に関して、パラメータの入力が必要となりますので、今回検証のために以下のように入力します。以下で言及していない点は、基本的にデフォルト値のままとなっています。
| 項目 | 設定値 |
|---|---|
| インスタンスID | test1 |
| 容量の割り当て | 1 |
| リージョン | us-central-a |
| ゾーン | us-central-a |
| ファイル共有の構成 | file1 |
以下のようなFilestoreインスタンスが作成されました。
このインスタンスを仮想サーバにマウントします。今回、詳細は割愛しますが、仮想サーバはGoogle Compute Engine（GCE）を使用しています。仮想マシンにSSHで接続し、以下のコマンドを順に実行します。
- Filestoreファイル共有のマウントディレクトリの作成
sudo mkdir -p /mnt/test
- FilestoreインスタンスのIPアドレスとファイル共有名を指定し、ファイル共有をマウント
sudo mount 10.32.241.178:/file1 /mnt/test
- ファイル共有へのアクセスが可能なように権限変更
sudo chmod go+rw /mnt/test
上記のコマンド実行後、dfコマンドでディスクの状態を見てみると、
10.32.241.178:/file1 1007G 0 956G 0% /mnt/test
として先ほどマウントした１TBのファイル共有が表示されていることがわかります。
バックアップをテストするため、このファイル共有にバックアップ用のtest.txtというテストデータを置いておきます。
こちらで事前準備が完了しました。この状態でFilestoreのバックアップ設定を行い、先ほど作成したtest.txtを削除します。
その後バックアップデータからリストアした際に、このtest.txtが存在していれば、正常にバックアップが完了していることになります。こちらを次項以降で試していきましょう。
バックアップ設定
Filestoreの「インスタンス」から作成したインスタンスの右側の縦に点が３つ並んでいる部分をクリックします。すると「バックアップの作成」という項目があるので、こちらをクリックします。
その後、いくつかの項目を入力し、作成ボタンをクリックします。
| 項目 | 設定値 |
|---|---|
| バックアップID | test2 |
| リージョン | us-central-1 |
バックアップ完了後は以下のように表示されます。
検証
この状態で、先ほどの仮想マシンで作成したtest.txtを削除します。
test.txtは消えてしまいました。こちらが本当に必要なファイルだった場合、復元が必要となります。ではバックアップからFilestoreを復元してみましょう。
Filestoreの「バックアップ」から、先ほどと同様に右側の縦に点が3つ並んだところをクリックすると、「バックアップを復元」が表示されますのでクリックします。
ターゲットインスタンスの選択として、左側に三つの選択肢が表示されますが、今回は「Source Instance」を選択します。ソースインスタンスにバックアップを復元し、先ほど削除したtest.txtがリストアされているか、戻ったかを確認するためです。こちらを選択し、「復元」をクリックします。
確認画面が出ますので、インスタンスIDを入力し、「復元」をクリックします。
復元の実行画面となりますので、完了するまで待機します。
バックアップ復元が完了すると、ステータスが準備完了となります。
再度仮想マシンのディスクを確認してみると、マウントが解除されていますので、５－１で行ったのと同様に、ファイル共有をマウントします。
その後、/mnt/testディレクトリを確認すると、削除したtest.txtが復元されているのがわかります。
バックアップが正常に行われていることが確認できました。
まとめ
今回はGoogle Cloud(GCP)におけるバックアップについて、実例を交えながら確認してみました。バックアップ対象となるものは、どれもITシステムの根幹となる大事なデータです。
バックアップのポリシーを議論し、適切なタイミングでバックアップをとることで、システムの継続性を高めることが可能です。今回の記事がみなさまのご参考になれば幸いです!
弊社トップゲートでは、専門的な知見を活かし、
- Google Cloud (GCP）支払い代行
- システム構築からアプリケーション開発
- Google Cloud (GCP）運用サポート
- Google Cloud (GCP）に関する技術サポート、コンサルティング
など幅広くあなたのビジネスを加速させるためにサポートをワンストップで対応することが可能です。
Google Workspace（旧G Suite）に関しても、実績に裏付けられた技術力やさまざまな導入支援実績があります。あなたの状況に最適な利用方法の提案から運用のサポートまでのあなたに寄り添ったサポートを実現します！
Google Cloud (GCP）、またはGoogle Workspace（旧G Suite）の導入をご検討をされている方はお気軽にお問い合わせください。
メール登録者数3万件！TOPGATE MAGAZINE大好評配信中！
Google Cloud（GCP）、Google Workspace（旧G Suite） 、TOPGATEの最新情報が満載！
