resticを使ってGoogle Cloud Storageにバックアップする方法を検証してみる
アーティスでは、ファイルシステムのストレージサーバーにGCPのCloud Filestore（以下、Filestore）を利用しています。FilestoreはマネージドのNFSサーバーで、手軽に大容量のストレージを利用できとても便利ですが、自動的にバックアップしてくれるサービスはありません。
また、ゾーン間のレプリケーションはサポートされておらず、特定のゾーン内でのサービスなので、定期的にバックアップを取ることが奨められています。
gsutilのrsyncでバックアップする方法のデメリット
当初は、gsutilコマンドのrsyncでバックアップする予定でしたが、OS固有のファイルタイプの同期で問題があることがわかりました。
- シンボリックファイルをバケットから復元した場合、シンボリックではなく実際のファイルになる
- 壊れたシンボリックリンクを含むディレクトリがある場合、中断される
- ディレクトリを指すシンボリックリンクはスキップされる
シンボリックファイルが正常に展開できないと、アプリケーションが正常に動作しない可能性があります。
ですので、公式では、tarなどを使って該当のディレクトリを固める方法が推奨されています。
resticを使ってバックアップする
tarを使うのなら、Cloud Storageをバックエンドに指定できるバックアップツールを使ってもいいのではないのかと思い、以前から気になっていたresticを試すことにしました。
インストール
公式には、パッケージマネージャからインストールする方法が書かれていますが、今回は検証なのでバイナリを直接ダウンロードします。
上記のページから、自分の環境に合ったバイナリをダウンロードして、展開しました。
curl -OL https://github.com/restic/restic/releases/download/v0.9.5/restic_0.9.5_linux_amd64.bz2 &&
bzip2 -df restic_0.9.5_linux_amd64.bz2 &&
sudo mv restic_0.9.5_linux_amd64 /usr/local/bin/restic &&
sudo chmod 755 /usr/local/bin/restic$ restic version
restic 0.9.5 compiled with go1.12.4 on linux/amd64リポジトリの準備
resticは、バックアップするのにリポジトリを使うので、その準備を行います。
リポジトリはローカルに作成することもできますし、さまざまなクラウドストレージに対応しています。
今回は、Filestoreのデータをバックアップするので、Cloud Storageを利用することにしました。
まずは、サービスアカウントを作成して「ストレージのオブジェクト管理者」の役割を付与して、その鍵を保存します。
環境変数にプロジェクトIDと、サービスアカウントの鍵のパスを保存します。
$ export GOOGLE_PROJECT_ID=******
$ export GOOGLE_APPLICATION_CREDENTIALS=/home/****/.config/***********.json次に、Cloud Storage側でバケットを作成します。
そして、リポジトリを初期化します。
$ restic -r gs:restic-test:/ init
enter password for new repository:
enter password again:
created restic repository 08b1bf8561 at gs:restic-test:/
Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.パスワードを紛失すると、データが復元できなくなるので大切に保管します。
バックアップとレストアをして時間を計測する
テスト用データとして、ブロックサイズで約20GB（67,544ファイル）のデータをバックアップしてみます。
実行するインスタンス環境は、Filestoreのデータをマウントしている「f1-micro」タイプのGCEです。
Cloud Storageは、マルチリージョンでローケーションは「asia」です。
ストレージクラスは、検証用なので短期間でIOオペレーションが発生するのでStandardを選択しました。
$ restic -r gs:*****:/ --verbose backup /*****/*****
open repository
enter password for repository:
repository 679295fc opened successfully, password is correct
created new cache in /home/*****/.cache/restic
lock repository
load index files
start scan on [/*****/*****]
start backup on [/*****/*****]
scan finished in 16.182s: 67544 files, 18.866 GiB
Files: 67537 new, 0 changed, 0 unmodified
Dirs: 2 new, 0 changed, 0 unmodified
Data Blobs: 35137 new
Tree Blobs: 3 new
Added to the repo: 10.934 GiB
processed 67537 files, 18.867 GiB in 37:58
snapshot 134f14e6 saved約38分で20GBのバックアップが完了しました。 1GBあたり2分くらいかかる計算です。
$ restic -r gs:*****:/ restore 134f14e6 --target /*****/*****
enter password for repository:
repository 679295fc opened successfully, password is correct
restoring <Snapshot 134f14e6 of [/*****/*****] at 2019-11-18 01:49:16.986718488 +0000 UTC by artis@*****-instance> to /*****/***** -r gs:*****:/ restore 134f14e6 --target /*****/*****こちらは、約17分で20GBの復元が完了しました。
現在のバックアップツールだと、80GBのバックアップに4.5h時間、レストアに5時間かかってます。
今回の方式に変更することで、遅めに見積もって、バックアップに2.5時間～3時間、レストアに1.5時間～2時間くらいなので、かなり高速化できそうです。
まとめ
Filestore内のデータをCloud Storageにバックアップする方法として、resticを使ってみました。
goで実装されていることもあり、シングルバイナリをデプロイすることで非常に簡単に検証できました。
バックアップの速度やレストアの速度は、障害やインシデント発生時の復旧時間に影響してきます。
Webアプリケーションのデータは日々増えていくので、大容量のデータを迅速にバックアップ、復元することが次第に難しくなっていきます。
ある程度データが大きくなったら、インフラ全体の構成を見直して、データを分割する必要も出てくると思います。
この記事を書いた人
- 事業開発部 web application engineer
-
2008年にアーティスへ入社。
システムエンジニアとして、SI案件のシステム開発に携わる。
その後、事業開発部の立ち上げから自社サービスの開発、保守をメインに従事。
ドメイン駆動設計（DDD）を中心にドメインを重視しながら、保守可能なソフトウェア開発を探求している。
この執筆者の最新記事
関連記事
最新記事
FOLLOW US
最新の情報をお届けします
- facebookでフォロー
- Twitterでフォロー
- Feedlyでフォロー