KuriKumaChan’s diary

Kuri ちゃんと Kuma ちゃんの飼い主の独り言

QNAP と クラウドバックアップ (6) - 新しい "S3 Glacier Deep Archive " を試す(本番バックアップ編)- もやもや残る

前回までに、新しい(と言っても知らなかっただけで 2019年から使える)AWS の低コストクラウドストレージの S3 Glacier Deep Archive へのバックアップとリストアが QNAP のバックアップソリューション(アプリ)である HBS3 (Hybrid Backup Sync 3) を用いてかなりお手軽にできることがわかりました。

いよいよ今回は当初の目的である写真データの S3 Glacier Deep Archive へのバックアップです。

バックアップジョブの作成

ジョブ作成の手順はこちらの動画の通りです。 バックアップ時のポイントは、(1) ストレージクラスに "Glacier Deep Archive" を指定する。(2) バケットをどのリージョンに作るか指定する、の2点がポイントでした。 一応私にとってそこそこ大容量(と言ってもたかだか 1TB にも満たないですが)なのでストレージコストが一番安い北米リージョンを選日ました。

バックアップの実行と結果

初回は手動でジョブを開始。リストアとは違って時間の経過とともに%表示も徐々に増えていきます。回線自体は信頼の Nuro の高速回線なのでここでボトルネックになって実行時間が長くなることは無いので安心して放置しておきます。

処理時間

翌日朝確認するとちゃんと「成功」という表示があり一安心。11時間半で初回の丸ごとバックアップが完了しました。 f:id:KuriKumaChan:20210504142904p:plain f:id:KuriKumaChan:20210504142945p:plain

AWS コンソールからバケット内部を覗いてみる(もやもや その1)

400弱のファイル数、6GB ちょっとという小さなサイズをバックアップしてみた時はアップロード後に AWS コンソールからそのディレクトリ構造やファイル名およびファイル毎の一つ一つのストレージクラス("Glaceir Deep Archive")を確認することができましたが、今回のバックアップ後にそのバケットを AWS コンソールから覗いてみるとジョブ名のディレクトリに意図しない ".qdff" という拡張子がついているし、その下のディレクトリ構造がバックアップ対象の NAS 上のディレクトリ構造と全く違う。ファイル単位でもバックアップもとのファイル名は確認することができず、"0000000_0000000000000000.qdv" といった ".qdv" という身に覚えのない拡張子のファイルに揃えられていました(この .qdv ファイルのストレージクラスが "Glacier Deep Archive" になっていました。)。 んー、んー、んー 分かりません、なぜこうなっているのかは‥

バックアップテスト時と今回の大きな違いはファイル数/容量が大きく異なるくらいでしょうか。ある程度大容量になるとファイル自体が何らかの変換をされてアップロードされるのだろうか‥ 残念ながらこれを書いている時点で全く手がかりはありませんでした。残念。

f:id:KuriKumaChan:20210505213326p:plain
背面の画像が本バックアップのバケットの中身。手前が前回のテストバックアップのバケットの中身。

コストの確認 (もやもや その2)

コストもモヤモヤです。
ちゃんと計算していないですが、バックアップ実行にかかるコストも $6 って安いですし、ストレージコストが旧 Glacier に比べて 1/4。容量が少なくなはっていますが‥

f:id:KuriKumaChan:20210505181505p:plain
バックアップコスト、保存コスト

この後

ちょっとモヤモヤが残ります。
もやもや 1) AWS コンソールから見える ".qdff" ディレクトリと ".qdv" ファイルの謎
もやもや 2) 安すぎるのではないか?

本当はこの後つぎの二つに進みたいのですが...

旧 Glacier バックアップデータの削除
バックアップジョブのスケジュール実行