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

【2026年最新版】ZFS scrubでエラーが出る・scrubが完了しない原因と対処法【完全ガイド】

ZFS scrubとは何か

ZFS scrub（スクラブ）は、ZFSプール上のすべてのデータを読み取り、チェックサムを検証して整合性を確認する処理です。通常のディスクI/Oとは別にバックグラウンドで実行され、以下の問題を検出・修復します。

• サイレントデータ破損（Silent Data Corruption）: ファイルシステムに記録されたデータが物理的に変化してしまう現象（ビットロット）
• ディスクの読み取りエラー: ハードウェア障害の兆候
• 書き込みエラー: データ書き込み時の問題の痕跡

ZFSはチェックサムを持っているため、エラーを検出した場合に冗長構成（RAIDZ / Mirror）があれば自動修復もできます。定期的なscrubはこの自動修復機能を活かすための必須メンテナンスです。

scrubの実行方法と基本コマンド

# scrubを開始（プール名: tank）
zpool scrub tank

# scrubの進捗・結果を確認
zpool status tank

# scrubを途中で停止
zpool scrub -s tank

# scrub結果のサマリー（より詳細）
zpool status -v tank

zpool status の出力例:

  pool: tank
 state: DEGRADED
status: One o​r more devices has been removed by the administrator.
  scan: scrub repaired 0B in 02:31:45 with 3 errors on Sun Apr 3 00:25:12 2026
config:
        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     FAULTED      3     0     2  too many errors

errors: Permanent errors have been detected in the following files:
        /mnt/tank/data/important-file.txt

エラー種別の違いと深刻度

エラー種別	意味	深刻度	対処
CKSUM (checksum errors)	データを読み取ったがチェックサムが一致しない	高	ディスク交換・ECC RAM確認
READ (read errors)	ディスクからデータを読み取れない	高	ディスク交換
WRITE (write errors)	ディスクへの書き込みが失敗した	中〜高	ケーブル確認・ディスク交換

checksum errorsの特殊性

checksum errorsは単なるディスク障害だけでなく、ECC RAMなしのメモリ（Non-ECC）によるデータ破損が原因の場合があります。データはメモリ上で処理されてからディスクに書き込まれるため、メモリでビットが反転するとZFSはチェックサム不一致として検出します。

ディスクを交換してもchecksum errorsが再発する場合は、ECC RAMの問題を疑ってください。

scrubエラーが出た際の調査手順

ステップ1: エラーの全体像を把握

# 詳細なステータス確認
zpool status -v tank

# 全プールの状態確認
zpool status

どのデバイス（ディスク）でエラーが発生しているか、エラーカウントの数値を確認します。

ステップ2: SMART情報でディスクの健康状態を確認

# smartmontools のインストール
apt install smartmontools   # Debian/Ubuntu系
yum install smartmontools   # RHEL/CentOS系

# ディスクのSMARTステータス確認（/dev/sdb の場合）
smartctl -a /dev/sdb

# SMARTセルフテストを実行（長時間テスト: 数時間かかる）
smartctl -t long /dev/sdb

# テスト結果確認
smartctl -l selftest /dev/sdb

特に以下のSMART属性を確認します。

SMART属性	意味	危険な値
Reallocated_Sector_Ct	不良セクタで代替済みのセクタ数	1以上
Current_Pending_Sector	代替待ちの不安定セクタ数	1以上
Offline_Uncorrectable	訂正不能なオフラインエラー	1以上
UDMA_CRC_Error_Count	ケーブル/接続の問題	増加傾向

ステップ3: エラーが軽微な場合（1〜3件のchecksum errors）

scrubを再実行します。ZFSはミラー/RAIDZから正しいデータを読み込んで破損データを自動修復できます。再scrub後にエラーカウントがリセットされていれば（または増加していなければ）、一時的な問題だった可能性があります。

# エラーカウントをリセット
zpool clear tank

# scrubを再実行
zpool scrub tank

# 結果確認
zpool status tank

障害ディスクの交換とresilver（再同期）

