価格.com - NAS(ネットワークHDD) ASUSTOR のなんでも掲示板のクチコミ掲示板 (なんでも掲示板)

クチコミ

※掲載情報についての保証はいたしかねます

クチコミ掲示板 > パソコン > NAS(ネットワークHDD) > ASUSTOR > なんでも掲示板

ASUSTORなんでも掲示板のクチコミ掲示板

（138件）

このページのスレッド一覧（全6スレッド）

内容・タイトル	ナイスクチコミ数	返信数	最終投稿日時
RAID1内のデータを取り出す方法	1	1	2023年12月17日 14:26
RAID1（の両ディスク）エラーを解消するには？	17	38	2021年10月11日 00:45
特定ユーザのみアクセス可能なフォルダが作れない	0	5	2021年1月23日 12:41
ＮＡＳのディスク交換方法	44	80	2019年11月5日 22:52
KODI	0	5	2016年5月7日 21:16
フォルダの容量制限について	0	3	2015年8月27日 06:53

最初｜前の6件｜次の6件｜最後

「ASUSTORなんでも掲示板」のクチコミ掲示板に

スレッド表示順

返信表示切替

分類別に表示

質問の絞込み※

―件

2件

「質問の絞込み」の未返信、未解決は最新1年、解決済みは全期間のクチコミを表示しています

ナイスクチコミ1

返信1

お気に入りに追加

RAID1内のデータを取り出す方法

2023/12/15 17:51（1年以上前）

NAS(ネットワークHDD) > ASUSTOR

kuni225617さん

クチコミ投稿数：1件

スレッドの最後へ

AS5304Tを使用しています。
RAID1でボリューム1、ボリューム2を作成し、使用していました。
ボリューム1のHDDを入れ替えるため、新しいHDDを準備しましたが、誤ってボリューム1の古いHDDを2つ抜き取り、新しいHDDを2つ入れて、ボリューム1を作り直してしまいました。
古いHDDを入れても非アクティブでデータを取り出す事が出来ません。
古いHDDからデータを取り出す方法は有りますでしょうか？

書込番号：25547039　スマートフォンサイトからの書き込み

1点

ムアディブさん

クチコミ投稿数：31892件Goodアンサー獲得：3189件

2023/12/17 14:26（1年以上前）

エラー検知するとバッドマーク付けてわざわざ壊しに行くRAIDコントローラーとかもあるのでなんとも。

サポートを受けてください。
その程度でデータ喪失するようなら、もう、そのメーカーは止めたほうがいいですが、、、

腕に覚えがあるなら、恐らく中身はLinuxなので、Linuxインストールしてマウントしたら読める可能性が高いとは思いますけど、Linuxは親切機能はあんまり無いので、フォーマットも不明だとおぼつかないですな。

ちゃんとその辺も含めてサポート情報出しているsynologyみたいなメーカーもありますけど、多分ほとんどの非エンタープライズ向けの装置はナンチャッテなので放り出すと思います。

書込番号：25549589

0点

スレッドの先頭へ

ナイスクチコミ17

返信38

お気に入りに追加

RAID1（の両ディスク）エラーを解消するには？

2021/09/23 16:59（1年以上前）

NAS(ネットワークHDD) > ASUSTOR

KA-7300さん

クチコミ投稿数：574件

スレッドの最後へ

全般ではなく、別機種固有の掲示板に投稿してしいたので、あらためて全般であるこちらに（再）投稿させて頂きます。（機種固有というよりADMの話なので）

■質問１

同時にHDD2台がMediaErrorとなったものの、ASUSTORのRAID1はなかなか優秀らしく、障害発生後もボリュームには普通にアクセス出来ていました（過去形。理由は質問2に記します）。そこでお教えいただきたいのですが、どちらのHDDを先に交換すれば良いでしょうか？サポートに質問中なのですが、6日間経った現在も有効な回答がありませんので、何かヒントとなるアドバイスでも頂ければ幸いです。

構成：
vol1 Disk1, Disk3 でRAID1
vol2 Disk2, Disk4 でRAID1
上記のDisk2及びDisk4が同時刻にMediaError（幸いにもセクタ番号は異なる）。

ASUSOTRのサイトを参照すると、RAID1の片側が障害を起こした場合は当該ディスクを引き抜いて新しいディスクを入れるだけで解消する旨の文書がありますが、両ドライブに赤LEDが点灯する状況ではどちらから交換すればデータが失われずに済むのか見当がつかず。

■質問2
良い手を思いつかなかったので、まずはバックアップを取ろうと、冗長性のなくなったvolume2のデータをvolume1へ（ASUSTORのファイルマネージャにて）コピーしていたところ、ASUSTORがハングアップしてしまいました。
現在Disk2のLEDのみ猛烈に点滅しているので、ボタン長押しによる強制電源断は怖くて試せていません。
（ハングアップする前は、Disk4台全てのLEDが明滅していました）
ハングアップの症状としては、
　・本体液晶の表示は通常右から左へスクロールするのですが、それが途中で止まったまま。
　・LANから接続できない（ログオン画面にも至らない）
　・pingにも反応が無い
です。
この状態を解消するには、電源長押ししかないでしょうか。
（ほかの技をご存じでしたらご教示いただけますと幸いです）

以上よろしくお願いします。

書込番号：24358298

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/23 18:48（1年以上前）

＞KA-7300さん

ASUSTORのNASは使ったことがありませんので、正確な情報が必要な場合はスルーしてください。

＞この状態を解消するには、電源長押ししかないでしょうか。

HDDの異常によりSATAのリセットを繰り返していて、システムが他の事にリソースを割けない状態かと思われます。
その場にいないので何とも言えないのですが、自分なら数十分まっても復旧しない場合は、あきらめてシャットダウンさせます。
多分ボタン長押しすら受け付けないかもしれません…

最近のNASのOSはベースにLinuxを使っています。
ADMも同様になるかと思います、RAIDもソフトウェアRAIDのmdadmというソフトウェア上で構築されています。

＞vol2 Disk2, Disk4 でRAID1
＞上記のDisk2及びDisk4が同時刻にMediaError（幸いにもセクタ番号は異なる）。

RAID1はミラーリングですので、RAID5やRAID6のようなパリティによる修正は出来ません。
今回のようにアレイを組んでいるHDD全てにダメージがある状態ですと、全てのデータを正常な状態への復旧は難しいです。
また、RAIDの状態が不明(おそらくクラッシュしてる)ですので、ADM上からは１から作り直しになるかと思います。

先にメディアエラーとなったHDDは、RAIDアレイから切り離されてると思いますが
この時ディスクマネージャーでボリュームのステータスはデグレード(劣化)になっていまいしたか？
もしデグレード(劣化)状態で、このボリュームのデータを更新していた場合は、残った１台にしか保存されていません。

残った１台がメディアエラーとなった時、ボリュームのステータスがクラッシュなどの言葉が使われていた場合は
２台ともmdadmのステータスにfaultyがセットされてしまってるかと思います。
このような場合の一般的な方法での修復手段を私は知りません。

ある程度Linuxの操作に慣れているなら、２台のHDDから無事なファイルのみを集める事は出来るかもしれません。
ただ、不良セクタのあるHDDでRAIDアレイを作成する事はお勧めしませんし、ADMでも作らせてくれないでしょう。
スペアのHDDは準備される方向性なのでしょうか？
とりあえずでもサポートからの回答が早く来るといいですね。

あと、SSHというリモートコンソールが使えるなら
cat /proc/mdstat
である程度RAIDの状態が判るかと思います。参考までに。

書込番号：24358487

1点

KA-7300さん

クチコミ投稿数：574件

2021/09/23 22:22（1年以上前）

＞たく0220さん

ASUSTORのNASを使ったことは無いとされながらも、こちらの掲示板でも示唆に富むアドバイスを頂きありがとうございます。

出来うる限りデータを救出したいので、当該ボリュームのディスクアクセスが継続している状況でのシャットダウン手段に悩んでおり、5日ほど手が出せていない状態です。

# 長押しさえ受け付けない状況、確かにそういうケースも有り得ますね。
（サポートがちゃんと回答してくれればその方法を実施するのですが）

RAID1の話になりますが、今回の件ではASUSTORの作りの良さに感謝しています（サポートの応答の悪さは酷いですが）。
よくあるナンチャッテRAID1（MASTERに障害が出た場合は完全にSLAVEに切り替わってしまうタイプ）だと、今回のケース（両方MediaError）は全滅になると思います。ASUSTORの場合、HDDそのものはMediaErrorとなっているものの、どちらのHDDもRAID1ボリュームに組み込まれたままの状態であり、RAIDボリュームへは問題なくアクセスできていました。ボリュームのステータスは、通常は障害を起こしたドライブへの耐久性が1台と表示されていますが、ここは0に変わっていたと思います（慌てていたのでうろ覚え）。

それゆえ、MediaErrorを起こしたHDDで構成されるボリューム2へのアクセス時はエラー箇所までDisk2を使い、エラー箇所のみDisk4を使ってくれるのだろうと（私が勝手に）思っていました。とはいえ全データバックアップを行ったところ途中でハングアップしたので、もしかしたらその部分の挙動が弱いのかもしれません。（なのでサポートの回答を心待ちにしています）

HDD内部でのセクタ代替処理が不可となったのでしょうから、NAS(ASUSTOR)自体の方にBBM(BadBlockManagement)、或いはPDM(PredictiveDataManagement)と呼ばれるような機能が備わってくれていれば（別アレイにデータを吸い出さなくとも）RAID1アレイの片側を交換する形で治せないかと期待しています。ただASUSOTRサイトのカレッジ（技術情報の）などを見てもそういった記載はないので無理なのかもしれません。

ご説明頂いたmdadmの話からすると、その辺は期待薄ということですね。
いずれにせよ、交換用のHDD2台及び吸い出しに使える領域（別RAID1のボリューム1）も準備しました。

なおTeraTermでSSHを掛けてみましたが、応答がなく駄目でした。
（そういう使い方ができるとは知らなかったので、今後活用させていただきます）

書込番号：24358931

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/24 01:22（1年以上前）

＞KA-7300さん

機種によるかと思いますが、フロントパネルに液晶ディスプレイがある機種なら
ひょっとすると、その横にいくつかボタンがついてませんか？
型番が判らないので、その機能があるかまで確認出来ませんがボタン操作でシャットダウンをNASに指示できないかなと思います。

mdadmの場合、HDDの状態がよほど酷くなければReadOnlyになりますが、ユーザーが操作出来るようにしてくれます。

＞ボリュームのステータスは、通常は障害を起こしたドライブへの耐久性が1台と表示されていますが、ここは0に変わっていたと思います（慌てていたのでうろ覚え）。

そのボリュームのRAIDアレイがDegradedの状態である事は確かみたいですね。
ですので初めに故障したHDDはその時点以降は更新されてないとみなした方がいいです。
無事シャットダウン出来た場合は、できたら現状維持を優先してNAS本体から２台とも外しておいた方が無難です。

ADMも同様かと思いますが、各HDDはいくつかのパーティションに分けられOS(ADM)の基本領域とデータ領域、その他といった感じになります。
データ領域のパーティションを束ねた物がボリューム(RAID)として使われます。
各HDDのRAIDアレイに使われるパーティションにはSuper blockと呼ばれるRAIDの管理データがあります、RAID1がミラーリングと言われますがSuper blockだけはユニークで同じにはなりません。
HDDのパーティション(GPT)とSuper blockが無事の場合は、Linux PCと接続する事で状況の確認とサルベージが可能な場合があります。
ただ、今回のケースでは不良セクタによりファイルに影響がある可能性がありますので、HDDの容量によっては１日では終わらないくらい大変かもしれません。

