前回までに 2回の Glacier Deep Archive へのバックアップを行いました。バックアップのテストでは AWS コンソールから S3 バケット内部にアップロードされたディレクトリやファイル名がそのまま確認できていたのに、本番バックアップではディレクトリ構造がバックアップ元と異なった（".qdff" ディレクトリなんてのができていた）り、ファイル名自体がオリジナルのファイル名と異なり拡張子が皆 ".qdv" になっていたりと気分的に落ち着かない状態となっていました。単にジョブの実行結果を見ていただけなら何も不安に思わなかったと思うのですが、旧 Glacier と違って S3 の一員になってバケットの中身を AWS コンソールから確認できるようになって、実態を目の当たりにしてしまい衝撃を受けたといっても言い過ぎではありませんでした。
- 調べてみると ".qdff" ディレクトリの正体は
- 再度 "QuDedup" をオフにしてバックアップ - 今すぐやるか 180日待つか？
- 実行結果（ "QuDedup" オン/オフの比較も）
- 本来やるべきことにチャレンジ！
調べてみると ".qdff" ディレクトリの正体は
ネットを調べてみると、どうやら HBS3 の新機能？の "QuDedup" なるファイル圧縮機能を利用した時に作られるディレクトリ/ファイルだったようです。
QuDedup とは
私の理解では、一言で言えば QNAP NAS データを他の NAS やクラウドにバックアップする際にデータ量を減らすことによりスペースも処理時間も節約できるという機能のようです。
「バックアップデータの重複を排除」という謳い文句がファイル単位の重複なのかどうか不明なので何とも言えませんが、それだけでは今回の私のデジカメファイルのような基本的には同じファイルが存在しないデータ群には余り向いていないような気がします。別の脈絡で（上図にありますが）「QDFFファイル圧縮で‥」という表現からもしかしたら重複排除以外に強力なデータ圧縮アルゴリズムも備えているのかもしれませんが、素人レベルに「なるほど〜！」というほどの納得感のある説明は見当たりませんでした。
(QNAP さん、私が見落としていたらけでしたらゴメンなさい。)
効果は？(紹介記事)
QNAP 製品を取り扱っているフォースメディアさんの記事にあったテスト事例では「3割近く」（ほぼ2割ではないか？というツッコミはありますが）効果があったとされていました。
オリジナルデータは7GBほどでしたが、重複排除(Qudedup)で3割近く削減されました。
7GB → 5.62GB
効果は？(私の場合)
私の場合の容量をバックアップ元と S3 のバケット容量を比べてみると、
バックアップ元（NAS 上の外付け HDD）： 1.05TB (Qfile の表示)
バックアップ先 (S3 Glacier Deep Archive)：777.6 GiB (AWS CLI での表示)
単位の桁が違いますし、GB/TB と GiB/TiB では同じバイト数に対する値も異なり同じ値であれば Gib/TiB の方がやや大容量であることを示すようですが、そんなに劇的に圧縮されているようではありません。（GiB/TiB に関してはこちらの記事を参考にさせていただきました。）
容量面での効果はともかく、仕事上バックアップを行うのであれば、Qudedup をもっと時間をかけて勉強したりテストするのですが、趣味で(当然無給で)時間をかけて頑張るほど暇ではないのと、今のところさほど大きなバックアップ保存コストにもなっていないこと、そして何よりアップロードした S3 バケットの中身がファイル単位で確認できるか否かというのは精神安定上違いが大きいので、私は Qudedup はオフで使いたいと思います。
QuDedup Extract Tool というのもある
完全に私の使い方ではないのですが、ローカルに qdff ファイル/ディレクトリをダウンロードした後にそれを解凍するソフトも提供されているようです。仕事で使うのだったら何か用途があるかも。
https://www.qnap.com/ja-jp/how-to/faq/article/qudedup-extract-tool-%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6-qdff-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%88%E3%83%A9%E3%82%AF%E3%83%88%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95www.qnap.com
なぜ本番バックアップだけ QuDedup が機能したのか？
これは完全に私のオペレーションミスでした。
HSB3 に残っているジョブの構成を確認すると、後から変更できないようにグレーアウトされていますが QuDeDup にはチェックが入っていました。ジョブ設定時に一通りの設定項目は確認していて、テストバックアップではこのチェックを外していたのですが、肝心の本番の時に外し忘れてしまったようです。
再度 "QuDedup" をオフにしてバックアップ - 今すぐやるか 180日待つか？
私にはさほどの価値はなさそうな QuDedup オプションでバックアップしてしまったので、早速削除してバックアップを取り直そう！と思ったのですが、 Glacier Deep Archive には「最小ストレージ期間料金」という制約があることを思い出しました。
(1) 180日待ってQuDeDup オプション付きのバックアップを削除するとともにオプション無しのバックアップを新たに取る。（重複コストが無い）
(2) さっさと QuDeDup オプション無しバックアップをとって 180日後にオプション付きのバックアップを削除する。（重複コストを受容）
重複コストはどのくらいかと言うと、前回ご紹介したように $0.05/日 (正確にはバックアップ以外の用途で使っている $0.01 も含まれているので $0.04 ですが)で、180日で $9。
と言うことで、再度ジョブを設定して実行！
実行結果（ "QuDedup" オン/オフの比較も）
当然ジョブは成功です！
HBS ジョブ実行結果
HNS3 に残っている二つのジョブのレポートから数字を拾ってみました。
| 項目 | QuDeDup 付き | QuDeDup 無し |
|---|---|---|
| 処理時間 | 11:24:16 | 11:14:21 |
| 合計ファイル数 | 190132 | 190132 |
| 合計サイズ | 832.08GB | 832.08GB |
| 転送サイズ | 777.58GB | 832.14GB |
| 合計転送速度 | 19.39MB/s | 21.06MB/s |
| データ縮小率 | 1.07 | 1 |
確かに転送サイズは少しですが QuDeDup の指定をした方が少なくなっていることは確認できましたが、私のデータセットの場合はさほどの効果ではないと言うのが素直な感想です。
AWS コンソールからの確認
当然ですが、ちゃんとディレクトリ構造やその下のファイル名まで確認できました。
本来やるべきことにチャレンジ！
さて、次回は本来やるべき二つのことに前進しようと思います！
- 旧 Glacier バックアップデータの削除
- バックアップジョブのスケジュール実行
