※本ページにはプロモーション(広告)が含まれています

【2026年最新版】TrueNAS ScaleでプールがDegradedになる・ドライブエラーが出る原因と対処法【完全ガイド】

TrueNAS ScaleのダッシュボードにDegradedの赤いアラート、zpoolのステータスエラー、S.M.A.R.T.エラーの通知――これらはストレージプールが危険な状態にあることを示すシグナルです。見て見ぬふりをすることが最も危険な行為です。

TrueNAS ScaleはZFS（Zettabyte File System）をベースにしており、Degradedステータスはデータが危険にさらされているが、まだ読み書きできる状態を意味します。この状態を放置すると、もう1本ドライブが壊れた時点でデータが完全に失われます（RAIDZの場合）。

この記事では、TrueNAS ScaleのプールがDegradedになる原因から、S.M.A.R.T.テストの実施、ドライブ交換（resilver）の手順、zpool scrub/statusコマンドの使い方まで、データを守るための完全ガイドを解説します。

TrueNAS ScaleのDegradedとは何か

TrueNAS ScaleのZFSにおけるプールステータスは以下のように分類されます。

ステータス	意味	緊急度
ONLINE	正常稼働中	なし
DEGRADED	1本以上のドライブで問題発生。データアクセスは可能だがRedundancy低下	高（早急に対処が必要）
FAULTED	プール全体へのアクセス不可（データ喪失の可能性）	最高（即時対応必要）
UNAVAIL	プールが利用不可	最高
REMOVED	ドライブが物理的に取り外された	高

DEGRADEDの状態でも通常のデータアクセスは継続できますが、RAIDZの場合は冗長性が低下または喪失しているため、追加のドライブ障害でデータが失われます。

Degradedになる主な原因

原因1: HDDまたはSSDの物理的な障害

最も多い原因。ドライブのS.M.A.R.T.エラー（Read Error Rate、Reallocated Sectors Count、Pending Sectorsなど）が増加し、ZFSがドライブをFAULTEDと判定してプールがDEGRADEDになります。

原因2: ドライブのタイムアウト（応答遅延）

ドライブが壊れているわけではなく、応答が遅くなってZFSのタイムアウト閾値を超えた場合もDEGRADEDになることがあります。ケーブル不良・電源不足・ファームウェアのバグが原因です。

原因3: SATAケーブルまたはHBAカードの問題

ドライブ自体ではなく、接続ケーブルやHBA（Host Bus Adapter）カードに問題がある場合、複数のドライブが同時にエラーを出すことがあります。

原因4: ECC RAMの問題（メモリエラー）

ZFSはメモリ上でデータの整合性チェックを行うため、RAMのエラーがデータ破損に直結します。Non-ECCメモリを使用している場合、メモリエラーがストレージエラーとして現れることがあります。

原因5: キャッシュドライブ（SLOG/L2ARC）の障害

ZFSのwriteキャッシュ（SLOG）またはreadキャッシュ（L2ARC）として使用しているSSDが故障した場合、プールが影響を受けることがあります。特にSLOGが失われると、最近の書き込みが失われるリスクがあります。

対処法1: まず現在の状態を確認する（zpool status）

TrueNAS Scaleでシェルにアクセスして（「システム設定」→「シェル」）、以下のコマンドを実行します。

# プールの全体ステータスを確認
zpool status

# 特定のプールを確認（例：poolname = "tank"）
zpool status tank

# 詳細情報を表示（エラーカウント付き）
zpool status -v tank

出力の見方

  pool: tank
 state: DEGRADED
status: One o​r more devices has been removed by the administrator.
action: Online the device using 'zpool online' o​r replace the device
  scan: resilvered 2.73T in 04:15:44 with 0 errors on Sun Jan  5 10:20:02 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz1-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     FAULTED      5   212   140  too many errors
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

この例では sdb がFAULTEDになっており、READエラー5、WRITEエラー212、CHECKSUMエラー140が発生しています。このドライブを交換する必要があります。

対処法2: S.M.A.R.T.テストでドライブの健康状態を確認する

TrueNAS Web UIからS.M.A.R.T.テストを実行する

ステップ1: 「ストレージ」→「ディスク」を開き、テストしたいドライブを選択します。

ステップ2: 「S.M.A.R.T.テストを実行」をクリックします。

ステップ3: テストの種類を選択します：