大事なデータの場合は無理せず復旧業者におまかせする事も選択肢として忘れないでください。

あと、記録方式がSMRなHDDは選ばない方がいいですのでお気をつけ下さい。

書込番号：24359193

1点

KA-7300さん

クチコミ投稿数：574件

2021/09/24 19:13（1年以上前）

＞たく0220さん

そう言えばありましたね。フロントパネルのキー（AS-604T）。
試してみたものの、残念ながら反応はありませんでした。

ようやくサポートから回答はあったものの、（ハングアップしているのでどうしたら良いかを質問しているにも関わらず）DSMのレポートを送れと言われました。この状態でどうやってDSMのレポートを送るのか質問中ですが、回答ありません。（また5日間ほど待たされるのかも）

もうサポートは諦めて電源ボタンの長押しを試そうかと思っています。
その後もう一度（今度はハングアップしないように部分的な）バックアップを行う予定です。

最悪の場合でもLinuxPCでサルベージ可能とのこと、安心しました。
ASUSTORのNASを購入したのは本体が故障してもHDDを新筐体に移すだけで使えるという宣伝があったことも理由なのですが、サポートがこれだと新規購入は躊躇われる状況です。

# 丁寧なアドバイスありがとうございます。頻繁に更新するので、無論CMRです。
（監視カメラなどの保管専用であればSMRでも良いのかもしれません）

以上よろしくお願いします。

書込番号：24360413

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/24 20:04（1年以上前）

＞KA-7300さん

＞試してみたものの、残念ながら反応はありませんでした。

ん～残念。完全に応答をなくしてますね。

＞ようやくサポートから回答はあったものの、（ハングアップしているのでどうしたら良いかを質問しているにも関わらず）DSMのレポートを送れと言われました。この状態でどうやってDSMのレポートを送るのか質問中ですが、回答ありません。（また5日間ほど待たされるのかも）

残念なサポートですね。DSMだとSynology?… ^^;

＞もうサポートは諦めて電源ボタンの長押しを試そうかと思っています。
＞その後もう一度（今度はハングアップしないように部分的な）バックアップを行う予定です。

そのバックアップは個人的にはお勧めしません。また不良セクタの部分で止まる可能性が大きいです。
生きてた方のHDD(Disk2?)が判るなら、スペアのHDD(もう用意できてたら)にセクタコピーしてデータロストに備えます。
そして、コピーしたHDDと残りのDisk1、Disk3で起動テストするのが妥当です。
この場合、不良セクタに当たったファイルはコピー出来ますが一部データが破損したままとなります。
アプリによっては正常に扱えなくなってしまいますのでご注意ください。

書込番号：24360503

0点

KA-7300さん

クチコミ投稿数：574件

2021/09/24 21:58（1年以上前）

＞たく0220さん

ご指摘ありがとうございます。確かにDSMではなく、ADMです。（あちらも所持してます）

それにしても、たく0220さんは大変手堅いですね。
確かにデータの安全な救出を目指すには、HDDのバックアップを取得した上で挑むべきです。

バックアップ以後の変更点が少ししかなければ、まずはそこを吸い出そうと思っていたので悩んでいます。
そこが不良セクタにヒットしなければ、古いバックアップデータと併せサクッと救出完了になるので。

＞この場合、不良セクタに当たったファイルはコピー出来ますが一部データが破損したままとなります。

RAID1の片側を抜くのでそうなりますよね。
ただ、おっしゃっている趣旨は、ハングアップさせずに全データを安全に読み出す方法をご教授頂いたと理解しております。
当該セクタが管理情報などを保持しているのでなければ、NASの全ファイルに対して僅か1ファイル、それも更にそのファイル内で1セクタ分のデータ化けだけで済む訳ですね。

# セクタ番号を入力すると、当該ファイル名を教えてくれるソフトが切実に欲しいです。
　どのファイルが壊れるんだろう。これがわからないと、結構致命的です。

ちなみに、次の動作を期待していました。
-----
冗長性のあるアレイでは大雑把に言うと同じデータが 2つある状態です。
もし、一方のデータを読み出し中にエラーが発生した場合、RAID コントローラはもう一方のコピーからデータを読み出しホストの要求に答えます。
-----
有名なRAIDカードでのエラーコードについて、dosparaさんが作成されたFAQからの（恣意的な）抜粋です。
（http://faq3.dospara.co.jp/faq/show/788?site_domain=default）

ASUSTORはLinuxベースで少し弄ってあると何かの紹介記事で読みましたので、このぐらいの動作はしてくれないかなぁと。
（ハングしましたけれど）

ただこの機能（がASUSTORのADMにあるかどうかは不明ですが）に期待する場合、HDDのデータを正常なHDDにコピーしてしまうと、エラーとしてもう片方のディスクに読みにいかなくなってしまうので、これまた悩ましいです。

頭を冷やしてよく考えてみます。
アドバイスありがとうございます。

書込番号：24360739

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/24 23:02（1年以上前）

＞KA-7300さん

＞ご指摘ありがとうございます。確かにDSMではなく、ADMです。（あちらも所持してます）

そちらもお持ちでしたか ^^

＞バックアップ以後の変更点が少ししかなければ、まずはそこを吸い出そうと思っていたので悩んでいます。
＞そこが不良セクタにヒットしなければ、古いバックアップデータと併せサクッと救出完了になるので。

心配なのは、その最近のファイル以外が大丈夫なのか？ですね。
コピー中に止まってしまったので、バックアップ以後のファイルに不良セクタがある可能性は高いのですが
ファイルシステム(Ext4とかBtrfs)にはinode(アイノード)とか管理領域があり、連続したセクタつまり断片化を許容してくれない場合があります。
不良セクタがReallocateされてもファイルシステムの修復も必要となる場合もあります。(ファイル名やディレクトリツリーとかはデータ部と分離されています。)

＞# セクタ番号を入力すると、当該ファイル名を教えてくれるソフトが切実に欲しいです。
＞　どのファイルが壊れるんだろう。これがわからないと、結構致命的です。

以前、ext4のHDDで試した時に参考にしたサイトです。（mdraidなのでこの手順通りではありません）

不良セクタを叩いて潰す - nyacom.net
https://nyacom.net/?p=78

debugfsは稼働中のNASでの実行はお勧めではないので別にPCを用意しました。
そういえばフォーマットは何でされてたのでしょう？
とりあえず１台づつ確認してダメージのあるファイルがかぶってなければ、そのファイルだけコピーして更新日時とかから最新か判断できるかと思います。

＞有名なRAIDカードでのエラーコードについて、dosparaさんが作成されたFAQからの（恣意的な）抜粋です。

深読みすると「冗長性のあるアレイ」ですので…、HDD２台でのRAID1でDegradedになると冗長性は失われてしまっています。
今回はおそらくDisk2のみで動作してたと思われますので…

提案はいくらかあるのですが人によっては難しい場合もあります。
うまくいかなかった場合に損をしてしまうのは私ではなく質問者殿になってしまいますので…
何を選択するのは各人の自由ですので、もし試される上でアドバイスが必要な時はおっしゃって下さい。

書込番号：24360861

1点

KA-7300さん

クチコミ投稿数：574件

2021/09/25 06:03（1年以上前）


ASUSTORのログ（ハングアップ前）

＞たく0220さん

おお！
コマンド、あるのですね。
これは期待が持てます。

# なお、フォーマットはext4だったと思います。

お教えいただいたdebugfsとncheckを（ハングアップから回復したら）使ってみようと思います。
その場合、debugfsへの引数として与えているBLOCK番号は、セクタ数と同意の理解で良いでしょうか。
（icheck BLOCK で、ブロックを利用しているiノードが表示されるという認識です）
念のため、ADMでのシステムログ抜粋を貼ってみます。（media error on sector xxxxxxx）
このxxxxxxxをBLOCKとして指定して良いかという点がよく分かっておりません。

あと私の説明不足で誤解を招いている部分もあるようなので、一部捕捉します。

・単なるRAID1なので、このASUSTORの外部に物理的なバックアップを（1ヵ月ほど前に）取得済みです。
・今回のMediaError発生時、外にバックアップを取るよりも内部でコピーしたほうが早いだろうと、
　このASUSTOR内のVolume2 (6TB)からVolume1 (14TB)へコピーを実施し、途中でハングアップしています。
・なのでバックアップの指すものが2つあるので正しく説明し直すと、
　外部バックアップ以後に更新されたVolume2の（おそらくそう多くは無いことを願う）データを吸い出して
　外部バックアップとマージすることで、ハングアップしてしまったバックアップの代替とすることを現在
　目論んでいます。
・その後、更新分の特定し損ねに備え、Volume2の修復を行えればと願ってます。
　（修復方法がない場合は、ご案内頂いた方法でVolume2を復活させ、debugfs,ncheckで当該ファイルをパージ）

ただバックアップ以後の更新分を目視で特定できるのか、或いは更新日時で検索を掛けてそのままハングアップしないか、
もしくはそもそもアドバイス頂いたようにまずはバックアップを取得しておくべきか（悩むまでもなくすべきなのですが、
6TB×2本の所要時間＋更なるお財布への負担と、上記の手軽さで）決めかねています。
# これは自分で決めるべきことなので、後日結果を記します。

全くの雑談ですが、友人には自己責任でと軽く言えますが、あまり親しくない人に自己責任でとは言いにくい時もあります。
これをうまく言う方法はないかと思っておりましたが、素晴らしい伝え方ですね。参考にさせていただきます。

書込番号：24361124

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/25 12:35（1年以上前）

＞KA-7300さん

現在もハングアップしたままだと思われますが、HDDはカッコン、カッコン鳴ってて
16日からずっとその状態だったら、ダメージが酷くなってないかが心配なところです。

＞その場合、debugfsへの引数として与えているBLOCK番号は、セクタ数と同意の理解で良いでしょうか。

BlockというのはWindowsのNTFSでいうクラスターにあたる用語になります。
debugfsのicheckへの引数はBlockになりますので、HDDの素性から
＞(123631985 - 2048) * 512 / 4096 = 15453742.125
と算出したものを引数として入力します。

で、すみません情報が小出しになってしまうのですが…（過去の記録をどこに保管したのか、私の記憶が飛んでまして…）

参考：帰ってきた徒然苔: 3月 2021
https://ttgcameback.blogspot.com/2021/03/?m=0

こちらはbadblocksコマンドを使って不良個所を特定してます。ただ6TBだと15時間ほどかかるかと思います。

私が提案したかったのは、上記と下記(英語)を参考にしてddrescue(GNU ddrescue)コマンドでクローンをしながら
このlogから不良セクタを特定して、debugfsでファイルを特定するという方法です。

計算の参考：Batch processing a ddrescue mapfile with debugfs - Unix & Linux Stack Exchange
https://unix.stackexchange.com/questions/473453/batch-processing-a-ddrescue-mapfile-with-debugfs

ddrescueでは、読み込めなかったセクタをlogとして残すことができます。
Ext4では無いのですが実行時は↓みたいになります。

