KuriKumaChan’s diary

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

QNAP と クラウドバックアップ (2) - 旧AWS Glacier から 900GBをリストアしてみた - 実行時間とコストは?(リストア結果編)

前回の実施結果です。

blog0.kurikumachan.com

blog0.kurikumachan.com

blog0.kurikumachan.com


リストア対象(バケット)の確認と HBS3 復元ジョブの設定

今回チャレンジするのは 2016年にバックアップを取り始めた vault が対象です。

今回のリストア(ダウンロード)対象は "Photo_Full_20161129b"。クラウド上の容量は 913.5GB の表示
この vault を HBS3 の復元ジョブの「バケット名」に指定します。
HBS3 復元ジョブのソースストレージの「バケット名」に指定する
実際には vault の存在する AWS データセンターの地域名(リージョン)やアクセス件に関する設定などもありますが、もともとはバックアップを作成するときに指定した項目なのでここでは割愛し、新しいバックアップを作成するときに細かな項目もご紹介したいと思います。

HBS 3 による Glacier のリストア

実行時間は?

ジョブを開始した後は HBS 3 で進行状況を確認することができます。

進行の % はそう簡単に進まない
それなりに時間もかかりますので、あとは NAS に実行をお任せしてパソコンは off にして問題ありません。
結局 21時間 25分 31秒かかりました
午後にジョブを開始して、翌日の昼過ぎに完了で 21時間 25分でリストア完了しました
この間の平均転送速度は 12MB/s ということなので、超高速回線でなくても大丈夫そうですね。ただしジョブ実行中に満遍なくダウンロードしているようではなく、最初の頃はおそらくクラウド側の準備工程が実行されたのちに中盤以降に実際のダウンロードが行われているようですので、実際にはもっと大きな帯域が必要なはずです

コストは?

さて、ドキドキのコストですが、AWS 管理コンソールのコスト管理から確認です。

二日にわたってリストアのコストが発生!
二日の合計が $122.92 なので、ざっくり ¥110/$ とすると、13,521円。税抜きなのでまぁ 15,000円くらいかかったことになります😢。

リストアしたデータの中身は?

Glacier の vault の中身をファイル単位に直接確認することはできませんが(本当はメタデータのダウンロード機能があるようなのだけれどもうまくデータが取得できなかった)、リストアしてしまえば当然内容は確認できます。
目視で FInder で眺めていてもよくわからないので、私のデジカメ保管のルートディレクトリである "Photo" 配下のファイルを NAS のオリジナルとリストア先のものと比較してみます。今回はネットで評判の良さそうな CompareMerge というアプリを購入して NAS 上のデータを目視比較して見ました。

CompareMerge

CompareMerge

  • Tien Thinh Vu
  • 開発ツール
  • ¥2,200
apps.apple.com

CompareMerge で目視比較

CompareMerge はちゃんと操作ガイドを読んでいませんが、結構直感的にわかるようになっています。
タイトルバーには、以下の数字が表示されます。なお基本的な設定として比較対象をパネルの左右にどのように設定するかを決められますが、私は「左:NAS のオリジナル」「右:リストア先」のディレクトリを指定しています。

  • 差異 :ファイルは双方に存在するけれども何かしらの?相違がある。

  • 左側のみ :オリジナルにしか存在しない

  • 右側のみ:リストア先にしか存在しない

  • 同一:オリジナルにもリストア先にも同じファイルが存在する。

CompareMerge の表示例。左側(オリジナル)にしか存在しないものを表示する設定。

オリジナルに存在してリストア先に無いもの

