ディスクの健全性チェックの方法
TODO
SMARTテストの定期的な実行の自動化
short
long
ログを監視してReallocated_Sector_Ctなど5大項目が1を超えたら即メール通知する設定
メールが来たら即座にHDDを発注し、rsyncでコピーする
Time Machine用2 TBを将来入れ替えるときは、まずバックアップ完了を確認してからディスクを差し替え、Time Machineを再設定するだけで済む。
RAID5グループの健全性チェックは月1でSMART確認＋年1でフル読み出し（Disk UtilityのFirst Aid）を走らせると安心。
月1 SMARTチェックを省くと
再配置セクタ数などの悪化に気づかず、予兆なしで突然電源断・異音→RAID脱落。
脱落後にリビルド中の2本目故障でRAID5が崩壊する確率が上がる。
年1フル読み出し（First Aid全セクタ検査）を省くと
長期間一度も読まれないブロックに潜んだ「読めないセクタ」が放置される。
そのままバックアップにコピーされ、両方とも壊れたデータで固定される。
RAID再同期時に未検出エラー（URE）が出るとリビルド失敗→全ボリューム消失。
目安: URE 10-14 のHDDで32 TB読み込み(16 TB×2) ≈ 2〜3 %の確率で発生。 URE は “Unrecoverable Read Error”（読み取り不能エラー）の略です
ドライブは読み取ったビット列がおかしいと、自前の ECC（誤り訂正コード）で直そうとします。それでも直せない場合を URE と呼びます。
メーカーは「10¹⁴ ビットに 1 回」など確率で公表します。これは 10¹⁴ ビット（約12 TB）を連続で読むと平均して 1 回だけ直せないビットが出る、という意味です。
例として 16 TB のディスク全体を一気に読み直すと、理論上 1 回弱の URE が起きる計算になります。RAID 再同期やバックアップ検証で大量に読むと、この確率が現実になりやすいわけです。
URE が発生したブロックを RAID が他ディスクから再構築できれば問題ありませんが、再構築中に 2 本目でも URE が出ると RAID5 などは崩壊します。
要するに「ドライブ内部でも直せなかったビット化け」のことで、読み取り量が大きいほど遭遇率が上がるため、月1 SMARTチェックや年1フル読み出しで早めに不良を出し切っておくと安全、という話につながります。
併発する追加リスク
ファームが「読んだとき初めて不良を再配置する」方式なので、定期読込みをしないと自動修復も働かない。
SMARTしきい値超過後もOS通知を見落とすと、バックアップを取る時間的余裕すらなくなる。
手順
Homebrewでsmartmontoolsを入れ、sudo smartctl -t short / -t long をcronやlaunchdに登録。
デバイス番号確認
diskutil list external
→ 例: 外付けSSDが /dev/disk2 なら後は disk2 を使う
月1 SMART短時間テスト
1. 属性を確認
sudo smartctl -a /dev/disk2
2. ショートテスト実行（約2分）
sudo smartctl -t short /dev/disk2
3. 終了後に再度 smartctl -a を打ち “Completed without error” を確認
年1 SMARTロングテスト＆フル読み取り
sudo smartctl -t long /dev/disk2 （数時間かかる）
※short と long は同日に連続で走らせても問題ない
さらに読めないブロックをあぶり出す目的で
sudo dd if=/dev/disk2 of=/dev/null bs=1m （全体を強制リード）
エラーが出たら即バックアップしてドライブ交換
自動化
1. プリセットを ~/Library/LaunchAgents/com.smart.short.plist に作成
code:xml
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
<key>Label</key><string>smart.short</string>
<key>ProgramArguments</key>
<array><string>/usr/local/sbin/smartctl</string><string>-t</string><string>short</string><string>/dev/disk2</string></array>
<key>StartCalendarInterval</key>
<dict><key>Day</key><integer>1</integer><key>Hour</key><integer>2</integer></dict>
</dict>
</plist>
→ 毎月1日午前2時にショートテスト
2. 年1ロング用に com.smart.long.plist を作り Month1 を追加
3. 読み込み
launchctl load ~/Library/LaunchAgents/com.smart.short.plist
launchctl load ~/Library/LaunchAgents/com.smart.long.plist
結果確認・通知
ログは /private/var/log/system.log に出る
$ grep smart.short /private/var/log/system.log
異常値を早く知りたい場合は smartd を常駐させ
$ sudo nano /usr/local/etc/smartd.conf
$ DEVICESCAN -a -m your@mail -s (S/../.././02|L/../../01/02)
$ brew services start smartd
年1回ディスクユーティリティのFirst Aidを手動クリック。
作業時間は月5分＋年1回数時間のロングテスト待ち。コマンド入力が面倒でなければ実質コスト0円。
Disk UtilityのFirst Aidでも「全セクタ読み取り検査」に近い処理はできる
必ず左上の表示を「すべてのデバイスを表示」に切り替え、外付けSSDの“物理ディスク”を選んでFirst Aidを実行
物理ディスクを選ぶとfsck＋サーフェス（read-only）チェックが走る
所要時間は容量×数分レベル。エラーがあれば停止し報告
なぜddやsmartctl longを挙げたか
First AidはGUI操作が必要で自動化しにくい
APFSコンテナだけ選ぶとメタデータ検査が中心で、未使用領域を読まない
smartctl longはSMARTセルフテストなのでファーム側がECC再配置も同時に行う
smartctl long は「ドライブ自身に『全部の領域をゆっくり読んでみろ』と命令し、結果を SMART に書き込ませる」テスト
→ コントローラは各ブロックを読みながら ECC（誤り訂正コード）でビット化けを修復し、直せない場所はその場で「代替セクタ」に置き換える（リマップ）。
→ エラー数やリマップした場所は SMART ログに残るので、テスト後に smartctl -a を見ると劣化具合が分かる。
→ 読み取りと修復がドライブのファームウェア内部で完結するため、OS はデータ損失を見ずに済む。
cf. Disk Utility の First Aid（物理ディスクに対して実行）は「OS が全セクタを読み込んでみる」だけ
→ 読めない所があれば macOS がエラーとして報告。
→ しかし多くの HDD/SSD は「書き込み時」にしかリマップしない設定なので、読み取りエラーが出ただけでは代替セクタに置き換わらない場合がある。
→ エラーが出たブロックはまだ壊れたまま残る → その後のバックアップにもコピーされる恐れ。
dd if=/dev/diskN of=/dev/nullはファームを介さずOSが強制リードするため「長らく触れていない未割当領域」も確実に読む
どれを採用すれば良いか
1. 手動で年1回チェックできればOK → Disk Utilityで物理ディスクをFirst Aid
2. 毎年自動で夜間に回したい → smartctl -t longをlaunchdに登録
3. とにかく簡単に“全部読み”したい → dd if=/dev/diskN of=/dev/nullを実行しエラー確認
どれでも目的は達成できるので、好みと自動化のしやすさで選んでください。
これを乱暴に要約するとこうなる。
Googleがサービスで利用している10万台以上に及ぶディスクからデータを収集
そのうち故障したディスクを分析し、原因を調査
SMARTの以下のパラメータのうち、1つでも0を超えたら、60日後の故障確率は14倍から39倍になる 1 Raw_Read_Error_Rate
5 Reallocated_Sector_Ct
196 Reallocated_Event_Count
197 Current_Pending_Sector
198 Offline_Uncorrectable
ただし、故障ディスクの56%は上記のカウントが0だったにも関わらず壊れていた
温度を除くすべてのSMARTパラメータを考慮に入れても、36%以上のドライブがカウント0で壊れた
つまりSMART情報のみに頼っていてはドライブが故障するか否かを予知できない。SMARTで異常値を検知したらすぐに交換するべきだが、SMARTが正常だからといって安心することはできない。
以上から言えるのは、ひとまず代表的な5つのSMART指標について監視トリガを作成し、ひとつでも0を超えたら発報するようにするべきということだ。
監視間隔だが、SMARTは1時間程度、RAIDのdegradeは15分間隔ぐらいでよいと思う。なぜこんな時間間隔かというと、ディスク故障を検知しても交換部品の買い付けにAmazonでオーダーするところから始めるので24時間以上かかるからだ。ちなみに過去5年間の運用でdegradeしたことが1度あり、その時は交換作業で無事に復旧させることができた。そういう意味でQNAPの機能は信頼している。
ディスク故障時のオペレーション
o3.iconrsync + –checksum とバックアップ二重確認を使えば「壊れたファイルをそのまま移す」確率はかなり下げられる
予兆が出た時点ですぐにコピーを始める
コピー
$ rsync -aAXH --checksum --info=progress2 元/ 先/
エラーが出たファイルはバックアップ側から戻す
ログに残るので該当パスだけ backblaze restore や Time Machine で復元
エラーやコピー結果は標準出力／標準エラーに表示
コピー済みか確認
$ rsync -aAXH --checksum --dry-run 元/ 先/
-‐dry-run を付けると「再コピーすべきファイルがあるか」だけをハッシュで比較し一覧表示。
→ 何も出なければ“元と先が完全一致”と判断できる。
壊れたデータがバックアップされてしまうことを防ぐ
o3.icon
バックアップが壊れを巻き込む最大の原因は「検証をしないまま旧世代を上書き」すること。
月 1 の自動ハッシュ検証＋長期保持＋オフラインコピーの三段構えを入れておけば、ディスク大破後でも“正常版”をほぼ確実に取り戻せる。
NASはそれを完全自動で回したい人向けの上位解、と覚えておくと選択が楽になります。
smartctl は「SMART 情報を読み書きする道具」
コマンドを出すだけで、実際の検査・修復はディスクの中にあるファームウェアが行う。
smartctl ＝「物理ディスクが壊れ始めたら知らせてくれる係」
化けた内容までチェックしない
壊れかけセクタはドライブ自身が “代替セクタ” に置換する。
ここまでで「読めないままバックアップへ載る」事故はほぼ防げる。
long セルフテストを走らせると何が起きるか
1. ディスク全域を少しずつ読んでみる
2. 読み取ったデータがおかしければ内部 ECC（誤り訂正コード）でまず修正を試みる
3. ECC で直せないブロックは「不良セクタ」と判断
→ 代わりの空きセクタ（スペア領域）に内容をそっくりコピーし、
以後は新しい場所を自動的に使う（これが再配置＝リマップ）
4. 何個リマップしたか、エラーがあったかを SMART テーブルに書く
→ smartctl -a で Reallocated_Sector_Ct などの数値が増えるので劣化がわかる
ここで分かる＆直ること
読み取れない「物理エラー」はセルフテスト中にリマップされ、次回からは正常に読める
読み取りはできたが中身がすでに壊れている（サイレント腐敗）はここでは検知できない
→ ファイルシステム側のチェックサムやバックアップで拾う必要がある
ファイルシステムのハッシュ照合（ZFS/btrfsスクラブやfsck）、バックアップのハッシュ検証、通知自動化まで入れると「読めているけど壊れている」をほぼ防げる。これらを追加しておけば、Mac mini構成でも長期保存時の腐敗リスクは実用的に低く抑えられる。
ファイルシステム側のチェック
APFSはメタデータにはCRCがあるがデータブロックはノーチェック。最低でも年1でdiskutil verifyVolume（fsck）を走らせるか、ZFS／btrfsのように月1スクラブできる仕組みを用意すると安心 「diskutil verifyVolume」を定期的に回す意義は、あくまでファイルシステムの論理構造（メタデータ）に問題がないかを早めに発見すること
長期間マウントしっぱなしで起きやすいカタログの破損や、ディスクのメタデータ不整合を防げる
問題が見つかったら「diskutil repairVolume」でリカバリが可能
ボリューム上のファイルシステム構造（カタログ、メタデータ、ファイル拡張情報など）を読み取り専用で点検し、不整合や破損箇所を報告するコマンド
diskutil verifyVolume は APFS のメタデータ構造（ディレクトリツリーやカタログノード）の整合性だけを読み取り専用でチェックし、ユーザーデータの中身までは検証しない
APFS はメタデータにのみ Fletcher チェックサムを付与し、ファイル本体（データブロック）にはチェックサムを付けないため、ビットが静かに反転した「サイレントデータ腐敗」は検出／修復できない
diskutil repairVolume を使えばメタデータの破損は直せるが、ファイル内容の隠れた誤りは手を付けられない
ZFS／btrfsを外付けUSB/Thunderboltケース上に作り、月1 scrubで全ブロックを強制リードすればビット腐敗検知＋自動修復が可能
Mac mini＋APFS のままだとこれが限界です。物理層のエラー（不良セクタ）は検出してリマップできますが、ビット単位の静かなデータ破損はスルーされます。
もしサイレント腐敗を確実に防ぎたい場合は、ZFS や btrfs を使った NAS の定期スクラブが有効です o3.iconデータブロックにチェックサムがない点ではAPFSと同じで、静かなビット腐敗の自動検出・修復はできない ext4ではメタデータの整合性チェック（ディレクトリ構造やinodeのリンク数など）しかできず、静かにビットが反転したファイル本体の誤りは見つけられない
Gemini 2.5 Pro.iconmacOSのAPFSや多くのNASで使われるext4といった一般的なファイルシステムでは、ファイルのデータ部分で発生したサイレントなビット腐敗（ビット化け）をファイルシステム自身が検知・修復する仕組みはありません 。
ファイルサイズや更新日時は変わらないまま、画像の一部が乱れたり、動画が再生できなくなったりといった形で、ある日突然データが壊れていることに気づく、という事態が起こり得ます。
HDDメーカーが公開している仕様から、そのリスクを確率的に推測することができます。
指標となるのが「URE（Unrecoverable Read Error）」で、「回復不可能な読み取りエラー率」を意味します 。一般的なコンシューマー向けHDDでは、この値が「1エラー / 10¹⁴ビット」とされていることが多いです 。 約12.5TB（10^14/8|Byte/10^12|TB基素.icon）のデータを読み込むごとに、平均1回の修復不可能な読み取りエラーが発生する可能性がある
一度に大量のデータを読み出す以下のような場面では、無視できない現実的なリスクとなります
大容量HDDの全データバックアップやコピー
例えば16TBのHDDの全データを読み出す場合、理論上は1回以上のUREに遭遇する可能性が十分にあります
RAIDのリビルド
対策
計画されているrsync --checksumを使ったデータ移行は、APFSの弱点を補う非常に有効な対策です 。コピー元とコピー先のデータがビットレベルで同一であることを保証するため、移行中に破損データを持ち込んでしまうリスクを大きく減らせます。
ただし、この対策はあくまでコピー時に有効なもので、ディスク上で長期保管されているデータ（at-rest data）が静かに破損するのを防ぐものではありません。そのため、Mac miniの構成では、バージョン管理されたクラウドバックアップ（Backblaze）が最後の安全策として極めて重要になります。
基素.iconとはいえ長期保管されているデータが静かに破損されていたって普通はそれに気づかんだろうし、そのうちバックアップは上書きされちゃうから、実際には確率的に起きちゃうものだよね
Gemini 2.5 Pro.iconそれが、ZFSのようなファイルシステムが長期的なデータアーカイブにおいて高く評価される、まさにその理由です。
ZFSの定期的なスクラブ機能は、システム自身がプロアクティブ（能動的）に全データをパトロールし、ビット腐敗を検知・修復する仕組みです。破損がバックアップに記録される前に、あるいはユーザーが気づく前に、問題を未然に解決します
レビュー
Gemini 2.5 Pro.iconMac mini（RAIDなし）構成の最大のリスクである「ドライブ故障によるデータ損失」を、予兆検知と計画的な移行によって最小限に抑えるための、非常によく考えられた実用的なアプローチです。この計画を実行されるのであれば、ダウンタイムを最小限に抑えるという目的は十分に達成可能でしょう。
故障余地
定期的なSMARTチェックの自動化: smartmontoolsを使い、launchdで月次のショートテストと年次のロングテストを自動実行する計画は、ドライブの健康状態を定点観測するための基本かつ最も重要なステップです 。
危険な兆候の監視: 特に重要なのは、Googleの研究でも故障との相関性が指摘されているReallocated_Sector_Ct（代替処理済のセクタ数）などのSMART値を監視し、値が変動したら即座にメールで通知する設定です 。
潜伏エラーの検出: 年に一度ddコマンドやディスクユーティリティのFirst Aidで全領域を読み出す計画は、普段アクセスされない領域に発生した「読み取り不能エラー（URE）」をあぶり出すのに有効です 。
2. 安全なデータコピー： 壊れたデータをコピーしない技術
予兆を検知した後、新しいHDDにデータを移行する手法も的確です。
rsync --checksumの活用: お客様のメモにあるrsync -aAXH --checksumコマンドは、単なるファイルコピーではありません 。--checksumオプションにより、ファイルの日付やサイズだけでなく、中身（チェックサム）を比較して差分をコピーします。これにより、元のディスクで発生したかもしれない「ファイルは読めるが中身が静かに壊れている（サイレント故障）」データを、そのまま新しいディスクにコピーしてしまうリスクを大幅に低減できます 。
コピー後の検証： 移行の完全性を確認
データ移行の最後の締めくくりも万全です。
rsync --dry-runでの最終確認: コピー完了後に--dry-runオプション付きで再度rsyncを実行することで、コピー元とコピー先に差異がないかを最終確認できます 。ここで何もファイルがリストアップされなければ、移行が完全に成功したと確信でき、安心して古いドライブを引退させられます 。
認識しておくべき限界
突然死には対応できない: この戦略は、SMART値の悪化など、予兆を示しながら緩やかに劣化するドライブには非常に有効です。しかし、コントローラーの突然の故障や電力系のトラブルなど、予兆なく即死するケースも存在します。その場合は、当初の想定通りBackblazeからの復旧が最後の頼みの綱となります。
通知への対応が前提: 当然ながら、自動化された監視システムが警告を発しても、それを見逃したり、対応を先延ばしにしたりすると、この戦略は意味を成しません。