ストレージ変更・復旧マニュアル

分割・LVM・FS・mount・ZFS の変更を扱う。ディスク診断で対象を特定してから順序を決める。/dev/vdb・vg_data/lv_data・/srv/data は置換用の例。唯一のデータで練習しない。

やりたいこと	参照先
拡張後も容量が同じ	各層の拡張
新規ディスク・mount	作成と mount 確認
FS の破損	オフライン検査・復旧
記録済み tank の保守	ローカル構成記録

下層の容量を上層へ反映する

filesystem と下位層を確認する

# 対象ディレクトリの実 device と filesystem を読む
findmnt -T /srv/data

SOURCE/FSTYPE/TARGET で以下の方法を選ぶ。未 mount のディレクトリは root disk にある場合がある。

# filesystem・LV・PV・partition・disk をたどる
lsblk -f

暗号化・thin・RAID は独自の容量と正常性確認が必要。

# PV 容量と VG 所属を読む
sudo pvs -o pv_name,pv_size,pv_free,vg_name

/dev/vdb1 が対象か、名前だけでなく ID・安定パスで確認する。

# VG に割当可能な空きがあるか確認する
sudo vgs -o vg_name,vg_size,vg_free

VFree が足りれば PV 拡大を省いて LV 増量を計画できる。

# LV 型・容量・thin data/metadata 使用量を読む
sudo lvs -a -o lv_name,vg_name,lv_size,segtype,data_percent,metadata_percent

通常の linear LV と thin pool は別の判断が必要。df -hT /srv/data で基準を記録する。

図を準備しています

図は通常の linear LV。thin pool・RAID・暗号化は対象外。下位ディスク・partition の後に pvresize、既に VG free があれば LV から始める。block device の拡張だけでは df は増えない。

下位 device 拡大後に PV を更新する

通常の linear LV の手順。partition 上の PV は同じ partition を拡大し、kernel が新境界を認識してから pvresize する。

# 対象 PV に拡大した下位領域を認識させる
sudo pvresize /dev/vdb1

pvs/vgs で PSize/VFree 増加を確認する。増えなければ partition・mapping を調べてから進む。

# 確認した LV を 10 GiB 増やす
sudo lvextend -L +10G /dev/vg_data/lv_data

+10G は増分、+ なしは総量。先に VFree、後で LSize を確認する。filesystem は次で別途拡大する。

pvresize は拡張済みの対象 PV と確認して実行する。+10G は増分。以降は FS に応じて一方を選び、lvs と df を確認する。-r の自動呼出しも対応と結果の確認が必要。

FSTYPE に合う一つを選ぶ

# ext4 の場合だけ：拡大 LV を filesystem に反映する
sudo resize2fs /dev/vg_data/lv_data

引数は block device。online 拡大は対応が必要。失敗時に lvreduce を汎用復元として使わない。

# XFS の場合だけ：mount 済み filesystem を拡大する
sudo xfs_growfs /srv/data

引数は mount point。ext4 との選択肢で、findmnt で XFS を先に確認する。

# filesystem の容量増加を確認する
df -hT /srv/data

変更前と lvs を照合し、アプリ書込も確認する。下位だけ大きければ未拡大の層が残る。

縮小は単なる逆コマンドではない。対応 FS を先にオフライン縮小し、その後 LV・partition を縮める。境界誤りはデータ切断になる。XFS に ext4 手順を当てず、新 FS への移行を検討する。thin pool は metadata と data の両方を監視する。

作成・mount・起動設定を分ける

signature と現在の利用先を確認する

# 書き込まず disk の signature を列挙する
sudo wipefs -n /dev/vdb

-n は書込禁止。空でもデータ不存在の証明にはならず、partition・PV・RAID・記録も確認する。

# partition table・容量・境界を読む
sudo fdisk -l /dev/vdb

既存 table を保存する。上書き可能と確認した対象だけ fdisk を使い、書込前に p、取消は q。partition 作成と format を一体化しない。

# mount 用の UUID と型を読む
sudo blkid

fstab は新 filesystem の UUID。旧 disk や PV の UUID ではない。

wipefs -n は署名を見るだけ。mkfs・pvcreate・partition 書込みは内容を変える。空き媒体・backup・配置を確認して作成する。fdisk も GPT 対応。LVM 新設は pvcreate → VG → LV → mkfs の各対象を確認する。

新規作成例：空で上書き可能と確認した partition に新 VG と ext4 を作る。mount・swap・既存 PV/RAID でないことを先に確認する。作成は一つずつ実行し失敗時は停止、mkfs へ進まない。vg_newdata は新規対象に限る。

LVM 新規作成：空 partition を特定する

# 確認した空 partition の安定パスを記録する
ops_part=/dev/disk/by-id/REPLACE_WITH_CONFIRMED_EMPTY_PARTITION

置換して同じ shell で続ける。disk 全体や既存データ partition を指定しない。

# 対象の階層と filesystem 利用を確認する
lsblk -f "${ops_part:?Set the verified partition}"

