さて、前回までに S3 Glacier Deep Archive に設定したファイルがバックアップされていることをジョブのレポートだけではなく直接 AWS コンソールからも確認できましたので、今回はリストアジョブを作成して実行してみたいと思います。
前回のバックアップジョブでは保存先のストレージクラスに "S3 Glacier Deep Archive" を指定するのがポイントでしたが、 今回のリストアでのポイントは取り出しオプションに低速でも良いので最も安い「大容量」をちゃんと指定することでしょう。
リストアジョブの準備
バックアップと同様 HSB3 でジョブを作成します。今回も詳細は動画にしましたで流れはこちらをご覧ください。個別の解説は割愛し、ポイントとなるデータ取り出しの設定だけ書いておきます。
AWS も HSB も英語からそれぞれ日本語に訳しているためだと思うのですが、AWS 側でいうデータ取り出しオプションは「データ検索方法」というよくわからない名称になっているので気をつける必要があります。そしてこれまた AWS でいう「大容量」が「一括」と表示されているのでこれも間違えずにチェックするように。
リストアジョブの実行
今回指定したデータ取り出しの設定は「大容量」です。AWS サイトでこれがどのようなものか確認しておくと、
Q: 大容量取り出しとはどのようなものですか?
大容量取り出しは、S3 Glacier で最も低コストの取り出しオプションで、たとえペタバイト単位でも、大容量のデータを割安に 1 日で取り出すことができます。大容量取り出しは通常、5～12 時間以内に完了します。
ということなので、たかだか数 GB であっても付きっきりで見ているわけには行きません。ジョブを手動で開始して翌朝確認することにします。
が、翌朝になっても丸一日たっても表示は 5% のまま。じたばたしても仕方がないので放置しておきましたら、丸一日半 (37時間) かかって終了していました。
ようやく終わりました！
リストア結果の検証
今回も旧 Glacier からのリストア実施の際に導入した CompareMerge でローカルにある元データと比較してみました。
結論は、もちろん元データと差異なくリストアできていました！
（当たり前ですが）
不思議なことに
一つ不思議だったのが、前回バックアップ取得後に AWS コンソールを除いて S3 バケット内のファイルを確認したときのタイムスタンプとリストア後のファイルのタイムスタンプの相違。S3 バケット内ではアップロードの際のタイムスタンプが付いていたのにそれをリストアしたらローカルのオリジナルのタイムスタンプに戻っていること。S3 もしくは HBS の機能でタイムスタンプも復元したのでしょうけれどもちょっと不思議です。
リストアのコストは？
コストの確認ですが、S3 のコストとして少し見えるくらい発生するかと思っていたのですが、小数点2桁目の変動すらありませんでした。日本時間で 05/01 の実施なのでもしかしたら 05/02 に計上されているのかもしれませんがいずれにしても目に見えるコストにはなっていませんでした。
一方、特に影響の出ないと思われていた (旧) Glacier のコストが微減。なぜなんだろう？？
ということで、コスト面は実感を持って確認することはできませんでしたが、QNAP HBS3 を用いて機能的にはバックアップ、リストアとも S3 Glacier Deep Archive を利用して問題ないことがわかりましたので、次回はいよいよ大切な写真データの再バックアップ実施です！
