ext4からXFSへのデータ移行と本番切り替え前後のファイルシステム整合性検証

ext4からXFSへの移行は、適切な手順と検証を踏めば安全に実施できる作業です。ただし手順を省略した場合や検証を後回しにした場合には、本番切り替え後にデータ不整合が発覚するリスクがあります。本記事では移行の背景整理から、データ転送・整合性検証・切り替え・切り戻し計画まで、1本の運用シナリオとして解説します。

ext4からXFSへの移行が求められる場面と前提条件

ext4は長年にわたってLinuxの標準ファイルシステムとして信頼されてきましたが、大容量ファイルが多い環境や並列IOが求められるワークロードでは、XFSが優位になる局面があります。動画アーカイブ・バックアップサーバー・大規模データベースの一時領域など、単一ファイルが数GBから数TBに達するユースケースでは、XFSのエクステント管理とジャーナリング方式がスループットの安定性に寄与します。

また、RHEL 9系（AlmaLinux 9・Rocky Linux 9）ではインストール時のデフォルトがXFSになっており、新規サーバーへの移行やディストリビューション更新作業に合わせてext4からXFSへ切り替える運用が増えています。既存環境との標準化という観点から移行を検討する現場も多いです。

重要な前提として、ext4はXFSへのin-place変換に対応していません。btrfsのようなコンバートツールは存在せず、新しくXFSファイルシステムを作成してデータをコピーする方式が唯一の選択肢です。この点を押さえたうえで作業計画を立てることが、後のトラブルを防ぐ基本になります。

移行前の環境確認とバックアップ取得

作業に入る前に、対象ボリュームの現状を正確に把握します。

lsblk -f
df -hT
dumpe2fs -h /dev/sdXN

lsblk -fでデバイス構成・ファイルシステムタイプ・UUIDを確認し、dumpe2fs -hでブロックサイズ・inode数・最終チェック日時を記録しておきます。移行後の比較に使えるほか、予期しないinode使用率の問題を事前に発見できます。

バックアップは省略できません。LVM環境であれば、スナップショットを作成してから作業に入るのが確実です。

lvcreate -s -n snap_data -L 50G /dev/vg0/lv_data

スナップショットをマウントして読み取り可能な状態にしておくと、万一の際にデータを即座に参照できます。また、現行のfstabエントリやfindmnt -o TARGET,OPTIONSの出力を控えておき、マウントオプションを移行後に再現できるよう準備します。ext4固有の不変属性（chattr +i）が設定されているファイルがある場合は、lsattr -R /dataで事前に状況を把握しておきます。XFSではこれらの属性の扱いが異なる場合があるためです。

XFSファイルシステムの作成とrsyncによるデータ転送

新しいLVを作成してXFSをフォーマットします。

lvcreate -n lv_data_xfs -L 200G /dev/vg0
mkfs.xfs -f -L "data_xfs" /dev/vg0/lv_data_xfs

-Lでラベルを付与しておくと後のfstab管理が容易になります。RHEL 9系ではmkfs.xfsのデフォルトでCRC（メタデータ整合性チェック）・finobt（フリーiノードBツリー）・reflink対応が有効になっているため、追加オプションを指定しなくても標準的な構成が得られます。

一時マウントポイントにマウントしてrsyncでデータを転送します。

mkdir /mnt/newxfs
mount /dev/vg0/lv_data_xfs /mnt/newxfs

rsync -aHAXS --numeric-ids --progress \
  /data/ /mnt/newxfs/

オプションの役割を整理すると、-aは再帰・パーミッション・タイムスタンプの保持、-Hはハードリンクの再現、-AはACLの保持、-Xは拡張属性（xattr）の保持、-Sはスパースファイルの効率コピーです。--numeric-idsはUID/GIDを数値のまま転送し、転送先のユーザーデータベースに依存しない点で本番移行に適しています。

本番環境でサービスを停止できない場合は2パス方式が有効です。1回目のrsyncで大半のデータを転送しておき、メンテナンスウィンドウ中に短時間停止→2回目rsync（--delete付き）→切り替えという流れをとります。

# 2回目（差分と削除を同期）
rsync -aHAXS --numeric-ids --delete \
  /data/ /mnt/newxfs/

本番切り替え前後の整合性検証手順

データ転送後の整合性検証は省略すべきではありません。ファイル数・チェックサム・メタデータの3段階で確認します。

ファイル数とサイズの確認

find /data -type f | wc -l
find /mnt/newxfs -type f | wc -l

du -sh /data
du -sh /mnt/newxfs

ファイル数と合計サイズが一致することを最初に確認します。スパースファイルが多い環境ではduの表示値に差が出ることもあるため、du --apparent-sizeと使い分けるとより正確に比較できます。

チェックサムによる内容照合

find /data -type f -exec sha256sum {} \; | \
  sed 's|  /data/|  |' | sort > /tmp/checksums_src.txt

