サウンドバーが壊れたので新調した - YAS-209

くまのお世話で幾つか記事が滞っていましたので、少しずつ書き始めたいと思います。

今使っているテレビの前の代から、ヤマハのサウンドバー YSP-2200 を使っていましたが最近テレビからの音が出なくなり、毎朝テレビの電源を入れた後に YSP-2200 の電源を切るルーティンになっていました（サウンドバーの電源を切ることにより、テレビ本体のスピーカーから音が出るようになる）。そしてやはりテレビのスピーカーではニュースなどは問題ないのですが、映画や音楽では「ちょっとなぁ〜」と言う気持ちを持って過ごしていました。
そこでもう 10年も使っているデバイスなので故障するのもやむなしと思って買い替えを検討したのですが、くまの体調が悪くなってきていたこともあるかもしれませんが、結構新し物好きではあるのですが、最新スペック満載の新型を選ばず、発売からある程度時間の経っている比較的安価なものを選択したというお話です。

ヤマハ フロントサラウンドシステム ブラック YAS-207(B)

最近のサウンドバーでの流行り

ブログの記事にはしていませんでしたが、少し前に Apple TV 4K (デバイスの方) を導入して Amazon Prime や Youtube をリビングのテレビで見る機会が増えたのですが、Apple TV 4K の売り文句に、Apple 独自の空間オーディオや Dolby Vison とか Dolby Atoms とか高機能 AV 用語が散りばめられています。Dolby Vison は映像の世界のお話ですが、Dolby Atom は音響のお話で、左右だけではなく音の高さを再現するものだそうです。
当然ソースと再生デバイスに依存するお話なのですが、Apple TV+ (コンテンツ配信の方) では対応したコンテンツの配信も始まっているようです。
ネットで調べると、ソニーや JBL では比較的低価格帯から対応している製品があるようで、量販店で聞いてみるとやはりその2社が積極的に Dolby Atoms に取り組んでいるのだとか（ヤマハのスタッフのかたが説明してくれました）。

YSP-2200 でよかったこととガッカリしたこと。そして現実。

一方今まで使っていた YSP-2200 はサブウーファーも付いており、当時はそれなりの価格帯の製品だったように思います。低音はそれなりに満足していたのですが、買ってすぐガッカリしたのが音響自動セット機能の「インテリビーム」。テレビを視聴する位置に専用のマイクをセットして音響セットアップを行うと最適な設定にお手軽にできると言うもの。ヤマハの名誉のために正確に言うと、この機能がダメだと言うのではないのですが、私の家のリビングルームではあまり効果を発揮することができ無かった、ということです。私のリビングはテレビに正対して左手は外に面した全面ガラス窓、右手はダイニングに続くスペース、と左右が大きく非対称で、右手は音を反射する壁が遠いのです。当時何回かインテリビームのセッティングを行いましたが、いくら設定してもデフォルトより音が悪くなる一方でした。
すっかりその高機能を発揮できていなかった YSP-2200 ですが、今更その機能を調べてみると、

「アルミボディ＋専用サブウーファーで、高音質な7.1ch再生を実現」

なんて書いてありました。
「ん？ 7.1ch ？ そういえば 7.1ch も上部のスピーカーを使っていたな。YSP-2200 も『高音質な7.1ch再生』を謳っていたけれどどうだったんだろう？？
と思ってしまいました。もちろん 7.1ch のソースでしっかり確認したことは一度も無かったのですが、そもそも実際に上部のスピーカーを設置せずサウンドバーだけでしかもうちのリビングで上下方向まで再生するなんてできるのだろうか？と言う疑念が湧いてきました。

Dolby 社の説明

本家 Dolby 社の説明でもモバイルでも可能としていますが、多くのスピーカーを配置して視聴するのが基本だといっているように思えました。

本家「ドルビーアトモス」「概要」より

確かにテクノロジーの進化はあるので、AirPods Pro での空間オーディオは確かに自分でも聞いて違いはわかります。しかし「一度聞いたら無いことに耐えられない」ほどのめり込むものでは無いのも事実です。Dolby Atoms はどうなのでしょうか‥

量販店での視聴

ソニーか JBL にしようかな、と思ってネット情報を見ていると、スペックが気になります。気になるとより良いスペックの製品がさらに気になっていくという循環に入り込みます。そこで再度新宿や秋葉原の量販店に視聴しに行ってみることにしました。普段あまり足を踏み入れていませんでしたが、ちゃんとした個室を再現した視聴環境があったと思ったからです。でもどうやらそういった個室でチェックできるのはサウンドバーなどではなく高性能スピーカーとアンプなどのようで、サウンドバーはオープンの展示だけでした。少々ガッカリしたものの「これはサウンドバーはいくら高機能でも個室でサウンドチェックするようなものでは無いんだな。」と言うメッセージを得たのだと理解しました。
その上でオープンスペースに展示してある製品を幾つかチェックしてみると、少なくとも私の耳では（当然）左右のサラウンド感とサブウーファーの有無による違いはそれとなく自然に分かりましたが、Dolby Atoms は頭上を飛ぶヘリコプターといった限られた音源と音に対する集中力がないとはっきりとは聞き取れ無かった、というのが実感でした。それよりはカタログスペック上はあまり華やかではない Bose の製品の方が「おっ！」と言う印象が強かったです。ただし Bose だけは流しているコンテンツが宣伝用のものだったので、そこは差し引かなければならないかもしれません。

最終方針は高価ではなく安定した評価のあるもの

正直に言うと、「良いものを買ってもうちのリビングではなぁ」と言う諦めと、だんだんめんどくさくなってきたこともあり、高い製品でガッカリはしたくないという思いも強くなり、新製品ではなくても値がこなれて評価も安定している製品にしよう、と言うことに落ち着きました。

