QNAP のバックアップソリューション HBS3 を使っていていろいろチョンボをして悩むことがありました。もともと下記の記事の流れで記載していたのですが、文章が長くなりすぎたので別の記事として切り出しました。
ストレージ構成変更にあたっての作業でのチョンボ
リストア対象の共有フォルダを作成しないでリストアできない！と慌てる
以前は static volume だった Datavol2 にあった "Pro5300" というディレクトリをバックアップして、新たにストレージプール上に作成した Datavol2 にリストアするのですが、その際に "Pro5300" のディレクトリ（共有フォルダ）を作成しないでリストアしようとして構成がうまくいかず悩みました。これは私の過去の経験上「バックアップはボリューム単位で取得する」という概念を前提として持っていたため「バックアップの中に含まれるディレクトリもリストアの過程で作成される」と言う認識だったのですが、HBS3 ではリストア先にリストアする共有フォルダが存在しないとジョブの構成ができません。HBS3 によるバックアップの概念には「ボリュームをバックアップする」という考えはなく、「共有フォルダをバックアップし、リストアの際には先にその共有フォルダをリストア先に作成しておかないとリストアできない。」ということの様でした。
さらに言うと、私の認識では HBS3 はジョブの構成でリストア先を "Origlonal location" に設定するとどのボリュームにあるかは関係なくバックアップされている共有フォルダと同じ名称の共有ホルダをリストア先として自動的に選択する様です。
リストア対象の共有フォルダを誤って別ボリュームに作成してそのボリュームがパンク！
上記の流れのチョンボなのですが、私が改めてリストア先のボリューム "Pro5300" を作成する際に、誤って新規作成したボリュームではなく既存のボリュームに作成してしまったのです。そうするとどうなるか？というと既存のボリュームがパンクしてしまい、ジョブがエラーで終了してしまったのです。
落ち着いていればそんなことは避けられますし、仮に共有フォルダ作成ボリュームを間違ってパンクさせただけだったらまだ良いのです。しかしそうした際には誤ってリストアが途中まで行われてしまった残骸の "Pro5300" を削除しなければならず、別のジョブでの残骸の削除を繰り返していると、残骸削除操作を何回も行ううちにチェックが雑になってしまい、同名のバックアップ HDD にある "Pro5300" を削除してしまう、という最悪の状況に陥ったりします。
小さな誤りや異常が繰り返し発生していると、だんだん頭が煮詰まってきて冷静な作業ができなくなってしまいますね。
クラウドからのリストアの際にオプションで「一括」の指定を忘れる
これはローカルでのリストアには無い話で、クラウド（S3 Glacier Deep Archive) からのリストアに限った話です。
S3 Glacier Deep Archive は長期保存用に平常時は低コストでサービスが提供されていますが、アップロード時、ダウンロード時（リストア時）にそのアクセスに個別のコストが発生します。これは QNAP の仕様ではなく AWS 側の仕様です。
（詳細は下記記事を参照ください）
AWS 側からどのデータ取り出しオプションを用いるかは、HBS3 でのジョブの設定時に指定します。AWS 側の「大量 (bulk)」が HBS3 側では「一括 (bulk)」に相当しますが、ジョブ設定上のデフォルトは「標準」です。標準以外のオプションはドロップダウンに隠されているので、意図してクリックしない限り「一括」の文字は現れません。気が急いているとクリックして「一括」に変更するのを忘れてしまいがちで、実際にボリュームの大半のダウンロードを「標準」の設定のまま行なってしまいました。
ちなみに怖くて AWS コンソールのコスト部分はチェックしていません。
その他の作業での気づき
あったらその時に追記していきます。
