この記事について

「RAID」と「ZFS」という言葉、聞いたことはあるけど違いが説明できない。そんな方は多いのではないでしょうか。

この記事では、ストレージ設計の基礎を図解と具体例で解説します。難しい数式や専門用語は最小限に抑え、「結局どう選べばいいのか」まで踏み込みます。

対象読者

  • RAID / ZFS という言葉は聞いたことがあるが、違いが説明できない
  • インフラに苦手意識があるWebエンジニア
  • 小〜中規模システムの受託案件を検討している企業・CTO
  • ラズパイ・自宅サーバー・業務サーバーをこれから構築する人

なぜ RAID / ZFS が分からないまま運用されがちなのか

「動いているからOK」が一番危険

正直に言います。ストレージ設計は「動いているうちは気にならない」分野です。

Webアプリの開発では、画面が動くかどうかがすぐ分かります。バグがあればエラーが出ます。しかしストレージの問題は、壊れるまで気づかないことがほとんどです。

そして壊れたときには、取り返しがつきません。

データ消失は技術力不足ではなく設計不足で起きる

私がこれまで相談を受けたデータ消失事故の多くは、「技術力が足りなかった」のではなく、「設計段階で考慮されていなかった」ことが原因でした。

  • RAIDを組んでいたのにディスクが2本同時に壊れた
  • ZFSを使っていたのにメモリ不足でデータが破損した
  • バックアップはあったが、復元手順を誰も知らなかった

これらはすべて、設計時に「もし〇〇が起きたら」を考えていれば防げたものです。

ここを説明できると信頼が跳ね上がる

フリーランスとして仕事をしていて感じるのは、ストレージ設計をちゃんと説明できる人が少ないということです。

「なぜこの構成にしたのか」「壊れたときにどうなるのか」「復旧にどのくらいかかるのか」——これらを説明できるだけで、クライアントからの信頼は大きく変わります。

まず超重要な前提

RAID と ZFS は「同じカテゴリではない」

ここが最大の混乱ポイントです。

多くの人が「RAIDとZFS、どっちがいいの？」と比較しますが、これは**「車とエンジン、どっちがいい？」**と聞いているようなものです。

  • RAID = 複数のディスクを束ねて冗長化する「仕組み」
  • ZFS = ファイルシステム + ボリューム管理 + 整合性保証を統合した「システム」

ZFSの中にはRAIDに相当する機能（RAID-Zと呼ばれます）が含まれていますが、それだけではありません。

小学生でもわかる比喩

RAIDは、大事な書類をコピーして別の引き出しにも入れておくようなものです。一つの引き出しが壊れても、別の引き出しから取り出せます。

ZFSは、書類をコピーするだけでなく、すべての書類に「正しい内容かどうかのチェック印」を押し、さらに「いつでも過去の状態に戻せる仕組み」まで備えた、超高機能な書庫システムです。

RAIDが「コピーを取る係」だとしたら、ZFSは「書庫全体を管理する司書」のようなイメージです。

RAIDとは何か

RAIDの基本的な考え方

RAID（Redundant Array of Independent Disks）は、複数のディスクを組み合わせて、速度向上や冗長性確保を実現する技術です。

重要なのは、RAIDにはいくつかの「レベル」があり、目的によって選ぶべきレベルが違うということです。

RAID0：速度重視（冗長性なし）

    ┌─────────┐  ┌─────────┐
│ Disk 1  │  │ Disk 2  │
│  A C E  │  │  B D F  │
└─────────┘  └─────────┘
    ↓            ↓
  データを分散して書き込む（ストライピング）
  • 用途：動画編集の作業領域、一時ファイル置き場
  • 特徴：2台で2倍の速度。ただし1台壊れると全データ消失
  • 注意：「RAID」という名前だが冗長性ゼロ。消えても困らないデータ専用

RAID1：安全重視（ミラーリング）

    ┌─────────┐  ┌─────────┐
│ Disk 1  │  │ Disk 2  │
│ A B C D │  │ A B C D │
│（原本） │  │（コピー）│
└─────────┘  └─────────┘
    ↓            ↓
  まったく同じデータを2台に書く
  • 用途：OSが入ったシステムディスク、小規模サーバー
  • 特徴：1台壊れても、もう1台から復旧可能
  • 注意：容量効率は50%（2TBのディスク2台で使えるのは2TB）

RAID5：バランス型（分散パリティ）

    ┌─────────┐  ┌─────────┐  ┌─────────┐
