プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

NAS のディスクの I/O エラーと HDD の交換

先日、仕事が一段落していたので、 NAS (QNAP TS-231P)の QTS のアップデートの通知に従って、アップデートしました(5.0.1.2173 (20221001) -> 5.0.1.2194 (20221022))。

ですが、アップデート終了後、 NAS にログインしてみると、ダッシュボードのアイコンがオレンジ色になっていて、何かやばい様子です。

開いてみると、ディスクに対してエラーが出てました。

おぉ、なんてこった。 ログを確認すると以前からあったのではなく、アップデート前のタイミング(アップデート時にNASが長時間稼働していると一度再起動するんですが、どうもそのタイミングのようです)でエラーを検出したようです。

開いたダッシュボードのアイコンをクリック(または、『ストレージ&スナップショット』->『ストレージ』->『ディスク』を開き、エラーのあるディスクを選んで、『ディスクの健康状態』を選択)すると、

って感じに、 I/O エラーが検出されたようです。 この HDD 自体はかなり昔から使っていたやつなので、エラーが出るのもまあ致し方ないかな、って感じです。

とはいえ、こりゃやばいぞ。

HDD 自体の交換は確定なので、取り急ぎ次の HDD を手配しておきます。このタイミングで SSD にすることも考えたのですが、2台同時に交換しないと意味ないし、 NAS 自体も NAS につながっているネットワークが現状ギガビットなうえ、まだ 10G とかに変更する予定もないので、まあ今回は HDD でいいかな、としました。

不良ブロックのチェック

新しい HDD がつくまで数日かかるやろでと、 QNAP のマニュアルをいろいろとみてみると、一応不良ブロックの検査をやってみなさい、とあります。なので、『アクション』から『不良ブロックのスキャン』を選択して、やってみます。

実行時に、スキャン結果に異状がなければ、I/Oエラーを消去するかと聞かれます(マニュアルの表記だと選択できないよう感じでしたが、選択式になってます)。今回はとりあえず『はい』を選択しました。

ちなみに、QuLog Center に出ていたメッセージにも、不良ブロックの検査をするように載ってました。

なお、対応する記事が下記になります。 What should I do if I see a disk error or storage related warning message shown on the QNAP NAS? | QNAP

2TBのディスクですが、おおよそ4時間半~5時間程度でスキャンが完了しました。で、結果は、、、あれ?

不良ブロックがなくて、エラーが解消されています。こんなのあり? ディスク注文済みだったので、ちょっと早まったかな?と一瞬思いました。

が、別件で NAS を再起動する必要があり、再起動してみると、またエラーが検出されました。もう一度不良ブロックのチェックをする気にはならなかったのですが、様子からするとどうも(再)起動時にエラーが検出されているようです。

詳しくは不明ですが、2回検出されたということは、やっぱり、何かしらのエラーが潜んでますね、きっと。こりゃあ、エラーが頻発するようになるのも時間の問題だな。

とはいえ、この時点でできることはないので、ミラーのもう一方が壊れないことを祈りつつ、新しい HDD が到着するのを待ちました。

HDD の交換

ネットで注文して数日で届きました。近い将来、もう一方の HDD もエラーになるかもしれないと思い、その時に容量を増やせるように、今回は 4GB のドライブにしました。 Western Digital の Red Plus ですね(WD40EFZX, 128MBキャッシュ版)。

もう一つの HDD でエラーが出る前に、なんとか無事に新しい HDD が到着したので、早速交換します。

こちらの記事を見ると、 NAS を起動したまま、ディスクを交換しろとあります。ホットスワップで、自動的に認識されてリビルドされるっぽいです。

ちょっと怖いので、他の方法がないか調べてみます。

準備

その前に、準備です。この NAS は iSCSI ドライブとして PC から常に接続されています。書き込みも起きることがあるので、ディスクの交換が終わるまで、 PC 側の接続をいったん切っておきます。

