KuriKumaChan’s diary

さて、前回までに S3 Glacier Deep Archive に設定したファイルがバックアップされていることをジョブのレポートだけではなく直接 AWS コンソールからも確認できましたので、今回はリストアジョブを作成して実行してみたいと思います。
前回のバックアップジョブでは保存先のストレージクラスに "S3 Glacier Deep Archive" を指定するのがポイントでしたが、今回のリストアでのポイントは取り出しオプションに低速でも良いので最も安い「大容量」をちゃんと指定することでしょう。

リストアジョブの準備
リストアジョブの実行
リストア結果の検証
- 不思議なことに
リストアのコストは？

リストアジョブの準備

バックアップと同様 HSB3 でジョブを作成します。今回も詳細は動画にしましたで流れはこちらをご覧ください。個別の解説は割愛し、ポイントとなるデータ取り出しの設定だけ書いておきます。
AWS も HSB も英語からそれぞれ日本語に訳しているためだと思うのですが、AWS 側でいうデータ取り出しオプションは「データ検索方法」というよくわからない名称になっているので気をつける必要があります。そしてこれまた AWS でいう「大容量」が「一括」と表示されているのでこれも間違えずにチェックするように。

データ取り出しオプションは「データ検索方法」というよくわからない名称になっている。

リストアジョブの実行

今回指定したデータ取り出しの設定は「大容量」です。AWS サイトでこれがどのようなものか確認しておくと、

Q: 大容量取り出しとはどのようなものですか?
大容量取り出しは、S3　Glacier で最も低コストの取り出しオプションで、たとえペタバイト単位でも、大容量のデータを割安に 1 日で取り出すことができます。大容量取り出しは通常、5～12 時間以内に完了します。

ということなので、たかだか数 GB であっても付きっきりで見ているわけには行きません。ジョブを手動で開始して翌朝確認することにします。
が、翌朝になっても丸一日たっても表示は 5% のまま。じたばたしても仕方がないので放置しておきましたら、丸一日半 (37時間) かかって終了していました。

ようやく終わりました！

途中何回か不安になることもありましたが何とか終了。データ量が少なかったのに謳い文句の「大容量取り出しは通常、5～12 時間以内に完了します。」とは進まなかったことに本当に必要な時に大容量をリストアする時間が気になります。

リストア結果の検証

今回も旧 Glacier からのリストア実施の際に導入した CompareMerge でローカルにある元データと比較してみました。
結論は、もちろん元データと差異なくリストアできていました！
（当たり前ですが）

不思議なことに

一つ不思議だったのが、前回バックアップ取得後に AWS コンソールを除いて S3 バケット内のファイルを確認したときのタイムスタンプとリストア後のファイルのタイムスタンプの相違。S3 バケット内ではアップロードの際のタイムスタンプが付いていたのにそれをリストアしたらローカルのオリジナルのタイムスタンプに戻っていること。S3 もしくは HBS の機能でタイムスタンプも復元したのでしょうけれどもちょっと不思議です。

AWS コンソール（ブラウザ）で確認したファイルのタイムスタンプはバックアップ実施時(04/27)のもの

リストアしたファイルはオリジナルのバックアップデータと同じ 03/13 のタイムスタンプに戻っている！

リストアのコストは？

コストの確認ですが、S3 のコストとして少し見えるくらい発生するかと思っていたのですが、小数点2桁目の変動すらありませんでした。日本時間で 05/01 の実施なのでもしかしたら 05/02 に計上されているのかもしれませんがいずれにしても目に見えるコストにはなっていませんでした。
一方、特に影響の出ないと思われていた (旧) Glacier のコストが微減。なぜなんだろう？？

ということで、コスト面は実感を持って確認することはできませんでしたが、QNAP HBS3 を用いて機能的にはバックアップ、リストアとも S3 Glacier Deep Archive を利用して問題ないことがわかりましたので、次回はいよいよ大切な写真データの再バックアップ実施です！

youtu.be

2021-05-02

QNAP とクラウドバックアップ (4) - 新しい "S3 Glacier Deep Archive " を試す（準備・バックアップテスト編）

NAS 家庭内IT ガジェットクラウドストレージ

前回の雑な整理で、新しい "S3 Glacier Deep Archive " は S3 のストレージクラスとして提供されているので、S3 の API でバックアップ等の操作を行うものだとわかり、HBS3 でも S3 の一員としてバックアップジョブをしているのではないかという想定まで辿り着きました。今回は実際に HBS3 でどうやって "S3 Glacier Deep Archive" へのバックアップジョブを設定するか確認し、簡単なテストを行ってみます。

なお、大切なことではありますが以下のポイントには細かく言及しません。