実際に YAS-209 はどう？

私にはサウンドに関するレビューを書けるような耳も文章力もありませんが、十分満足しています。テレビのスピーカーとは比較にならない音の広がりと重厚さには満足しています。多分倍くらいの値段のしていた YSP-2200 との比較は、もうだいぶ YSP-2200 の音を聞いていないのでちゃんと比較できませんが、もしかしたら YSP-2200 の方がより重厚で好きだったかもしれません。
でも YSP-2200 は Bluetooth はおろか Lightning にも対応しておらず "30ピンDockコネクタ" の対応のみだったので、iPhone の音楽を聴くこともできずつまらなかったのですが、YAS-209 はもちろん Bluetooth 対応です。しかしそれ以前に Apple TV があるので iphone は使わず Apple TV で Apple Music も再生できるので Apple TV 経由が多いですが...

最後に HDMI の接続

ほとんどサウンド機器のレビューには程遠い「諦めの選択」の話で役に立つ内容はあまり無かったと思いますので、Apple TV も含めた HDMI/ARC の接続だけ書いておこうと思います。
ARC (Audio Return Channel) に関しては調べてみると説明が簡単に見つかるのでここでは素人の私が詳しく書くことはしませんが、私のいつもの雑な理解では以下のようなものです。

• HDMI : 映像と音声を一方通行で伝える規格。簡単な例ではテレビに対して、外部からビデオレコーダーやゲーム機、Apple TV 4K のようなセットトップボックスを接続し、テレビで再生するために使う。
• HDMI/ARC : 上記の一方通行に加えて逆方向に音声データを戻せる規格。テレビから音声をサウンドバーに出力できる。今までの光ケーブルの代替。

今回私は上図のように接続していますが、一つだけ疑問を持っています。テレビを用いず Apple TV 4K で音楽を再生するにあたっては水色の矢印に従って 「Apple TV 4K → サウンドバーのスピーカー」と音声信号は流れるのでしょうけれども、映像をテレビで再生するときの音声データはどう流れるのでしょう？赤色の矢印のように一旦テレビに映像と一緒に渡された音声データが ARC でサウンドバーに戻されるのでしょうか？それとも音声データは Apple TV から直接サウンドバーに認識されるのでしょうか？？？ eARC なんで規格も出ているようですが、映像と音声を一本のケーブルで扱えるのは便利ですが、データの流れの方向性も考えるとちょっとよくわからないな、と思いました。

ヤマハ | YSP-2200 - サウンドバー - 概要

jp.yamaha.com

9年前の Windows PC では Windows 11 に移行できないのかな？ - Endeavor Pro5300

最近 Microsoft が発表した Windows 11 ですが、すでに Windows PC は私の環境ではすっかりメインではなくなって久しいので、あまり真剣に考えていませんでした。とは言え、Windows 10 の時も
「Windows 10 に無理矢理にでも移行させようとする Microsoft に嫌気がさしていっそう 10 にアップデートしたくなくなった」
とは思いながらもしばらくするとやっぱり Windows 10 にアップデートしてしまったように、きっと今回も移行できるのであれば移行するのだろうな、と思って、チェックプログラムを実行してみました。

Endeavor Pro5300

私の Wondows PC は Epson の Endeavor Pro5300 で、2012 年頃に Window 7 モデルとして購入したものだと思いますので、ほぼ 10年前の機種となります。

faq.epsondirect.co.jp

「PC の正常性のチェック」の実行

この日本語が今ひとつのチェックプログラムは Microsoft のサイトから導入できます。

チェックプログラムなのに実行すると「Windows 11 を導入しています」と驚かせるような表示がありますが、GA にもなっていないのに導入されるわけがないだろうと「今すぐチェック」を押してみます。 www.microsoft.com

「PC の正常性のチェック」って日本語がおかしいプログラム

結果はあっさりと「この PC では Windows 11 を実行できません」との表示。 不適合要因は示されていません。

あっさりと Win 11 不適合と。原因は示されず。

Windows 自体を英語モードにすれば不適合の要因も教えてくれる？

移行の可否しか教えてくれなかったチェックプログラムが英語モードであれば否の場合の理由も教えてくれる様になった、とのことです。

Windows 11チェックプログラムに「アップデートできない理由」が分かる新機能 - ITmedia NEWS

Windows を英語モードにするには

設定 → 時刻と言語→ 言語 → Windows の表示言語

で "English (United States)" を選択し（場合によっては言語の導入が行われて）sign out/in で反映されました。

再実行

日本語でおかしな名称のチェックプログラムは "PC Health Check" と言う名称でした。Health Check を「正常性チェック」と訳したのはきっと Microsoft の人ではないと信じたいと思います。

Secure Boot に対応していない？

どうやら "Secure Boot" に対応していないと言うことの様です。
そういえば Pro5300 を購入したあたりの時期には、旧来の BIOS 起動の仕組みから UEFI なる仕組みが出回ってきたところでしたが、私は UEFI はよくわかっていなかたので Disable にしていました。この辺りは変更してみる必要がありそうです。ついでにハードウェアでのセキュリティモジュールの TPM も Disable のままにしていたはずなのでこれも変更しなくっちゃ。

Pro5300 を Setup Utility で構成変更

再起動時に "Delete" キー押下で Setup Utility に入れます。一通り眺めて "Secure Boot" と言う直接的な項目名は見当たらなかったのですが、下記の項目は設定変更してみました。

• "Security" → "TPM Function" を Enable に

• "Boot" → "Boot Settings Configuration" → "UEFI boot" を Enable に

• "Boot" → "Boot Settings Configuration" → "Boot Device Priority" の "1st" を UEFI に

それでもダメだって

再起動して "PC Health Check" を再実行してみましたが、残念ながら状況は変わりませんでした。