│ Disk 1  │  │ Disk 2  │  │ Disk 3  │
│  A  B   │  │  C  P1  │  │  P2  D  │
│  P3  E  │  │  F  G   │  │  H  P4  │
└─────────┘  └─────────┘  └─────────┘
        ↓         ↓         ↓
    P = パリティ（復元用の計算データ）
  • 用途：ファイルサーバー、中規模システム
  • 特徴：1台壊れても復旧可能、容量効率は(n-1)/n
  • 注意：後述する「なぜ嫌われることがあるのか」を必ず読んでください

RAID10：速度と安全の両立

    ┌─────────────────────────────────────┐
│              RAID0                  │
│  ┌───────────┐    ┌───────────┐    │
│  │  RAID1    │    │  RAID1    │    │
│  │ D1 ⟷ D2  │    │ D3 ⟷ D4  │    │
│  │ (mirror) │    │ (mirror) │    │
│  └───────────┘    └───────────┘    │
└─────────────────────────────────────┘
  ミラーしたペアを、さらにストライピング
  • 用途：データベースサーバー、高負荷システム
  • 特徴：高速かつ冗長。各ペアから1台ずつなら壊れても大丈夫
  • 注意：最低4台必要、容量効率は50%

なぜRAID5は嫌われることがあるのか

RAID5は長年「バランスの取れた選択肢」とされてきましたが、最近は避けるべきという意見も増えています。

理由はURE（Unrecoverable Read Error）問題です。

ディスクが1台壊れてリビルド（再構築）するとき、残りのディスクを全読みします。このとき、読み取りエラーが発生する確率が無視できないほど高くなったのです。

特に大容量ディスク（4TB以上）では、リビルド中に別のディスクでエラーが発生し、結果的に全データ消失という事故が起きやすくなりました。

対策：

  • RAID6（2台まで故障OK）を検討する
  • ZFSのRAID-Z2を使う
  • そもそもRAID5は避け、RAID10にする

ZFSとは何か

「RAIDの進化版」ではない

ZFSを「RAIDの進化版」と説明する記事がありますが、これは誤解を招きます。

ZFSは、**ファイルシステム、ボリュームマネージャー、RAID機能を一つに統合した「ストレージスタック全体」**です。

Linuxで言えば、ext4 + LVM + mdadm の役割を、一つのシステムで担っています。

ZFSが解決した3つの歴史的課題

1. サイレントデータ破損

ディスクは「壊れました」と報告せずに、こっそり間違ったデータを返すことがあるのをご存知ですか？

これを「サイレントデータ破損」と言います。ビット腐敗（Bit Rot）とも呼ばれます。

従来のファイルシステムはこれを検出できません。バックアップを取っても、壊れたデータをコピーしているだけかもしれないのです。

ZFSはすべてのデータにチェックサムを付与し、読み込むたびに検証します。壊れていたら、冗長コピーから自動修復します。

2. ボリューム管理の複雑さ

従来のLinux環境では、ストレージを使うために複数のレイヤーを設定する必要がありました。

    物理ディスク → パーティション → RAID (mdadm) → LVM → ファイルシステム

それぞれ別のコマンド体系、別の設定ファイル、別のトラブルシューティング手順。

ZFSはこれを一つのコマンド体系で統合しました。

    # プール作成（RAID-Z1相当）
zpool create mypool raidz /dev/sda /dev/sdb /dev/sdc

# ファイルシステム作成
zfs create mypool/data

# これだけ。LVMもmkfsも不要

3. バックアップの属人化

「バックアップは〇〇さんしか分からない」——そんな現場、ありませんか？

ZFSのスナップショット機能は、瞬時にその時点の状態を保存できます。

    # スナップショット作成（一瞬で完了）
zfs snapshot mypool/data@before-update

# 何か問題があったら戻す
zfs rollback mypool/data@before-update

ディスク容量をほとんど消費せず、手順も単純。属人化しにくい設計です。

ZFSの重要キーワード（噛み砕いて説明）

用語 意味 なぜ重要か
Copy-on-Write データを「上書き」せず、「別の場所に書いてから切り替える」 書き込み中に電源が落ちてもデータが壊れない
Checksum すべてのデータに付けられた「正しさの証明書」 サイレントデータ破損を検出・修復できる
Snapshot 「その瞬間」の状態を記録する機能 瞬時バックアップ、簡単ロールバック

RAID + LVM と ZFS の思想の違い

比較表