AWS 関連の基本的な設定（アカウント作成、IAM設定等）：これは一度設定してしまえばバックアップのつど再設定するものではなく既存の設定の再利用となります。5,6年前にちょっと S3 を勉強して最初の設定を行ったのですが、今となっては私がそれを再度丁寧に説明するほどしっかり覚えていないことと、分かりやすい解説情報は当時からネット上にいくらでもあることからここではこれらの設定は割愛します。今回の範囲で入力が必須なのは、アクセスキー、シークレットアクセスキーは事前設定したものを利用しています。
HBS3 入力設定項目：バックアップなりリストアするのにどのような設定項目が必要なのかを事前に知ることは大切なことです。しかし今回はポイントとなるいくつかの項目は記事でご紹介しますが、全体としては別途動画にしてどのような設定項目があるのかお見せしたいと思います。記事中に細かい設定を記載するのも煩雑なので。

テストの準備
QNAP HBS3 でバックアップジョブの準備
- (a) ストレージクラスの設定： "Amazon Glacier" を選択しても "deep archive" 関連のメニューが見当たらない
- (b) バケットとリージョンの設定
バックアップジョブの実行結果

テストの準備

テストデータ

このテストで 1TB 弱のデータをリストアして一万円を超えるコストが発生してしまったので、少しケチケチでテストしてみようと思います。

特定のディレクトリをバックアップするジョブを準備し、後日データを追加して差分バックアップができていることを確認する。

テスト方法

NAS 上に、"GlacierTestData" ディレクトリを準備し、このディレクトリをバックアップ対象としたジョブを準備する。
Day1, Day2, Day3 のそれぞれのディレクトリにはそれぞれの日に 1GB 程度のデータを追加していき、毎日データ追加後にバックアップジョブを実行する。（今回はここまでをご紹介します。）
Day4 に合計 3GB 程度となった "GlacierTestData" ディレクトリをリストアしてみる。（これは次回ご紹介します。）

確認事項

思いつくままに、だいたいこんなレベルは確認しておきたいな、と思うものを書き出しました。

コスト

コストに関しては、扱うデータ量が少ないので実測できるほどのコストが発生するか分かりませんのであとで AWS コンソールから確認する程度にしようと思います。

バックアップ時間

リストア時に「取り出し」時間がかかる Glacier ですが、バックアップ取得時にはさっさとバックアップが完了することは確認しておきたい。

差分バックアップ

差分のデータだけバックアップされていることを何らかの方法で確認したい.
リストア時 (Day4) に全てのファイルが確実にリストアできていること。

リストア（取り出しの設定）

バックアップ済みのデータをリストアするためには、S3 Glacier ではダウンロードする前に Vault (バケット)からデータを「取り出す」というステップが設定され、その処理時間が 3段階ありそれぞれコストが異なります。

「迅速」> 「標準」> 「大容量」

詳細は S3 料金ページを確認いただきたいのですが、S3 Glacier は上記 3段階、S3 Glacier Deep Archive は標準と大容量の 2段階の設定があり、早いほどコストがかかる設定となっています。

旧 Glacier のリストアテストでは大金を散財してしまったので、ケチケチで一番安いけれども一番待たされる、という「大容量」で試したいと思います。

(おまけ) ブラウザからの操作

もともと S3 で扱うファイルはブラウザから操作できます（アップロードやダウンロードも）。
旧 Glacier ではサーバーの Vault にあげてしまったデータはダウンロードしない限り内容を確認できなかったのですが、S3 と同じ扱いができるかもしれません。

QNAP HBS3 でバックアップジョブの準備

ジョブの設定に関しては動画を準備しましたので流れとしてはそれを参照ください。ここではポイントとなる (a) ストレージクラスの設定、(b) バケットとリージョンの設定だけ書いておこうと思います。動画はこちらを参照ください。
動画で紹介しているジョブの設定はこのテスト用の設定ではなく大切な写真データのバックアップ用ジョブ設定です。この記事で紹介しているディレクトリ等の情報が異なることはご容赦ください。

QNAP のバックアップの統合ソリューションアプリである HBS3 でも 2019/12/06 のリリースで deep archive のサポートが記載されていますので、HBS3 から deep archive を利用したバックアップができるはずです。

よく読むと、"Amazon S3 storage space now supports" とあるが、"HBS now supports" とは書いていないのが気になる。

(a) ストレージクラスの設定： "Amazon Glacier" を選択しても "deep archive" 関連のメニューが見当たらない

ところが今までのように "Amazon Glacier" を保存先に選択して先に進んでも今までと同様の Glacier の指定項目しか表示されず、今回の最大の目的である "deep archive" といった文言はどこにも見当たりません。

保存先ストレージの選択で、"Amazon Glacier" 選んで行っても "deep archive" 関連の設定が見つからない

ここで「やっぱり S3 の一員になったのだから S3 側のメニューから選ぶのかな？」と思って色々検索してみると、QNAP の Forum でやはり HBS3 で deep archive にどうやってバックアップするのか悩んでいる人たちがいて、そこで deep archive を選択する方法がアドバイスされていました。
そうなんです。HBS3 で保存先として "Amazon Glacier" を選択してもダメなようで、隣の "Amazon S3 & S3 互換" という日本語が今ひとつわからない方で進めなくてはならなかったようです。

forum.qnap.com