msinfo32 で確認してみる

Windows で一体ハードウェアがどの様認識されているのか確認するために、msinfo を実行してみました。

Secure Boot は "Unsupported" だって‥

明らかに "Secure Boot state" は "Unsupported" となっていますので、Pro5300 では今の Windows 11 の基準では対象外なのでしょうね。気になるのが "BIOS mode" が "Legacy" となっていること。この後も Setup Utility で確認しましたが、"UEFI boot" は Enable になっていましたが、UEFI モード？になっていないのでしょうか。

負け惜しみ？

ま、Windows 11 がどうしても使いたいわけではないし、Secure Boot が

2013年に仕様が策定されたUEFI 2.3.1から対応

と言う仕様のようなのでまだ世の中には Secure Boot に対応していない PC は山ほどあると思われます。Microsoft が積極的に Windows 10 を 11 に移行させたければきっと条件も緩和される可能性もあるので、またその時に考えることにしたいと思います。
(一瞬だけ「10年ぶりに新しい Windows PC を買うかな？」とよぎり Epson Direct を見てしまいましたが、冷静さを保つことができました。)

https://shop.epson.jp/pc/desktop/

再び AirPods Pro で雑音 → Genius Bar で点検、交換してもらう

昨年 9月にチリチリノイズで本体を交換してもらった AirPods Pro ですが、ふたたびチリチリノイズが発生しました。 blog0.kurikumachan.com

通常では気が付かないのですが、ノイズキャンセリングをオンにすると途端に右側にチリチリと異音がするようになりました。とくに周囲の低音ノイズがあったり、音源自体もウッドベースの曲などを聴くとハッキリとしたノイズが出て気になります。一昨日久しぶりに飛行機に乗ったのですが、落ち着いて音楽を聴いていられないほどの状況になりました。
と言う事で、Genius Bar の予約を取って行ってきました。昨年 9月は Apple Store もようやく開店し始めて人数制限が強かった時期だと思いますが、現在ではさほどの人数制限は無いようです。とは言え家族連れで来店するようなお客さんには「椅子はお一人分しかありませんので、どこかでお待ち頂く方が良いかも知れません。」と案内していました。

私の AirPods ですが、15分ほどバックヤードで点検した結果「左右ともエラーが出ていました」ということで両方とも交換になりました。購入から 1年を超えているのですが、AppleCare+ のおかげで無料での対応でした。 今ネットで AppleCare+ で支払った料金を確認すると 3,400円だったそうな。 iPhone の AppleCare+ は今ひとつ元が取れない印象だけれども、AirPods は元が取れた感じ。

ところで AirPods Pro を買う前は結構な数の Bluetooth イヤホンを試していましたが、AirPods Pro を使い始めてからこの使い勝手と音質になじんでしまい、一切他の Bluetooth イヤホンを検討する事もなくなりました。もちろん AirPods Pro にも不満なところもあり、特に最初は音量調整が出来ない事がとても不便に感じました。でも慣れとは恐ろしいモノで、急に音量を下げたいときは単に再生停止をするだけ、その他音量調整をしたいときは iphone をとりだして操作することに慣らされてしまいました。
最近ソニーの新しいデバイスも発表されていて、少し前の自分だったらポチっていたかもしれないのに全くその気配も無いのは AirPods に飼い慣らされてしまったからなのでしょうか。

ソニー ワイヤレスノイズキャンセリングイヤホン WF-1000XM4 : 完全ワイヤレス/Amazon Alexa搭載/Bluetooth/LDAC対応/ハイレゾ相当 最大8時間連続再生/高精度通話品質/IPX4防滴性能/ ワイヤレス充電対応/2021年モデル / マイク付き 360 Reality Audio認定モデル ブラック WF-1000XM4 BM

Apple AirPods Pro

Apple AirPods Pro (整備済み品)

QNAP のバックアップソリューション HBS3 を使って戸惑ったこと、チョンボしたこと

QNAP のバックアップソリューション HBS3 を使っていていろいろチョンボをして悩むことがありました。もともと下記の記事の流れで記載していたのですが、文章が長くなりすぎたので別の記事として切り出しました。

blog0.kurikumachan.com

---

ストレージ構成変更にあたっての作業でのチョンボ

リストア対象の共有フォルダを作成しないでリストアできない！と慌てる

以前は 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 側の仕様です。 （詳細は下記記事を参照ください）

blog0.kurikumachan.com

AWS 側からどのデータ取り出しオプションを用いるかは、HBS3 でのジョブの設定時に指定します。AWS 側の「大量 (bulk)」が HBS3 側では「一括 (bulk)」に相当しますが、ジョブ設定上のデフォルトは「標準」です。標準以外のオプションはドロップダウンに隠されているので、意図してクリックしない限り「一括」の文字は現れません。気が急いているとクリックして「一括」に変更するのを忘れてしまいがちで、実際にボリュームの大半のダウンロードを「標準」の設定のまま行なってしまいました。
ちなみに怖くて AWS コンソールのコスト部分はチェックしていません。

表示されているジョブはテスト実行したものです。

その他の作業での気づき

あったらその時に追記していきます。

QNAP NAS の ボリュームタイプ変更 (4) - バックアップからのリストアがエラー！さらに悪夢のバックアップデータを削除😭

本当は前回の記事で構成変更を完了後に、static volume から外付け HDD に取ってあったバックアップからさっさと新しい thin volume にリストアして作業完了！としたかったのですが、自分の痛恨のミスもあり、作業を始めて 2週間経ってもリストア復旧できなかったという涙が枯れてしまいそうなお話です。