root@ubuntu:~# ddrescue -f -n -v /dev/sdb \
> /dev/sda \
> /media/ubuntu/boot/rdn_log/rdn_dd_logfile_20210220.txt
GNU ddrescue 1.23
About to copy 5000 GBytes from '/dev/sdb' to '/dev/sda'
Starting positions: infile = 0 B, outfile = 0 B
Copy block size: 128 sectors Initial skip size: 97792 sectors
Sector size: 512 Bytes

Press Ctrl-C to interrupt
ipos: 19345 MB, non-trimmed: 0 B, current rate: 10112 B/s
opos: 19345 MB, non-scraped: 3072 B, average rate: 106 MB/s
non-tried: 0 B, bad-sector: 1024 B, error rate: 128 B/s
rescued: 5000 GB, bad areas: 2, run time: 13h 48s
pct rescued: 99.99%, read errors: 3, remaining time: 1s
time since last successful read: 0s
Finished

１回目は読み込めなかった時のリトライなし、２回目以降は何度かリトライさせる設定で実行します。
１回目のlogを使う事で２回目以降は読み込めなかった所のみで実行されますので数分で終わります。

最終的にlogは
root@ubuntu:~# cat /media/ubuntu/boot/rdn_log/rdn_dd_logfile_20210220.txt
# Mapfile. Created by GNU ddrescue version 1.23
# Command line: ddrescue -f -d -r1 -v /dev/sdb /dev/sda /media/ubuntu/boot/rdn_log/rdn_dd_logfile_20210220.txt
# Start time: 2021-02-20 22:53:26
# Current time: 2021-02-20 22:54:23
# Finished
# current_pos current_status current_pass
0x481195E00 + 1
# pos size status
0x00000000 0x481195000 +
0x481195000 0x00001000 -
0x481196000 0x487E09A0000 +

となりstatusが「-」の行「0x481195000 0x00001000 -」が不良と判ります。
0x481195000はバイトですので、まず16進から10進にすると 19345788928
これをSector sizeで除算します、19345788928/512 = 37784744
これで不良セクタの場所が判りますので、ログで表示された値と近いか確認します。

root@ubuntu:~# parted /dev/sdb
GNU Parted 1.9.0
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) p
Model: ATA WDC WD50EZRX-00M (scsi)
Disk /dev/sdb: 9767541168s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
1 2048s 9766492159s 9766490112s xfs Basic data partition
2 9766492160s 9767532543s 1040384s linux-swap(v1)

今回は１番目なので開始オフセット分を引きます、
37784744-2048 = 37782696
んで、またブロックに変換 37782696*512/4096 = 4722837
(xfsのBlockSizeは4096に設定してたので)
これでパーティションの開始位置からのBlockが算出されましたので
これをdebugfsのicheckで確認します。
※注：上記は計算の例ですxfsはdebugfsは使えなかったはずなので、別の方法を使ったと思います。

書込番号：24361614

1点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/25 13:31（1年以上前）

＞KA-7300さん

Linux環境ですが、Ubuntuのインストールメディアで起動させて試用するのが便利かもしれません。
UbuntuのUSBブートについては下記を参考にしてください。

WindowsでUbuntuのインストールUSBメディアを作成する
https://diagnose-fix.com/topic2-003/

Ubuntu Desktop 日本語 Remixのダウンロード
https://www.ubuntulinux.jp/products/JA-Localized/download
から「ubuntu-ja-20.04.1-desktop-amd64.iso（ISOイメージ）」をDLしてください。

バージョンによって多少かわりますが、基本的な操作はわかるかと思いますので、参考程度に。
Ubuntu 18.04 LTSの基本的な使い方
https://sicklylife.jp/ubuntu/tsukaikata/usage.html

USBからの起動方法はPCによってUEFI setupなどの変更が必要だったりとすると思います。
サルベージする場合は、他のディスクは誤って操作しないように外された方が無難です。

USBから起動後「Ubuntuを試す」で開始する事が出来ますが、再起動後にはリセットされますのでご注意ください。
UbuntuのインストールUSBにはファイルなどの保存が難しいですので、ログやメモ用にもう１つあると便利です。

状況が確認出来るようにならないと判断が難しいと思います。
とりあえず必要そうな情報として置いておきますので、参考になればと思います。

書込番号：24361713

1点

KA-7300さん

クチコミ投稿数：574件

2021/09/26 00:44（1年以上前）

＞たく0220さん

NASをハングアップから復帰させて、現在絶賛混乱中です。

とはいえ、ご丁寧にお教えいただきありがとうございます。
まずは御礼申し上げます

そのような状況の為、斜め読みで恐縮ですが、RAWでのコピーつまりLinuxで通常はddを行うところそれだとエラーセクタで止まるか若しくはエラーを無視して全部突っ走るかになってしまうので、エラー箇所を記録しながらddを行うツールをご紹介頂いたものと理解しています。また計算も実際に行っていただいて助かります。まだ理解が追い付いていないので、式自体を理解しなくてはなりませんが、簡易に使わさせていただこうと思っております。
　どうも的確なご返信を頂いているなぁと薄々思ってはいたのですが、ご経験者（実践者）なのですね。Linux（Ubuntu）の使用開始方法も含め、貴重なアドバイス参考になります。

話が戻りますが、現在混乱しているのは、見た目上は「治って」しまったからです。
あれからとうとう、電源ボタン長押しを実施してしまいました。他のキーは反応ありませんが、この手法はハードウェア的に処理されるのか、問題なく電源が切れました。

その後システム（NAS）は無事起動し、状態を確認したところRAIDボリューム1,2：正常、HDD（drive1～4）：正常と、訳わかりません。
良い話ではあるのですが、MediaErrorで冗長性が無くなった筈のRAID1ボリュームも「冗長性1ドライブ」があることになっています。
そこで、そういえばcat /proc/mdstatをお教えいただいたなぁと実施してみました。（SSHはデフォルト無効でしたので有効にした上で）

-----
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid1 sdb4[0] sdd4[1]
5855934464 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sda4[2] sdc4[3]
13667923968 blocks super 1.2 [2/2] [UU]
[>....................] resync = 0.0% (10368384/13667923968) finish=23746.6min speed=9585K/sec

md126 : active raid1 sda3[6] sdd3[5] sdb3[4] sdc3[7]
2096064 blocks super 1.2 [4/4] [UUUU]

md0 : active raid1 sdc2[7] sdd2[5] sdb2[4] sda2[6]
2096064 blocks super 1.2 [4/4] [UUUU]
-----

不勉強故、読み取り方を分かっていませんが、明らかにresyncが走っています。
GUIの画面表示をもう一度確認すると、故障していなかった筈のvolume1は同期処理中でした。
考えてみれば、vol2からvol1へデータをコピー（書き込み）中にハングアップしたので、まあ当然ではあります。

そうするとvolume1は同期を待てばそのまま使えるとして、volume2は正常扱いとなっているものの、データが正しいかどうかの疑念が残ります。そこで（これまたお教えいただいた）debugfsを（NAS上で）叩いてみましたが、not foundでした。更新分はロストしても構わないデータでしたので、バックアップから全リストアすべきかを悩み中です。今後もASUSTORを使い続けてゆくのであれば、1セクタ（もしくは2セクタ）分のデータが無事かどうかを検証すべきなのですが。

# 音も静かで、それでいてHDDがさして熱くならず、ASUSTORの筐体自体は大変気に入っています。
　ただサポートの無いものを使い続ける気はしないので、今後どうするかも検討しなくてはならなくなりました。
　昔RAID5で痛い目にあったのでRAID1にしていたのですが、今後はRAID6にするべきかもしれません。
　（HDDの大容量化が進んできたので、もしくは単にsingleドライブを複数接続とするか悩みます。
　　RAID1で大半が生き残っていてもデータが腐っているか悩むのであれば、singleの方がマシなような）

なお意外なことにS.M.A.R.T.のReallocated_Sector値は全て0でした。抜粋すると
----------
Disk1 Disk2 Disk3 Disk4
Raw_Read_Error_Rate 0 0 0 51
Reallocated_Sector_Ct 0 0 0 0
Reallocated_Event_Count 0 0 0 0
Current_Pending_sector 0 0 0 0
Offline_Uncorrectable 0 0 0 0
----------
という感じで、Disk4はそろそろセクタ代替処理が走りそうです。（無論、今回を期に交換します）

以上とりとめないですが、現状を記してみました。
（RAID1が治った、というよりもハングアップで管理情報が失われた感があります）

書込番号：24362867

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/26 08:56（1年以上前）

＞KA-7300さん

おはようございます。

＞問題なく電源が切れました。

なんとか切れましたか、スイッチもNGでコンセントから泣く泣くブチッと…という事もありますが、それは避けられたみたいでなによりです。
最近の電源スイッチはモーメンタリスイッチで自己保持回路持たせてると思うけどリセットが効かないなんてのもたまにあるそうです。

SSHのポートは22以外にするか、使わないときは無効にしておいた方がセキュリティ的に安心です。
Tera Termのキーボードショーットカットは、コピーはAlt+C、ペーストはAlt+Vです。
Ctrl+CはBreak(中断)になります。初期設定だとマウス右クリックもペーストになってるので誤操作にはご注意ください。

＞そこで、そういえばcat /proc/mdstatをお教えいただいたなぁと実施してみました。

root@NAS220J01:~# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md3 : active raid1 sdb3[0]
5855700544 blocks super 1.2 [1/1] [U]

md2 : active raid1 sda5[0](E)
239367424 blocks super 1.2 [1/1] [E]

md1 : active raid1 sda2[0] sdb2[1]
2097088 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
2490176 blocks [2/2] [UU]

別メーカーですが実験でクラッシュさせた時は↑みたいな感じに(E)や[E]のようにErrorと判る感じだったのですが
無いので、Faltとマークまでつけられてなかったみたいですね。「冗長性1ドライブ」この表示の信憑性がないですね。
仮に０でも冗長構成を維持させてるなら紛らわしいですね、JAROにでも相談しますか ^^;
さて、再起動時にRAIDアレイが読み込まれたタイミングでdisk1とdisk3のsuperblockがチェックでひっかかったと思われます。
そちらに書込みしてた時にハングしたのでタイミングが悪かったとしか…

mdadm -D /dev/md1
※ D :Detail --detailと同じ
でsyncの方向は確認できると思います。
finish=23746.6minですか、長いですね。正常にシャットダウン出来なかったのでファイルシステム(Ext4)のチェックが並走してるかもしれませんので、しばらくは負荷をあまりかけない方が無難ですね。

＞debugfsを（NAS上で）叩いてみましたが、not foundでした。

root@NAS220J01:~# env | grep PATH
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin
root@NAS220J01:~# which debugfs
/sbin/debugfs

PATHが通っていたら「debugfs」で実行できますが、PATHが通っていない場合は「/sbin/debugfs」と絶対パスで入力する必要があります。
whichコマンドはPATHが通ってたら、どこにあるかを教えてくれます。
ADMにはdebugfsが入ってないかもしれません。(ググってみたけどそれらしいの無いです。)

貼ってもらったログから
slot4(Disk4) ：1011768セクタ
slot2(Disk2) ：1080464セクタ
での通知だったと思うのですが、一応の確認はした方がよいのでS.M.A.R.T.のlogが無いか見た方が良いでしょう。
1セクタ512バイトだと、
Disk2は553197568バイト = 527.5703125MiB
Disk4は518025216バイト = 494.02734375MiB
かなりHDD先頭の部分となります。