HBS3 のジョブの設定で保存先を "Amazon S3 & S3互換" を選択するとバケットの設定でストレージクラスとして "Glacier Deep Archive" が選択できる。

(b) バケットとリージョンの設定

いくつか混乱する表示が AWS 側も HBS3 側も出てきますので覚えていたら後でまとめておきたいと思いますが、旧 Glacier では "Vault" という名称の格納庫を設定してそこにバックアップを取得しますが、ここではバケット (Backet) という S3 標準の名称の格納場所を指定します。本当は今回のテスト用に新しいバケットを作成するつもりでしたが、HBS3 の画面を行き来しているうちに過去にテスト用に作成した "test20161126" というバケットを指定したままジョブを実行してしまいました。しかし皆さんが初めて S3 にバックアップするにあたってはここでバケットを新規に作成する必要があります。

バケット名はこのテスト用のものではありませんが、新規バケット作成にあたってはバケットめいと地域名が必要となります。

上記の画像は動画の一部ですが、新規バケット作成にあたってバケット名（ここでは "gda-pro5300"）と地域名（ここでは "US East (N. Virginia)"）を指定する必要があります。どこのリージョン（地域）のデータセンターを使うか、という指定なのですが、個人情報たんまりで日本から出したくないとか、コストを優先して安いリージョンにしようとかで選べば良いでしょう。この図ではコスト優先で一番ストレージコストの安い北米リージョンを選択しています。

ここは全くの余談なのですが、今回の目玉である "Glacier Deep Archive" はちゃんと S3 のストレージクラスとして選択できました。
ここで若干私の頭の中にモヤモヤが残っていますが、一つの S3 バケットの中に複数の異なるストレージクラスのオブジェクトをバックアップできる、ということなのですね。バケット作成時の 2016年に少なくとも "Glacier Deep Archive" というストレージクラスはありませんでしたから。きっとちゃんと S3 を勉強すれば「ストレージクラス」はバケットの属性ではなくそこに格納されるオブジェクトの属性と書いてありそうです。

バックアップジョブの実行結果

HBS3 での確認

さて毎日データを追加してはバックアップジョブを実行するということを繰り返して、その結果はサマリーとしては下図 HBS3 のジョブ実行結果をご覧ください。

3 回目の処理ファイルが多いのは気まぐれで多くしたこと、4回目の実行で処理済みファイルが 0 なのは新規ディレクトリだけ作成してそこにはファイルを置かなかったためです。またここの表示されているファイル数にはバックアップ対象のディレクトリ自体は数に含まれていません。
処理時間としては、1回目：42秒、2回目：32秒、3回目：1分14秒でした。
ジョブの詳細結果は 3回目だけスクショを掲載しておきます。

AWS コンソールからの確認 (S3)

やはり、AWS コンソールから（ブラウザ上で）バックアップされたファイル単位で存在を確認することができました。旧 Glacier だとバックアップジョブは成功したと結果はわかるのですが、ファイル単位で本当バックアップされたかを確認したいと思ってもできないことだったので、これはバックアップする人にとってはありがたいことです。

ちなみに HBS3 で指定したバックアップ対象のディレクトリは "GlacierTesData-20210427" なのですが、アップロードされたディレクトリ構造は NAS 上のルートディレクトリ (Pro5300) から表示されていました。

AWS コンソールからの確認 (コスト)

Glacier, S3 ともテスト実施期間 (04/24-30) はそれ以前とコストに変化は見られませんでした。これは想像するに、今回のテストでは Glacier ではなく S3 にコストがチャージされるはずなのですが、小数点 2桁以下なので表示されないのだと思います（さすがに今となっては無料枠の利用はないと思いますので）。ちなみに Glacier で毎日 $0.22 チャージされているのは旧 Glacier へのバックアップ分でこれが 1ヶ月で約 $7 になっているので早く削除しないともったいないです‥

ということで、次回はリストアのジョブを準備して実行してみたいと思います。

2021-04-30

QNAP とクラウドバックアップ (3) - 新しい "S3 Glacier Deep Archive " を試す（雑な整理編）

NAS 家庭内IT ガジェットクラウドストレージ

前回まで 2回にわたって 2016年からバックアップを行なってきた AWS の Glacier というストレージサービスに関して(今更ですが)リストア実施やそのコストの確認を行なってきましたが、ちらっとご紹介したように 2019年から AWS は Glacier の機能拡張を行うとともに位置付けも新たにした "Amazon S3 Glacier" と "S3 Glacier Deep Archive" の提供を開始していました。
またそれとは別のお話ですが、私が昨年 NAS を TS-453Be に交換したのちにクラウドバックアップが正しく取れていなかったこともわかったので、もともとの Glacier より安い "S3 Glacier Deep Archive" というものを勉強してこれに NAS のバックアップをとりなおそう、というのが今回のお話です。

【前提のお話】アマゾンと Amazon と Amazon Web Service (AWS)
もともと Glacier とはどんなサービスだったのか？
新しくなった　Amazon S3 Glacier、Amazon S3 Glacier Deep Archive とは？

