はじめに

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構成）

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

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

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

sudo zfs create tank/data

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

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

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

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

4. 圧縮の有効化

sudo zfs set compression=on tank/data

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

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

zfs list
zpool status
zpool list

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

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

sudo zpool scrub tank

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

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

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

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

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

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`	手動でマウント／アンマウント

よく使う組み合わせ例

# プール作成
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. 状況の確認

zpool status

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

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

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

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

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

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

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

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

sudo zpool scrub tank

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

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

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終了通知なども可能）

リンク

さいごに

ZFSをつかっていきたい