wipefs -n・pvs・swapon --show と RAID/暗号化所属も確認する。既存利用が不明なら先に止める。

# 上書き可能と確認した partition だけを PV 化する
sudo pvcreate "${ops_part:?Set the verified partition}"

pvs で確認してから進む。metadata を書くため、後で LVM を消しても元データは戻らない。

# この PV から未存在の独立 VG を作る
sudo vgcreate vg_newdata "${ops_part:?Set the verified partition}"

vgs の容量・空きを確認する。同名があれば止め、既存ストレージを意図せず変更しない。

# 新 VG に 10 GiB の LV を割り当てる
sudo lvcreate -L 10G -n lv_data vg_newdata

空きを確認し、lvs で新 LV の名前・容量を確認する。この新 LV だけを format する。

# 新規 LV だけに ext4 を作る
sudo mkfs.ext4 /dev/vg_newdata/lv_data

filesystem 構造を書き込む操作で、既存 filesystem の検査ではない。次に mount の識別子を取得する。

# 新 filesystem の UUID・TYPE を記録する
sudo blkid /dev/vg_newdata/lv_data

TYPE=ext4 を確認し、この UUID を mount 手順に使う。アプリの所有者・権限も設定する。

partition を適切な tool で作り安定 path を確認する。過去の sda/sdb を使わない。UUID を fstab に設定し、以下の手順で機器・容量・アプリ権限を確認する。10G 分の VG 空きが必要。

UUID=REPLACE_WITH_REAL_UUID /srv/data ext4 defaults 0 2

mount 前にディレクトリを確認する

# mount 先ディレクトリを用意する
sudo mkdir -p /srv/data

既存内容を確認する。mount は隠すだけで移行しない。fstab 行を実 UUID/FSTYPE に合わせて追加し、元ファイルと他の行を保存する。

# fstab と mount 情報を検証する
sudo findmnt --verify --verbose

エラーを先に直す。成功してもアプリ権限は付与されない。

# systemd ホストで生成 mount unit を更新する
sudo systemctl daemon-reload

管理設定の再読込で、mount 自体は行わない。

# 確認した一つの fstab mount を有効にする
sudo mount /srv/data

findmnt で SOURCE・型・option、df とアプリユーザーのアクセスを確認する。

# unmount が占有で止まる場合に process を特定する
sudo fuser -vm /srv/data

対応アプリの書込完了と停止後に sudo umount。fuser の kill option を問い合わせと混同しない。

fstab は ext4 の例。他 FS は別設計。mount は既存内容を隠すだけで移動しない。まず一つの対象を検証する。busy は fuser -vm で確認し、lazy unmount を参照消滅や初期化可能の証拠としない。

検査・snapshot・backup の限界

目的	方法と前提
ext4	unmount 後に e2fsck -fn。修復書込み前に backup
XFS	unmount 後に xfs_repair -n。dirty log を安易に -L で捨てない
Btrfs	scrub は checksum と冗長修復、check は構造検査。--repair は通常保守でない
LVM snapshot	通常 COW snapshot は容量監視が必要。満杯で無効化し得る。thin は別
Snapshot ≠ backup	同一 pool 障害では両方を失い得る。独立コピーで復元検証

offline 評価前に unmount を確認する

アプリ停止・読めるデータ保存・hardware 確認後、findmnt -S DEVICE で未 mount を確認する。root は救援環境を使う。ext4/XFS は選択肢。

# ext4 の場合：未 mount の対象を書かずに検査する
sudo e2fsck -fn /dev/vg_data/lv_data

-f は検査強制、-n は修復拒否。非ゼロの診断を読み、副本保存後に修復を判断する。自動で -y にしない。

# XFS の場合：未 mount filesystem を読取評価する
sudo xfs_repair -n /dev/vg_data/lv_data

dirty log 等は診断と復旧計画に従う。-L は log とデータを失い得るため既定の次手順ではない。

Btrfs の容量・subvolume・scrub を分けて読む

# Btrfs の場合：data/metadata 割当と空きを読む
sudo btrfs filesystem usage /srv/data

metadata 圧迫は df の空きだけで判断せず、複製 profile も見る。

# Btrfs filesystem の subvolume を列挙する
sudo btrfs subvolume list /srv/data

通常の directory と区別する。snapshot は入れ子の subvolume 内容を再帰コピーしない。

# 既存 scrub とエラーを先に確認する
sudo btrfs scrub status /srv/data

必要時だけ別途 scrub start し、I/O 時間帯と最終 status を確認する。構造修復の check --repair とは別。

swap：変更前に使用量を見る

# swap device・容量・使用量・優先度を読む
swapon --show

free -h と比較してから停止を検討する。swapoff は RAM に戻すため圧迫し得る。

# swap と file reclaim の傾向設定を読む
sysctl vm.swappiness

使用メモリの閾値ではなく回収方針。基準を記録し、kernel 文書と負荷で効果を確認する。