【前提のお話】アマゾンと Amazon と Amazon Web Service (AWS)

クラウドバックアップのご紹介で "AWS" についてたびたび触れていますが、あまり馴染みのない方のために補足しておいたほう良いかと思いましたので、少し AWS とそのサービスをちらっとご紹介しておこうと思います。特に役立つことはないと思いますが、知っていて損はないことを書いておこうと思います。

AWS は本家 Amazon.com の一事業

まず普段われわれが日頃お世話になっているネットショッピングのアマゾンは US の Amazon 社 (Amazon.com, Inc.)の子会社です。会社名自体に ”.com" が入っているところから全て商品サービスがネットで提供されていることが分かりますよね。この Amazon.com はネットショッピングだけではなく、各種コンピュータサービスも提供しています。それが AWS (Amazon Web Service) 事業です。ですので、AWS (Amazon Web Service, アマゾンウェブサービス)、 Amazon、Amazon.co.jp および Amazon.co.jp ロゴは、Amazon.com, Inc.またはその関連会社の商標です。

ちなみに Amazon.com の決算発表 (2020 Q4) を見ると、売上のページ (TTM; Trailing 12 months) に全体に占める AWS の割合などが掲載されています。2020年の第4四半期では全体の売り上げの中で 12%を占めているようです。

四半期ごとの売り上げ推移で、Amazon 全体の中で Webサービス事業 (AWS) は 12% を占めています。ちなみに日本の物販事業は international に含まれています。

クラウドコンピューティング

私たちがスマホアプリなど多くのネットを使ったサービスを利用していますが、昔だったらサーバーとなるコンピュータやデータを格納するハードディスク装置といったものを自社で購入して運用するのが当たり前だったのですが、そういったハードウェアを自分で購入しなくてもネットを通じて使えるようにするのがクラウドコンピューティングで、AWS はその先駆けであり現在も最先端をリードしている会社です。スマホアプリの多くのものが AWS の各種サービスを使っていますので、私たちも知らず知らずのうちに AWS にお世話になっているはずです。

AWS も Amazon.com のアカウントで

少し話は変わりますが、ネットショッピングの本家 US アマゾン (Amazon.com) も AWS も同じアカウントが使われます。別の言い方をすると、AWS を利用するには、日本で普通に我々が使っている Amazon.co.jp のアカウントではなく、Amazon.com のアカウントを作成しておく必要があります。もちろんこのアカウントで AWS だけではなく US アマゾンのネットショッピングも利用可能です。最近は日本への配送もしてくれる商品も増えている印象ですので、AWS 利用だけではなく US アマゾンのネットショッピングのためにも Amazon.com のアカウントを作っておくと便利だと思います。

もともと Glacier とはどんなサービスだったのか？

昔の話はあまり役立つものではないのですが、経緯も少し分かったほうが良いと思いますのでチラッとだけお話ししておきます。
AWS ではクラウドコンピューティングでのストレージサービスとして、初期段階から S3 と呼ばれるサービスを提供しています。これはパソコンなどの一般のコンピュータの HDD（正確にはファイルシステム）に相当するもので、オブジェクトストレージという形態で提供されています。クラウドで動くサーバーも実際には HDD を使用していますが、クラウドで動くアプリには物理的なデバイスを直接意識しなくても良いようになっており、HDD の容量とか故障とかを意識せず（ファイルシステムを意識せず）、バケットという器にデータをオブジェクトとして操作する仕組みを S3 で提供しています（詳細は割愛しますが、興味のある方はネットや書籍で勉強されると良いかと思います）。
S3 ではバケットを用途に応じていくつかの「ストレージクラス」として分類しています。例えば高速レスポンスの「汎用」に比べて「低頻度アクセス」はレスポンスでは劣るもののコストは安いなど。
そのうちそういった S3 のストレージクラスに比べても大容量だけれども滅多にアクセスしない長期保存を目的として、データ保存用の Glacier が後から登場しました。当時 Glacier は（私の認識では）S3 とは別のサービスとしてインターフェースも独自の API で提供されていました。保存したデータの内容を覗いてみるインターフェースもなく、バックアップとリストアに徹した物だったと理解しています。ただし、私のような一般の NAS ユーザーがそのバックアップに使うにあたっては自分で API を意識する必要はなく、QNAP などの NAS メーカーが Glacier にデータをバックアップしたりリストアするアプリを提供してくれているので、それを使えば良いようにはなっていました。

新しくなった　Amazon S3 Glacier、Amazon S3 Glacier Deep Archive とは？

私の勉強不足ではありますが、とりあえず QNAP のバックアップさえ安価に長期保存できれば良いという一般ユーザーの視点で雑なまとめを書き散らかしますが、詳細をチェックしたい方は AWS の記事をご紹介しておきますので参考にしてください。また実際に S3 Glacier Deep Archive をテストした記事もいくつかありましたのでこれも下の方にリンクを載せておきます。

Amazon S3 Glacierのよくある質問