2週間も試行錯誤していたのですから色々な発見や気づきそして思いもありましたので、それらをまとめて書こうとしていたのですが、痛恨のミスの精神的なダメージがひどく、大まかな経緯だけは忘れないうちにまとめておこうと思います。個別ポイントに関しては今後整理しておくべき項目だけ列挙しておき、気持ちが乗ったら追記して行こうと思います。。。

また、今回発生したエラーの原因はまだ分かっていません。私が問題判別のためのバックアップデータを削除してしまった、という痛恨のミスによって、もしかしたら原因究明は出来ないかもしれません。この点はご了承ください。

※下記の記述の中で「(id=nn)」とされている表記は、HBS3 (Hybrid Backup Sync; QNAP のバックアップソリューションであり、NAS 上で稼働するアプリケーション) のジョブ id です。この ID は残念ながらパネル上には表示されていませんが、内部的に管理されているもので "Debug Report" と呼ばれるログで確認することができました。UI 上はジョブ名で識別されていますが、ジョブ名自体は後から変更して再利用可能ですが変更すると過去のジョブ名は残らないので、ジョブを一意に識別するためにジョブ id を用いることにしました。
※HBS3 のジョブ設定に関するチュートリアルや、"Debug Report" の取得方法など、私が頻繁に参照していたけれども忘れやすい項目は下記記事に列挙してあります。

QNAP 自分のためのヒントメモ - KuriKumaChan’s diary

---

ここまでの振り返り

前回までで下図のような段階まで完了しています。

後はバックアップからデータをリストアするだけ！

続きのステップとしては残るは "5. Copy the data back." だけです。
この文章の "5" がなぜ Restore ではなく "Copy Back" と書いてあるのか？すごく疑問に思って、もしかしたら「static volume から取ったバックアップからでは Storage pool 上の thin/thic ドライブにはリストアできないからあえて "Copy back" しないとならない」と書いてあるのかとも思いました。しかし、リストアジョブはちゃんと設定も実行もできるのであまり深い意味はないのではないかと考えてリストアジョブで作業を進めています（今となっては少しだけ気にはなっていますが、この後ご紹介する QNAP Support の対応でもリストアする事に何も指摘はありません）。

To be able to use the flexible volumes features, one would need to:

1. Backup data from the static volume

2. Remove the static volume

3. Create new Storage Pool ➡︎ 既存ストレージプールの拡張

4. Create a thin or thick volume inside the new Storage Pool

5. Copy the data back.

【経緯1-ローカルバックアップ】外付け HDD にとったバックアップからリストアできない

最初に結論です。

• 前提のお話として、バックアップ取得もバックアップからのリストアも QNAP の HBS3 というアプリで実行しています（HBS3 は過去の記事でも紹介したように、リストアも私の手もとである程度の実績あり。）。

• 移行前（Static volume） のバックアップジョブ (id=22)はエラーも無く終了していた（ので正しくバックアップが取得できていたと信じている）。

• 上記のバックアップデータを新しいボリュームにリストアするジョブ (id=29 ) を実行するが、17時間後に異常終了。その後何回も試行錯誤を繰り返すが、バックアップデータの特定のディレクトリでエラーが発生してエラーで終了するもしくはリトライを繰り返してジョブの UI 上進捗 % が 何時間以上も進まずキャンセル（手動でストップ）せざるを得なくなる。

  * 「エラーの発生でリトライを繰り返す」ことは、後ほど HBS3 のログから確認して分かったことです。

• リストア対象から特定のディレクトリを外すとエラーなくリストアできる。

まとめて書いてしまうとこれだけなのですが、リストアジョブの実行から結果が分かるまでに長時間かかる傾向があり、最初は何が起こっているのか頭の中での整理がなかなか進みませんでした。

試行錯誤の繰り返しの 10日間

最初にジョブの設定項目の意味の確認を兼ねたリストアのテストを 数回行った後、「これでいける！」と思ったジョブ (id=29 )のリストアが、一晩たって (19時間後) QTS の Event notification にエラーメッセージが表示されていてビックリ！声

Warning 2021-05-23 13:51:14 admin 127.0.0.1 Hybrid Backup Sync Job Status [Hybrid Backup Sync] Failed to complete Restore job: "Restore-otachidai". Bad job parameters. Check job settings. Attempting to retry. Error code: -22.

エラーコードも表示されていることなので早速 QNAP のサポートでチケットをオープンして追加資料（NAS が自動的に作成する HBS3 の "Debug Report"）取得のアドバイスを受けて自分でも少し覗いてみたり、ジョブの設定を変更するなど試行錯誤をまるまる 10日間ほど苦闘し続けました。
本当はここの整理が大切だとわかっていたので色々メモしたり記録を撮っていたのですが、QNAP サポートへの報告は行ったものの現時点で再度見直そうという気力が湧かず、この間の詳細は割愛させていただきます。

試行錯誤の山

HBS3 で内部的にエラーを検知してリトライすることはバッチジョブとしては当然だと思います（リトライすれば先に進むエラーもあるので、「エラー発生即ジョブの終了」よりはリトライしてくれた方がバッチジョブとしては好ましいことが多い）ですが、その間ジョブの状況を UI 上では進捗%と処理済みファイル数くらいしか確認できません。そうなるとユーザーとしてはとても不安に陥ってしまいます。特にデジカメファイルがたくさん入ったディレクトリでこうなると 24時間以上進捗の無い状態が続いたりして、私のような小心者にはとても耐えがたい気持ちに陥りました。

部分リストア + ファイルコピーで対応しよう！

