【2025年04月版】ZFS 学習メモ 【初学者向け】

# はじめに

ZFSの学習メモです。初学者向けです。

PROXMOX等で使い始めたので、再学習しました。

後述の Oracle/Fujitsu のリンクより学習しています。

# ZFSとは

- ZFSは高機能なファイルシステム兼ボリュームマネージャで、Sun Microsystemsが開発しました。  
- データの整合性保証、スナップショット、重複排除など多数の機能を持ち、高信頼性と柔軟性を提供します。  
- RAID機能を内蔵し、エラーの自己修復やプール単位の管理が可能です。

---

# ZFS のメリットとデメリット

## ZFS のメリット

| 項目 | 説明 |
|------|------|
| **データ整合性の保証** | 書き込み時にチェックサムを計算し、読み出し時に整合性を検証・修復可能。Silent data corruption（静かなデータ破損）を防止。 |
| **スナップショット・クローン** | スナップショット（読み取り専用）とクローン（書き込み可能）を高速かつ省容量で作成可能。 |
| **統合されたRAID機能** | RAID-ZによってRAID5/6のような冗長性を提供し、write hole問題も回避。 |
| **ARCキャッシュによる高速アクセス** | メモリ上にデータをキャッシュし、高速な読み出し性能を実現。 |
| **スケーラビリティ** | 数ペタバイト規模のデータにも対応でき、大規模ストレージに強い。 |
| **プールによる柔軟なディスク管理** | 複数の物理ディスクを1つの「zpool」にまとめて一元管理可能。 |
| **圧縮・重複排除（dedup）** | データ圧縮や同一データの排除により、ディスク容量の節約が可能。 |

---

## ZFSのデメリット

| 項目 | 説明 |
|------|------|
| **メモリ使用量が多い** | パフォーマンスを最大限に引き出すには、最低でも8GB以上のRAMが推奨される。 |
| **動的にRAID構成を変更できない** | 例えば、RAIDZ1にあとからディスクを1本だけ追加することはできない（新しいvdevとして追加は可能）。 |
| **重複排除の負荷が高い** | Dedup機能は大量のメモリとCPUリソースを消費しやすく、用途によっては逆効果。 |
| **導入難易度がやや高め** | 初学者には操作や管理が複雑に感じられる場合がある。特にzpoolやzfsコマンドの理解が必要。 |
| **非公式なLinux対応（OpenZFS）** | LinuxではOpenZFSとして提供されており、カーネル統合が難しくトラブル対応時に注意が必要。 |

---

# ZFS の使用例

ZFSではディスクを「プール（zpool）」としてまとめ、その上にファイルシステム（zfs）を作ります。

## 1. プールの作成（例：RAID-Z構成）

```bash
sudo zpool create tank raidz /dev/sd[bcd]
```

- `tank`: プールの名前
- `raidz`: RAID5相当の冗長性
- `/dev/sdb`, `/dev/sdc`, `/dev/sdd`: 対象のディスク

## 2. ファイルシステムの作成

```bash
sudo zfs create tank/data
```

- `tank/data`: `tank`プール内のZFSファイルシステム
- 自動で `/tank/data` にマウントされる（Linuxでは `/tank/data`）

## 3. スナップショットの作成とロールバック

```bash
# スナップショットの作成
sudo zfs snapshot tank/data@snap1

# ファイルをいじったあと、スナップショットに戻す
sudo zfs rollback tank/data@snap1
```

## 4. 圧縮の有効化

```bash
sudo zfs set compression=on tank/data
```

- ファイルを書き込むと自動で圧縮され、容量節約が可能

## 5. スペースの確認・管理

```bash
zfs list
zpool status
zpool list
```

- `zfs list`: ZFSファイルシステムの使用状況
- `zpool status`: プールの健全性チェック
- `zpool list`: プールの使用量など概要

## 6. データ整合性の確認（scrub）

```bash
sudo zpool scrub tank
```

- 全データを読み出してチェックサムで検証
- 問題があれば自動修復（冗長性がある場合）

---

# ZFS を導入するにあたってのポイント

ZFSを導入・設計する際には、**初期構成を慎重に決めること**が非常に重要です。あとから柔軟に構成変更できない点もあるため、以下のポイントを参考に設計します。

## 1. **用途に合ったRAIDレベルを選ぶ**