parted -s /dev/sdb unit s print
と
parted -s /dev/sdd unit s print

でログのセクタが何番目の範囲か確認してみてください。「Number」が４以外だとOS関連のパーティションで発生したと思われます。
OS関連であると、それがハングアップに至った要因ではないかとも…
（はやく気づけよっ！とつっこまれそうですが、見逃してたんですよ…）

次のレスに続く…

書込番号：24363210

1点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/26 09:00（1年以上前）

長くなって収めきれなかったので続きになります。

一応、他に波及してないかの確認。
root@NAS220J01:~# which smartctl
/bin/smartctl

で使えるようだったら
smartctl -a /dev/sdx
※ sdx：xはa～z、該当ドライブのデバイスに合わせる。

logが記録されてない時は下記みたいになり、エラーがあったらその内容が記録されている場合もあります。

SMART Error Log Version: 1
No Errors Logged

張ってもらったログに「[Disk Docter] S.M.A.R.T. quick scanning of...」とあるので
S.M.A.R.T.のショートテストをスケジュールかマニュアルで実行されてるので

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 48910 37784744

とログが見えるかもしれません。

icheckへの引数の計算は、
セクタは4kネイティブなHDD以外は512バイトでの計算で大丈夫だと思います。
Block sizeの調べ方は、さすがにtune2fsはあると思いますが
root@NAS220J01:~# which tune2fs
/sbin/tune2fs

tune2fsあれば下記のようにボリューム２「/dev/md2」を指定して確認できると思います。
tune2fs -l /dev/md2 | grep -i "block size"

LVM使ってるのでパスは違いますがこんな感じに
root@NAS220J01:~# tune2fs -l /dev/vg1000/lv | grep -i "block size"
Block size: 4096

ボリューム２のファイルシステム上の開始セクタ(Start sector)は下記でまずRAIDアレイのStartセクタを確認（0sだと思いますが）
parted -s /dev/md2 unit s print

アレイは/dev/sdb4と/dev/sdd4ですので、先ほどの結果を見てStartセクタを確認し
Start sector = [/dev/md2の開始セクタ] + [/dev/sdb2かsdd4の開始セクタ]
と計算します。

smartctlのLBAからは前回の式参考に
＞(123631985 - 2048) * 512 / 4096 = 15453742.125

Block = ([LBA] - [Start sector]) * [Sector size] / [Block size]
= ([LBA] - [Start sector]) * 512 / 2048
となります。

ログに表示されたセクタ番号(＝LBA)からでも上記と同じになります。

linuxの不良セクタチェックはツールとしてbadblocksがよく使われています。
ただ既存のデータがある状態では、非破壊チェックを指定しても心配な面はありますので運用中は実行しない方が良いと個人的には思います。
今回の原因は/dev/md0で発生してるのではと疑っていますが、resync中でなければNASをシャットダウンして
別PCで/dev/md0や他のパーティションもチェックをお勧めしたいところです。

書込番号：24363218

1点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/26 11:49（1年以上前）

すみません、誤記訂正になります。

×:/dev/sdb2 -> ○:/dev/sdb4
[誤]
アレイは/dev/sdb4と/dev/sdd4ですので、先ほどの結果を見てStartセクタを確認し
Start sector = [/dev/md2の開始セクタ] + [/dev/sdb2かsdd4の開始セクタ]
と計算します。

[正]
アレイは/dev/sdb4と/dev/sdd4ですので、先ほどの結果を見てStartセクタを確認し
Start sector = [/dev/md2の開始セクタ] + [/dev/sdb4かsdd4の開始セクタ]
と計算します。

×:2048 -> ○:4096
[誤]
Block = ([LBA] - [Start sector]) * [Sector size] / [Block size]
= ([LBA] - [Start sector]) * 512 / 2048
[正]
Block = ([LBA] - [Start sector]) * [Sector size] / [Block size]
= ([LBA] - [Start sector]) * 512 / 4096

書込番号：24363575

1点

KA-7300さん

クチコミ投稿数：574件

2021/09/26 19:45（1年以上前）

＞たく0220さん

セキュリティへ（port番号）の配慮についても示唆有難うございます。一応操作機以外の他IPは弾くようにしています。
残念ながらdebugfsは/sbinにもなく、見つけられませんでした。

それはそうと、ご指摘はドンピシャリなような気がします。

-----
# parted -s /dev/sdb unit s print
Model: ATA HGST HDN726060AL (scsi)
Disk /dev/sdb: 11721045168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 2048s 524287s 522240s
2 524288s 4718591s 4194304s raid
3 4718592s 8912895s 4194304s raid
4 8912896s 11721043967s 11712131072s raid
-----

Disk2のmedia errorはセクタ1080464で起きたので、上記結果からすると領域No.2内で発生しているということでしょうか。ただDisk2と4で1つのRAID1にしているので、同一ドライブ内にRAIDパーティションが3つあるのがどういうことか（Linuxの仕組み自体を）よく分かっておりません。一番サイズの大きい4番目には該当していないのでデータが無事としても、Number2と3の領域が何なのかが不思議です。

知識不足故、お教えいただいた後半部分にはまだ手を出せていません。

以上よろしくお願いします。

書込番号：24364546

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/26 21:46（1年以上前）

＞KA-7300さん

＞Number2と3の領域が何なのかが不思議です。

この２つはおそらくシステム領域と仮想メモリのスワップ領域に使われていると思われます。
先にも書きましたが、データの領域とOSの領域は分離されていて、データの領域（ボリューム）を追加したり消したりしやすく作られています。
システム(ADM)の中核をrootfsとか言ったりします。(WindowsのC:\windowsの役割みたいな)

下記コマンドで「Mounted on」が「/」になっているのがNumber2のRAIDアレイであればrootfsになります。
df -h

root@NAS220J01:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 914M 1.3G 42% /
none 224M 0 224M 0% /dev
/tmp 243M 1.5M 241M 1% /tmp
...(省略)

スワップはOSによって実装が異なるのですが下記で確認可能かもしれません。
swapon -s

root@NAS220J01:~# swapon -s
Filename Type Size Used Priority
/dev/md1 partition 2097084 2308 -1

少し気になったのですが、
md2 : active raid1 sdb4[0] sdd4[1]
md1 : active raid1 sda4[2] sdc4[3]
md126 : active raid1 sda3[6] sdd3[5] sdb3[4] sdc3[7]
md0 : active raid1 sdc2[7] sdd2[5] sdb2[4] sda2[6]

sdb4[0]の様に[]内の数値は各アレイで追加された順番でナンバリングされるのですが
一旦アレイからremoveされると、その番号は欠番になり同じHDDで再度追加しても番号が変わるはずなので
md2以外のアレイは全部1回removeされた感じに思われます。
現在md1がresyncの最中かと思いますが、コマンドで確認する以前にmd0とmd126もresyncされてた可能性が考えられます。
ただ、アレイ内のファイルが何か使用中の場合アレイを停止する事もremoveも受付け無いはずなので何が起こったのか不思議な感じがします。

あと、ファイルの比較はopensslコマンドが使える場合はSHA256ハッシュなどで確認しています。
不良セクタにかかったファイルはコピー自体失敗してしまう事があるので、ddrescure使った後の簡易比較には使えるかな？

root@NAS220J01:~# openssl sha256 /var/services/homes/taku/openvpn.log
SHA256(/var/services/homes/taku/openvpn.log)= 55c593799c16523d09e28eaff314849bf3f598235a2e8799004bcabf6cc78856

Windowsだと7zipとかでもSHA256は確認できますね。

ddrescureはクローン作りつつ潜在的な不良ブロックの確認とその記録ができるので便利ですよという事です。
システムに通知されて無いだけの場合もありますので。

Raw_Read_Error_Rateは再起動するとRAW_VALUEはリセットされて0になったと思いますので
VALUE、WORST、THRESHの項目も見てWORST(最悪値)がTHRESH以下になってないかも確認しといた方が無難かと思います。

書込番号：24364815

1点

KA-7300さん

クチコミ投稿数：574件

2021/09/26 23:06（1年以上前）

＞たく0220さん

呪われているのではないか、と思うような状況になりました。
バックアップが読み出せません。

正確には、このASUSTORとは別に、HPのMicroServer(N36L)で構築したNASへバックアップを保存していました。昨日まで読めていたのですが、現在N36Lの電源が入りません（本来黄色から緑色になる筈が、黄色のまま）。独立機構であるMicroServerのRemoteAccessCardのみ生きていて、電源コントロール画面は表示されるものの（当然ながら）電源は入らず、虚しさが募ります。N36LにはHardwareRaidCardを入れていたので、Raid5の読み出しが通常のHDDより早く気に入っていただけに残念です。ちなみにHPのN36LはASUSOTRのAS-604Tとそっくりです（ボックス型で、下部にレバー式のHDDベイが4台分）。

よくよく考えてみれば、N36Lが古くなってきた（特に3Wareのサポートが）のでASUSOTRを購入したことを考えると、今故障したのも不思議ではないのかもしれません。ただ、何故ASUSTORのRAID1がおかしくなったこのタイミングで壊れるのかとは思いますが。

現在バックアップが0になってしまったので、本来はASUSTORのHDDと交換しようと思って準備したHDDへ、データ吸出し中です。

さて、肝心のdの結果は

Filesystem Size Used Avail Use% Mounted on
rootfs 480M 68M 413M 15% /
tmpfs 494M 184K 493M 1% /tmp
/dev/md0 2.0G 360M 1.5G 20% /volume0
/dev/loop0 951K 13K 918K 2% /share
/dev/md1 11T 7.4T 3.5T 69% /volume1
/dev/md2 5.5T 4.9T 564G 90% /volume2

となっており、rootfsって何処？状態です。
一方swaponについては-sオプションが無いようです。

-----
# swapon -s
swapon: invalid option -- 's'
BusyBox v1.19.3 (2021-07-27 00:40:20 CST) multi-call binary.

Usage: swapon [-a] [-p PRI] [DEVICE]

Start swapping on DEVICE

-a Start swapping on all swap devices
-p PRI Set swap device priority
-----

質問ばかりですみません。

# 補足 volume1のHDDは、容量の大きなHDDに換装済み（6TB->14TB）です。

以上よろしくお願いします。

書込番号：24365000

0点

KA-7300さん

クチコミ投稿数：574件

2021/09/27 01:13（1年以上前）

＞たく0220さん

typoと誤情報がありましたので、以下訂正します。

誤：さて、肝心のdの結果は
正：さて、肝心のdf -h の結果は

正しい df -h の結果
-----
Filesystem Size Used Avail Use% Mounted on
rootfs 480M 54M 427M 12% /
tmpfs 494M 40K 494M 1% /tmp
/dev/md0 2.0G 361M 1.5G 20% /volume0
/dev/loop0 951K 14K 917K 2% /share
/dev/md1 13T 3.4T 9.3T 27% /volume1
/dev/md2 5.5T 4.8T 627G 89% /volume2
-----

また、その他お教えいただいたコマンドの結果は次のようになりました。

・smartctl
　ありました。見慣れていないので、どれも問題ないように見えます。

・tune2fs
　/dev/md0, md1, md2 ともに 4096 でした。
　/dev/md126は
　　　tune2fs: Bad magic number in super-block while trying to open /dev/md126
　　　Couldn't find valid filesystem superblock.
　となりました。