find /mnt/newxfs -type f -exec sha256sum {} \; | \
  sed 's|  /mnt/newxfs/|  |' | sort > /tmp/checksums_dst.txt

diff /tmp/checksums_src.txt /tmp/checksums_dst.txt

sedでパスのプレフィックスを除去することで、相対パス単位での比較が可能になります。差分がゼロであれば、バイト単位での一致が確認できます。大規模なデータセットでは時間がかかるため、重要ファイルを優先してサンプリング検証する現場も多いです。

メタデータの照合とXFS自体の検証

find /data -printf "%P\t%n\t%U\t%G\t%m\t%s\n" | \
  sort > /tmp/meta_src.txt

find /mnt/newxfs -printf "%P\t%n\t%U\t%G\t%m\t%s\n" | \
  sort > /tmp/meta_dst.txt

diff /tmp/meta_src.txt /tmp/meta_dst.txt

%Pはコマンドライン引数を起点とした相対パス、%nはハードリンク数、%Uは数値UID、%Gは数値GIDです。ACLや拡張属性はgetfacl・getfattrで別途確認することも検討します。メタデータの照合が完了したら、デバイスをアンマウントしてXFSファイルシステム自体をドライランでチェックします。

umount /mnt/newxfs
xfs_repair -n /dev/vg0/lv_data_xfs

-nはno-modifyモードで、ファイルシステムを変更せず問題点のみを報告します。エラーが報告されない状態を確認してから、次の切り替え手順に進みます。

fstabの更新と本番切り替えの実施

UUIDを使ってfstabを更新します。まずUUIDを確認します。

blkid /dev/vg0/lv_data_xfs

出力されたUUIDを使い、/etc/fstabを編集します。旧エントリはすぐに削除せず、コメントアウトして残しておきます。

# 旧エントリをコメントアウト
# UUID=<old-ext4-uuid>  /data  ext4  defaults,noatime  0 2

# 新エントリを追加
UUID=<new-xfs-uuid>  /data  xfs  defaults,noatime  0 0

XFSのfstabエントリのパス番号は0 0が標準です。XFSはマウント時にジャーナルから自動回復するため、起動時のfsckパスに組み込む必要がありません。noatimeはアクセス時刻の書き込みを抑制してIOを削減するオプションで、多くの本番環境で採用されています。

fstab編集後はmount -aで構文を確認し、問題がなければ再起動して正常マウントを検証します。

mount -a && echo "fstab OK"
findmnt /data
xfs_info /data

xfs_infoでブロックサイズ・セクションサイズ・CRCの有効状態などXFSのメタデータを確認します。crc=1と表示されていれば、メタデータ整合性チェックが有効な状態です。再起動後にサービスが正常に起動し、対象ディレクトリへのアクセスが問題なく行えることを実際に確認してから、移行完了と判断します。

切り戻し計画と2026年現行環境での注意点

本番切り替え後も旧ext4ボリュームは1〜2週間は保持することを推奨します。LVMスナップショットが残っている場合はそのまま維持し、削除済みの場合はバックアップから元に戻せる体制を整えたうえで、切り戻し手順を文書化しておきます。切り戻しはfstabを旧UUIDに戻して再起動するだけですが、旧ボリュームを削除した後では復旧が困難になります。安定稼働を一定期間確認するまでは、軽率に削除しないことが重要です。

2026年時点の現行環境では以下の差分を押さえておくと、移行後のトラブルを未然に防げます。

• RHEL 9系（AlmaLinux 9・Rocky Linux 9）：デフォルトがXFSのため、mkfs.xfsの既定でCRC・finobt・reflink・sparse inodeがすでに有効です。追加オプションを指定しなくても標準的な構成が得られます。
• Ubuntu 22.04/24.04：ext4がデフォルトです。XFSへ移行する際はxfsprogパッケージ（apt install xfsprogs）の明示的なインストールが必要です。
• XFSの縮小非対応：一度作成したXFSボリュームはサイズを縮小できません。容量設計は拡張方向のみを前提とし、初期サイズを慎重に決定する必要があります。
• クォータ管理の変更：ext4のquotaツールチェーンとXFSのxfs_quotaは管理方式が異なります。クォータを設定している環境では、移行後にXFS形式でプロジェクトクォータを再設定する必要があります。
• systemdとのマウント順序：データ領域が/var配下にある場合、systemd-journaldの起動に影響することがあります。マウント順序を/etc/systemd/system/配下のユニットファイルで明示的に制御するか、fstabのx-systemd.requiresオプションを活用します。
• reflinkとCopy-on-Write：RHEL 9系ではreflink対応が既定で有効です。cp --reflink=autoによる高速コピーが使えますが、バックアップツールの一部はreflink環境で動作が変わることがあるため、使用ツールの対応状況を確認しておきます。