| RAIDレベル | 最小台数 | 特徴 | 向いている用途 |
|------------|----------|------|----------------|
| `mirror`   | 2台〜     | RAID1相当。高速＆シンプル | 重要データ、仮想マシン |
| `raidz1`   | 3台〜     | RAID5相当、1台故障までOK | バックアップや低コスト構成 |
| `raidz2`   | 4台〜     | RAID6相当、2台まで冗長 | アーカイブ、大容量安全設計 |
| `raidz3`   | 5台〜     | 3台まで冗長性あり | ミッションクリティカル用途 |

:::note warn 
**RAIDZはあとからHDDを1本だけ追加できない**ため、余裕を持った構成がよい
:::

## 2. **vdev（仮想デバイス）の組み合わせを意識する**

- ZFSではストレージ構成は「複数のvdevの集合体（pool）」として扱われる。
- vdev単位での性能と冗長性が決まり、**プール全体の性能は最も遅いvdevに依存**する。
- 性能を求める場合は「複数のmirror vdev」を使うのが有効（RAID10風の構成）。

## 3. **ECCメモリの使用を推奨**

- ZFSは**データ整合性に非常に厳格**で、誤ったメモリビットによる破損も検知できるが、
  メモリ自体が壊れていた場合は「破損したまま整合性が取れてしまう」ことがある。
- そのため、本番運用では**ECCメモリ付きのマシン**が推奨される。

## 4. **RAMは多めに確保（最低8GB、理想は16GB以上）**

- ZFSはキャッシュ（ARC）を活用して性能を引き出す。
- 圧縮・スナップショット・scrub・dedupなどの高度な機能を使うならRAMは多いほど有利。

## 5. **スナップショットの設計**

- スナップショットは低コストでバックアップのように使える。
- ただし**削除しないとどんどん容量を食う**ため、自動削除ポリシー（cron + `zfs destroy`）の設計が重要。

## 6. **パーティショニングを使わず、ディスク全体を使うのが原則**

- 例外もあるが、ZFSは物理ディスクを丸ごと使うことで最大パフォーマンスを発揮。
- 変則的なパーティション分割は将来のトラブル原因になることも。

## 7. **ZIL/SLOGとL2ARCの設計**

| 用語 | 説明 | 推奨される場合 |
|------|------|----------------|
| **ZIL/SLOG** | 同期書き込みログ（ZFS Intent Log）を高速SSDに退避 | DBなど**sync writeが多い**場合 |
| **L2ARC** | セカンドレベルキャッシュ。読み込みキャッシュをSSDに保存 | 大容量データで**頻繁に読み込み**が発生する場合 |

## 8. **バックアップ戦略は別途用意**

- ZFS自体は堅牢だが「rm -rf」やウイルスによるデータ削除までは防げない。
- スナップショット + 別サーバへの`zfs send | zfs recv`で**オフサイトバックアップ**を構築するのが理想。

---

# ZFS でよく使うコマンド

ZFSでよく使うコマンドは大きく分けて2種類に分類されます。

## zpool（ZFSプール管理）コマンド一覧

| コマンド | 概要 |
|----------|------|
| `zpool create` | プールの作成 |
| `zpool destroy` | プールの削除 |
| `zpool import` | 既存のプールをインポート |
| `zpool export` | プールのエクスポート（アンマウント） |
| `zpool status` | プールの状態確認（エラー・リビルド進行状況など） |
| `zpool list` | プールの一覧と使用量表示 |
| `zpool iostat` | I/Oパフォーマンスの表示 |
| `zpool scrub` | データ整合性チェック（スクラブ）を開始 |
| `zpool clear` | エラー状態のクリア |
| `zpool add` | プールにデバイスを追加（vdev単位） |
| `zpool remove` | 一部のvdevやデバイスをプールから削除（※限定機能） |
| `zpool replace` | 故障したデバイスを交換 |
| `zpool offline` / `zpool online` | デバイスを一時的にオフライン/オンラインにする |
| `zpool upgrade` | プールのフォーマットバージョンをアップグレード |

---

## zfs（ファイルシステム管理）コマンド一覧