・parted
　　 Number Start End Size File system Flags
　　/dev/md0　　　 1 0s 4192127s 4192128s ext4
　　/dev/md1　　　 1 0s 27335847935s 27335847936s ext4
　　/dev/md2　　　 1 0s 11711868927s 11711868928s ext4
　　/dev/md126 　 1 0s 4192127s 4192128s linux-swap(v1)

以上補足となります。

書込番号：24365161

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/27 02:11（1年以上前）

＞KA-7300さん

＞となっており、rootfsって何処？状態です。

あれ？この手法は私も見るの初めてなので…
ネットも少し確認してみたのですが、ちょっと判らないです。

＞一方swaponについては-sオプションが無いようです。

-sオプションなかったですか。
多分/dev/md126だと思われるので、下記でも試してみてください。
「linux-swap(v1)」みたいにswapが含まれてたらOS起動時にセットされるみたいです。

parted -s /dev/md126 print

root@NAS220J01:~# parted -s /dev/md1 print
Model: Linux Software RAID Array (md)
Disk /dev/md1: 2147MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0.00B 2147MB 2147MB linux-swap(v1)

という事で上記でスワップ領域となったら、消去法で「/dev/md0」はシステム関係という事かと思います ^^;

＞# 補足 volume1のHDDは、容量の大きなHDDに換装済み（6TB->14TB）です。

なるほど、了解です。

# 行き違いになりそうだったので追記

＞また、その他お教えいただいたコマンドの結果は次のようになりました。

partedの結果から/dev/md126がスワップですね。
スワップはtune2fsに対応していないファイルシステムなのでopen出来なくて正常となります。
S.M.A.R.T. も異常なさそうですので、ひとまずresyncが終わるまでは様子みですね。

＞呪われているのではないか、と思うような状況になりました。

不運って続いてしまう時がありますよね…
無事に吸い出せるよう、願っております。

書込番号：24365191

1点

KA-7300さん

クチコミ投稿数：574件

2021/09/27 22:51（1年以上前）

＞たく0220さん

お陰様で、吸出しも（ハングアップせず）順調に進んでおります。meda errorとなったセクタが、データ領域ではないことを丁寧にご案内頂き大変助かりました。厚く御礼申し上げます。（同期処理の方は無事完了しました）

なお今回のバックアップは、前回のようにADM上のファイルエクスプローラーによるバックアップではなく、一旦PC経由で別HDDへコピーを行っています。私はwindowsを使っているのでコピーにはROBOCOPY.EXE※という（OS標準の）ユーティリティを使用しております。後学までに、Linuxで同様のおすすめツールがあればお教えいただければ幸いです。

※　explorer(GUI)でコピーするよりも速く、かつ抜群に安定しています。多彩なオプションを指定できるのは無論のこと、コピー時にログを出力するので、万一コケた場合でもやり直しの手掛かりが得られます。きっとLinux（ubuntu）にも同様なツールがあるのだろうと思いつつ、そちらには知識がなく。ADMのエクスプローラーではなく、コマンドで直にコピー出来るものであれば、使ってみたいと思っております。

以上よろしくお願いします。

書込番号：24366865

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/28 20:44（1年以上前）

＞KA-7300さん

こんばんは。
タイミング的に伝えられなかったのですが、Synology、QNAPでもHDD入れ替えでの移行(migration)には条件付きで対応はしてます。

参考：Synology NAS（DSM 6.0 以降）間でデータを移行する方法
https://www.synology.com/ja-jp/knowledgebase/DSM/tutorial/Backup/How_to_migrate_between_Synology_NAS_DSM_6_0_and_later

参考：NAS 移行の互換性 | QNAP
https://www.qnap.com/ja-jp/nas-migration

＞昔RAID5で痛い目にあったのでRAID1にしていたのですが、今後はRAID6にするべきかもしれません。

再構築中に２台目もNGになってしまった感じですかね。
bit rotに備える為に、BtrfsかZFSあたりなんだろうけど、そこまで必要か…

参考(英語)：How data scrubbing protects against data corruption
https://blog.synology.com/how-data-scrubbing-protects-against-data-corruption

＞後学までに、Linuxで同様のおすすめツールがあればお教えいただければ幸いです。

WinだとFastCopy使ったりします。Linuxはrsyncですね。ちょっとした単純コピーはcpコマンド。
rsync --help
で実装されてれるオプションを使用する前に確認しておくと良いです。

自分のテンプレは下記、「コピー元」は特に注意です。
rsync -av --progress コピー元コピー先

参考：rsync コピー元のスラッシュの有無で挙動が変わる - Qiita
https://qiita.com/bibouroku/items/872bc46637e366cfa940

参考：rsyncコマンドで覚えておきたい使い方10個 | 俺的備忘録 〜なんかいろいろ〜
https://orebibou.com/ja/home/201506/20150612_001/

ssh経由で実行するならnohupコマンドも併用すると便利かも。rsyncの--log-fileオプションなどもあるので試してみてください。

参考：【 nohup 】コマンド――端末を閉じてもログアウトしても処理を続ける：Linux基本コマンドTips（137） - ＠IT
https://atmarkit.itmedia.co.jp/ait/articles/1708/24/news022.html

書込番号：24368442

1点

KA-7300さん

クチコミ投稿数：574件

2021/09/29 05:49（1年以上前）

＞たく0220さん

rsync、ご紹介ありがとうございます。特に重視している機能、--existingと-uを併用できるか、実機で試してみます。

データの吸出しは無事完了しました。とすると、前回何故ハングアップしたのかは謎です。今回は用心のため、ADMのファイルマネージャを使わずにPCからROBOCOPY（windows機なので）を掛けているからかもしれませんが、検証するとなるともう一度同じ時間をかけてADMのファイルマネージャーでバックアップを取らないとならないので考慮中です。

medaia errorが生じた時刻は同一時刻（秒まで同じ）なので、リカバリした瞬間という事なのかもしれませんね。そういったログもあれば嬉しいのですが、今できる手段で対応したいと思っています。RAID6にしたらしたでまた嵌りそうなので、当面RAID1+別バックアップ2セットの予定です。

SynologyとかもHDD入れ替えでの移行が可能とのこと、大変興味深いです。次の理由で深いところまで読まないとならない気がするので、落ち着いたら熟読させていただきます。ASUSTORの場合は単純にHDDを移し替えればslotの番号なんか気にしなくてよいという大変素晴らしい謳い文句があります。なので、RAID1の容量拡張時の取り外した小容量のボリュームを取り付けたところ、全くRAIDボリュームとしては認識されませんでした（単なるHDD扱い）。安NASみたいにRAIDボリュームの容量変更（拡張）が出来ないということは無く、ホットスワップで実施できるのは大変ありがたかったのですが、元のディスクをバックアップ扱いにしようと思っていたので意外でした。

イメージとしては4スロットあるので

容量拡張前　vol1:slot1-Disk1( 6TB), slot2-Disk2( 6TB)
容量拡張後　vol1:slot1-Disk1'(14TB), slot2-Disk2'(14TB)　＋　取り外されたDisk1(6TB), Disk2(6TB)
お試し　　　　vol1:slot1-Disk1'(14TB), slot3-Disk2'(14TB)k slot3:Disk1(6TB), slot4:Disk2(6TB)

としたところ、slot3,4のDiskをボリュームとしては認識しませんでした。容量拡張の際、古いディスクはRAIDボリュームとしては扱われない処理がなされているのか、もしくはボリューム名が同じになるので弾かれているのか、そのあたりは不明です。おそらく元々のDisk1,Disk2のみで起動すれば旧ボリュームが扱えたのかもしれません（未検証）。そのまま6TBは新しいRAIDボリュームとして組み込み、今に至ります。

たく0220さんのご尽力のおかげで、安心してRAID1（の両ディスク）エラーに対処することが出来ました※。重ねて御礼申し上げます。

※ まだまだ換装等残作業がありますが、現在エラーを起こしているRAID1のvolume2は削除予定（システムにエラーセクタを含むものを残したくない）なので、それをもってRAID1エラーとしては一旦区切りをつけたいと思っております。

書込番号：24369037

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/09/29 23:26（1年以上前）

＞KA-7300さん

＞前回何故ハングアップしたのかは謎です。

rootfsはどうもNAS内部のUSBのバスにストレージが隠されているようで、そこから読み込まれてるそうです。
「/dev/md0」にはSambaなどの主要なソフトウエアが保存されているとの事ですが、実際に見てないので多分と付け加えておきます。

S.M.A.R.T.の情報をあてにし過ぎてはいけないのですが、何も記録されていないので
おそらくHDDへのアクセスがタイムアウトしたのだろうと思います。
ADMのそのアラートが何を検知して出しているのか、サポートが説明してくれるならいいのですが…
システム関係のログは
dmesg
か
cat /var/log/messages
で確認できます。長い場合はheadコマンドやtailコマンドを併用してください。

＞としたところ、slot3,4のDiskをボリュームとしては認識しませんでした。

RAID superblock formats - Linux Raid Wiki
https://raid.wiki.kernel.org/index.php/RAID_superblock_formats

「Section: Array-State Information area」に「events」field があります。Notesに書かれてますが

＞Incremented whenever the superblock is updated.
＞Used by mdadm in re-assembly to detect failed/out-of-sync component devices.

mdadm -D /dev/md1
eventsは上記でも確認出来ますが、

mdadm --examine /dev/sdb4
等RAIDアレイのメンバであるパーティションに対して「mdadm --examine」でDisk毎に情報を確認する事も出来ます。

各RAIDアレイは作成時にUUIDが採番されますので、すでに同じUUIDのRAIDアレイが存在する場合は
Eventsが同じ値でないとそのDiskは組み込まれません。
またUUIDが同じペアが存在したとしても、おそらく「utime」fieldで更新時刻が新しいものが優先されると思われます。
1本ずつDiskを交換した場合、Eventsが１ずつ増えてるわけですので、交換した旧Diskそのままではバックアップにはなりません。
「--force」などで強制的に実行すれば出来るかもしれませんが、同一システム上で同一UUIDのRAIDアレイを組むのは出来ないでしょうが、無用なシステムトラブルを招くだけで無意味だと思います。

AsustorのNASではLVMは使ってないみたいですので不要ですが、流れの参考にはなるかと思います。
「mdadm -Asf」ではsuperblockが更新されてしまうので、ただ確認するだけや、読み込むだけなら「--readonly」にするのが良いかと思います。

mdadm -Asf
↓
mdadm --assemble --scan --readonly

Synology NASが故障したときにPCでデータを復元する方法 - Synology ナレッジセンター
https://kb.synology.com/ja-jp/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC

mdadmのRAIDではDiskの順番はsuperblockで管理されてるので、mdadmで管理されてるNASはどのスロットに入れても普通に動くと思います。
各メーカーはサポート時にログを追っかけるのが面倒とか、そんな理由だと個人的には思っています。

書込番号：24370475

1点

KA-7300さん

クチコミ投稿数：574件

2021/09/30 01:36（1年以上前）

＞たく0220さん