Btrfs コマンドは対象 FS でのみ使う。swapfile は hole・COW 制約があり専用作成方法を使う。swapoff はページを戻すメモリが必要。swappiness は0–100限定ではなく機器と負荷で評価する。

tank：保持したローカル構成記録

記録済み by-id（保守前に GUID と物理 slot を再確認）：

/dev/disk/by-id/ata-WDC_WD40EFZZ-68CPAN0_WD-WX12DA5H2PCN
/dev/disk/by-id/ata-WDC_WD40EFZZ-68CPAN0_WD-WX12DA5H234S

2026-07-02 の記録であり現状検出ではない。zpool status・zfs get・実 unit で照合する。閾値はこの機器用で、過去の sda/sdb を交換識別子にしない。

項目	記録
Pool	tank · 2-way mirror · WD40EFZZ 4TB × 2 · D4-320 USB3
ashift / ARC	12 / 32GB (/etc/modprobe.d/zfs.conf)
Mount	/tank

Dataset	recordsize	compression	用途 / 共有
tank	128K	lz4	ルート
tank/media	1M	lz4	動画 / SMB + NFS
tank/photos	128K	lz4	写真 / SMB + NFS
tank/data	128K	lz4	データ / SMB + NFS
tank/backup	128K	lz4	backup 親 / 非共有
tank/backup/system	1M	lz4	restic システム backup / 非共有

tank の device ID と健康を確認する

# GUID・実パス・詳細エラーを読む
zpool status -gLPv tank

-g は GUID、-L は link 解決、-P は完全パス、-v はデータエラー詳細。交換前に by-id・slot と照合する。

# pool・vdev の容量と割当を読む
zpool list -v tank

quota/reservation 等があるため dataset の空きとは一致しない。

# dataset 階層・使用量・mount point を読む
zfs list -r tank

USED/AVAIL/REFER/MOUNTPOINT を見る。snapshot・子 dataset の影響は du だけでは見えない。

# 値と local/inherited の来源を読む
zfs get -r mountpoint,compression,recordsize tank

変更前に来源を記録する。継承へ戻すことと同値の再設定は別。歴史表をそのまま上書きしない。

event・転送量・cache を別々に見る

# global ZFS event を pool・時刻で絞る
zpool events -v

全 pool の event であり、tank を位置引数にしない。

# 各 vdev の I/O を継続比較する
zpool iostat -v tank 1

最初は通常累計平均、以降は間隔値。偏りを見て Ctrl-C。ARC は arc_summary で別に調べる。

zpool events に tank を pool 引数として渡さない。recordsize 変更は既存ファイルを再配置しない。ARC 上限はローカル方針で、命中率は cold start と working set を分けて見る。

scrub と snapshot は別の保守作業

# 保守時間帯に pool 検証を開始する
sudo zpool scrub tank

既存 scrub/resilver を確認し、status で進捗・完了エラーを見る。コマンド復帰と完了は別。

# 整理前に未使用名の snapshot を作る
sudo zfs snapshot tank/data@before-reorg

アプリ整合性を先に調整する。サービス間 transaction は保証されない。この dataset だけで、暗黙の再帰処理ではない。

# snapshot の存在と参照容量を確認する
zfs list -t snapshot -r tank/data

名前・時刻を今回と合わせる。同一 pool の snapshot だけでは pool 障害を守れない。

# snapshot と現在の path 変更を比較する
sudo zfs diff tank/data@before-reorg

path の変更で、内容 patch ではない。snapshot directory から別の確認場所にコピーし、内容・権限を検証して対象だけを置換する。単一ファイル復元で dataset 全体を rollback しない。

scrub の負荷を計画し完了結果を確認する。mirror 修復は backup の代わりにならない。rollback は以後の変更を捨てるため単一ファイルは snapshot 閲覧や別 clone から復元する。snapshot 削除は増分送信の基点にも影響する。

サービス	unit / path
SMB / NFS	smb.service / nfs-server.service
ZFS mount / events	zfs-mount.service / zfs-zed.service
メトリクス / 月次 scrub	zfs-prometheus.timer / zfs-scrub-monthly@tank.timer
Grafana dashboard UID	host-li-home-0-zfs
Grafana alert file	/etc/grafana/provisioning/alerting/zfs-storage.yaml

共有記録は media/photos/data、NFS は192.168.31.0/24。容量80/90%、ARC50%は再評価する。共有障害は先に dataset の mount を確認して testparm・exportfs -v・network を見る。showmount だけで NFSv4 の正常性は判断しない。

特定した障害範囲を復旧

障害	対応 / 完了の根拠
mirror の片側故障	GUID・by-id・slot と残存側・backup を確認し交換。resilver 完了とエラーを確認
import 失敗	機器と import 候補を確認し他ホスト未使用を確かめて指定 import。安易な -f/-a を避ける
USB 切断	配線・電源・kernel log と安定した by-id を確認。全 bus 再走査や全盤 online をしない

LVM lvextend · Btrfs administration · OpenZFS manuals · Kernel swappiness