新しい Amazon S3 ストレージクラス – Glacier Deep Archive

NAS ユーザーにとっての S3 Glacier と S3 Glacier Deep Archive を私の雑な整理でまとめてみると、おおよそ以下のことがわかっていれば良いと思います。

S3 の新しいストレージクラスとして S3 Glacier と S3 Glacier Deep Archive ができた
さらに安くなった！（一番大切！）
Glacier が S3 の一員になった ➡️ 使い勝手が以前とは変わるかも

S3 の新しいストレージクラスとして S3 Glacier と S3 Glacier Deep Archive ができた

上記の AWS の記事などはこの新しい二つのストレージクラスについて説明されています。でも今ひとつはっきりしないことは既存の Glacier はどう位置付けられるの？ということです。既存の Glacier は S3 Glacier となったのか？既存の Glacier はそのまま存続し新たに二つの S3 ストレージクラスができたのか？
どうやら後者の方ではないかと思います。

さらに安くなった！

上記の続きでもありますが、AWS が宣伝している「1 テラバイトあたり月額 1 USD から利用できる」は S3 の新しいストレージクラスのうち "S3 Glacier Deep Archive " に言及しているようです。実際に料金体系は "Amazon S3 Glacier 料金 (Glacier API のみ)" と "Amazon S3 の料金" の二つの体系があり、「「1 テラバイトあたり月額 1 USD から」は後者の "S3 Glacier Deep Archive" でさらに「米国東部（オハイオ）」リージョンを利用した場合の "0.00099USD/GB" を示していると考えられます。ちなみに同じ "S3 Glacier Deep Archive" でも「米国西部（北カリフォルニア）」や「アジアパシフィック（東京）」では "0.002USD/GB" となっています。Glacier API の場合ではアジアパシフィック（東京）」では "0.005USD/GB" となっていますので、同じ東京リージョンを使うのであればすぐさま "S3 Glacier Deep Archive" にいうした方がお得なようです。（as of 2021/04/30）

0.00099USD/GB (S3 API/オハイオ) < 0.002USD/GB (S3/API/北カリフォルニア、東京) < 0.005USD/GB (Glacier API/東京)

料金 - Amazon S3 ｜AWS

料金 - Amazon S3 ｜AWS

S3 Glacier および S3 Glacier Deep Archive の Amazon S3 ストレージクラス料金表

「安くなった」というお話の中心は上記の通りですが、補足しますと上記の料金は

ストレージ
S3 バケットにオブジェクトを保存するための料金

という部分にかかるコストで、他にもコストはかかります。さらに複雑なのですが、保存しているデータを取り出すにもコストが発生します。

リクエストとデータ取り出し
S3 バケットとオブジェクトに対して行われたリクエストに対してお支払いいただきます。

のちのテスト際にも見直そうと思いますが、S3 Glacier 、S3 Glacier Deep Archive それぞれにもいくつかのオプションがあってコストは変わるようです。

*  S3 Glacier : 迅速, 標準,大容量

*  S3 Glacier Deep Archive  : 標準, 大容量

データ転送
Amazon S3 に出入りするすべての帯域幅に対してお支払いいただきます。

これは取り出したデータをインターネットを通じてダウンロード（リストア）するのに必要になります。

Glacier が S3 の一員になった ➡️ 使い勝手が以前とは変わるかも

一旦コストの話から離れて、S3 の新しい二つのストレージクラスとなった Glacier は何か使い勝手が変わるのでしょうか。
はっきり分かっているのは、今までの Glacier API に加えて S3 インターフェイスが新たに使えるようになった、ということですが、それは同じ保存データに対してどちらのインターフェースでも使えるということではなく、既存の Glacier API でバックアップされたものは Glacier API でしかリストアできず、逆に新しいストレージクラスは S3 API からしかバックアップ/リストアできないのだと考えられます。
では上記の料金体系を踏まえて、既存の Glacier API で作成したバックアップは削除して、S3 ストレージクラスの Glacier でバックアップし直すことを考えると何か良いことがあるのでしょうか？
これは実際にテストしてみなければ分かりませんが、QNAP のバックアップアプリの HBS3 での取り扱いは何か変わるでしょうし（S3 Deep Archive のストレージクラスを明示的に指定できなければ困る）、S3 のファミリー入りしたのであれば既存 Glacier にはできなかった保存データの中身（ファイル名など）をブラウザ経由でチェックすることもできると考えられます。これはちょっとしたことですが、今まで vault と呼ばれる器の名称とその説明書きでしか内容を判断できなかったものが直接どのようなファイルがバックアップされているか確認できるということはバックアップの確認もしやすくなるのではないかと期待できます。
他にもパソコン上のデータでも直接ブラウザから S3 にアップロード（バックアップ）することもできるという記事も見かけますので、NAS 経由ではなくパソコン上のデータのバックアップにも用途が広がりそうです。

note.com

qiita.com

dev.classmethod.jp