この間、iTunes のライブラリなどが入っている NAS 上のもう一つのボリュームは利用できていたのでなんとか日常作業をこなせていましたが、さすがに 10日も経つと撮影データの保存やら「ちょっと Lightroom で確認を！」ということが出来ないのがだんだん辛くなってきて、方針転換をすることにしました。
具体的にはエラーの発生している α77 と OM-D EM-1 の一部（と言っても今までの主力機のデータなので大量！）のディレクトリを除けばリストアはできそうなのでまずはそれらを通常のリストアジョブで復旧し、残りはバックアップファイルのある外付け HDD を QNAP の FileStation (ブラウザ上で稼働する Finder や Exploler に相当するもの)でファイルにアクセスできたような気がしていたので、エラー発生ディレクトリのファイルだけは手動でコピーしてみよう、という作戦です。
手動の個別ファイルコピーだと作業の管理をしなくてはならないのと、ファイルコピーだとファイルのタイムスタンプが今日のものに変更されることもあるのであまりやりたくなかったのですが、もう背に腹は変えられません。

悪夢のバックアップデータ削除！

ということで、幾つかテストジョブを実行して確認をしたのちに、テストジョブの残骸を FileStation で削除した上でリストア先のボリュームを綺麗にしてからさぁリストア開始！
ところがリストアジョブが実行できません。そうです、誤って残骸データと間違えてバックアップデータのディレクトリを削除してしまったのです。
・・・
・・・・・
・・・・・・・
やっている作業がリストアなので、Finder/Explorer 似の FileStation で削除した残骸だっと思ってクリックした "Pro5300" というディレクトリはリストア先のテスト残骸ではなく、バックアップを格納していた外付け HDD のものだったのです😭
この時の自分の様子は思い出したくありません。その後しばらく何もできませんでした。 自分の今までの全てのデジカメデータが。
手元にあった FileStation でアクセスすればちゃんとアクセスできたであろうデータが。

その日は何もできないまま終わったと思います。QNAP サポートに拙い英語で「自分の不注意で大切なバックアップデータを消去してしまった」とだけ伝えて。

取り外してあった旧 Static volume の HDD からの復旧を試みるが中身が見れない

翌日気を取り直して、NAS から取り外して残っていた旧 Static volume の HDD をotachidai経由で PC に接続して中を除いてみました。以前 Windows PC の内蔵 RAID 1 HDD を交換した際に、RAID 1 の片割れの HDD であれば普通に Windows のエクスプローラーでアクセスできた経験があったからのチャレンジです。
しかし、エクスプローラーに表示されるドライブの様子は全く理解できないもの。ファイルにアクセスすることはできませんでした。

【経緯2-クラウドバックアップ】最後の手段 - クラウドバックアップからのリストア

最後の手段を使わなくてはならなくなりました。リストアにコストが発生しますがそんなことは言っていられません。クラウドには Static volume を外す直前の日曜日に自動バックアップで更新されたデータが残ってい流はずです。つい先日 HBS3 でリストアのテストも行っていたことがが心の支えです。

順調にリストア進むも途中でリストアジョブが異常終了

S3 Glacier からのリストアジョブ (id=49) を流し始めてすぐに、S3 Glacier の取り出しオプションを変更するのを忘れていたことに気づきました（本来はコストの安い「一括」に設定すべきだったのに、デフォルトのコストの高い「標準」のまま実行してしまった）。
ローカルにあるバックアップファイルからのリストアジョブなら気軽にキャンセルできますが、クラウドの場合はジョブ実行が内部的に何段階かに分かれているはずで、最初にクラウド側にデータ取り出しのリクエストを出しているはずです。それを開始してしまったであろう今、ジョブをキャンセルして設定変更をしたジョブを再実行するとどうなるのだろうか？なんて考えると恐ろしくてキャンセルもできません。仕方がないのでそのまま見守ることにしました。少々のコスト高（高くても 1,000円かそこら？）は大切な写真データには代えられません。
翌朝ジョブの様子をチェックするとエラーで終了していました。夜寝る時には快調にダウンロードが進んでいたのに...

[Restore 3] Files that Were Filtered or Skipped.,,,, Name,Size,Status,Reason,Date&Time /Pro5300/Photo/OM-D_E-M1/101OLYMP/P7161227.MOV,1.30 GB,Skipped,,2021/06/01 05:21:15
：
"Total files:10,Filtered files:0,Skipped files:10",,,,

また落ち込んではいましたが、これはスキップされたファイルサイズがいずれも 1GB 超だったこと、ジョブの設定に "skipped file limit" という項目がありデフォルト 10 だったことから、ファイルサイズの大きなファイルはリストアがスキップされる（その訳はわかりませんが）、そのスキップしたファイルの数が上限に達するとジョブがエラーで終了する、という仕組みだと想像できました。

skip file の上限設定変更して再度リストア実行 ➡︎ダウンロード待ちのループで停止

本来ファイルサイズが大きかろうがなんだろうが、バックアップしたファイルをリストアしないということ自体例外だと思うので、そのような機能を作るのであればそれはオプションにすれば良いと思うのですが、現実こうなっているので、こちらの想定外の理由でジョブが終了しないように limit を 1000 にして再実行 (多分 id=54)。 Glaier からのリストアは、最初にクラウド内でファイルの準備をするのに数時間かかるため、このジョブでは 9時間ほど何もダウンロードされない状態が続きましたが、ある時から快調にダウンロードが始まります。HBS3 で実行中のジョブの状況を確認できる "Job Run Status" をみると、"Skipped files: 12" の表示があり、Glacier に実際にあったスキップ対象のファイル（おそらく 1GB 超のもの）は 12個存在しており、前のジョブでは上限が 10 であったので異常終了したけれど今回は 1000 の設定なのでジョブは続行していることが確認できました。 しかし翌日ジョブは実行中なのにファイルのダウンロードが停止してしまいました。上図にある "Status: Restoreing....nn%" の表示が進間ないのです。8時間ほど経った時にやむなくジョブをキャンセル。ログから結果特定のディレクトリでファイルのダウンロード待ちのままループしていたことが分かりました。
この日はこれでまた心が折れかかってしまいました。