観点 RAID + LVM ZFS
設計思想 部品を組み合わせる すべてを統合する
学習コスト 低め（個々は単純） 高め（概念が独特）
安全性 設計者の腕次第 フレームワークが守る
柔軟性 高い（自由に組める） 制約がある（ルール厳格）
メモリ要件 低い 高い（1GB以上推奨）
運用難易度 属人化しやすい 手順が標準化されやすい

どちらを選ぶべきか？

一概には言えませんが、判断基準を示します。

RAID + LVM が向いているケース

  • メモリが少ない環境（512MB以下）
  • チームに Linux/ストレージの経験者がいる
  • 既存のノウハウを活かしたい
  • 柔軟なカスタマイズが必要

ZFS が向いているケース

  • データの整合性が最優先
  • 運用を標準化・自動化したい
  • スナップショットを活用したい
  • メモリに余裕がある（8GB以上推奨）

よくある「やらかし構成」集

受託やコンサルティングで実際に遭遇した、あるいは相談を受けた「やらかし」を紹介します。

1. RAIDの上にZFSを載せる地獄

    ❌ やってはいけない構成

ハードウェアRAID
      ↓
    ZFS ← 「RAIDの上にZFSを載せれば最強！」
      ↓
   データ

なぜダメか：

  • ZFSはディスクを直接制御することで真価を発揮する
  • ハードウェアRAIDが間に入ると、ZFSの自己修復機能が働かない
  • RAIDコントローラーのキャッシュ設定次第でデータ破損リスクが上がる

正解：ZFSを使うなら、RAIDはZFSに任せる（RAID-Z）。ハードウェアRAIDカードは「HBAモード」で使うか、使わない。

2. 仮想マシンでZFSを雑に使う事故

    ❌ 危険な構成

仮想化ホスト（VMware/Proxmox等）
      ↓
   仮想ディスク（thin provisioning）
      ↓
   ゲストOS + ZFS ← 「容量足りなくなったら増やせばいいや」

なぜダメか：

  • ZFSはディスクの空き容量が少なくなると、パフォーマンスが激減する
  • thin provisioningで「見かけ上の容量」を割り当てていると、実際の容量不足に気づかない
  • ZFSのCopy-on-Writeは空き容量がないと動けず、最悪データ消失

正解：ZFSを仮想環境で使うなら、thick provisioning（実容量割り当て）にするか、監視を徹底する。

3. 「RAIDがあるからバックアップ不要」という誤解

これが一番多い誤解です。

RAIDはバックアップではありません。

RAIDが守れるのは「ディスクの物理故障」だけです。以下は守れません：

  • 誤操作でファイルを削除した → RAIDには関係ない
  • ランサムウェアに感染した → ミラー先も暗号化される
  • RAIDコントローラーが壊れた → 全ディスク読めなくなる可能性
  • データセンターが火事になった → 全滅

正解：RAIDとバックアップは別物。3-2-1ルール（3つのコピー、2種類のメディア、1つはオフサイト）を守る。

用途別おすすめ構成

「完璧な構成」ではなく、「壊れにくく、壊れても復旧しやすい設計」を重視しています。

家庭サーバー（NAS用途）

    推奨構成：ZFS mirror（2台）または RAID-Z1（3台）

┌─────────────────────────────────────┐
│         家庭向けNAS構成例           │
├─────────────────────────────────────┤
│  OS: TrueNAS / Ubuntu + ZFS        │
│  ディスク: 2〜4台のHDD              │
│  メモリ: 8GB以上（ZFS用）           │
│  構成: mirror または raidz1        │
│  バックアップ: 外付けHDD + クラウド │
└─────────────────────────────────────┘

ポイント：

  • 家庭用途ならZFSのスナップショットが便利
  • 写真・動画の長期保存にはチェックサムが安心
  • 外付けHDDへの定期バックアップは必須

ラズパイ（Raspberry Pi）

    推奨構成：USB SSD + 外部バックアップ

┌─────────────────────────────────────┐
│         ラズパイ構成例              │
├─────────────────────────────────────┤
│  OS: Raspberry Pi OS / Ubuntu      │
│  ストレージ: USB SSD（単体）        │
│  ファイルシステム: ext4            │
│  バックアップ: rsync + 別ストレージ │
└─────────────────────────────────────┘

ポイント：

  • ラズパイでZFSは基本的に非推奨（メモリ不足、CPU負荷）
  • シンプルにext4 + 定期バックアップが現実的
  • SDカードは信頼性が低いのでUSB SSD推奨

小規模業務サーバー

    推奨構成：RAID1 または RAID10 + 定期バックアップ