ということで、今まで Glacier にバックアップしてあったものをそのまま置いておくよりも S3 のストレージクラスとなった　Glacier を用いた方が長期的にはコストが安くなるのは間違い無いでしょう。私の場合たまたま現在の TS-453Be のディレクトリ構造と異なるバックアップが Glacier に残っているので、TS-453Be から S3 Deep Archive のストレージクラスに新規にバックアップをとって古い Glacier のバックアップは削除しようと思います。

2021-04-25

Mac mini が 10GbE をオプションでサポート -追加費用は 11,000円と 10GbE NAS 運用への近道？

NAS 家庭内IT 10GbE ガジェット

【国内正規品】OWC Thunderbolt 3 10G Ethernet Adapter (OWC サンダーボルト3 10G イーサネットアダプタ) Thunderbolt 3 / 10GbE / Mac/PC

ネット情報で知ったのですが、M1 チップで好評な iMac が知らないうちに 10GbE のオプションを選択できるようになっていて、しかもお値段が 11,000円❗️とお安いのでびっくりしました。

japanese.engadget.com

私が MacBook Pro に使っているのは Thunderbolt 接続の OWC のアダプターで昨年夏に探した範囲では一番求めやすいものでしたが、それでも今でも 3万円くらいします。

https://www.dospara.co.jp/express/dospara/spo1733368www.dospara.co.jp

なかなか新製品の出てこない 10GbE 関連製品においては今年になってセンチュリーから Thunderbolt 接続の 10GbE アダプターが 2万円を切る価格で登場しました。もう少し 10GbE が普及すればもっと低価格化が進むのだとは思いますが、iMac の 11,000円は安い！

Thunderbolt3 to 10GbE LAN adapter [CATB3LAN10G]www.century-direct.net

安いだけではなく、iMac の本体内蔵（のはず）のオプションの良いところは単に安いだけではなく、貴重な Thunderbolt コネクタを消費しなくて済むことはもっと大きいメリットかもしれないですね。

「今は 10GbE なんて必要ないよ」という方でも、iMac でデジカメ写真を扱おうと考えていらっしゃる方には注文時にぜひオプション選択しておくことをオススメします。

2021-04-25

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

家庭内IT NAS ガジェットクラウドストレージ

前回の実施結果です。

QNAP(キューナップ) TS-453Beクアッドコア1.5 GHz CPU 2GB/4GBメモリ 4ベイ DTCP-IP/DLNA対応ランサムウェアからも復元可【日本正規流通品】

リストア対象（バケット）の確認と HBS3 復元ジョブの設定
HBS 3 による Glacier のリストア
- 実行時間は？
- コストは？
リストアしたデータの中身は？
次に備える

QNAP(キューナップ)

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

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

今回のリストア（ダウンロード）対象は "Photo_Full_20161129b"。クラウド上の容量は 913.5GB の表示

この vault を HBS3 の復元ジョブの「バケット名」に指定します。

実際には vault の存在する AWS データセンターの地域名（リージョン）やアクセス件に関する設定などもありますが、もともとはバックアップを作成するときに指定した項目なのでここでは割愛し、新しいバックアップを作成するときに細かな項目もご紹介したいと思います。

HBS 3 による Glacier のリストア

実行時間は？

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

それなりに時間もかかりますので、あとは NAS に実行をお任せしてパソコンは off にして問題ありません。

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

コストは？

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

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

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

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

CompareMerge

Tien Thinh Vu
開発ツール
¥2,200

apps.apple.com

CompareMerge で目視比較

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

差異：ファイルは双方に存在するけれども何かしらの？相違がある。
左側のみ：オリジナルにしか存在しない
右側のみ：リストア先にしか存在しない
同一：オリジナルにもリストア先にも同じファイルが存在する。

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

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

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

双方にディレクトリは存在するけれどもファイルがオリジナル側にしかない：これはみる限りは ".DS_Store" というファイル。調べてみると MacOS が勝手に作成している隠しファイルらしい。つまりもともとバックアップをとったときには Lightroom は Windows マシンのローカルで作業していて、NAS は Windows ローカルのバックアップを置いてあったので、NAS のドライブに Mac から直接アクセスすることはあまり無く、リストア先のほとんどのディレクトリには ".DS_Store" は存在しなくて当然です。
ディレクトリ自体がオリジナルにしかない：これも当然そうなるディレクトリがあります。TS-431p からクラウドバックアップしていた当時には持っていなかった OM-D EM1 mk3 や新しいスマホ用のディレクトリが該当します。他にも比較的最近整理用に作成したディレクトリもこれに該当します。

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

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

バックアップした後に削除したファイル：主にブレやボケなど不要な写真を削除していたのがリストされていました。
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.またはその関連会社の商標です。

2021-04-23

QNAP とクラウドバックアップ (1) - 現在は旧AWS Glacier を利用 - その実際のコストとリストアをやってみる(準備編)

NAS 家庭内IT ガジェットクラウドストレージ