| コマンド | 概要 |
|----------|------|
| `zfs create` | ファイルシステムの作成 |
| `zfs destroy` | ファイルシステムやスナップショットの削除 |
| `zfs list` | ファイルシステムの使用量・プロパティ表示 |
| `zfs set` | プロパティの設定（例：圧縮、マウントポイント） |
| `zfs get` | 現在のプロパティの取得 |
| `zfs snapshot` | スナップショットの作成 |
| `zfs rollback` | スナップショットに巻き戻す |
| `zfs clone` | スナップショットからクローンの作成 |
| `zfs send` | スナップショットをバイナリで出力（バックアップ用） |
| `zfs receive`（`recv`） | `send`されたデータを受信（レストア） |
| `zfs rename` | ファイルシステムやスナップショットの名前変更 |
| `zfs promote` | クローンを独立ファイルシステムに昇格 |
| `zfs mount` / `zfs unmount` | 手動でマウント／アンマウント |

---

## よく使う組み合わせ例

```bash
# プール作成
zpool create tank mirror /dev/sdb /dev/sdc

# 圧縮付きファイルシステム作成
zfs create -o compression=on tank/data

# スナップショット作成と復元
zfs snapshot tank/data@snap1
zfs rollback tank/data@snap1

# バックアップ送信
zfs send tank/data@snap1 > backup.zfs
# バックアップ受信
zfs receive tank/restore < backup.zfs
```

---

# 運用のポイント

ZFSの運用時には、堅牢な設計とはいえ注意すべきポイントがいくつかあります。

## 1. **データ消失・破損を防ぐための注意**

| 項目 | 説明 |
|------|------|
| **ECCメモリの使用** | ZFSはデータ整合性を保証しますが、非ECCメモリでは逆に整合性のある“誤ったデータ”を保持するリスクがあります。 |
| **定期的な`scrub`の実行** | `zpool scrub`を月1回程度実行し、サイレントデータ破損を検知・修復します。 |
| **スナップショットの運用管理** | 多数のスナップショットを放置すると容量を食います。定期的に古いものは削除する仕組みを整えましょう。 |
| **バックアップは別途確保** | ZFSは高信頼でも、「rm -rf」やランサムウェアには無力です。`zfs send` + `zfs recv`でオフサイト/他ノードにバックアップを推奨。 |

## 2. **運用時のパフォーマンス・容量に関する注意**

| 項目 | 説明 |
|------|------|
| **空き容量の維持（推奨80%以上使用しない）** | ZFSは空き容量が少ないとパフォーマンスが大きく低下します。使用率は70〜80%程度に留めるよう意識します。 |
| **ARCキャッシュのメモリ消費に注意** | ZFSはメモリを多く使うため、アプリケーションと競合しないように調整 (`zfs_arc_max`) が必要な場合があります。 |
| **dedupは原則使わない** | 重複排除はRAMを大量消費し、誤って使うと性能が著しく低下することがあります（検証の上で使用判断）。 |

## 3. **障害時の対応・運用整備**

| 項目 | 説明 |
|------|------|
| **ディスクのシリアル番号を記録しておく** | `zpool status -v`でエラーが出たとき、物理ディスクの特定に役立ちます。 |
| **zpool statusを監視** | `zpool status`に出る`DEGRADED`や`FAULTED`をcronやZabbix等で監視するのがおすすめ。 |
| **RAID-Zの特性理解** | 例：RAIDZ1で1台故障時に`scrub`ではなく`replace`を適切に行うこと。操作ミスでプール崩壊する恐れも。 |
| **電源断対策** | 書き込み中に停電するとSLOG（同期書き込み）に依存するワークロードでデータ損失リスクが高くなるため、UPSの導入が理想的です。 |

## 4. **監視・ログ・通知の仕組み**

| 項目 | 説明 |
|------|------|
| `zpool status`のログを毎日取得 | `zpool status`の結果をログに記録し、異常が出たら通知。 |
| `zpool list`や`zfs list`で容量監視 | 容量しきい値超過時のアラートを設定。 |
| エラー発生時にメール通知 | `smartd`, `systemd`, `cron`などでZFS状態に応じた通知を構成。 |

## 5. **アップグレードと互換性管理**

| 項目 | 説明 |
|------|------|
| **OSアップデート時のZFS互換性確認** | OpenZFSのカーネルモジュールはOSバージョン依存。事前検証を行うこと。 |
| **zpool upgradeは慎重に** | 一度アップグレードすると古いバージョンのZFSでは読み込めない。アップグレード前にバックアップ必須。 |

---

# ZFS の障害時

ZFSの障害時対応については、**エラーの検出 → 状況確認 → 適切な修復**の3段階で考えるのが基本です。