[2021-06-02 16:28:50,081][ Thread-8][I][FileRetriever][retriever.py:retrieve_next_batch:235] : Retrieve next batch: rate=3932160.0, ready pool size=293446798800, retrieve pool size=0
[2021-06-02 16:28:50,083][ Thread-8][I][FileRetriever][retriever.py:retrieve_next_batch:243] : No more items need to retrieve
[2021-06-02 16:28:51,870][ RstWorker][I][FileRetriever][retriever.py:iter:163] : Waiting available download
[2021-06-02 16:29:50,183][ Thread-8][I][FileRetriever][retriever.py:retrieve_next_batch:235] : Retrieve next batch: rate=3932160.0, ready pool size=293446798800, retrieve pool size=0
[2021-06-02 16:29:50,184][ Thread-8][I][FileRetriever][retriever.py:retrieve_next_batch:243] : No more items need to retrieve
[2021-06-02 16:29:53,082][ RstWorker][I][FileRetriever][retriever.py:iter:163] : Waiting available download

やむなく対象ディレクトリのリストア状況を個別確認して再実行

今やっている作業が最後の手段なので、ここで諦めるわけにはいきません。Glacier 側では AWS コンソールでバックアップ対象のディレクトリ構造やファイル（数、容量）の確認もできるので、NAS 側のリストア済み状況を FileStation でディレクトリ単位で一つ一つ確認していきました。

Glacier 側のディレクトリ構造を確認して Glacier 側と NAS 側のファイル数とバイト数をチェック(画像はチェック対象ディレクトリの一部)

結果、リストアが途中で終わっているディレクトリや、そもそも一つのファイルもダウンロードされていないディレクトリがあることが確認できたので、その対象ディレクトリだけ再度リストアジョブ (id=56) を流しました。その結果部分完了していたディレクトリに関しては、HBS3 がチェックしてダウンロード済みのものを除外して残りをリストアしてくれたようです（HBS3 賢い！... 初めて HBS3 を褒めた）。

すでにリストア済みのファイルが "Unchanged files" にカウントされているようだ

クラウドからリストアできないファイルに福の神到来 "R-Linux" !

ようやく久しぶりに Mac から接続して新しいデジカメファイルを NAS に保存したり、Lightroom で以前の写真をチェックしたりする日常が取り戻せてきました（そういえばフィルムのデジタル化が進んでいない..）。 しかし、ここで終わりにしてはいけないのです。10個の 1GB超の動画ファイルがスキップされていてリストアできていないのです。実際にはやらなかったですが、やろうと思えば S3 Glacier から S3 に転送してAWS コンソールでダウンロードできるような気がします。

QNAP サポートから「旧 Static volume の HDD をアクセスするフリーソフトあるよ！」と連絡

S3 経由のファイルダウンロードを行う腹は括っていたのですが、少しめんどくさくなって躊躇していると、QNAP から、

Because the disks are configured inside the NAS hence it can't be easily read by simply attaching it via USB connection. You can try this procedure and see if the files will be retrieved on the disk that was not formatted. - Download on a Windows PC (or Linux) the R-Linux program (https://www.r-studio.com/free-linux-recovery/) - Use the old disk, (use only either 1 disk if from RAID1) - Attach the NAS disk to your PC - Use R-Linux SW to access the disk data partition - Copy the data to your PC or to an external storage device" https://www.r-studio.com/free-linux-recovery/

とアドバイスがありました。ポイントは NAS の内蔵 HDD として使っていた HDD は取り出して USB 接続しても簡単に中身を読めないので、Windows か Linux 環境で R-Linux というツールを使ってみる価値あるよ、とのこと。
調べてみると結構以前から存在するフリーのツールのようです。最近の新しい記事はあまり見つかりませんでしたが、手元にあるこの前まで使っていた static volume のデータに直接アクセスできるならとても嬉しい事です。何より skip された 1GB を超える 12個のファイルをネット経由でダウンロードする手間が省けます。

R-Linux を実際使って Static volume のオリジナルデータをコピーできた

Windows 環境で R-Linux を起動すると USB 接続した HDD の中に "Datavol2" のパーテシション名があった！

このツールを使ったところ、旧 static volume に存在していた "Datavol2" というドライブ名が確認でき、その中にある "Pro5300" というディレクトリを丸ごと別の HDD にコピーすることができました。
（このあたりの詳細は（気力が出てきたら）また書いておこうと思いますが、今の段階では「役立つツールだった」というだけで終わります。）

skip されたファイルは実はダウンロードされていた！

R-Linux による 旧 Static Volume からの読み出しは結構時間がかかり、私の場合 6時間ほどかかりました。その間、skipped file とされていた以外はちゃんとダウンロードされているのか NAS を FileStation でチェックしていると、なんと skip file とされていたファイルもちゃんとダウンロードされていたことがわかりました。

skip した、とされたファイルは、実際にはダウンロードされておりファイル名の一部が変更されていた。

これらのファイル名についていた余分な ".download.xxx" をファイル名から外してやれば（rename するだけ）、ちゃんと動画ファイルとして再生できることも確認できました。
skip されたという割には実際にはダンロード完了されており、わざわざ AWS S3 からダウンロードしたり、R-Linux の処理完了を待たなくてもファイル名の rename だけで良いこともわかりました。結局 skipped files も無事復旧でき、普通に利用するには問題のないレベルに NAS を回復させることができました。

---

ということで、以下、最低限の試行錯誤の項目だけメモしておいて、心の傷が癒えたら整理を始めようと思います。本日はここまでで終わりです。

---

【今後整理予定】具体的なエラーの内容（書きかけ）

幾つかのエラーメッセージを QTS の Notification なり HBS3 のログから確認しています。落ち着いたら QNAP へのレポートやログを見直してまとめようと思います。