オンライン交換（ホットスワップ対応の場合）

# 障害ディスクをオフラインにする（/dev/sdb が障害ディスクの場合）
zpool offline tank /dev/sdb

# 物理的にディスクを交換

# 新しいディスクを追加してreplaceを実行
zpool replace tank /dev/sdb /dev/sdb   # 同じスロットの場合
# または別のデバイス名の場合
zpool replace tank /dev/sdb /dev/sdc

# resilverの進捗確認
zpool status tank

resilver（再同期）の確認

replaceを実行すると自動的にresilverが始まります。resilver中の出力例:

  scan: resilver in progress since Sun Apr  3 10:00:00 2026
        1.23T scanned at 450M/s, 456G issued at 166M/s, 1.23T total
        456G resilvered, 37.10% done, 00:45:23 to go

resilver完了後、zpool status で全ディスクが ONLINE になり、エラーカウントがゼロであることを確認してください。

TrueNASでのディスク交換手順

1. Web UI → Storage → Pools → プール名の横の「Settings」アイコン
2. 「Status」をクリック
3. 障害ディスクの横の「Replace」ボタンをクリック
4. 新しいディスクを選択して「Replace Disk」を実行
5. resilverの進捗をStatus画面で確認

ECC RAMがZFSに必要な理由

ZFSは「信頼できるストレージ」として設計されていますが、そのデータパスにはメモリ（RAM）が含まれます。Non-ECC RAMでビット化け（1ビットが反転する現象）が発生すると、ZFSはそのデータをそのままディスクに書き込んでしまいます。

ECC（Error-Correcting Code）RAMはこのビット化けを自動検出・修正する機能を持っています。ZFSの開発元であるSun Microsystemsも、本番環境でのZFS使用にはECC RAMを強く推奨していました。

ECC RAMなしで起きうる問題

• scrubで原因不明のchecksum errorsが繰り返し発生する
• ディスクを交換しても問題が解決しない
• RAIDZ冗長性があってもデータが静かに破損し続ける

自宅NASでコスト優先の場合、Non-ECC RAMでも運用している方は多いですが、重要データを扱う場合はECC RAM対応マザーボード（AMD EPYC、Intel Xeon、一部の Ryzen/Intel Consumer向け）への移行を検討してください。

scrubスケジュールの設定

月次scrubの推奨設定

ZFSコミュニティのベストプラクティスは「月に1回のscrub」です。週次は過剰でディスクへの負荷が高く、季次（3ヶ月に1回）ではビットロットの検出が遅すぎます。

crontabでのスケジュール設定

# 毎月1日の午前2時にscrubを実行
crontab -e

# 以下を追記
0 2 1 * * /sbin/zpool scrub tank

systemd timerでの設定（Debian/Ubuntu系）

# /etc/systemd/system/zfs-scrub.timer
[Unit]
Description=Monthly ZFS scrub

[Timer]
OnCalendar=monthly
Persistent=true

[Install]
WantedBy=timers.target

TrueNASでのスケジュール設定

1. Web UI → Data Protection → Scrub Tasks
2. 「Add」をクリック
3. Pool: 対象プール選択
4. Threshold Days: 35（35日以内にscrub済みならスキップ）
5. Schedule: Monthly（毎月最初の日曜日など）
6. 「Save」で保存

scrubが完了しない場合の対処

I/O帯域の制限

scrubはバックグラウンドで実行されますが、本番環境でのI/Oに影響が出る場合はscrubのスループットを制限できます。

# scrubのI/Oスロットリング（ZFS on Linux）
# /sys/module/zfs/parameters/zfs_scrub_delay を設定
echo 4 > /sys/module/zfs/parameters/zfs_scrub_delay   # 値が大きいほど遅くなる

# 現在の設定確認
cat /sys/module/zfs/parameters/zfs_scrub_delay

大容量プールでの時間目安

プール容量	HDD（スピンドル）	SSD/NVMe
1TB	1〜3時間	20〜60分
10TB	10〜30時間	2〜6時間
50TB	2〜5日	12〜24時間