rootfs、お教えいただいたログを後ほど見てみます。
というのは先ほどmedia errorが発生したRAID1ボリュームをASUSTORのNASから取り除いたところだからです。Linuxの知識不足でddの比較をサクッと行う方法を思いつかず、windows機に接続して、エラーセクタを見てやろうという趣旨です。ただwindows10はいつの間にかdiskprobeが標準ではなくなっていて、XPのバックアップ（これはNASに取っといてある）から取り出して使用しました。XPが互換モードの指定とか管理者で実行の指定とかありましたが、media errorとされていたセクタはさっくり読み出せました。念のためDisk2及び4それぞれで当該セクタを読み出し、お互いのデータをバイナリで比較しましたが、全く同じでした。（つまり壊れていない）。ご指摘のようにADMが何かを検知したのだと思います。ただ、サポートはあれから回答が無く、、、。古い製品だからサポートしないというスタンスであれば、せめてその旨返信が欲しいところです。HDD壊れるのって数年後なのに。

取り出したディスクを認識させる件、丁寧にご説明頂き大変貴重な知見を賜り大感謝です。ゆっくり試してみたいと思っています。なお、slotに依存しないのは、mdadmならみなそうなのですね（謳う謳わないは別として）。

物凄い勉強になりました。
一旦、当質問は解決としておきます。
（残りのためしたい事項はあるので、追記は行う予定ですが）

ありがとうございます。

書込番号：24370633

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/10/01 22:00（1年以上前）

＞KA-7300さん

＞ただwindows10はいつの間にかdiskprobeが標準ではなくなっていて

HDDレコーダの換装なんかによく使われてるHxDが(使ったことはないが)代わりにならないかと思います。
「Download page」から日本語版も選べます。

HxD - Freeware Hex Editor and Disk Editor | mh-nexus
https://mh-nexus.de/en/hxd/

不良セクタだらけのNTFSからファイル特定してくれと頼まれて使ったけど…
出来たらもう使う機会が来ないことを願うソフト↓

Active@ Disk Editor - Freeware Hex Viewer & Hex Editor for raw sectors/clusters
https://www.disk-editor.org/index.html

Linuxだとhexdumpコマンドが使えれば表示させる事は可能です。
ddで一部切り取って、そのファイルをhexdumpで見る事も出来るのですが、Windowsの方が扱いやすいかもしれませんね。

＞古い製品だからサポートしないというスタンスであれば、せめてその旨返信が欲しいところです。

国内メーカーの対応に慣れてしまうと…
向こうの事はよく知りませんが、国がメーカーに義務を課してないのかもしれません。
正規品といえども代理店経由の輸入品ですので、保証期間が過ぎた後のサポートに期待してはいけないのかもしれません。(メーカーによるとは思いますが)
延長保証が適用できる機種の場合は必要に応じて課金しておくのが無難かと思います。

ちなみにLinuxでのHDD関係のコマンドタイムアウトはデフォルトは30秒みたいです。
まだ詳しく調べてませんが、SMRなHDDは10分ぐらいかかる場合があったような報告もあり…

あと、ドライブ自体にERC(Error Recovery Control)があるモデルもありQNAPでは時間を調整できたりします。
WDの場合はTLERと呼ばれてるみたいです。smartctlで下記コマンドなどで表示されれば設定値を確認する事が出来ます。
smartctl -l scterc /dev/sdb

この辺どう調整しようか悩み中だったりします。

今回はOS(ADM)のトラブルっぽいですが、原因の特定はなかなか難しそうですね…
HDDの処理が一時的にスタックしてたか、その原因となるソフトがあるのかもしれません。
ファイル名やディレクトリから何のソフトかは判るので、その情報が後で役立つかも…しれませんね。

書込番号：24373890

1点

KA-7300さん

クチコミ投稿数：574件

2021/10/02 00:23（1年以上前）

＞たく0220さん

容量大きくしたのは良いものの、入れ替えたHDDでRAID1を組む処理や、そこへのリストアに複数日かかるので、ひたすら待ち続けの日々です。処理中にあまり余計な処理をさせるのもと思う部分もあり折角お教えいただいたものをまだあまり試せていません。dmesgだと左側の日時の見方がわからないというか、起動時からのものになっていると思われるのでハングアップ前の情報を見るにはどうしたらよいかと、Linux入門者状態です。

セクタ読み出しソフトの紹介有難うございます。「ddで一部切り取って、そのファイルをhexdumpで見る事も出来るのですが」とのこと、Linuxは便利ですね。ただddで一部切り取りって出来るのでしょうか。最初から指定位置の部分だけ読み取ることは出来るのでしょうか。なんとなく最初から指定サイズを読み込み、tail（バイナリーに使えるのだろうか？）しか思いつかないといった、初歩的な部分で躓いています。まあLinuxを弄れる貴重な機会と思ってゆっくり見てみます。

＞　延長保証が適用できる機種の場合は必要に応じて課金しておくのが無難かと思います。

それですねぇ。ただ壊れるのは数年後なので悩ましいです。
たく0220さんのように知識があれば自分で切り分けることも可能なのでしょうけれども。

＞　まだ詳しく調べてませんが、SMRなHDDは10分ぐらいかかる場合があったような報告もあり…

単位を見間違えたかと、ちょっと目を疑いました。
そんなのでパリティ付きのRAID組んだら発狂しそうです。
幸いにも全てCMR（というか当時は無かった）で揃えていますので、騙し騙し※使っているところです。
QNAPでは時間を調整できるとのこと、今後のリプレースの際に参考にさせて頂きます。（でも私の場合、そこまで手が回らなさそうです）

※ADN上のファイルマネージャーではなく、外のPCからファイル操作を行っています。せっかくrcpを教えていただいたのですが、volum1からvolume2へコピーしている際に、結果をどこにリダイレクトしておけばよいか自信がなく。（NASのシステム領域を使ってしまってもよいのかどうか）

書込番号：24374213

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/10/03 18:17（1年以上前）

＞KA-7300さん

＞dmesgだと左側の日時の見方がわからないというか、起動時からのものになっていると思われるのでハングアップ前の情報を見るにはどうしたらよいかと、Linux入門者状態です。

dmesg --help
で
-T, --ctime show human-readable timestamp (may be inaccurate!)
があれば「dmesg -T」で読みやすくなります。

そうですね、説明抜けてましたねすみません。ある程度すると古いのから消えてしまいますので…
あと再起動時にリセットされてるかもしれません。最近見てなかったのでうっかりしてました。

＞ddで一部切り取りって出来るのでしょうか。

ddコマンドの使い方 - Qiita
https://qiita.com/hana_shin/items/042799a03f8d0b871ef7

参考情報としてリンクされてる下記の「主要オプション一覧」
コマンド:dd: UNIX/Linuxの部屋
http://x68000.q-e-d.net/~68user/unix/pickup?dd#prgmemo-dd-opts

bs=512 でブロックサイズを512バイトと指定すれば１ブロック＝１セクタと簡単に計算できる。
たとえば1080464セクタを確認するのであれば、少し手前からとるとしてskipを
skip=1080460
そこから10セクタ分の場合は
count=10
としてみると良いかと思います。

dd if=/dev/sdb of=out.dat bs=512 skip=1080460 count=10

出力先(of=)はlsコマンドなどを使って「/Volume1」や「/Volume2」のディレクトリを確認して
適当な共有フォルダとかにすれば確認しやすいかもしれません。
pwd
と入力して実行すると、今いるディレクトリ(cd: カレントディレクトリ)を知ることができます。

例えば
dd if=/dev/sdb of=/volume1/homes/taku/out_sdb.dat bs=512 skip=1080460 count=10
dd if=/dev/sdd of=/volume1/homes/taku/out_sdd.dat bs=512 skip=1080460 count=10

といった感じに出力して、Windowsで添付画像の様に比較ソフト使って確認する事も出来るかと思います。

＞QNAPでは時間を調整できるとのこと

出来るのだけど、最近のIronWolf(ST6000VN001)で確認したところ初期値がdisableになっていて
自分で考えて設定しなよっていうメーカーからの意思表示なのか、もう少し理解深めるまでは変更しないつもり。

＞volum1からvolume2へコピーしている際に、結果をどこにリダイレクトしておけばよいか自信がなく。（NASのシステム領域を使ってしまってもよいのかどうか）

心配な時は直感を頼りに止めておくのも手かと ^^;
コマンド等は何かあった時の今後の糧にはなるかなとは思います。
なので無理、無茶をしてまで試してほしい訳では無いので、その辺の気遣いはしなくて構わないですよ。

コマンドの練習とかはPCのスペックがほどほどであれば、仮想環境(VMwareなど)にUbuntuをインストールしてみるとか実環境に被害を与えなさそうな手段もあります。
仮想ハードディスクを設定すればmdadmも組めたりします。

最近はLinux関係の記事やブログも多く参考になるかと思いますので、余裕がある時にでも色々試してみると面白いかもしれません。

書込番号：24377330

1点

KA-7300さん

クチコミ投稿数：574件

2021/10/03 22:08（1年以上前）


RAID5の4台中2台が！	この状態なのに何故かリビルドが開始された	リビルドが100％と思いきや	訳が分かりません

＞たく0220さん

なにかもう手取り足取り有難うございます。
昔viは触っていた（emacsは完璧に忘れた）ので、入門的な記事を拾い読みしています。

しかし、現在被害拡大中で涙が出そうです。

写真1枚目：RAID5の4台中、2台がエラー　！

メインで使っている（一番容量の大きな）NASが信頼ならないとなると、受け皿（バックアップを収納できるストレージ）が多数必要になってしまいます。というわけで、昔使っていた（でもデータはバックアップしていない）RIAD5のマシンを起動したところ、上記エラーでした。ところが、わたわたと対応に悩んでいるうちに、何故かリビルドが始まりました（2枚目）。1枚目をよくよく見ると確かにSubunit1自体が認識されていません（Vportが空欄）。つまりあまりに古いので、ディスクが同一タイミングでは起動せず、1台だけ遅れて起動した為にrebuildとなってしまったようです（Subunit3はアウト）。

良かった良かった（でも何故rebuild）と思っていたのですが、rebuild100%のタイミングで再び画面を見たところ、なんと今度はinitializeが始まっています（写真3枚目）。ナニコレ状態です（現在進行形）。詳細を見ると、えー？という理解できない状態にあります（4枚目）。もう、initializeが終わったら何が出てくるのか、半ばあきらめの境地で結果待ち中です。
（慌てていたのでスクリーンショットではなく、手持ち撮影です。余裕なしのジェットコースター状態）

話を元に戻しddの件ですが、私の質問がわかりにくくすみません。ddでそのように指定した場合、例えば10TB目だけを読みたくても最初からひたすら読んで時間がかかるのと、その分の出力をどこかに保持しなくてはならないのだと思っています。なので読み出し開始位置を指定し、512Byteだけddで読み込むような指定方法は無いか（引数では見つけられず）というところでした。

# ASUSTORはNASの機能とは独立してLinuxを導入出来る（しかも別IPで、画面も本体からHDMI出力？）らしいので、ひと段落（してくれらば）試してみようと思います。

連鎖的に訳わからない状況に陥ってしまい、呪われているのかと思うこの頃です。
# 古いマシンを起動するのだから、OS起動前にHDD単独で何か処理しておけばよかったと後知恵で後悔しています。
　4台を別HDDにクローンしておけば、データをいくらかは救い出せた筈。
　このまま、見事RAID5で前の状態キッチリ復帰とかあり得るのだろうか。

書込番号：24377839

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/10/03 23:15（1年以上前）

＞KA-7300さん

vi出来れば大丈夫。emacs…使った事ないのですよね～ ^^;