同一」が大半なのは当然として、それ以外が気になります。
まず「左のみ」つまりオリジナルに存在してリストア先に無いものだけを表示してみます。
本当は全てのディレクトリを一つ一つ比較すべきなのでしょうけれども、そこは大きくは信頼しているということでいくつかを選んでチェックしてみます。そうするとこれに該当するものは以下のようなものでした。

  1. 双方にディレクトリは存在するけれどもファイルがオリジナル側にしかない:これはみる限りは ".DS_Store" というファイル。調べてみると MacOS が勝手に作成している隠しファイルらしい。つまりもともとバックアップをとったときには Lightroom は Windows マシンのローカルで作業していて、NAS は Windows ローカルのバックアップを置いてあったので、NAS のドライブに Mac から直接アクセスすることはあまり無く、リストア先のほとんどのディレクトリには ".DS_Store" は存在しなくて当然です。

  2. ディレクトリ自体がオリジナルにしかない: これも当然そうなるディレクトリがあります。TS-431p からクラウドバックアップしていた当時には持っていなかった OM-D EM1 mk3 や新しいスマホ用のディレクトリが該当します。他にも比較的最近整理用に作成したディレクトリもこれに該当します。

リストア先に存在するがオリジナル側には無いもの

ちょっと嫌な感じがするグループですが、以下の二つの原因がありました。

  1. バックアップした後に削除したファイル:主にブレやボケなど不要な写真を削除していたのがリストされていました。
  2. NetBak Replicator が勝手に作成していたもの:".qtmp" これは当時 WIndows PC から NAS のドライブを Lightroom でアクセスするには遅くて実用的ではなかったので、PC のローカルドライブをオリジナルとして NAS には QNAP の同期ツールである NetBak Replicator を使っていたのですが、この NetBak Replicator が勝手に同期先に作成していたファイルのようです。これは同期するファイルごとに何かしらのタイミングで個々に作成されていたようで、それなりのサイズとそれなりの数が残されているので、今回ジャマなファイルたちを見つけられた、ということでしょうか。もしかしたら現在の TS-431p のデータを引き継いだ TS-453Be 上にも ".qtmp" が残っているかと心配しましたが、残っていませんでした。
    ということで、このグループも一安心です。

右側(リストア先)にしか存在したいものたち

差異 :ファイルは双方に存在するけれども何かしらの?相違がある。

一番嫌な感じのグループです。結論を先に言ってしまうと原因は今のところわかっていません。 ファイルサイズ、タイムスタンプも同じです。ですので何かしらの画像上の変更が加えられているのかもしれません。テキストファイルならば差分を CompareMerge が示してくれるのですが、画像ファイルなどバイナリファイルはその差分の箇所を目で見ることはできませんでした。
傾向としては比較的最近の主力カメラたちのディレクトリですが、TS-453p 時代のファイルばかりでした。E-M1_mk2 では比較的多く発生していますが、それ以外ではわずかな発生でしかありません。原因は究明できませんでしたが、最低限の確認として際のある両サイドの jpeg ファイルを表示しても問題ないことを確認して、ちょっとモヤモヤが残るままですが、「差異」の確認この辺りで諦めます。

比較的最近の主力機に偏っている様子。

リストアしたファイルのタイムスタンプは?

リストアしたディレクトリのタイムスタンプはいずれもリストア実行時のものになっていましたが、ファイル自体はバックアップした当時のものと思われるタイムスタンプのままでした。

リコーの GX100 のフォルダ。全てリストア実行時の 2021年になっている。
リコーの GX100 のファイル。2010年のタイムスタンプ。それにしてもファイルサイズが小さかった。

次に備える

最低限 TS-431p 時代のクラウドバックアップはちゃんと取れていたしリストアできることも確認できましたのでヨシとしたいと思います。
またリストアに当たってのコストはそれなりにかかり、今回もちょっとした HDD 1台分くらいのお金がかかってしまいましたが、貴重な経験ができたと考えて納得することにします。
これからは、まだちゃんとクラウドバックアップが取得できていない現在の TS-453Be のバックアップを取ること、新しい Glacier の機能が提供されているのでそれを勉強して採用してみることなどにチャレンジして見たいと思います。

クラウドストレージの一つ AWS の Glacier を紹介しましたが、AWS (Amazon Web Service, アマゾン ウェブ サービス)、 Amazon、Amazon.co.jp および Amazon.co.jp ロゴは、Amazon.com, Inc.またはその関連会社の商標です。