┌─────────────────────────────────────┐
│       小規模業務サーバー構成例       │
├─────────────────────────────────────┤
│  OS: Ubuntu Server / Rocky Linux   │
│  システム: RAID1（SSD 2台）          │
│  データ: RAID10（HDD 4台）or ZFS    │
│  バックアップ: 日次 + 週次オフサイト│
└─────────────────────────────────────┘

ポイント：

  • 運用者のスキルに合わせて選択
  • ZFSに慣れていないならRAID + LVMが無難
  • バックアップの復元テストを必ず行う

データベースサーバー

    推奨構成：RAID10 + 高速SSD + レプリケーション

┌─────────────────────────────────────┐
│       DBサーバー構成例              │
├─────────────────────────────────────┤
│  OS: 安定したLinuxディストリ        │
│  ストレージ: NVMe SSD RAID10       │
│  ファイルシステム: xfs または ext4  │
│  冗長化: DBレプリケーション併用     │
│  バックアップ: 論理 + 物理バックアップ│
└─────────────────────────────────────┘

ポイント：

  • DBはI/O性能が重要なのでSSD必須
  • ZFSのCopy-on-Writeは書き込み負荷が高いDBには不向きな場合がある
  • ストレージの冗長化とDBのレプリケーションは別物

バックアップ専用機

    推奨構成：ZFS + 大容量HDD + オフサイト転送

┌─────────────────────────────────────┐
│       バックアップサーバー構成例     │
├─────────────────────────────────────┤
│  OS: TrueNAS / Ubuntu + ZFS        │
│  ストレージ: 大容量HDD RAID-Z2     │
│  機能: スナップショット + 圧縮      │
│  転送: zfs send でオフサイトへ     │
└─────────────────────────────────────┘

ポイント：

  • バックアップ専用機こそZFSの真価が発揮される
  • 圧縮・重複排除で容量効率アップ
  • zfs sendで差分転送が可能

フリーランス視点の設計思想

なぜ私はZFSを「条件付き」で勧めるのか

ZFSは素晴らしい技術です。しかし、すべての案件で勧めるわけではありません。

ZFSを勧める条件：

  • クライアントまたは運用者がZFSを理解している、または学ぶ意欲がある
  • メモリに十分な余裕がある
  • 私が継続的にサポートできる
  • データの整合性が最優先事項である

ZFSを勧めない条件：

  • 運用者がLinux初心者で、私が離れた後のサポートがない
  • メモリが4GB未満
  • 「とりあえず動けばいい」という温度感
  • 既存のRAID + LVM環境があり、安定稼働している

なぜ小規模案件ではRAID + LVMを選ぶことが多いのか

小規模案件では、私が去った後も運用できることを重視します。

RAID + LVMは：

  • ネット上に情報が豊富
  • トラブル時に別のエンジニアでも対応しやすい
  • 「枯れた技術」として安定している

ZFSは強力ですが、トラブル時の対応にはそれなりの知識が必要です。運用体制が整っていない現場にZFSを入れると、結局私がずっとサポートし続けることになります。

それが悪いわけではありませんが、クライアントの自立を妨げることにもなりかねません。

技術選定は「正解」ではなく「責任の持てる選択」である

私が大切にしているのは、「最新・最強の技術を使うこと」ではなく、「選んだ技術に責任を持てるかどうか」です。

  • この構成で壊れたとき、どう復旧するか説明できるか？
  • クライアントが理解できる複雑さか？
  • 5年後もサポートできる技術か？

これらに自信を持って「はい」と言えるなら、その技術を選びます。

まとめ

3つのポイント

  1. RAIDとZFSは優劣ではなく役割の違い

    • RAIDは冗長化の「仕組み」
    • ZFSはストレージ管理の「統合システム」
    • 比較するなら「RAID + LVM + ext4」と「ZFS」

  2. ストレージは「最後に効いてくる設計」

    • 壊れるまで気づかない分野だからこそ、最初の設計が重要
    • 「動いているからOK」は最も危険な考え方

  3. 分からないまま使うのが一番危ない

    • ZFSだから安全、ではない
    • RAIDがあるからバックアップ不要、ではない
    • 仕組みを理解して使うことが、データを守る唯一の方法

ストレージ設計は、地味だけど重要な領域です。

この記事が「何となく不安だったけど、どこから手をつければいいか分からなかった」という方の助けになれば幸いです。

構成に迷ったら、用途と運用体制を整理するところから一緒に考えます。