スタートメニューから『Windows 管理ツール』->『iSCSI イニシエータ』を呼び出し

『切断』を選択して、切断しておきます。

これで、準備完了です。

ディスクを1台ずつ交換

以前、HDD交換をやった際に、いろいろと調べたのを思い出しました。その時の記事の方法を試してみます。

『ストレージ&スナップショット』->『ストレージ』->『ストレージ/スナップショット』を開き、『管理』を呼び出します。

ディスク2でエラーが表示されてますね。ここで、『管理』->『ディスクを1台ずつ交換する』

を選ぶと、あれ?選択できません。

どうも、この方法ではエラー時は交換できないようです。

ホットスワップで交換

結局、うまい方法が無かったので、ホットスワップによる交換を試してみます。

エラーの赤ランプがついている側(ディスク2側)

のスロット下部のレバーをおもむろに引っ張って、外します。

しばらく待って、ビープ音が鳴るのを確認します。これで、 NAS がディスクが外されたことを認識したということですね。

ちなみに、 NAS の管理画面上はこんな感じにドライブが無いことを示してくれてました。

HDD ケースのドライブを入れ替えます。こんな感じになっているので

とめているネジ4本を外して、新しい HDD に交換します。

交換ができたら、おもむろにNASに戻します。

これで、自動的に認識されて、リビルドが始まるはずです。

リビルドが始まらないことへの対応

が、どうも様子が変です。管理画面を見てみますと、

とあり、新しいディスクは正しく認識されているようです。この画面の『RAIDグループ』を選択すると

となっており、信頼性が低下していると判断されています。リビルド始まっていないっぽいので、当然ですね。

自動で始まらないなら、手作業でリビルドを開始すればいいやと思い、『ストレージ&スナップショット』->『ストレージ』->『ストレージ/スナップショット』を表示すると

警告状態です。この画面で『管理』を呼び出すと、

とあり、交換したディスクが『メンバーではありません』となっています。

ん?RAIDのメンバーとして認識されていないので、リビルドが始まってないのか?

じゃあ、明示的にリビルド呼べばいいや、と思って、

『管理』から『RAIDグループをリビルド』を選択すると

空きディスクが表示されるはずなのに、何も表示されていません。

マジか!?やばいぞ、これは。

さきほどの交換手順の記事を見ると、

If the replaced disk is detected by the NAS but the RAID rebuild does not started, try setting the newly replaced disk as a spare disk

(自分なりの訳)

交換したディスクがNASに認識されているけど、RAIDのリビルドが始まらないときは、新しい交換したディスクを予備のディスクとしてセットしろ

とだけあります。具体的に何やればいいか書いてないやん!

いろいろと調べてみても、やり方が見つかりません。

ネットを見ていたら、エラー時のディスク交換の方法として、ホットスワップではなく、いったんNASを停止して、交換後起動すると自動的に認識・リビルドをする、というのがありました。

QNAP製のNAS TS-231+でRAID1を構成しているHDDにエラーが発生したので交換してみる – 酔人日月抄

なので、すがる思いで、最後の手段として、NASを一度シャットダウンして、再起動してみます。

起動したっぽいけど、ブラウザから管理画面にアクセスできません。ディスクのランプの様子からは動いているっぽいので、とりあえず翌日の朝までほっときます(こちらの記事で経験済みですが、2TBのリビルドで大体5時間程度かかったので)。

翌朝確認すると、無事リビルドが終わってました。

助かったー。

余談

実は、リビルド完了を確認しようとしたとき、やっぱり、ブラウザからアクセスできませんでした。 このときは ping も通らない、 SSH でログインもできない状態で、かなり焦る状況でした。

仕方ないので、ディスクアクセスランプが激しく点滅していないことを確認して、電源スイッチを押してシャットダウンし、もう一度起動したところ、無事に起動しました。