QNAP(キューナップ) TS-453Beクアッドコア1.5 GHz CPU 2GB/4GBメモリ 4ベイ DTCP-IP/DLNA対応ランサムウェアからも復元可【日本正規流通品】

フィルム写真のデジタル化に伴い、NAS 上に新たな大切な画像ファイルが増えています。私の NAS は RAID 1 構成されているので、たまに HDD 不良/故障が発生しても RAID の機能でデータはしっかり保持されたまま新しい交換 HDD を装着すればちゃんとその機能は復活します。
でも、NAS が盗難や火事にあってしまったら、いくら RAID とは言っても復旧は困難でしょう。盗難や火事にあわないように生活するのは大前提ですが、南海トラフや首都直下などの大地震に巻き込まれないぞ！と言うのはなかなか難しいことだと思います。
そうなると HDD を含む NAS が使用不能になることを前提としたバックアップが必要です。自宅が損壊することも想定すると、 NAS to NAS の遠距離地点バックアップなども一つの手段として考えられるでしょうけれども、企業のように複数拠点があるような場合は良いですが、個人では別荘を持っているような人以外は難しいソリューションだと思います。そうなると個人の NAS と併用できる現実的なバックアップとしてはクラウドバックアップしかないと考えています。

過去の記事ではチラッとしか紹介していませんでしたが、私は以前の NAS である TS-431 の頃から本当に失いたくないデータは丸ごとクラウドストレージにバックアップしています。そこで、現状のクラウドバックアップの状況（容量や費用）と点検するとともに、実際にリストアも行ってちゃんとバックアップ出来るか？時間は？など確認してみたり、利用しているクラウドストレージが新しいサービスを提供していたようなので、新しいサービスも検討してみたいと思います。

今回は今までのクラウドバックアップの利用状況のチェックとリストアの準備までを書き留めておこうと思います。

QNAP(キューナップ)

私の NAS ➡︎ クラウドバックアップ
- バックアップ「元」 - QNAP のバックアップ機能 "HBS 3"
- バックアップ「先」 - Amazon の保存用クラウドストレージ "Glacier"
  - 安い！のだけれど
現在の Glacier 利用状況
Glacier からローカルにリストアしてみる！
- リストアジョブの作成
  - 外付け HDD を準備する

私の NAS ➡︎ クラウドバックアップ

バックアップ「元」 - QNAP のバックアップ機能 "HBS 3"

NAS からクラウドにバックアップする手段としては、NAS のアプリが提供されています。QNAP だと HBS3 (Hybrid Backup Sync 3) と呼ばれるアプリがあって、パソコンからブラウザで操作します。他社でも同様の仕組みが提供されていると思います。

HBS3 に関する QNAP のサイトはこちらなのですが、そこは個人利用ではとっても高機能すぎる？説明が多いので下図を見ていただければ「QNAP NAS で HBS3 を使うことで大抵のクラウドストレージにバックアップすることができる」ことがわかると思います。

私がデータバックアップ用に利用しているのはアマゾンの Glacier というサービスです。

HBS3 での保存先クラウドストレージの選択画面。Glacier が先頭にあります。

バックアップ「先」 - Amazon の保存用クラウドストレージ "Glacier"

(下記の情報は特に断っていない限り 2016年当時に調べた理解をベースに記載しています。現在は色々変わっているかもしれません。この辺りは後から勉強し直してみようかと思っています。 )

"Glacier" という名称は「氷河」という意味らしく、データを凍結保管しておくというイメージのようです。それは頻繁なアクセスを想定せず、 Google drive のような UI でファイルの中を一つ一つチェックしたりする機能も無く、API 経由で利用する前提の、但し安い！というのが私の理解です。 API で利用する、ということは自分でプログラムを書くことを思い浮かべますが、API を利用して作られている HBS3 のようなアプリがあればそれを操作すれば特にプログラムが書けなくても全く問題ありません。

センチュリー裸族のお立ち台DJ クローンプラスSATA6G Ver.2 (WEB簡易パッケージ仕様) CROS2EU3CP6G2_FP

安い！のだけれど

上の Glacier の説明ページに

1 テラバイトあたり月額 1 USD から利用できる、データアーカイブのための長期保存用の安全で耐久性に優れた ‥

とありますが、安いと思いませんか？ 8TB HDD で 12,000円だとして（まだそこまで安くない）、TB 単価は 1,500円です。Glacier は 110円/ドルとして TB 単価は 110円/月。
もちろん考え方次第です。HDD だと 1年ちょっとで元が取れる計算ですが、その間電気代はかかりますし、何年かに一回は故障して交換は必要なので、無制限に容量当たり単価が低減することはありません。
とは言え、HDD に比べて直接的に安い、と言うわけではありませんが、本当に大切なファイルであれば、火事に見舞われても地震に襲われても大丈夫なデータセンターに預けておくことで少なくとも自宅 NAS 本体の被災の心配をしなくて済みます。
ということで、私は 4年間 Glacier に預けっぱなしにしています。

