TL;DR
- Minetestのバックアップを取るようにした。
- cronとgsutilを用いてGoogle Cloud Storageにバックアップファイルをアップロードするようにした。
たかだかゲームのデータだがバックアップを取る
秘密基地と称してMinetestのサーバーを建てて、数人でゲームしたりシステムの管理などをして遊んでいる。Minetestには(マイクラ同様)サーバー機能があり、数人で一緒に同時プレイできる。そのデータベースはサーバー内に幾つかのファイルとして保存される。お遊びの一環として使用していただけなので、これまでデータベースはバックアップを取っていなかった。別にもう一度最初から作りなおせばよかったからだ。そのゲームを数ヶ月プレイし、さざまなデータが蓄積されるにつれ、データ自体の重要性が高まってきた。そこで今回はデータベースのバックアップを取ることにする。
構成図
秘密基地のデータベースのバックアップに関連する構成をまとめた。秘密基地は超低価格運用を行っているためそもそも構成要素が少なく、構成もとてもシンプルなものとなった。ゲームサーバ上からcronを用いてデータベースをアーカイブし、Google Cloud Storageにアップロードする。
+---------------------------------------------------------------------+
| |
| us-west1 |
| |
| |
| +-------------+ +-----------------+ +---------------+ |
| | us-west1-a | | us-west1-b | | us-west1-c | |
| | | | | | | |
| | | | +-------------+ | | | |
| | | | | | | | | |
| | | | | Compute | | | | |
| | | | | Engine | | | | |
| | | | | Game server1| | | | |
| | | | | | | | | |
| | | | +------+------+ | | | |
| | | | | | | | |
| | | | | | | | |
| | +------------------------+--------------------------+ | |
| | | | | | |
| | | v | | |
| | | Cloud Storage +------+----+ | | |
| | | Bucket | | | | |
| | | | Backup | | | |
| | | | file | | | |
| | | +-----------+ | | |
| | | | | |
| | | | | |
| | +---------------------------------------------------+ | |
| | | | | | | |
| +-------------+ +-----------------+ +---------------+ |
| |
| |
+---------------------------------------------------------------------+データベースのバックアップ手順
大まかななバックアップの手順をして以下を実施する。
- サービスを停止する。
- ファイルをコピーする。
- サービスを起動する。
- アーカイブする。
- GCSにアップロードする。
Cloud Storageの設定
バックアップファイルの保存先はCloud Storageにした。これは特に考える余地はないだろう。細かな設定は以下のようにした。
- オブジェクトのバージョニングを有効にして特定のキーに上書きしつづける。 つまり最新は常に取得できる。
- バックアップ用にバケットを新設する。 バージョニングの設定を固有のものにする必要があったため、専用のバケットを作成する。
- ストレージクラスはNearlineとする。 Google Cloud Storageのストレージクラスは4種類ある。今回の場合、読み込みや書き込みのスピードはそれほど重要ではない。ファイル自体は数日間保持される必要はあるが、1ヶ月以上保持する必要はない。それらを考えNearlineを採用する。
- サービスアカウントを発行し該当バケットへのPUTのみを許可する。 バックアップファイル保存用のバケットへは、ファイルのアップロードのみできればよい。そのため最低限の権限を付与する。
バックアップの頻度
どの程度の頻度でバックアップを取るかということは、そのデータの重要性による。今回の場合、趣味で扱っているゲームのデータであり、作業者も5人と少ない。問題があっても1日前ぐらいのデータに戻せるのであれば、許容範囲だろう。ということで、ほぼ主観で、頻度を1日1回と決めた。
何世代のデータを保持するか
バックアップの頻度同様、バックアップデータを何世代保持するかというのも、そのデータの重要性によって変わる。これも主観だが5世代ぐらいあれば問題は発生しないと考え、5世代分を保持することにした。それぞれのバージョン自体はGoogle Cloud Storageのバージョニング機能で自動で保持し、自動で破棄するようにする。
Cloud Storageへのクレデンシャル
専用のサービスアカウントを発行する。サービスアカウントにはGoolge Cloud Storageへ権限を付与する。GCEの実行サービスアカウントとして、ここで作成したサービスアカウントを設定する。
Cloud Storageへのファイルのアップロード
gsutilを用いてCloud Storageへのファイルのアップロードを行う。
gsutil cp アーカイブファイル gs://バケット名/アーカイブファイル検討したが脚下した他の選択肢
実施した施策以外にも同様の事をする方法はある。検討した結果、脚下となった他の選択肢を記載する。
データベース領域をボリュームとして切り出し、ボリュームごとバックアップようにすると、自分でバックアップの機構を準備しなくても、Google Cloudのマネージドなサービスだけでバックアップが可能だ。コードとデータの領域も分離できるため、魅力的ではある。しかし、現状の構成をそれなりに変更する必要があるため、このタイミングでは実施しないことにした。ボリューム全体を保存するため、保存するデータが多くなり、それに伴い微量ではあるが料金も増加する。いずれにしてもそれらの事情を見て今回は対応しない。
またデータベースをマネージドな製品に乗り換えるという事も考えたが、確認するとsqliteと知らない形式のファイルが使用されていた。これらはマネージドなサービスがないため、選択肢としては成立しなかった。
まとめ
今回はMinetestのバックアップするため、構成を考え実施した。gsutilを用いてGoogle Cloud Storageにバックアップファイルをアップロードするようシンプルな構成となった。これでデータベースがぶっ壊れても大丈夫なようになった。