ASUSTORすべて クチコミ掲示板

パソコン工房で処分特価33480円

[ポチ太郎3世]

【ショップ名】
パソコン工房

【価格】
33480円で処分特価でした
店舗によってやってるとことやってないとこがあるようです。

【確認日時】

【その他・コメント】

書込番号：24978774

NASのLANポート２つの使い方

[sumapan yyyy]

初歩的な質問なのですが、どなたか教えていただけますでしょうか？

NIMBUSTOR 2 AS5202T　はLANポート2.5Gが２つ付いていますが、下記の使い方だと２つついていた方が速度が早くなりますか？

●家庭用NASで２〜３代のパソコンから使用
●すべてのPC、LAN接続は2.5G環境で使用中。
●RAID1　ミラーリングでHDD 8Tb×2で運用予定。

上記の使い方で、2.5GLANポートが１つのDRIVESTOR 2 AS1102Tよりも書き込み、読み込み速度は早くなるものでしょうか？

使い方などご指南いただけたらとありがたいです。

書込番号：24648304

[flexible]

＞sumapan yyyyさん


一般的に、ＬＡＮが2つあるのは、管理用と別けたり、異なるセグメントでアクセスするようにするためです。

例えば会社内でネットワークが192.168.0.1と192.168.1.1と部署で分かれていたり
光回線を2回線で分けていたり、目的用途で分かれていた場合にこういうネットワークである

こういう環境にＮＡＳを置く場合にＮＡＳに、192.168.0.200と192.168.1.200で、ＩＰを振っていれば
アクセスしやすくなります。
別の解決方法として、ルーターなどの上位ネットワークに異なるセグメントを相互にいけるよう設定を書くのも手です。


また普段は192.168.0.200でメインＮＡＳを使い、192.168.1.201でバックアップ用のNASを動かしていて、
192.168.1.200のＮＡＳをミラーリングでコピーするときとかですね。
異なるネットワークにあるので、他のネットワークに圧迫されないというメリットがあります。


あとＬＡＮ2-3個といった複数LANをまとめる事をLinuxではボンディング、Windowsではチーミングというのですが
これを使って高速化する事もできます。

以下はSynologyの場合ですが、ＮＡＳ側などが対応していればいけると思います。(あとクライアント側のＰＣでチーミングができるＬＡＮのＮＩＣかどうかも鍵です)

https://personal-studio9.com/synology-smb-multichannel/

書込番号：24648419

[MIF]

NASに複数LANポートがあるのはリンクアグリゲーションのためだよ。
複数の機器からNASに大量のデータアクセスが同時に発生すると通信帯域が足りずに速度低下するので
論理リンクで2つの帯域を1つの帯域として扱う技術。

例えば高速道路で車線を増設できない箇所でもう一本別ルート作って右ルート左ルートってなってる箇所のイメージ。

書込番号：24648456

[おかめ@桓武平氏]

＞sumapan yyyyさん

>> 2.5GLANポートが１つのDRIVESTOR 2 AS1102Tよりも書き込み、読み込み速度は早くなるものでしょうか？

ポートトランキング(リンクアグリゲーション)を使い、
帯域を確保すると、
同時アクセス時に速度低下が軽減するかと思います。

なお、ポートトランキングさせたい場合、
2.5GbEで802.1ad対応のL2スイッチが必須になります。

まあ、LAN内を2.5GbEで構成しないと、
そこの区間だけ速いだけかと思います。

書込番号：24648566

[たく0220]

＞sumapan yyyyさん

他の方々の補足程度ですが

参考: TS-253Dのベンチマーク − 2.5GbE / 10GbE / SSDで性能はどこまでアップする?
https://www.forcemedia.co.jp/blog/ts-253d-benchmark

他社のNASの参考情報で申し訳ないのですが、HDD2台でのRAID1 + 10GbE接続でも221.0 MiB/s程度の処理能力しか出せてないので
NAS側をリンクアグリゲーションで負荷を分散させたとしても、期待する程の効果を得られるかは状況次第(複数のPCで何をするか)かと思います。
SMBマルチチャンネルに対応させても200MB/sで頭打ちしてしまうのではないでしょうか？(ASUSTORがSMBマルチに対応してるかは確認してません。)

リンクアグリゲーションやネットワークを分離させる使い方にしても、最終的にストレージがボトルネックとなりますので
その辺も考慮して製品を選んだほうが無難かと思います。

書込番号：24650377

[sumapan yyyy]

＞たく0220さん
＞おかめ@桓武平氏さん
＞MIFさん
＞flexibleさん

皆さん、丁寧に解説していただきありがとうございます。

とても参考になりました。

当方の使い方では、2.5GLANポートが１つのDRIVESTOR 2 AS1102Tで十分そうなのでそちらにいたします。

ありがとうございました。

書込番号：24651789

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

[KA-7300]

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

[たく0220]

＞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

[KA-7300]

＞たく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

[たく0220]

＞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

[KA-7300]

＞たく0220さん

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

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

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

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

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


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

書込番号：24360413

[たく0220]

＞KA-7300さん

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

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

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

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

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

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

書込番号：24360503

[KA-7300]

＞たく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

[たく0220]

＞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

[KA-7300]

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

[たく0220]

＞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

[たく0220]

＞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

[KA-7300]

＞たく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

[たく0220]

＞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

[たく0220]

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

一応、他に波及してないかの確認。
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

[たく0220]

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

×:/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

[KA-7300]

＞たく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

[たく0220]

＞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

[KA-7300]

＞たく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

[KA-7300]

＞たく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

[たく0220]

＞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

[KA-7300]

＞たく0220さん

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

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

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

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

書込番号：24366865

ずっとHDDアクセスしてる？

[コーtin]

