「スパン（結合）ボリュームにエラー」──SAS×HBA環境で出る警告の意味と、データを失わない最短ルート

ストレージを組んでいると、突然「何かのエラー」が出て心臓が止まりそうになる瞬間があります。特に Windows の「スパン（spanned）」や「ダイナミックディスク」で複数ドライブを1つのボリュームにしている場合、その警告は“設定の不具合”ではなく“ディスクの死に際”を示していることが珍しくありません。
この記事では、SASドライブをHBAカードに繋いだ構成で起きがちな「スパン構成のエラー警告」が何を意味するのか、どこを確認し、何を優先して動けば被害を最小化できるのかを、初心者でも迷わない順番でまとめます。

• 「スパン（結合）ボリュームにエラー」──SAS×HBA環境で出る警告の意味と、データを失わない最短ルート
  • まず結論：スパン構成で警告が出たら「片方が壊れかけ」の前提で動く
  • 「どこに出ているエラー？」を探すより、見るべき場所はこの2つ
    • 1) S.M.A.R.T（SMART）情報：増えるエラーは危険信号
    • 2) Windows側ログ：イベントビューアで「ディスク系」を見る
  • 今すぐやるべき手順：優先順位を間違えない
    • 手順1：重要データを別媒体へコピー（バックアップ）
    • 手順2：不調ドライブを特定（SMART＋ログ）
    • 手順3：構成を作り直す（ここで初めて設計の話）
  • なぜ「ダイナミックディスク／スパンはやめろ」と言われるのか
  • 代替案：Windowsでやるなら最低ラインは「Storage Spaces」
  • 本気でデータ保全するなら：TrueNAS/ZFS（あるいはZFS系）を検討
  • RAID0やスパンを“やるなら”守るべき最低限のルール
  • まとめ：エラーの正体探しより、データ退避が勝つ

まず結論：スパン構成で警告が出たら「片方が壊れかけ」の前提で動く

スパン（結合）ボリュームは、2台以上の物理ディスクを1つの大きなドライブとして見せる仕組みです。容量を足して使えるのがメリットですが、致命的な弱点があります。

• どれか1台でも故障・切断・読み書き不能になると、ボリューム全体が読めなくなる可能性が高い

• 冗長性がない（実質的に「危険な一本化」）

• 不調の兆候が出た時点で「保全手段がコピーしかない」ことが多い

つまり、スパンでエラーが出たら「原因究明」より先に「退避（バックアップ／コピー）」を最優先にするのが正解です。解析している間に不良セクタが増え、最終的にマウント不能になるケースは現場でよく起きます。

「どこに出ているエラー？」を探すより、見るべき場所はこの2つ

質問でありがちなのが「このエラーはどこで詳細を見られる？」ですが、スパン構成では“詳細ログを追う”より“ディスク状態を確定する”ほうが勝ちます。確認ポイントは次の2系統です。

1) S.M.A.R.T（SMART）情報：増えるエラーは危険信号

多くの場合、警告の正体はSMARTが検知した劣化です。特に次の項目は要注意です。

• Reallocated Sectors（代替処理済みセクタ）

• Current Pending Sector（代替待ちセクタ）

• Uncorrectable Sector Count（訂正不能）

• UDMA CRC Error Count（ケーブル/接続品質由来もあり得る）

• Read Error Rate / Seek Error Rate（メーカー依存で解釈注意だが急増は警戒）

Windows環境なら CrystalDiskInfo のようなツールで確認できます。SASの場合はツールによってSMARTの見え方が違うこともあるため、可能ならHBAの管理ツールや smartctl（smartmontools）側でも確認すると確度が上がります。

2) Windows側ログ：イベントビューアで「ディスク系」を見る

退避が済んだ後、原因を切り分けたいなら Windows のイベントビューアを見ます。

• 「Windowsログ」→「システム」

• ソース：Disk / storahci / iaStor / stornvme /（SASならコントローラ系）など

• 典型的には「不良ブロック」「I/Oエラー」「タイムアウト」「リセット」系のイベント