一連の作業時のログを確認したところ、リビルドは正しく開始されて、やっぱり5時間程度かかり完了していました。が、どうもこのときネットワーク周りでトラブルがあったのか、いままで見たことのないような警告がいろいろと出てました( NTP サーバーに接続できません、とかインターネットとの接続ができないことに起因するっぽいものが多い印象でした)。

推測ですが、リビルドを期待して再起動した際に、ネットワーク周りが正しく起動しなかったようです(とはいえ、ネットワーク自体の警告やエラーが無いのでなんともいえないのですが)。

あと、今回は、他の NAS などのバックアップ先がこの NAS なのと、この NAS 上のデータも別のところにバックアップ済みなので、新たにバックアップはとらずに作業を開始してます。が、このようにディスク交換時は想定外のことも起きえるので、バックアップは必ず取ってから作業することをお勧めします。

まあ、無事に起動したのでいいんですが、なかなか怖い経験でした。

SQL Server の互換性レベル変更のための検証

仕事で使ってる SQL Server があります。以前は、RDS の SQL Server 2014 を使っていたのですが、監査機能(のある機能)を使いたかったので、 SQL Server 2019 に移行しました。 RDS では、メジャーバージョンアップしても、互換性レベルをアップグレード前に合わせてくれるというのがあるので、互換性レベル 120 ( SQL Server 2014 相当) で使ってました。

いままでは、この形の運用で問題なかったのですが、ちょっと試してみたい機能(というより関数)が出てきました。が、自分で互換性を確認することを考えるとなかなか大変なので当初は躊躇してました。

ですが、ちょっと調べてみたら DMA(Data Migration Assistant)というツールがあり、これを使えば、SQL Server 間のアップグレード時の問題が簡単に確認できることが分かりました。

ということで、実際に試してみましたので、メモを残しておきます。

DMA のインストールと起動

DMA は、 Microsoft のサイトからダウンロードできます。早速、ダウンロードして、インストーラをダブルクリックすれば簡単んいインストールできます。インストールに成功したら、早速起動してみます。

無事起動できましたね。

アセスメントの実施

DMA にはアセスメントと移行の2つの機能があるようです。今回はアセスメントを使います。

まず『+』を押して、新しいプロジェクトを設定します。

今回は次のようにしました。

項目 設定内容
プロジェクトタイプ Assesment (デフォルト)
プロジェクト名 適当な名前(testにしました)
Assesment Type Database Engine (デフォルト)
Source Server Type AWS RDS for SQL Server
Target server type SQL Server

設定後 create ボタンを押すと、設定画面に移ります。

Select target version は SQL Server on Windows を選択します(デフォルトのまま)。

検査する内容を選択するのですが、 Compatibility Issue しか選べないので、そのままとして、nextを押します。

Assesment したい source server のアドレスとログイン情報を設定します。

このとき、 Trust server certificate にもチェックを入れときます。

Connect を押して、接続できればOKです。無事に接続すると、下記のような画面が表示されて、SQL Server のどのデータベースに接続するかを聞かれます。今回は、すべてのデータベースとしました。

ここまでの設定でよければ、addを押します。

もう一度、 source の確認画面が表示されるので、

問題がなければ、 Start Assesment を押してアセスメントを行います。

結果の確認

しばらく、下記のような画面が出てる状態で待ちます。

Assesment が終わると結果画面が表示されます。

おぉ、問題ないようです。Compatibility Level 毎に評価結果も出してくれるようです。今回の場合は Compatibility Level 150 (SQL Server 2019 相当)に上げても問題ないようですね。

まあ、そんなにややこしいことをやってる覚えもないので、妥当っちゃ妥当な結果なのですが、確認できるのは、精神衛生上いいですね。

最後に、念のため、 Export report で結果を保存しておきます。

まとめ

一応、機械的にですが、互換性レベルを上げても問題ないことが確認でした。あとは、こちらの記事などを参考に、実際に互換性レベルを変更します。