但し、上でも下線付きで書いたように頻繁なアクセスには不向きです。なぜなら一つはファイルの読み書きを簡単に行う機能はなく、まとめてバックアップ、リストアする前提になっているからです。あとはそれ以上に、アクセスにコストが発生するということです。つまりバックアップをしたりリストアをする場合には、上記とは別のコストが発生します。上記の TB 単価は預けておくだけのコストとなります。

というわけで、私の Glacier の利用状況を確認します。

現在の Glacier 利用状況

2016 年から Glacier に主に写真ファイルをバックアップしていていました。Glacier ではボールト (Vault; 地下貯蔵庫の意味) というものを作成してそこにバックアップデータを保管するイメージです。
その作成済み Vault ですが、QNAP の HBS 3 をで確認することができます。

ショック！な発見‥

現在のバックアップ先 "Pro-5300-20200924" には正しくバックアップされていない！（2.9GB しかない）

ここには先ほどご紹介した貯蔵庫の Vault がリストされています。
まず私が確認したのが、NAS を TS-453Be に移行した後に写真ファイルを中心とした大切なファイルをバックアップし直したはずの Vault "Pro5300-20200924" のサイズがたった 2.9GB。写真関連で TS-431 の時に作成した Vault は 913GB。TS-453Be での Glaceir へのバックアップはうまく取得できていなかったのです😢
幸いなことに TS-453Be が健在なことと、その大半を占めるファイルは TS-431 のバックアップに含まれていますが、近いうちに再度バックアップを試みます。また TS-453Be でのバックアップがちゃんと取れていなかった理由はわかりましたので、これも次回以降どこかでご紹介します。
ということで、今回リストアの実行は TS-431 で 2016年から積み重ねてきた "Photo_full_20151129b" の Vault から行うことにします。そのサイズは 1TB 弱なので、（お金はかかるけれども）実測してみる価値はあると思います。

使用容量は？

私の Glacier に預けてあるデータの使用総量は上図にあるように、4個の Vault の合計である 1.2TB です。

費用は？

1 テラバイトあたり月額 1 USD から利用できる、データアーカイブのための長期保存用の安全で耐久性に優れた ‥

これは本当でしょうか？上記にあるように私の1.2TBの保管にかかったコストの実績を確認してみます。 AWS コンソールで確認してみます。

今年に入って Glacier へのアクセス（バックアップやリストア）は無いので、純粋な保管コストは "$6.18/1.2TB月 = $4.9/TB月"(税抜) で、謳い文句の「1 テラバイトあたり月額 1 USD から」に比べるとはるかに高いです！

なお、AWS の肩を持つわけではありませんが、2016年当時の単価は現在の $4.9/TB月より高かったはずですが、その時に HDD 容量単価との比較をしてさほど見劣りするような高コストではなかったと記憶しています。そこから毎年のように HDD 容量単価が低減するとともに、AWS もストレージコストを低減させているので、最新の Glacier と相まって1 テラバイトあたり月額 1 USDを実現させたのだと理解しています。AWS コンソールで 4年前のコストを確認することはできませんでしたが、Glacier 利用開始直後は確か 500GB くらいで徐々に容量は増えていったのですが、ずーっと $7/月くらいの請求(含む、若干の他のサービス)が続いていたと思います。さらに新しい Glacier でより安くなっているのであれば、後々 TS-453Be から新しい Glacier にバックアップしなおすべきでしょう。

Glacier からローカルにリストアしてみる！

今までたびたび NAS から Glacier へのバックアップは行っていましたが、逆のリストアつまりクラウドのバックアップからローカル HDD への復元ダウンロードを本格的に行ったことがありませんでした。これはリストア自体がバックアップより時間がかかることもあるのですが、上記のようにリストアするにしてもコストが発生するので、vault 全体をリストアするとなると全体の容量に対するアクセスコストが発生してしまい、ちょっと敷居が高かったのです。あと大きい阻害要因として、あとで説明しますが旧インターネット回線の遅さ。当時 500GB 程度のバックアップに1週間くらいかかっていたので、リストアでもそんなにかかってはやっていられない！という気持ちがありました。
しかし現在は高速安定のインターネット環境になっているので、ネット環境上はなんの不安もなく実施可能です。

リストアジョブの作成

リストアするだけの空き容量が NAS 上にあれば、QTS から HBS 3 を操作してリストアジョブを作成して実行することでローカルに復元できます。細かい話もありますが、基本はクラウド上のリストア対象貯蔵庫 (Vault) と、リストア先のローカルの場所を指定するだけです。

HBS3 のリストアジョブの設定としては対象の Vault を「バケット名」に指定するだけ。

外付け HDD を準備する

私の場合、TS-453Be の空き容量が 1TB も残っていないので今回のテスト用に一時的に TS-453Be に HDD を USB 接続してリストア先を確保しました。今回 HDD を NAS に USB 接続するにあたっては結構昔から使っている「裸族のお立ち台」を接続してみました。現行モデルよりは古いですが、USB 3.0 で接続できるので TS-453Be のパフォーマンスにも十分対応できそうです。

センチュリー