• SHORT: 通常1〜2分。基本的なヘルスチェック
• LONG: 数時間かかる場合あり。全セクタの読み取りテスト（推奨）
• CONVEYANCE: 輸送ダメージのチェック（対応ドライブのみ）

シェルからS.M.A.R.T.テストを実行する

# SHORTテストを実行（/dev/sdb を対象ドライブに変更）
sudo smartctl -t short /dev/sdb

# テスト結果を確認
sudo smartctl -a /dev/sdb

# 重要な属性のみ表示
sudo smartctl -A /dev/sdb

注目すべきS.M.A.R.T.属性

属性名	ID	危険な値（RAW）	意味
Reallocated Sectors Count	5	1以上は要注意	不良セクタが代替セクタに移された数
Current Pending Sectors	197	1以上は要注意	再マッピング待ちの不安定セクタ数
Offline Uncorrectable	198	1以上は危険	修復不可能な不良セクタ数
Reallocated Event Count	196	増加傾向は危険	代替セクタへの移動イベント数
Spin Retry Count	10	増加傾向は危険	スピンアップ再試行回数（HDD）

対処法3: zpool scrubでデータ整合性を検証する

zpool scrubはZFSの全データをチェックサムで検証し、エラーを検出・修復する作業です。定期的な実行が推奨されます。

# scrubを開始
sudo zpool scrub tank

# scrubの進捗を確認
sudo zpool status tank

# scrubを停止（途中でキャンセルする場合）
sudo zpool scrub -s tank

scrub中の出力例：

scan: scrub in progress since Sun Apr  5 10:00:00 2026
        5.27T scanned at 1.05G/s, 1.23T issued at 246M/s, 14.9T total
        0 repaired, 8.27% done, 00:16:09 to go

scrub完了後のエラーが0であれば、データの整合性は保たれています。エラーがある場合は、ZFSが冗長データから修復を試みます（修復できなかった場合はエラー数が残ります）。

対処法4: 問題のあるドライブを交換する（resilver）

ドライブの物理的な問題が確認された場合、新しいドライブに交換してresilvering（再同期）を行います。

ドライブ交換の手順

ステップ1: データのバックアップを確認する

ドライブ交換前に必ずバックアップが存在することを確認してください。resilvering中にさらに別のドライブが壊れると、データが失われる可能性があります。

ステップ2: 問題のあるドライブを特定する

sudo zpool status -v tank

FAULTEDまたはOFFLINEのドライブを特定し、デバイス名（例：/dev/sdb）を記録します。

ステップ3: ドライブのシリアル番号で物理的な位置を確認する

sudo smartctl -i /dev/sdb | grep Serial

ステップ4: ホットスワップ対応の場合（推奨）

SATAホットスワップ対応のケースを使用している場合は、システムを停止せずに問題のあるドライブを取り外し、新しいドライブを挿入します。

ステップ5: ホットスワップ非対応の場合

TrueNAS Scaleをシャットダウンし、ドライブを物理的に交換してから再起動します。

ステップ6: 新しいドライブをプールに追加する（WebUI）

1. 「ストレージ」→「プール」を開く
2. Degradedのプールの「その他のオプション」→「ディスクの交換」を選択
3. 故障したドライブと新しいドライブを選択して「交換」をクリック

ステップ7: resilvering（再同期）の進捗確認

# resilveringの進捗確認（定期的に実行）
sudo zpool status tank

出力例：

scan: resilver in progress since Sun Apr  5 12:00:00 2026
        1.34T scanned at 334M/s, 892G issued at 223M/s, 5.62T total
        892G resilvered, 15.47% done, 05:42:11 to go

resilvering完了後、ステータスが ONLINE に戻ります。データ量によっては数時間〜数日かかります。

対処法5: ECC RAMについて（ZFSの重要な推奨事項）

ZFS開発元はECC（Error Correcting Code）RAMの使用を強く推奨しています。理由は以下の通りです。

• Non-ECCメモリのビットフリップ（メモリエラー）がZFSのキャッシュ（ARC）を経由してディスクに書き込まれると、データが静かに破損します
• ZFSのチェックサムはディスク上のデータを保護しますが、メモリ上の破損データには対処できません
• ECC RAMはメモリエラーをリアルタイムで検出・修正し、こうしたデータ破損を防ぎます

現在Non-ECCメモリを使用している場合、TrueNAS ScaleはECC RAMへの移行を推奨します。ただし、これは即座にDegradedを引き起こすものではなく、長期的なデータ保護の問題です。