にしても、これで検証できるのは楽ですね。また、使ってみよう。

おまけ

以前、 Access を SQL Server に移行する際に SSMA ( SQL Server Migration Assistant ) というのを使いました(こちらの記事参照)。今回の DMA と何が違うんだろうか?と思ったので、調べてみると

  • SSMA : 異なるデータベースを SQL Server に移行する際の手助けをしてくれるツール
  • DMA : SQL Server のアップグレード時の互換性の手助けしてくれるツール

ということでした(詳しくはこちらの記事などを参照)。

なるほどね。にしても、名前が紛らわしいな。

スマホの写真バックアップに dropbox を使ってみようとしたが諦めました

スマホ( Nexus 6P, Android 8.1.0 )で撮った写真のバックアップ先として、スマホへのログイン時の Google アカウント( Google Drive)を利用していました。Google アカウントは無料枠として 15GB の Google Drive の容量があり、写真のバックアップもここに含まれています。

以前はバックアップとして『高画質』を選択していれば、容量にはカウントされずに無制限だったりしました(2021年5月末で終了)。ですが、個人的には写真の画質は落としたくないので、元の画質で保存していました。いまはもう画質に関係なく容量にカウントされますね。

そんなに大量に写真を撮ることもないのですが、何年も使っているとそれなりに容量を使ってしまい、最近、容量がいっぱいになりました、と警告が出るようになりました。PCのブラウザで Google Photo を開くと、こんな感じに警告が表示されます。

写真のバックアップが取れないだけならまだしも、同じアカウントの Gmail もメールの受信ができなくなる、とあります。

これは困りますね。スマホのアカウントのメールは、子どもの学校からの緊急通知などを受けるようにしているので、いざという時に使えないのでは話になりません。

素直に考えれば、 Google One にアップグレードして、上納金 お金を払って、快適に使うことになると思いますが、なんかいやです。 ということで、いろいろとあがいてみたのをメモにまとめておきます。

とはいえ、結局、最終的には Google One にしたんですけどね。

Dropbox

スマホの写真のバックアップの選択肢が、 Google One 以外にないものか調べてみると、いろいろとあるにはあるようです。でも、一番身近なものとしては Dropbox が対応しているので、それを使うのが手っ取り早そうです。

Dropbox は仕事の関係で使っているため、有料プラン(Plus)を契約しているのですが、 2TB の容量は大きすぎて余りまくってます。なので、写真の保存先としてはよさそうです。スマホ側でも普段から使ってますしね。

使ってみる

写真のバックアップは、 Dropbox では『カメラアップロード』という機能になるようです。

使い方は簡単で、スマホ上で Dropbox アプリを開いて『設定』->『カメラアップロード』を選択して、『写真をバックアップ』を押して、オンにすれば終わりです。

オンにすれば、自動的に写真のアップロードが始まります。これはよさそうですね。

他の設定として、WiFi接続時のみアップロードするようにするとか、バッテリー残量に応じてアップロードを中止する、というようなオプションがありますので、お好みに合わせて設定してください。

で、実際に使ってみると、個人的に気になる点がいくつか出てきたので、以下にまとめておきます。

問題点1

Dropbox のカメラアップロードを有効にして、どれぐらいデータがあるのか確認するため、PC のブラウザで Google Photo を見ると、 2014 年~今年( 2022 年)まで写真があります。結構な量ですね。ということで、しばらくほっけばいいやと思って仕事してました。

しばらくしてから、ふと、 Dropbox のフォルダを見ると、 2022 年の新しいほうからアップロードが始まっていたのですが、 2018 年ごろの写真をアップロードしたあたりで処理が終わっています。 ここで、昼ご飯だったのでいったんアップロード処理を中断して(というか、スマホをもって外に出て)、帰ってから原因を調べてみました。

Dropbox のトラブルシューティングなどを見ると、カメラアップロードが中断される場合

  • WiFi 接続がない
  • バッテリー残量が少ない
  • Dropbox の空き容量がない

