AWS はデータ転送費用が高い
前回は NASのバックアップを Amazon S3 Glacier に置く検証をしたが、その後たっぷり12時間ほどかけて無事 NAS の全データ（今のところ 200GB 程度）のバックアップが S3 にアップロードされた。
次はリストアを検証しようと思ったが、リストアにはデータ転送費用がかかるため、仮に今の NAS の最大容量の 1.8TB をリストアした場合の費用を見積もったところ、思ったより高くてしょんぼりしてしまった。
リストアするだけで 210.01 USD かかってしまうため、リストア検証するのにもちょっと気が引けてしまう。AWS はデータ転送量が高いと聞いていたが、実際に金額にしてみるとその高さを実感した。Web サービスのコンテンツ用に使う分には、同一リージョンの AWS 内のサーバーから使うことで転送量を安くしたり、CDN を入れることで S3 からの直接的なデータ転送を減らしたりという工夫ができるらしいが、自宅の NAS のバックアップではそのような工夫はできない。正直 NAS のバックアップ用途としては費用対効果が微妙といったところだと思う。
Backblaze B2 Cloud Storage を検討してみる
NAS で使っているバックアップソフトウェア Duplicity は S3 以外のサービスにも対応しており、その一つである Backblaze を使ってみることにした。Backblaze は S3 ほどメジャーではないが、定期的に各メーカーの HDD の故障率のデータを発表してたりするので、名前だけは見かけたこともある人もいるのではないだろうか。
見積してみたところ、1.8TB フルでリストアしても S3 と比べてはるかに安い。というか S3 のインターネットへの転送費用がやっぱり高すぎると思う。AWS のエコシステムから絶対出させないという Amazon の強い意志が感じられる。
Backblaze のアカウントを作成する
Backblaze のアカウント作成はオンラインで手軽にできる。なぜか日本語のページからはサインアップがうまく機能しなかったが、以下の英語版のページからサインアップしたらうまくいった。
https://www.backblaze.com/b2/sign-up.html
ところでこの Backblaze、日本語のローカライズが近年まれにみるレベルでひどい。機械翻訳でもこんなひどい訳にはならないんじゃなかろうか。
日本語は完全に破滅しているので、英語に切り替えて操作することをお勧めする。
B2 のバケットの作成
アカウントの登録と 2FA などの最低限のセキュリティ設定をしたら、バックアップを格納するためのバケットを作成する。これは S3 とあまり変わらない。
Application Keys の作成
Amazon S3 ではバケットにアクセスするためには IAM ユーザーを作成してアクセスキーとシークレットキーを取得する必要があったが、B2 でも同様に App Key というキーが必要になる。
作成すると以下の3つが発行される。
- keyID
- keyName
- applicationKey
Duplicity の設定にはここで発行された keyID と applicationKey、そしてバケット名が必要となる。
Duplicity の設定
前回のスクリプトの設定ファイルを以下のように B2 仕様に変更した。
# /etc/periodic.local.d/config
# バックアップ対象とバックアップ先
DUPLICITY_SOURCE_DIR="/mnt/share"
DUPLICITY_TARGET_URL="b2://【keyID】:【applicationKey】@【バケット名】"
# 暗号化（GnuPG）設定
export GNUPGHOME=/mnt/credentials/gnupg
export PASSPHRASE='【GPGキーのパスフレーズ】'
DUPLICITY_ENCRYPT_SIGN_KEY="【GPGキーのフィンガープリント】"
# Duplicity に渡すコマンドラインオプション
# -vd でデバッグログを出力
DUPLICITY_OPTS="-vd --archive-dir /mnt/system/duplicity/cache --tempdir=/mnt/system/duplicity/tmp"
バックアップ先のターゲット URL を b2://key_id[:application_key]@bucket_name/[folder/] の形式で設定すれば OK である。ちなみに man duplicity では key_id ではなく account_id とあったが、指定するのは App Key 作成時に発行された keyID で良いようだ。
また初回フルバックアップに時間がかかるが、寝て起きてテレワークしている間に終わることだろう。
