従来Drupalのバックアップは、サーバー内のディスクにmysqldumpとtarで保存し、定期的にスナップショットを取っていた。一度だけトラブルがあって、一部のファイルが失われたことはあったが、丁寧にやっている有償契約で問題が出たことはないが、マルチサイトでホスティングしているとディスク容量が気になる。手元のPC/Mac経由で取外し可能な記憶媒体に保管してオフライン管理するなど工夫はしているが、AWSやGoogle Cloud等の信頼性の高いクラウドストレージに直接保管できればより安心だ。本格的な環境整備はすぐにはできないが、実証検証はやっておこうと思って今日挑戦してみた。
Google Cloud CLI をインストールするを参照してまずはインストールを実施した。
sudo apt-get install apt-transport-https ca-certificates gnupg
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
sudo apt-get update && sudo apt-get install google-cloud-cli
まあ呪文のようなものかと思ってただただ入れたら一発で通ってしまった。バックアップのことで既にgoogle cloud storageにバケットを作成するとともにサービスアカウント、そのアクセスキー(json)を取得していたので、ちょこちょこっとコマンドを調べて以下のコマンドでアクセスしたらあっさり動作した。
gcloud auth activate-service-account --key-file=eastern-map-なんちゃら.json
gsutil ls -l gs://takayuki_hagiharaほげほげ/
gsutil cpやgsutil rmでの操作も問題なく動作した。手を付けてみれば思ったより簡単だった。
本格的な運用時は、サービスアカウントのアクセス権から管理権限を外して読み書き、あるいは書き込みだけができるようにして何かの間違いでバックアップを消すことがないようにするとか、いくつか検討した方が良い点はある。それでも、まず間違いなく実用に耐えるだろう。
バックアップファイルをDrupalを動かすサーバーの外に置けば、トライアルインスタンスを立ち上げるコストが小さくなるので、例えばThemeの切り替えや、あまり使われなくなってしまったContributed Modulenの置き換えなどのハードルも低くなる。こつこすと改善していけば、競争力が向上できると考えている。
S3あるいはAzureも試してみるほうが良いのだろうが、まだやっていない。