あたりがよくある原因だそうですが、どれにも該当しません。また、スマホ上の Dropbox アプリを再起動してみても状況は変わりません。

ここで、 Dropbox に問い合わせしてみようと思って、写真フォルダのパスなどの情報を確認するために、スマホ本体を PC につなげて写真の保存先を確認すると

あれ?

日付を元にして、付けられているファイル名ですが、2018年より昔のものがありません。

なんだろうな?と思って、ブラウザで Google Photo にログインして、スマホ内にファイルがあるものの日付より古い日付の画像を選択して確認してみると、昔使っていた機種の名前が出てきます。

あ、そういうことか!

スマホ上の Google Photo のアプリだと、常にクラウドと連携してバックアップをしています。なので、スマホを交換した際も、同じ Google アカウントでセットアップさえしてやれば、昔の写真を見ることができます。が、この時、新しい端末内に写真はありません(せいぜいキャッシュが作られるぐらい?明示的にダウンロードしたら別でしょうけど)。 なので、 Dropbox からしたら、端末内にないファイルのことなんてしらないよ、ということなんでしょうね。

これについては、最悪、 Google Photo からデータをダウンロードして Dropbox 側にアップロードすればいいかな?と思われます。

問題点2

むしろこっちのほうが面倒そうなんですが、どうもカメラアップロードの場合、一部のファイルがアップロードされてないようです。 こちらはファイルそのものは、端末内にちゃんと存在しています。なんでアップロード対象にならないのかは、今一つわかりませんでした。

ただ、Windows PC にスマホをつないでカメラフォルダを見ていたら、サムネイルが生成されない jpg ファイルがいくつかあって、カメラアップロードされていないものと対応しているように見えました(数個のファイル見ただけなので、確定的なことは何もいえないですが)。

jpg の詳細なファイル形式の差異なのか、スマホ側で何かイレギュラーな情報を付加しているのか・・・、実際のところ、どういう理由かまでは分かりませんが、カメラアップロードの対象から漏れるファイルが存在し、バックアップとしては、中途半端な状態になっていることは確かなようです。

これへの対応はちょっと面倒ですね。どのファイルがまだアップロードされていないのか調べるなんてやりたくないです。 もしやるなら、

  • いったんカメラアップロードはオフにして
  • アップロード済みのデータをすべて消去して
  • Google Photo から全画像データをダウンロードして
  • Dropbox の『カメラアップロード』フォルダにデータをアップロードする

というような方法ですかね?で、その後追加で撮った写真は、カメラアップロードで Dropbox にバックアップする、という形が現実的なようです。

にしてもやりたくないな・・・

結論

ということで、今回の結論としては、使ってるスマホは Android 端末というのもあり、素直に Google One を使うことにしました。

とはいえ、せっかく調べたので、 Dropbox を写真のバックアップ先に使う場合のケースを考えてみると、

  • Dropbox の容量が余っている場合
  • または Google One の費用がかさむようになった場合
  • 1台目のスマホを使いだして以降同じ機種をずっと使ってるような場合
  • 写真の数が少なくて、バックアップが正しい状態であることを簡単に確認できる場合

などになりそうです。私の場合だと、当面は Google One を使うにしても、理由の2番目の Google One の費用が気になり、先々は Dropbox に切り替えることになるかもしれないですね。

また、もし、Dropbox を写真のバックアップ先に使う場合は、次の点を事前に考えておくのがいいかと思います。

  • スマホを替えたときは、(そのままでは)昔の写真を Google photo (Androd の標準の写真をみるアプリ)で見れない(はず)
  • カメラフォルダ以外(スクリーンショットとか)の写真もバックアップ対象になってる

というのがありそうです(2つ目については今回試したスマホがこの状態でした)。

なんにせよ、使う前にはいろいろとテストをすることをお勧めします。