# ERROR: Unable to create file "xxx/.../yyyy.zzz". (-22)

# WARNING: Unable to update the "xxx/.../yyyy.zzz" file (Permission denied), it will be skipped. (-5)

Failed to complete Restore job: "jobname". Bad job parameters. Check job settings. Error code: -22

Failed to complete Restore job: "Restore 3". Error count exceeds the allowed maximum number of skipped files.

【今後記載予定】どのような試行錯誤をしたのか？（書きかけ）

心が落ち着いたら整理しようと思いますのでしばらくお待ちください。

• HBS3 リストアジョブの設定変更
  • "Source:" の設定変更：
  • リストア「元」の変更：これには "Backup file" と "destination" があり、私が期待したのは "Backup File" を選択した上で、Backup file の中にある "Pro5300" を言うディレクトリを指定して丸ごとリストアすることですが、後で分かるようにこの中の特定のディレクトリでエラーが発生しており、
  • リストア「先」の変更：余り意味ないと分かっていながら
• リストア先のボリュームの変更：最初に Thin volume で試していましたが一旦 volume を削除して新規に Thick volume を作成してそこにリストア

なんで 10日間もしつこく試行錯誤を繰り返していたかというと、「最後は AWS S3 Glacier からのリストアという最後の手段もあるぞ」という安牌を持ったまま、その最後の手段はリストアにお金がかかるわけですし、私の過去の経験 (NAS 以外のメインフレームから PC までの) から、バックアップツールからのリストアには信頼を持っていたので、「エラーコードもわかっているわけだから QNAP から何かしらのアドバイスをもらえれば一部バイパスするなどしてもなんとかなるだろう。」という期待があったのだと思います。

慌てていた自分のチョンボの数々

※長文になってしまったので別の記事に分けて書きました。

blog0.kurikumachan.com

【今後記載予定】HBS Debuf Report について

【今後記載予定】R-Linux について

【今後記載予定】QNAP サポートについて

IIJmio ギガプランのデータシェアを設定する - 3回線 12GB を 2,816円

5月から契約の IIJ 回線をギガプランに変更し、さらにギガ単価の高い音声 SIM を最低の 2GB に変更してあった私の IIJ 3回線ですが、本日 (06/01) からデータシェア機能が利用できるようになると言うことだったので、早速その設定をしてみました。
私の場合は一人で 3回線を一つのグループに設定する、ということをやってみたいと思います。

みおぽん（スマホアプリ）ではグループ設定などはできないみたい

そもそもデータシェア機能に関してはアプリで設定するのか web で設定するのか分からなかったのでまずアプリのみおぽんを見てみましたが、データシェアやグループ関連情報は特に付け加わっておらず、ここではないな、とわかりました。

会員メニュー

「サービスの各種変更・利用状況紹介」に「ギガプラン」が

iPad で操作しましたが、IIJmio の会員メニュー自体はぱっと見変わっていませんでしたが、下にスクロールすると「サービスの各種変更・利用状況紹介」と言う中にギガプランがありました。この「サービスの各種‥」と言う部分自体にいままで気づいていませんでしたが。もしかしたらギガプラン提供開始の5月からこの次の「データ量」まではすでにあったのかもしれません。普段通信可能データ量はみおぽんでチェックしているので、会員メニューのこの部分まで来ることがないものですから。

会員メニューの下にサービスの各種変更・利用状況紹介」が

「ギガプラン」に「データ量」の項目が

「ギガプラン」のページに「データ量」

「データ量」の中に「データのシェア・確認」が

みおぽんでも操作できますが、このギガプランのページでも高速通信の on/off や データ利用量などもチェックできるようです。その中に新しい機能の「データのシェア・確認」や「データ残量のプレゼント」などの項目がありました。

「データ量」の中に「データのシェア・確認」

「データのシェア・確認」ではまずグループの作成から

スクショを撮り忘れてしまいましたが、最初はグループの設定が存在しないのでグループを作成するところから始まります。

グループに属する回線の選択

次はグループに含める（追加する）回線を選択します。私の場合全ての（3回線）を一つのグループとしてそのデータ量の総量をシェアしたいので、３階線にチェックしました。
すると「グループのデータ量」として 12GB が、現在のデータ残量として 17.75GB と表示されました。

グループに含める回線にチェックをする

---

と言うことで、私の場合は繰越分を除いて毎月 3回線 12GB を 2,816円で利用できるようになりました！

858 x 2 + 1,100 = 2,816

QNAP NAS の ボリュームタイプ変更 (3) - 静的ボリュームからストレージプールへ構成変更

本当は今回で 「NAS 構成変更が完了！」としたかったのですが、まだ作業途中なので下記 "5" の最初の段階までの途中経過です。
前回最後にまとめた QNAP のサポートの記事に従ったステップを実行してみようと思います。
下記の "3" のストレージプールに関してだけは、新規作成ではなく既存のストレージプールの拡張とします。
簡単な 5ステップの作業のはずなのですが、ガイドも見ないで操作したためか苦労しています..
ステップ 5 に限りませんが、作業にあたってはガイドや各種情報を十分に確認及び確実なバックアップ取得を行なった上で作業を開始しましょう！

To be able to use the flexible volumes features, one would need to:

1. Backup data from the static volume

2. Remove the static volume

3. Create new Storage Pool ➡︎ 既存ストレージプールの拡張

4. Create a thin or thick volume inside the new Storage Pool

5. Copy the data back.

ストレージプールは "Create new" ではなく既存のストレージプールを拡張する

---

1.Backup data from the static volume (static volume のバックアップを取る)

