KuriKumaChan’s diary

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

QNAP と クラウドバックアップ (7) - ".qdff" と ".qdv" の謎は QuDedup → バックアップやり直し

前回までに 2回の Glacier Deep Archive へのバックアップを行いました。バックアップのテストでは AWS コンソールから S3 バケット内部にアップロードされたディレクトリやファイル名がそのまま確認できていたのに、本番バックアップではディレクトリ構造がバックアップ元と異なった(".qdff" ディレクトリなんてのができていた)り、ファイル名自体がオリジナルのファイル名と異なり拡張子が皆 ".qdv" になっていたりと気分的に落ち着かない状態となっていました。単にジョブの実行結果を見ていただけなら何も不安に思わなかったと思うのですが、旧 Glacier と違って S3 の一員になってバケットの中身を AWS コンソールから確認できるようになって、実態を目の当たりにしてしまい衝撃を受けたといっても言い過ぎではありませんでした。

調べてみると ".qdff" ディレクトリの正体は

ネットを調べてみると、どうやら HBS3 の新機能?の "QuDedup" なるファイル圧縮機能を利用した時に作られるディレクトリ/ファイルだったようです。

f:id:KuriKumaChan:20210505215822p:plain
qdff は QuDedup テクノロジーを適用した結果

QuDedup とは

私の理解では、一言で言えば QNAP NAS データを他の NAS やクラウドにバックアップする際にデータ量を減らすことによりスペースも処理時間も節約できるという機能のようです。
「バックアップデータの重複を排除」という謳い文句がファイル単位の重複なのかどうか不明なので何とも言えませんが、それだけでは今回の私のデジカメファイルのような基本的には同じファイルが存在しないデータ群には余り向いていないような気がします。別の脈絡で(上図にありますが)「QDFFファイル圧縮で‥」という表現からもしかしたら重複排除以外に強力なデータ圧縮アルゴリズムも備えているのかもしれませんが、素人レベルに「なるほど〜!」というほどの納得感のある説明は見当たりませんでした。
(QNAP さん、私が見落としていたらけでしたらゴメンなさい。)

www.qnap.com

効果は?(紹介記事)

QNAP 製品を取り扱っているフォースメディアさんの記事にあったテスト事例では「3割近く」(ほぼ2割ではないか?というツッコミはありますが)効果があったとされていました。

オリジナルデータは7GBほどでしたが、重複排除(Qudedup)で3割近く削減されました。
7GB → 5.62GB

www.forcemedia.co.jp

効果は?(私の場合)

私の場合の容量をバックアップ元と S3 のバケット容量を比べてみると、

  • バックアップ元(NAS 上の外付け HDD): 1.05TB (Qfile の表示)

  • バックアップ先 (S3 Glacier Deep Archive):777.6 GiB (AWS CLI での表示)

単位の桁が違いますし、GB/TB と GiB/TiB では同じバイト数に対する値も異なり同じ値であれば Gib/TiB の方がやや大容量であることを示すようですが、そんなに劇的に圧縮されているようではありません。(GiB/TiB に関してはこちらの記事を参考にさせていただきました。)

www.guri2o1667.work

容量面での効果はともかく、仕事上バックアップを行うのであれば、Qudedup をもっと時間をかけて勉強したりテストするのですが、趣味で(当然無給で)時間をかけて頑張るほど暇ではないのと、今のところさほど大きなバックアップ保存コストにもなっていないこと、そして何よりアップロードした S3 バケットの中身がファイル単位で確認できるか否かというのは精神安定上違いが大きいので、私は Qudedup はオフで使いたいと思います。

QuDedup Extract Tool というのもある

完全に私の使い方ではないのですが、ローカルに qdff ファイル/ディレクトリをダウンロードした後にそれを解凍するソフトも提供されているようです。仕事で使うのだったら何か用途があるかも。

www.qnap.com

なぜ本番バックアップだけ QuDedup が機能したのか?

これは完全に私のオペレーションミスでした。 HSB3 に残っているジョブの構成を確認すると、後から変更できないようにグレーアウトされていますが QuDeDup にはチェックが入っていました。ジョブ設定時に一通りの設定項目は確認していて、テストバックアップではこのチェックを外していたのですが、肝心の本番の時に外し忘れてしまったようです。

f:id:KuriKumaChan:20210507183339p:plain
後から変更できないようにグレーアウトされているが QuDeDup にはチェックが入っていた。

再度 "QuDedup" をオフにしてバックアップ - 今すぐやるか 180日待つか?

私にはさほどの価値はなさそうな QuDedup オプションでバックアップしてしまったので、早速削除してバックアップを取り直そう!と思ったのですが、 Glacier Deep Archive には「最小ストレージ期間料金」という制約があることを思い出しました。

f:id:KuriKumaChan:20210507203751p:plain
Glacier Deep Archive の最小利用期間は 180日
要は仮にすぐに削除したとしたも、最低 180日分の保存コストは発生する、ということです。もし QuDeDup オプション無しのバックアップも取った場合、QuDeDup オプション付きのバックアップを削除しようがそのまま残そうが、180日(近く)はダブルでコストが発生してしまうのです。私の取りうる対応は大きく二つです。
(1) 180日待ってQuDeDup オプション付きのバックアップを削除するとともにオプション無しのバックアップを新たに取る。(重複コストが無い)
(2) さっさと QuDeDup オプション無しバックアップをとって 180日後にオプション付きのバックアップを削除する。(重複コストを受容)

重複コストはどのくらいかと言うと、前回ご紹介したように $0.05/日 (正確にはバックアップ以外の用途で使っている $0.01 も含まれているので $0.04 ですが)で、180日で $9。

f:id:KuriKumaChan:20210507205036p:plain
1日あたりの S3 保存コストは $0.05/日 = ¥5.5/日
180日と言えば 3ヶ月なのでそろそろ老化が目に見えてきているので、これまでの作業が頭にあるうちに対応しておいた方が良いだろうと考えることにしました。

と言うことで、再度ジョブを設定して実行!

実行結果( "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 コンソールからの確認

当然ですが、ちゃんとディレクトリ構造やその下のファイル名まで確認できました。

f:id:KuriKumaChan:20210507212852p:plain
一つ一つのファイル名まで確認できて一安心 ♪

本来やるべきことにチャレンジ!

さて、次回は本来やるべき二つのことに前進しようと思います!
- 旧 Glacier バックアップデータの削除
- バックアップジョブのスケジュール実行