＞写真1枚目：RAID5の4台中、2台がエラー　！

もう何がなんだか… 泣いていいですよ (T_T)

ハードウェアRAIDの場合はマニュアル見るしかないので…
rebuild、resync、recoveryと表現いろいろなので混乱しますね。

＞ddでそのように指定した場合、例えば10TB目だけを読みたくても最初からひたすら読んで時間がかかるのと、その分の出力をどこかに保持しなくてはならないのだと思っています。なので読み出し開始位置を指定し、512Byteだけddで読み込むような指定方法は無いか（引数では見つけられず）というところでした。

私の環境だと10TBないので、例えばDiskの先頭から5TiB目、そこから512Byte(1セクタ)だけ読み出すとしたら。
　5TiB = 5*2^40 [Byte]
セクタに直すと(-1いるかも？)
　5*2^40/512 = 10737418240 [sector]
となるので、timeコマンドつけて実測します。

time dd if=/dev/sda of=/volume1/homes/taku/out_5TiB.dat bs=512 skip=10737418240 count=1

root@NAS220J01:/# time dd if=/dev/sda of=/volume1/homes/taku/out_5TiB.dat bs=512 skip=10737418240 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.000220486 s, 2.3 MB/s

real 0m0.003s
user 0m0.000s
sys 0m0.000s

となり処理時間は0.003秒となります。
また「count=」はbs(ブロックサイズ)との積で計算された分のサイズを取得する事になります。(添付画像参照)
bs * count = 512[Byte] * 1 = 512[Byte]

こんな感じになります。

大変そうなので、安定したらゆっくり試してみてください。

書込番号：24377944

1点

KA-7300さん

クチコミ投稿数：574件

2021/10/04 00:36（1年以上前）

＞たく0220さん

その秒数からすると、文字通りskip（して最初を読まない）のですね。お教えいただきありがとうございます。
セクタ数の計算さえちゃんとできれば、かなり便利そうです。
ベストアンサーをこちらにも差し上げたいところですが（すでに質問を解決済みとしてしまっているので）すみません。

# エラー起こした前述のRAID5、rebuildはリビルドらしからぬ異様な速さでパーセンテージの進捗が上がってゆきましたが、initializeは地を這うようにゆっくりです。思わず、君、データ消しているよねと画面に向かって喋ってしまうほどヤバい感じです。
　rebuildでデータが復旧しそうな希望を持たせながら100%まで焦らしておいて、最後にinitializeを走らせてデータを切り刻んで見せるとは、映画も吃驚のどんでん返しで心臓に悪いです。いや、読めないと決まった訳ではありませんが。笑うにせよ泣くにせよ、（進捗率的に）明日には結果が出そうです。

AutoRebuildの指定がオフに出来るならば、今後はそうしておこうと決心しました。（リビルド前にHDDクローンですね）

書込番号：24378034

0点

KA-7300さん

クチコミ投稿数：574件

2021/10/04 17:45（1年以上前）

流石は3ware
（ASUSTORの話ではなく恐縮ですが）無事RAID5が修復されました。データ無事です。
Disk4台ともOKの扱いは納得いかない部分があるものの、古いマシンなのでここはデータを読み出せれば良しとします。
これを機に3ware製品に統一したいところですが、もう無いんですよね。

なお（本来の）ASUSTOR話としては、本日やっとサポートから回答がありました。（今日は質問してから何日目なんだろう。→11日）
以前ここにも記しましたが、ハングアップの対処方法について聞いているにもかかわらず、HDDを入れずに立ち上げてLEDの色を教えてくださいという、こちらの質問は全く無視した回答でした。ひょっとするとAIなのかも。

書込番号：24378959

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/10/04 21:36（1年以上前）

＞KA-7300さん

＞ベストアンサーをこちらにも差し上げたいところですが（すでに質問を解決済みとしてしまっているので）すみません。

この辺あまり気にしてないので大丈夫です ^^
質問するだけして放置な人が多いほうが気になりますね。マルチ+放置もみかけますし。

＞rebuildでデータが復旧しそうな希望を持たせながら100%まで焦らしておいて、最後にinitializeを走らせてデータを切り刻んで見せるとは、映画も吃驚のどんでん返しで心臓に悪いです。

この辺用語の使われ方によるんですよね。
initialize = resyncなのかも？ rebuildの作業的にはアレイの組直し、initializeでデータの再構築(verify、書き込み)なのかもしれません。

どっちにしろ終わるまでは心臓に悪いですね ^^;
データは無事だったみたいで良かったです。

＞これを機に3ware製品に統一したいところですが、もう無いんですよね。

LSI -> Avagoと買収されて3wareの血統はどこまで残っているか…

＞HDDを入れずに立ち上げてLEDの色を教えてくださいという、こちらの質問は全く無視した回答でした。ひょっとするとAIなのかも。
それで何か判るのかな… 言葉が通じないのかな？
保証切れると残念サポートしか受けれないのかも…

書込番号：24379352

1点

KA-7300さん

クチコミ投稿数：574件

2021/10/04 23:22（1年以上前）

＞たく0220さん

本当に冷や汗出ました。
さて、

＞initialize = resyncなのかも？ rebuildの作業的にはアレイの組直し、initializeでデータの再構築(verify、書き込み)なのかもしれません。

とのこと、なるほどと思いマニュアルを見にbroadcom.com※へ行ったら本日は見えなくなっていました。先月は見えたのですが。どうもftpのディレクトリからdocが無くなっているような（先月ダウンロードしたPDFは電源がなくなったと思われるRAID5機の中）。唯一手元にあったコマンドラインのマニュアルから強引に抜き出すとRapidRaidRecoveryの項に

＞Rapid Raid Recovery can accelerate the rebuild process, and it can accelerate initialize and verify tasks that might occur in response to an unclean system shutdown.

という文章がありましたので、おっしゃる（initialize=resync）通りのようです。

※なんでbroadcom.comに3wareのドキュメント一式があるのかはよく分かっていません。

サポートの件は、微妙にというか一部単語しか言葉が通じていない模様です。
RAIDアレイが結果的に無事だったので、心に少し余裕が出てきましたのでサポートの回答を察するに、（こちらの伝えた事は全て無視して）「NAS起動時に」ハングアップするトラブルシュートを行ってくれている気がします。HDD無しで起動するなら本体が原因ではなく、HDDに原因がある的な切り分け手順があるのかもしれません。今現在言えることは、ASUSTORのサポートは起票時に質問先を選択することができますが、そこを日本語以外にすべきようです。私は日本語サポートを選んでしまい現在の状況に至ります（回答者は名前からすると日本人ではありませんが、ちゃんと日本語で返信がありました。ただ話は前述の通り全く通じていない感があります）。

それにしても優先度をcritical（一番高い）にしていても11日間待ちって……、RAID1が壊れたりハングアップは大事ではないという見解なのかもしれませんが。お世話になりたくは無いですが、次は国内代理店のサポートが長いところを探してみます（でもテクニカルな質問は代理店から結局海外のサポートに行くような気がしています）。

書込番号：24379543

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/10/05 01:16（1年以上前）

＞KA-7300さん

＞※なんでbroadcom.comに3wareのドキュメント一式があるのかはよく分かっていません。

Broadcomも数年前Avagoに買収されて子会社化されたみたいですので、3wareの事業を継承したのかもしれませんね。

＞サポートの件は、微妙にというか一部単語しか言葉が通じていない模様です。

自分は英語をすっかり忘れてしまったので、
I am not very good at English, so I apologize in advance.
と前置きしてからじゃないとキツイ ^^;

やっぱり日本語だけだと、うまく伝わらないのですよね。
（日本の某メーカーは日本語でも伝わらなかったけど…）

＞お世話になりたくは無いですが、次は国内代理店のサポートが長いところを探してみます（でもテクニカルな質問は代理店から結局海外のサポートに行くような気がしています）。

サポートにはハードが壊れた時しか期待してなかったりして、ここ最近は運よくお世話になってないです ^^;
代理店もピンキリみたいで、担当してくれた方（運）次第なのかもしれません。
メーカーへエスカレーションしてくれるだけでも良いのですがね。
あと、各NASメーカーで延長保証は加入条件あるので購入時は確認すると良いですよ。

書込番号：24379659

1点

KA-7300さん

クチコミ投稿数：574件

2021/10/05 19:47（1年以上前）

状況報告となります。

ASUSTORのサポートの方から、適切な回答を得られました。今回は僅か1日での回答でしたので、質問方法に工夫（翻訳されやすいようにとても単純に記載）が必要なのかもしれません。ちなみに、電源長押しで良いそうです。ADMの機能によるヘルスレポートを送信したので結果待ちです。ただ今回はハングアップ後勝手に復旧しているので、エラー無しで終わりそうな気がします。ここの掲示板でお話しさせていただいたことをサポートの方と会話したくはあるのですが、話が通じるかどうか未知数です。

また何か情報がありましたら記載致します。

書込番号：24380804

0点

KA-7300さん

クチコミ投稿数：574件

2021/10/09 22:08（1年以上前）

状況報告（完了）です。

　ASUSTORのサポート、書き込み毎に回答が来るまで何日も待たなければならなかったのですが、最終的には当日中に回答がもう一度来るまでになりました。一体今までの放置っぷりは何だったのかというところですが、初回は状況をキッチリ書いた＝文章が長いのが敗因かもしれません。最初の問い合わせから1ヵ月ほどして、ようやく最初の書き込みの内容（RAID1内のディスク両方ともがメディアエラー発生している）が担当の方に伝わりました。結論としてはデータを別なところへバックアップとのことで、そこはまあ予想の範囲内の回答です。データに損傷がないか迄を確認したかったのですが、話が通じないので泣く泣く断念しています（技術的な裏付けをもってきちんとお付き合い頂いた、たく0220さんには大変感謝しております）。

　なお、ASUSOTRは古い機種だからサポートしないということは無いようで、その点は良かったと思いました。

　RAIDエラーを期に、更に大容量のHDDに替えましたがbakkup/restore時間が長いです（55時間とか）。もっともこれは1GbpsのLANしか使っていないので、ネットワークを含めた強化を考えなければというところです。（AS-604TはちゃんとLANポートが2つあるので、所要時間短縮は出来そうです。現在は1ポートのみ利用）

　なお、別件（ASUSTORではなく別機のRAID5崩壊）についてはデータが腐っていることが判明して、思わず寝込んでしまいました。大事なデータはRAIDアレイ相互にバックアップを取っている部分があるのですが、AutoRebuildで復旧後にその領域をバイナリでASUSTOR内のファイルとコンペアすると、化けてる化けてる……。ファイルの一覧はキッチリ見えるし、windowsのファイルエクスプローラーからはタイムスタンプもサイズも正常でありながら、中身は所々虫食い（テキストであれば文字化け）のファイルが多々。RAID5でRebuild成功の表示でしたが、実態はそうでなかったようです。これ、RAID6にすれば防げるのか、或いは6でも同様に治ったようでいて化ける話となるのか、とても悩みます。

　HDDが（搭載メモリーと比較して）大容量化してきた現在、速度を求めないのであればRAIDを使わなくてもよいのかなぁと思えてきました。ただバックアップの間隔に対し、RAID1であれば直前までのデータは残っていることを考えるとやはりRAID1が妥当かと、でもそもそも今回の件はRAID1の両ドライブで障害発生ということを思うと、考えがぐるぐる回って纏まりません。