バックアップの重要性: ZFSはバックアップではない

ZFSのRAIDZやミラー構成は「可用性（Availability）」のための技術であり、バックアップの代替ではありません。以下のリスクはRAIDZでは防げません。

• 誤った削除: ユーザーがファイルを削除するとすべてのディスクから消える
• ransomware（ランサムウェア）: プール全体が暗号化される
• コントローラー障害: RAIDコントローラーが壊れると全ディスクが読めなくなる
• 自然災害・火災: 物理的に全ディスクが失われる

「3-2-1バックアップ」原則（3コピー・2種類のメディア・1オフサイト）に従い、ZFSスナップショットとオフサイトバックアップを組み合わせて運用してください。

ZFSスナップショット + レプリケーションの設定

# スナップショットを作成
zfs snapshot tank/data@2026-04-01

# 別のサーバーにレプリケーション
zfs send tank/data@2026-04-01 | ssh backup-server zfs receive backup/data

よくある質問（FAQ）

Q1. scrub中にエラーが見つかった場合、すぐにディスクを交換すべきですか？

エラーの件数と種類によります。1〜2件のchecksum errorsのみで、SMARTに問題なければ「clear → 再scrub」で様子を見ます。read errorsが発生している場合や、SMARTでReallocated Sectorが検出されている場合は、できるだけ早くディスクを交換してください。

Q2. RAIDZ1で1本障害になった状態でscrubを実行しても安全ですか？

RAIDZ1の状態でもう1本障害が起きると全データを失います（DEGRADED状態）。DEGRADED状態ではscrubより先にディスク交換とresilverを優先してください。resilver中はできる限り別の作業を減らし、ディスクへの負荷を下げることを推奨します。

Q3. ProxmoxでZFSプールを使っています。scrubの設定はどこでできますか？

Proxmox VEは自動的に月次scrubのcron設定を行います（/etc/cron.d/zfsutils-linux に設定が書かれています）。Web UIのNode → Disks → ZFS からもプールの状態とscrubの実行が可能です。

Q4. ZFSのscrubはシングルディスク（ミラーなし）でも意味がありますか？

シングルディスク構成では、エラーを検出しても自動修復はできません（他のコピーがないため）。ただし、破損を早期検知してバックアップからの復元に備えるという意味では有効です。

Q5. checksum errorsが毎回一定数検出されるが増えていない場合は問題ありませんか？

増加していないなら緊急性は低いですが、定期的に監視してください。ただし、Non-ECC RAMによる問題の場合は根本解決にならないので、ECC RAM環境への移行を検討することを推奨します。

Q6. ZFS scrubと通常の読み取り操作の違いは何ですか？

通常の読み取りはリクエストされたデータのみを読みます。scrubはプール上のすべてのデータを順に読み取ってチェックサムを確認します。scrubは選択的な検証ではなく全体的な整合性チェックです。

Q7. scrubはディスクへの負荷が高いですか？

scrubはすべてのデータを読み取るため、ディスクへのI/O負荷が発生します。業務時間外（深夜・週末）に実行することを推奨します。zfs_scrub_delayパラメータで速度を制限できます。

まとめ

ZFS scrubは「問題を検出する」だけでなく「問題を修復する」強力なツールです。エラーが検出された際の対処をまとめます。

1. エラー確認: zpool status -v でエラーの種類と件数を把握
2. SMART確認: smartctl -a /dev/sdX でディスク自体の健康状態を確認
3. 軽微なエラー: clear → 再scrub → 自動修復を確認
4. 重大なエラー: ディスク交換 → zpool replace → resilver完了を確認
5. 繰り返すchecksum errors: ECC RAMの導入を検討
6. 月次scrub: cron/systemd timerで定期実行を設定
7. バックアップ: ZFSはバックアップ代替にならない、3-2-1原則を徹底

定期的なscrubとSMART監視・適切なバックアップの三本柱でZFSストレージを安全に運用してください。