対処法6: キャッシュドライブ（SLOG/L2ARC）の問題を対処する

SLOG（ZIL: ZFS Intent Log）の問題

SLOGはZFSのwriteキャッシュとして機能するSSDです。SLOGが故障した場合、プールがDegradedになることはまれですが、最近の書き込みが失われるリスクがあります。

# SLOGドライブを確認
sudo zpool status tank | grep -A 5 logs

# 故障したSLOGを削除する場合
sudo zpool remove tank /dev/sdX

SLOGなしでもZFSは動作します（パフォーマンスが低下する場合あり）。交換用SSDが届いてから再追加することが可能です。

L2ARC（2次Readキャッシュ）の問題

L2ARCが故障してもプールはDEGRADEDになりません。L2ARCは単なるreadキャッシュであり、データそのものは保存されていないためです。削除後のパフォーマンス低下はありますが、データへのリスクはありません。

# L2ARCドライブを削除する
sudo zpool remove tank /dev/sdX

予防措置: 定期メンテナンスの設定

定期scrubのスケジュール設定

TrueNAS Scale WebUIで自動scrubを設定します：

• 「データ保護」→「スクラブタスク」→「追加」
• 月1回のスケジュールを設定（例：毎月第1日曜日の午前2時）

S.M.A.R.T.テストのスケジュール設定

• 「データ保護」→「S.M.A.R.T.テスト」→「追加」
• SHORTテストを週1回、LONGテストを月1回に設定

メールアラートの設定

• 「システム設定」→「一般」→「メール設定」でSMTP設定
• 「アラート」で通知メールアドレスを登録

よくある質問（FAQ）

Q1. Degradedの状態でNASを使い続けても大丈夫ですか？

短期間であれば継続使用可能ですが、冗長性が失われているため非常に危険な状態です。RAIDZの場合、もう1本ドライブが壊れるとデータが完全に失われます。できるだけ早くドライブを交換してください。

Q2. resilvering中にNASを使用できますか？

はい、resilvering中もNASは通常通り使用できます。ただし、resilvering中はI/Oリソースが多く消費されるため、パフォーマンスが低下する場合があります。また、resilvering中の追加ドライブ障害はリスクが高いため注意が必要です。

Q3. zpool scrubとresliverの違いは何ですか？

scrubはすべてのデータブロックを読み込んでチェックサムを検証し、エラーを修復する定期メンテナンス作業です。resilverはドライブ交換後に新しいドライブへデータを再同期する作業です。どちらもデータの整合性を保つために重要です。

Q4. Non-ECCメモリを使っていますが、今すぐECCに変える必要がありますか？

必須ではありませんが、重要データを保存しているなら強く推奨します。Non-ECCでも多くの環境で問題なく動作しますが、まれなメモリエラーがサイレントデータ破損につながるリスクがあります。

Q5. SLOGが故障した場合、どのくらいのデータが失われますか？

SLOGが故障した場合、最後の正常なsync操作以降の非sync書き込みが失われる可能性があります。データベースやVMなどsync書き込みを使用するアプリケーションのデータは保護されています。

Q6. プールの空き容量が少なくなるとZFSのパフォーマンスは落ちますか？

はい、ZFSは空き容量が20%以下になるとパフォーマンスが低下します。プールの容量を80%以下に保つことを推奨します。これはZFSの書き込み最適化アルゴリズムの特性です。

Q7. バックアップはどうすれば良いですか？

ZFSでも3-2-1バックアップルール（3つのコピー、2つの異なるメディア、1つはオフサイト）が推奨されます。TrueNAS ScaleにはResticやcloud syncを使ったバックアップ機能が統合されており、Cloud StorageへのバックアップもWebUIから設定できます。

まとめ

TrueNAS ScaleのDegradedステータスは、データが失われる前の重要なアラートです。発見したら以下の手順で対処してください。

1. zpool status -v でどのドライブに問題があるか確認する
2. S.M.A.R.T.テスト（LONG） でドライブの健康状態を詳しく確認する
3. zpool scrub でデータ整合性を検証し、修復可能なエラーを修復する
4. 問題のあるドライブを同等以上のドライブに交換し、resilvering完了まで待つ
5. 今後のために定期scrub・S.M.A.R.T.テスト・メールアラートを設定する

ZFSは強力なデータ保護機能を持っていますが、定期的なメンテナンスとバックアップが不可欠です。ECC RAMの使用と定期scrubの実施で、長期的なデータの安全性を確保しましょう。