これは以前のクラウドバックアップからのリストアテスト（テスト、本番）に用いた USB 接続の裸族おお立ち台を再度接続して、今回は 「NAS 内蔵 HDD to USB 接続 HDD」でバックアップを取得しておきます。さすがにバックアップ先もローカルなので、1TB 弱のデータが 2時間弱でバックアップ完了です。

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

2.Remove the static volume

まず、static volume の "Datavol2" を削除します。 操作としては「ストレージ&スナップショット」から削除対象の "Datavol2" を開き、「アクション」から「ボリュームを安全に取り外す」を選択しました。

「ボリュームを安全に取り外す」

しばらくすると「ボリューム/スナップショット」のパネルに表示されている「ストレージ領域」から "Datavol2" の表示が消えました。　

取り外されたボリュームは表示されなくなる

(2'.HDD の交換)

単に static volume を削除して同じ HDD を利用して既存のストレージプールを拡張するだけならそのまま作業続行ですが、今回は HDD の交換も行いますのでここで static volume を構成していた HDD1 とHDD2（NAS の左から二つ）を取り外して新しい 8TB の HDD1' と HDD2' を装着します。
当然 NAS の電源を落とさずに操作できるはずなので、HDD 取り外しのメニューを探しますが、該当の HDD1, 2 のメニューには「取り外す」メニューがありません。継続利用する（つまり現在も Active な）Datavol1 側を構成する HDD3,4 には「取り外す」メニューがありますがこれは HDD 障害時の交換のためのメニューなのでしょう。取り外し対象の HDD1,2 にはそれらしいメニューはないので、先程の「ボリュームを安全に取り外す」によって HDD も取り外せるものと理解し、HDD1,2 を取り外します。その上で新しい 8TB の HDD を2本 HDD1,2 のスロットに装着します。

現在アクティブなストレージプールを構成する HDD には「取り外す」メニューがある

ボリュームを取り外した HDD には「取り外す」がなく「新規ボリューム」が表示

★★★注）この段階でちょっとしたトラブルがありました。「ストレージ＆スナップショット」で HDD 情報を表示しても取り外した 3TB の HDD 情報が表示されるだけで新しい 8TB の HDD 情報が表示されません。これは power off/on で新しい HDD 情報が表示されるようになりました。詳細は後ほどおまけとして「うまく作動しないので NAS の再起動で対応したもの」にまとめておきます（つまりその手の状況が何回か発生したと言うことです。）。

3.Create new Storage Pool ➡︎ 既存ストレージプールの拡張

次に既存のストレージプール (Storage pool1) を拡張します（新しい HDD1,2 を RAID 1 構成にして Storage pool 1 の一部に組み込みます）。
この作業にあたっては下記「QNAP フレキシブルボリューム管理の使用方法」の「ストレージプール容量のオンライン拡張」を参照しました。

www.qnap.com

「ストレージ＆スナップショット」パネルに表示されている今あるストレージプールの「プール拡張」を選択すると「ストレージプールの拡張ウィザード」が表示されます。

残るストレージプールから「プール拡張」を選択

ここで「新しい RAID グループを作成し、追加する」を選択します。

「新しい RAID グループを作成し、追加する」やっとわかりやすいメニューが出てきた！

ここに新たに追加した HDD 2本の情報が表示されたのでそれらを選択し、RAID のタイプを "RAID 1" を選択して「次へ」。

追加した二つの HDD を選択

表示内容を確認して「拡張」ボタンを押します。 　

これから行われることのサマリーが表示。「拡張」を押す。

「拡張」を押したら下記の表示に。OK を押して待っているとおおよそ 3分でストレージプールの拡張は完了しましたが、よくみると"RAID グループ2" の状態列に「同期中 (0.1%)」の表示。おそらく RAID の構成が並行して行われているのでしょう。

おおよそ3分でストレージプールの拡張が完了

ストレージプール 1 に新しい RAID も組み込まれた！

★★★注）QTS 上ストレージプールの拡張自体は 3分程度で終了したことになってボリューム作成に進めますが、新しい HDD の RAID 1 としての同期作業は延々と続いていました。これに関しては最後の「おまけ」メモを書いておきます。（「RAID の同期には時間がかかる」）

4.Create a thin or thick volume inside the new Storage Pool

ストレージプールに新しいボリュームを作成します。ストレージボリューム上に作成できるのはシン ("Thin")、シック("Thick") の2種類です（"static" はストレージプール無しに作成します）。両者とも高機能で相互に後から変換可能なボリュームタイプで、その比較表は下記記事の最後に「参考）ボリュームタイプの比較表」として転載してありますので参考にしてください。私のような個人利用であれば大した差は無いような気がするので、ここは今まで利用したことのない "Thin" で行ってみようと思います（"Thick" は現在の "Datavol1" で利用中）。
手順は下図の流れでわかるシンプルなものですが、"Thin" はストレージプールの物理サイズを超えたボリュームサイズを設定できる、というのもウリの一つなので、試しにストレージプールの 20TB を超える 50TB を指定してみましたが問題なく設定できそうでした（実際に 50TB で設定はせずにおとなしく 3TB を指定）。

blog0.kurikumachan.com

「新規ボリューム」を選択

せっかくなので ThIn volume を選んでみた

ストレージプールの空き容量に注意！と言う当然のお話

試しにストレージプールの容量を超える 20TB のボリュームも設定できる

ボリュームの容量を 3TB に設定してみた

作成するボリュームに関する情報を確認の上「完了」

作成中...

2分ほどでボリューム作成完了！

Thin vol.の作成も 2,3分で完了です。

ここまでで残すところは後はバックアップからのリストアだけです！

後はバックアップからデータをリストアするだけ！

5. Copy the data back. リストアの罠

先頭に書いたように、実はリストア作業は完了していません😢
"1" でとったバックアップからのリストアに苦労しています...
少し落ち着いて作業を行なった上で記事にまとめたいと思います。