6月頃に購入して、昨日組みました。
6TB×4台でRAID6で初期設定しました。
まだ何も保存してないのですが、ひと晩たってもずっと4台のHDDアクセスランプがチカチカしてゴリゴリ書き込む音がしています。
LANからもアクセスはできており、対応アプリADMも正常に見えてます。
特に初期化中・・・などの表記はされていないのに、なぜずっとHDDアクセスしているのか不可解です。
同様の症状の方はいらっしゃいませんか？

書込番号：24355853

[脱落王]

RAID6の構築時間は1TBあたり7時間位は見たほうがいいので、
最大2日かかります。

構築中でも使う事は出来ますが速度は落ちるし、不完全な状態での使用はあまりお勧めしません。

書込番号：24355867

[KA-7300]

初期化中・・・などの表記はされていないとのこと、ASUSTORのStorageManagerではどんな表示でしょうか。
具体的には左側でvolumeを選んで、右側で当該volumeの下向き矢印を押して詳細を表示した状態で。
ここに％が表示されていた気がします。

書込番号：24356333

REGZAからDTCP-IPでムーブ出来ますか？

[wild23]

REGZAでUSB-HDDに録画したデータを、DTCP-IPでムーブ出来ますか？

書込番号：24204330

[Excel]

その「REGZA」の型番は？

んで、できたとしても、NASからは、「2度とムーブできない」最後の墓場となるってことは、わかったうえってことでいいっすか。(・・?

さらにムーブするには、「バッファロー」「アイ・オー・データ」とかの、「国産NAS」でないとできないっすよ。

書込番号：24204429

AS1004T v2で2つ目のボリューム

[はたもん]

10TBのHDDを4本挿してRAID5を利用予定です。
現在16TB分のRAID5ボリュームを作成できましたが、残りの14TB分を2つ目のボリュームにする方法がわかりません。
どのような手順でおこなえばいいのでしょうか？

書込番号：23982109

[LsLover]

『10TBのHDDを4本挿してRAID5を利用予定です。
　現在16TB分のRAID5ボリュームを作成できましたが、残りの14TB分を2つ目のボリュームにする方法がわかりません。』

RAID5容量：10TB/本×4本×(4-1)/4＝30TB
30TB−16TB＝14TBを別ボリュームにはできません。

書込番号：23984412

[LsLover]

何故、ボリュームを別にする必要があるのでしょうか?

10TB×2本、10TB×2本の構成では、以下の容量となります。

1.RAID0容量：20TB×2［RAI0：HDD0とHDD1、RAID0：HDD2とHDD3］
2.RAID1容量：10TB×2［RAI1：HDD0とHDD1、RAID1：HDD2とHDD3］
3.RAID0容量：10TB×2　20TB［RAI0：HDD0とHDD1］、RAID1容量：10TB［HDD2とHDD3］
　ディスク容量：20TB＋10TB＝30TB

書込番号：23984841

[はたもん]

はい、このNASのCPU制限でRAID容量のMAXが16TBになってしまうんです。
RAID1にするほど重要なデータを扱うわけでもありませんし、9.1Tという小分けは使いづらいですし、RAID0にするとどちらかの玉が壊れると道連れになるので。
16TBでも当面は構わないのですが10TBの玉4個で16TBだけしか使えないのなら6TBの玉でもよかったので、なんとか空き容量をもう一個RAID5に出来ないかなという状況でした。

書込番号：23985046

[LsLover]

『このNASのCPU制限でRAID容量のMAXが16TBになってしまうんです。』

約4GB（セクター数＝2^32[LBA]）*4KB/セクタ＝16TB

『16TBでも当面は構わないのですが10TBの玉4個で16TBだけしか使えないのなら6TBの玉でもよかったので、なんとか空き容量をもう一個RAID5に出来ないかなという状況でした。』

RAID5では、未使用領域を利用できません。

RAID1でしたら、合計20TB利用は可能です。

RAID1容量：10TB×2＝20TB［RAID1：HDD0とHDD1、RAID1：HDD2とHDD3］

書込番号：23985415

[ねむーーん]

このNASのCPU制限ってのが気になりますがNASのOSをUpDateしたら
改善されるってのはないですかね。

また、
RAID5を10TBのHDDを3本で構成して、
20TBのところを16TBで利用。
残り1本は10TBの単体で利用。
ってのもあると思います。

書込番号：23985452

[はたもん]

実際には違うかもしれませんが、16TBの壁というのはCPUのアドレスバス数の関係で**MByte以上認識できないって言う昔の話と似た話と認識しています。
なので、上位の3204や4004の仕様を比べると1004だけ最大シングルボリュームサイズというのがあるんですよね。
そういう理由から16と14に分ければRAID5でも切り分けて使えると勝手に考えたのですが、駄目だったみたいですね。

書込番号：23985542

[LsLover]

『このNASのCPU制限ってのが気になりますがNASのOSをUpDateしたら
　改善されるってのはないですかね。』

「CPUアーキテクチャ：ARM 32-bit」のようですので、改善されることはないです。

ハードウェア仕様
CPU モデル Marvell ARMADA-385
CPUアーキテクチャ ARM 32-bit
https://www.asustor.com/ja/product/spec?p_id=43

書込番号：23985554

[LsLover]

『上位の3204や4004の仕様を比べると1004だけ最大シングルボリュームサイズというのがあるんですよね。』

AS3204T、AS4004TはCPUアーキテクチャが64bitサポートとなります。

AS3204T
ハードウェア仕様
CPU モデル Intel Celeron
CPUアーキテクチャ x64 64-bit
https://www.asustor.com/product/spec?p_id=47

AS4004T
ハードウェア仕様
CPUモデル マーベルARMADA-7020
CPUアーキテクチャ ARM6464ビット
https://www.asustor.com/product/spec?p_id=57

書込番号：23985586