## よくある障害の種類と状態

| 状態名 | 意味 | 対応概要 |
|--------|------|-----------|
| `ONLINE` | 正常稼働中 | 問題なし |
| `DEGRADED` | 冗長構成の一部に障害 | 冗長性が失われているが稼働継続中、**修復が必要** |
| `FAULTED` | デバイスが致命的に故障 | ZFSが完全に読み書きできない状態、**早急な交換**が必要 |
| `UNAVAIL` | プールにアクセス不可 | zpool自体が認識不能、復旧困難な場合あり |
| `REMOVED` | デバイスが物理的に外された | 意図的でなければ**再接続**・**import再試行** |
| `OFFLINE` | 管理者が手動で無効化 | `zpool online`で再有効化できる |

## 基本対応フロー

### 1. 状況の確認

```bash
zpool status
```

出力結果から、障害の発生している**ディスク名・エラー内容・状態**を確認します。

### 2. ディスク障害時の復旧例（RAID構成前提）

#### ケース：`DEGRADED` + デバイス交換

```bash
# 交換用ディスクの確認（新しいディスクにパーティション不要）
lsblk

# 故障ディスクをオフラインにする（例：/dev/sdb）
sudo zpool offline tank /dev/sdb

# ディスク物理交換後、再構成を開始
sudo zpool replace tank /dev/sdb /dev/sdX  # 新しいディスク名に置き換え

# 状態確認（リビルド進行中）
zpool status
```

### 3. スクラブを使ってデータ整合性の確認・修復

```bash
sudo zpool scrub tank
```

- 定期実行（週1または月1推奨）
- エラーがあるブロックは他の冗長データから自動修復

#### scrub後のエラー発見時の対応例

```bash
zpool status -v
```

- `errors: Permanent errors have been detected in the following files:`  
  と表示された場合、そのファイルは**完全には修復されていない**ことを意味します。
- バックアップからの復元が必要になるケースがあります。

## 修復できない場合の対応（緊急）

| 状況 | 対応策 |
|------|--------|
| プールがimportできない | `zpool import -f` や `zpool import -m`（mountなし）など試す |
| デバイス名が変わって復旧できない | `zpool import -d /dev/disk/by-id`で明示的に指定 |
| プール全体がUNAVAIL | バックアップからの復元を前提に再構築が必要なことも |

## 障害通知・検知

| 方法 | 説明 |
|------|------|
| `zpool status`を定期実行 | cronでログ保存 or メール送信 |
| `smartd`との連携 | SMART障害検知での早期対処が可能 |
| `zed`（ZFS Event Daemon） | イベント発生時に自動通知スクリプトを実行できる（zpool scrub終了通知なども可能） |

# リンク

- [Oracle Solaris ZFS 管理ガイド](https://docs.oracle.com/cd/E24845_01/pdf/819-6260.pdf)
- [Oracle Solaris の管理: ZFS ファイルシステム](https://docs.oracle.com/cd/E26924_01/pdf/E25824.pdf)
- [ZFSを使ってみよう～基本編～ - ZFSの特長 -](https://www.fujitsu.com/jp/documents/products/computing/servers/unix/sparc-enterprise/technical/documents/02_zfs.pdf)
- [ZFSを使ってみよう～基本編～ - ZFSの信頼性/可用性 -](https://www.fujitsu.com/jp/documents/products/computing/servers/unix/sparc-enterprise/technical/documents/03_zfs.pdf)
- [Oracle Solaris 11 ZFSを使ってみよう（概要・設計ガイド）](https://www.fujitsu.com/jp/documents/products/computing/servers/unix/sparc/technical/document/solaris11_zfs_gde01.pdf)
- [Oracle Solaris 11 ZFSを使ってみよう（実践編）](https://www.fujitsu.com/jp/products/computing/servers/unix/sparc/technical/tools/solaris11-zfs/)
- [ZFSを使ってみよう （基本編）](https://www.fujitsu.com/jp/documents/products/computing/servers/unix/sparc-enterprise/technical/documents/00_ZFS.pdf)
- [ZFSを使ってみよう （応用編）](https://www.fujitsu.com/jp/documents/products/computing/servers/unix/sparc-enterprise/technical/documents/zfs_apply.pdf)
- [How to ZFS | Gitbook](https://chibiegg.gitbooks.io/how-to-zfs/content/zpool.html)

# さいごに

ZFSをつかっていきたい