ここで「どのディスク番号（Disk 1 など）」が悪いか当たりが付くことがありますが、スパン構成では“どれが悪いか分かってもボリューム全体が危険”という事実は変わりません。

今すぐやるべき手順：優先順位を間違えない

スパンで警告が出たときに、最悪の行動は「ディスクの管理でいじる」「パーティションを触る」「再同期的な操作をする」です。データ破壊の引き金になります。動く順番はこれです。

手順1：重要データを別媒体へコピー（バックアップ）

• 可能なら別の物理ストレージ（外付けHDD、別PC、NAS）に退避

• 容量が足りないなら、まず“失いたくない順”に退避

• コピー中にエラーが出るなら、破損ファイルが混じり始めている可能性が高い

スパンの場合「片方が死んでも片方は残る」という発想は通用しません。一本の論理ドライブとして崩れると、ファイルシステムごと読めなくなることがあります。

手順2：不調ドライブを特定（SMART＋ログ）

退避できたら、SMARTとログで「どちらが怪しいか」を当てます。
ただし“怪しい方だけ交換して延命”は、スパンだとおすすめしにくいです。片方を新品にしてももう片方が古い・小さい・同世代劣化などだと、すぐ次が来て同じ地獄になります。

手順3：構成を作り直す（ここで初めて設計の話）

データの安全性と運用のしやすさを考えると、スパン／ダイナミックディスクは「学習目的以外では卒業」が現実的です。

なぜ「ダイナミックディスク／スパンはやめろ」と言われるのか

強い言葉で否定されがちな理由はシンプルです。

• 障害時の復旧難度が上がる（一般的な復旧フローが通りにくい）

• “容量を増やせる”以外のメリットが薄い

• 片方の異常が全体障害になりやすい

• 運用の積み重ね（長期保全）に向かない

特に中古ドライブを1本ずつ買い足す状況だと、世代も状態もバラつきやすく、スパンの弱点が最短で顕在化します。

代替案：Windowsでやるなら最低ラインは「Storage Spaces」

Windowsで大容量を扱うなら、最低限の選択肢として「記憶域スペース（Storage Spaces）」が現実的です。スパンよりは運用しやすく、冗長構成も取りやすいです。

• ミラー（2-way/3-way）：耐障害性重視

• パリティ：容量効率重視（ただし書き込み性能に注意）

さらに、運用ポリシー次第では ReFS を組み合わせる話も出ますが、まずは「冗長＋監視＋バックアップ」が揃ってから検討するのが安全です。

本気でデータ保全するなら：TrueNAS/ZFS（あるいはZFS系）を検討

長期的に“データを守る”観点では、ZFSの思想（整合性チェックや自己修復、スクラブ運用など）が強力です。NAS用途ならTrueNASが候補に上がりやすく、RAIDZ2のように2台同時故障まで耐える設計も選べます。

ただし、ZFSは「メモリ」「設計」「運用ルール」の理解が必要です。導入するときは、最初から完璧を狙うより次の順で成熟させるのが失敗しにくいです。

1. まず冗長化（ミラーやRAIDZ）

2. 定期スクラブ

3. SMART監視と通知

4. 3-2-1バックアップ（別筐体・別媒体・可能ならオフサイト）

RAID0やスパンを“やるなら”守るべき最低限のルール

学習や一時領域として割り切るなら、スパンやRAID0を使うこと自体は否定しません。ただし、最低限これだけは守ってください。

• 失って困るデータは絶対に置かない

• 重要データは常に別にコピーがある状態にする

• 異常が出たら原因調査より先に退避

• 「直ったように見える」は一番危険（再発時に全損しやすい）

まとめ：エラーの正体探しより、データ退避が勝つ

スパンされたSASドライブでエラーが出たとき、やるべきことは明確です。

• まず退避（バックアップ／コピー）

• 次にSMARTとログで不調を確定

• 最後にスパン卒業の設計へ移行（Storage Spaces、ZFSなど）

「データが消えても致命傷ではない」と思っていても、一度“全損の体験”をすると、復旧に使う時間とストレスのほうが高くつくことが多いです。今回の警告は、より安全な構成に移るための合図だと思って、最短でデータを守る動きに切り替えるのが一番得です。