RAIDはバックアップではございません
データ保護を目的とした仕組みとして紹介されることも多いRAID。
しかしRAIDは本来、バックアップの代わりになるものではありません。
RAIDの主な目的はドライブ故障が発生した場合でもシステムの稼働をできる限り継続させることにあります。
つまり連続稼働時間を延ばし停止リスクを下げるための仕組みです。
RAID1やRAID5・RAID6・RAID10では、ドライブ故障に対する冗長性（リビルド）があります。
そのためドライブが故障してもすぐにデータへアクセスできなくなるとは限りません。
しかし、それはあくまで「ドライブ故障への耐性」でありデータそのものを安全に保護する仕組みとは異なります。
たとえば、誤ってファイルを削除した場合はRAID上のデータも同じように削除されます。
ランサムウェアによる被害でもRAID内のデータは同じように暗号化されます。
ファイルシステムの破損やRAID構成情報が壊れた場合ではデータ自体にアクセス不能となります。
つまり、RAIDは「止まりにくくする仕組み」であって「失われたデータを戻す仕組み」ではありません。
RAIDとバックアップは役割がまったく異なります。
RAIDは稼働継続性を高めるための仕組み。
バックアップはデータを失ったときに戻すための仕組みです。
この違いがデータ保護において非常に重要です。
それでは「自動バックアップ」という概念はどうでしょうか。
複数のドライブを接続して運用するRAID・自動的にバックアップを取れるように組み込んだシステム・同時にミラーを生成するミラーリング。
これらはシーケンシャルの高速化やデータの冗長性などを求めて組まれます。
しかし、同時に脆弱性を抱え込む原因にもなっておりますので、それらをみていきましょう。
自動バックアップ
自動バックアップでは「徐々に」各ドライブが劣化する場合にデータを失います。
失うかもしれませんではなく、本当に失いますので、自動バックアップのみに頼るのは厳禁です。
数値の順：
空データ数, 実データ数, 読み込み不能セクタ数, 書き込み不能セクタ数, 読み書き不能セクタ数
同期前：
Disk1｜90, 10, 00, 00, 00｜
Disk2｜100, 00, 00, 00, 00｜
同期後：
Disk1｜90, 10, 00, 00, 00｜
Disk2｜90, 10, 00, 00, 00｜
各数値は全体を100として情報を保持している量を表します。
今回のDisk1は未使用が90・データ使用量が10・その他エラーのセクタはありません。
新しいDisk2(新品なので未使用100)にバックアップした様子(同期)です。
自動バックアップが知らないうちにデータ損失
バックアップ先のドライブが故障するまで一切検査せずに使い続けるのは危険です。
なぜなら故障に気が付かない場合がとても多いため気が付いたときには両方とも読めないという現象に遭遇します。
このようなデータ損失に至るまでの変化の流れ
数値の順：
空データ数, 実データ数, 読み込み不能セクタ数, 書き込み不能セクタ数, 読み書き不能セクタ数
新品の状態：
Disk1｜55, 45, 00, 00, 00｜
Disk2｜100, 00, 00, 00, 00｜
最初の同期(無事作動確認)：
Disk1｜55, 45, 00, 00, 00｜
Disk2｜55, 45, 00, 00, 00｜
定期的に使用中、データ量55から80へ(無事作動確認)：
Disk1｜20, 80, 00, 00, 00｜
Disk2｜20, 80, 00, 00, 00｜
障害の発生(無事作動確認)：
Disk1｜20, 80, 00, 00, 00｜
Disk2｜19, 80, 01, 00, 00｜
障害の発生２(無事作動確認)：
Disk1｜20, 80, 00, 00, 00｜
Disk2｜19, 70, 11, 00, 00｜損失10
障害の発生３(無事作動確認)：
Disk1｜18, 80, 02, 00, 00｜
Disk2｜15, 64, 21, 00, 00｜損失16
障害の発生４(無事作動確認)：
Disk1｜18, 80, 02, 00, 00｜
Disk2｜10, 55, 30, 05, 00｜損失25
障害の発生５(エラーで停止)：
Disk1｜18, 60, 02, 03, 17｜損失20
Disk2｜10, 55, 30, 05, 00｜損失25
障害の発生６(５のエラーを無視、再度エラー、再起不能)：
Disk1｜00, 00, 00, 00, 100｜損失80(ヘッドクラッシュ)
Disk2｜10, 35, 50, 05, 00｜損失45
Disk1(メイン側)が元気なのにDisk2(コピー先)が徐々に弱っていく
データを書き込んでから一定時間後に読み込み不能セクタに変化いたします。
同期の場合はファイル名または更新日時に変化がない場合は書き込みしないため、データ損失が気付かれずに放置されてしまいます。
頻繁に更新するファイルは書き込みの際にセクタが復活する可能性を秘めており、最終的に読み書き不能セクタになった場合はエラーで停止します。
これには、ほとんど更新しない保存用ファイルなども影響を受けます。
更新頻度の低い例としては保管用の画像などが犠牲となっております。
更新頻度の低いファイルはできる限り別のメディアにも保存することで対応します。
[重要] ミラーリングをバックアップとして利用してはいけません。
データ保護機能はありません。
ミラーリングはバックアップの代わりになりません。
ドライブに対する見えない消耗が重なりシステムが停止したときには、すでに時遅しとなります。
接続ドライブが全破損していたという結果につながる恐れがあります。
RAIDはあくまで稼働時間を延ばし、決められた時間に修理を可能にする利点のみです。
そこに、データ保護機能はありません。
ドライブの検査
バックアップ先の劣化を定期的に検査することで徐々に弱っていくデータ損失を防ぐ事ができます。
この検査にはFromHDDtoSSDに備わる「完全スキャン」「統計スキャン」をご活用ください。
RAIDとビット腐敗
RAIDの整合性を破壊する原因の一つとして「ビット腐敗」があります。
このビット腐敗とは、長期間アクセスされていないデータやセクタが経年劣化などによって正常に読み出せなくなる現象です。
実際には「読み取り不能セクタ」「訂正不能エラー」「データ化け」「整合性の不一致」などのさまざまな形で表面化します。
特に問題になりやすいのは、ほとんどアクセスされない領域です。
普段から頻繁に読み書きされる領域であれば異常が比較的早く発見されることがあります。
しかし、長期保管されているデータやほとんど使われない領域は、検査されないまま劣化が進むことがあります。
そのため、長期間保管されているデータほど「ビット腐敗」の影響を受けやすくなる傾向があります。RAIDではこの問題がさらに複雑となります。
RAIDは複数のドライブで構成されているため、通常動作中は一見正常に見えていても、
実際には複数のドライブ上ですでに読めないセクタや不安定な領域が発生している場合があります。
ところがRAID構成では、普段の運用中にすべてのセクタへ常にアクセスするわけではありません。
そのため劣化した領域が存在していても表面化しないまま運用が続いてしまうことがあります。
そして、そこに1台のドライブ故障が発生すると状況が一気に悪化します。
RAIDのリビルドや復旧作業では残っているドライブから大量のデータを読み出す必要があります。
これまで表面化していなかったビット腐敗や不良セクタが一気に露呈するとリビルドが失敗したりRAID全体の整合性が崩れたりすることがあります。
つまりRAIDゆえに動いていたのではなくRAIDだからこそ問題が見えにくいまま残っていた。
そして1台の故障をきっかけに隠れていた不良が一気に表面化することがあるのです。
RAID環境では、単にドライブ故障に備えるだけでは不十分です。
定期的な検査・整合性チェック・別媒体へのバックアップが重要です。
このようなRAIDには稼働継続性を高める仕組みですが「ビット腐敗」まで自動的に防いでくれるわけではありません。
長期的にデータを守るためにはRAIDの状態を定期的に確認することで見えない劣化を早めに検出することが大切です。