　雑記的に長くなって恐縮です。windowsなのでファイルのバイナリ比較には（信頼性の面で）OS標準のコマンドである「fc /b」を用いています。ファイル単位でしか指定できないのでNAS間の比較にはお手製バッチ（ファイル名中の空白非対応）で「fc /b」を実施していますが、fcより便利なコマンド或いはMS製のツール（ディレクトリ以下を含めて比較できるもの）をご存じの方がいらっしゃればお教えいただけると幸いです。※ROBOCOPYは信頼しているのですが、今回のようにタイムスタンプは同じでも中身が壊れている場合にはチェックに使えません。Linux系の場合は、たく0220さんにお教えいただいたrcpコマンドにchecksumオプションがあるようなので（本当の意味で比較になっているのか、漏れを生じないのかが疑問であるものの）羨ましいです。

書込番号：24387598

0点

たく0220さん

クチコミ投稿数：3225件Goodアンサー獲得：567件

2021/10/10 00:12（1年以上前）

＞KA-7300さん

＞状況報告（完了）です。

お疲れさまでした。なかなか意思疎通に難があると大変ですよね。
QNAPとかでも日本語わかるスタッフが少ないとかで時間かかった方もいましたね。
短文で箇条書き、ついでに英語でも併記したほうが良いのかもしれません。

＞なお、ASUSOTRは古い機種だからサポートしないということは無いようで、その点は良かったと思いました。

この点は凄いですね。(なんか上からで失礼なんだけど…)見直しました。
あと、一段落してからと思ってたのですが

ADM 4.0 Betaが登場 | ASUSTOR Inc.
https://www.asustor.com/ja/news/news_detail?id=26073

＞*ADM 4.0非対応機種：AS-2 / AS-3 / AS-6

AS-6更新出来ないみたいなので、EOL近いかもしれませんので気を付けてください。

＞ネットワークを含めた強化を考えなければというところです。

LAGはスイッチとか購入する事考えると、2.5G/5Gとか対応のスイッチが落ち着いてからかな私は…

＞なお、別件（ASUSTORではなく別機のRAID5崩壊）についてはデータが腐っていることが判明して

２台degradedになったので、残念ながらその影響が出てしまったみたいですね。
個人的には、mdadmのRAID6だとしてもそれらが防げるかは疑問に感じています。
パリティでデータが破損している事は判ります、ではどのディスクのデータが正しいのか？は判断出来ないと思います。
最近はBtrfsやZFS(RAIDZ)などその点を重視しているファイルシステムもあります。ただ速度とはトレードオフになるのでそれなりのマシンスペックが求められてしまいます。

＞windowsなのでファイルのバイナリ比較には（信頼性の面で）OS標準のコマンドである「fc /b」を用いています。

データの比較はMD5やSHA256でのハッシュ値でするのが良いかと思うのですが、
fcコマンドは１行ごとのテキストベースなので、バイナリの比較には向かないかなと思ったりします。
なにか便利なツールないか探してみますね。

書込番号：24387821

0点

KA-7300さん

クチコミ投稿数：574件

2021/10/11 00:45（1年以上前）

＞たく0220さん

＞AS-6更新出来ないみたいなので、EOL近いかもしれませんので気を付けてください。

これ全く知りませんでした。ご案内ありがとうございます。
# （私の使い方としては）新機能はいらないので、NASとして安定してくれさえすれば言う事ありません。

ツールは、何かのついでで見つかったらお教えいただけると幸いです。
なおそこそこいいツールは発見（というか再認識）しました。

　たく0220さんもご認識のようにwinodowsのfcは、unixでいうdiffの超劣化版です。ただ、/bオプションを指定するとバイナリで比較してくれるので、完全な比較の場合は重宝します。欠点はサブディレクトリを含め再帰的に実行はしてくれないので、ファイルをいちいち指定する必要があり面倒（実用的でない）です。

　GUIなので眼中になかったのですが、MS純正のWinDiffというユーティリティは上記要望を（GUIという事以外は）全て満たしてくれました。結果をファイルに出力できるので、そこが非常に役立っています（現在これで比較中）。タイムスタンプ同じだけど中身違うとか、サブディレクトリ内のファイルも含め、しっかり報告してくれます。惜しむらくはwindows8からサポート外となっているようで、win7時代のもの（SDK or サポートツール）からしか入手できません。つまりunicocdeには対応していないです。ただ、結果をファイルに出力させると、コードはそのまま出力されているらしく、ファイル名がunicodeでも（エディタでは）きちんと読めます。使い勝手的には、これのCUI版が欲しいところです。#こんなに便利なのに、なんでMSはサポート打ち切ったのだろう。

書込番号：24389830

0点

スレッドの先頭へ

ナイスクチコミ0

返信5

お気に入りに追加

特定ユーザのみアクセス可能なフォルダが作れない

2021/01/22 12:39（1年以上前）

NAS(ネットワークHDD) > ASUSTOR

taotao74さん

クチコミ投稿数：3件

スレッドの最後へ

AS1004Tを使用しています。
やりたいこととしては特定のユーザーのみアクセスできる隠しフォルダの作成
やったこととしては[test」という名前の共有フォルダを作成。ネットワークから見えませんに設定し、アクセス権はadminと特定ユーザ「test」に書き込みを許可し、他は拒否
特定ユーザ「test」はすべての共有フォルダへのアクセス権を書き込み許可にし、グループはusersとadministratorsに所属（usesグループは[test」フォルダへのアクセス権設定なし）
この状態でwindows10のファイル名を指定して実行で\\(nasIPアドレス）\test　とすると、IDとパスワードの入力画面が出ますが、
「test」ユーザのIDとパスワードを入れても、アクセスできませんと表示される。（管理者IDで試しても同様）
ネットで検索してwindows10の資格情報の削除も試しましたが症状変わらず。
ネットワークから見える状態にしても同じ、共有フォルダにguest権限を付与すれば当然だれからでもアクセス可能、消すと権限付与したはずのユーザーからもアクセス不可
それほど複雑なことがやりたいわけではないので何かシンプルな見落としだと思うのですが・・

書込番号：23920654

0点

Excelさん

クチコミ投稿数：23300件Goodアンサー獲得：2843件

2021/01/22 14:28（1年以上前）

うん、ふつーに考えると、「ユーザー名か、パスワードが違っている」としか思えないっす。(;^_^A

まずはっすね、いきなり「隠しフォルダー」とかにしないで、「最も基本的な設定」にしてやってみるっす。
それでどうなるっすか。(・・?

>アクセス権を書き込み許可にし

これって、「読み書き許可」ってことっすよね？
念のためっすけど、「読み込みのみ」にしてみるとか、

「なにをどーやってもダメ・・・(:_;)」
ってことならばっすね、「なにかにハマってしまった」ってことなんで、「リセットボタン初期化」しかないような気が・・・。

書込番号：23920829

0点

taotao74さん

クチコミ投稿数：3件

2021/01/22 14:57（1年以上前）

返信ありがとうございます。
隠しフォルダにしない設定は試してみました。
またユーザ名パスワードは例えば管理者のもの（管理ツールにログインできる）で試しても同じなんですよね。
リセット初期化はちょっと厳しい状況なのでまだ試していないですが…

書込番号：23920851

0点

LsLoverさん

クチコミ投稿数：13227件Goodアンサー獲得：2028件

2021/01/22 22:54（1年以上前）

『この状態でwindows10のファイル名を指定して実行で\\(nasIPアドレス）\test　とすると、IDとパスワードの入力画面が出ますが、「test」ユーザのIDとパスワードを入れても、アクセスできませんと表示される。（管理者IDで試しても同様）』

Guestアカウント（パスワードなし）での共有ファイルアクセスはWindows 10 Ver2004からセキュリティポリシーの強化でデフォルトでは排除されるようになりました。

以下を参考に対応してください。

正しいユーザー名とパスワード入力してもNASの共有フォルダにアクセスできません
https://unistar.jp/faq/a6/

書込番号：23921617

0点

taotao74さん

クチコミ投稿数：3件

2021/01/23 11:07（1年以上前）

＞LsLoverさん
そのページにはたどり着いていたのですが、書いてある意味がよく理解できずPCの資格情報を消しても改善しなかったので無視していました。
今回改めてNASのゲストアカウントを消してPCを再起動したところ、アクセスできなかったフォルダに管理者アカウントでアクセスできるようになりました。
「windowsは同時に一つのアカウントしか承認されません。」というところがおそらく原因で、すでにPCからNASに対し別のアカウント（guest)でアクセスしていたということのようです。（NASフォルダをネットワークドライブに設定していたので）
NASにアクセスするときに権限のあるユーザ名とパスワードを入れればそれでOKのはずと思っていました。
ありがとうございました。

書込番号：23922281

0点

LsLoverさん

クチコミ投稿数：13227件Goodアンサー獲得：2028件

2021/01/23 12:41（1年以上前）

『今回改めてNASのゲストアカウントを消してPCを再起動したところ、アクセスできなかったフォルダに管理者アカウントでアクセスできるようになりました。
　「windowsは同時に一つのアカウントしか承認されません。」というところがおそらく原因で、すでにPCからNASに対し別のアカウント（guest)でアクセスしていたということのようです。（NASフォルダをネットワークドライブに設定していたので）
　NASにアクセスするときに権限のあるユーザ名とパスワードを入れればそれでOKのはずと思っていました。』

今回の障害（不具合）は、既に投稿させて頂きましたが、Guestアカウント（パスワードなし）での共有ファイルアクセスはWindows 10 Ver2004からセキュリティポリシーの強化でデフォルトでは排除されるようになりました。
このため、「今回改めてNASのゲストアカウントを消してPCを再起動した」ことで、Windows PCからAS1004Tのsambaサーバにアクセスできるようになったと思います。

AS1004Tのユーザーガイドによれば、ローカルユーザー管理では追加/編集/削除ができるようです。。
すべての共有フォルダのアクセス権で、guestを「レ」DAに設定すれば、ローカルユーザー管理でguestユーザを削除する必要はないかと思います。

ユーザーガイド
アクセスコントロール（P49）
ローカルユーザー
ここで、システムのローカルユーザーを管理（追加、編集または削除）したり、共有フォルダにそのアクセス権を割り当てるこ
とができます。
ローカルユーザーについて
初期化後、システムは「admin」と「guest」の各ユーザーアカウントを自動的に作成します。
共有フォルダ情報（P53）
フォルダ - アクセス権: 共有フォルダのアクセス権は、検証されるアクセス権の最初のレベルです。ここで、それらのア
クセス権を編集できます。（P54）
guest　Deny Access　「レ」DA
https://downloadgb.asustor.com/download/docs/User_Guide/ADM30/ASUSTOR_NAS_USER_GUIDE_JPN_3.0.0.0918.pdf

「windowsは同時に一つのアカウントしか承認されません。」については、Windowsの仕様のようです。

書込番号：23922471

0点

スレッドの先頭へ

ナイスクチコミ44

返信80

お気に入りに追加

ＮＡＳのディスク交換方法

2019/10/27 10:15（1年以上前）

ASUSTORなんでも掲示板 クチコミ掲示板

ASUSTORなんでも掲示板 のクチコミ掲示板

新着ピックアップリスト

ASUSTORなんでも掲示板クチコミ掲示板

ASUSTORなんでも掲示板のクチコミ掲示板