大容量データのバックアップにはBtrfsとXFSのどっちがおすすめ？運用リスクとメリットを比較

大容量データのバックアップ先として、ファイルシステムの選択は運用の効率と安全性を左右する重要要素です。
特にLinux環境では、BtrfsとXFSが大規模ストレージの主力候補として挙がります。
しかし、両者の設計思想は大きく異なり、単純な性能比較だけで結論を出すことはできません。
バックアップという観点では、スナップショットやデータ整合性の保証方法、障害発生時の復旧手順の明確さが、日々の運用負荷に直結します。

まず、Btrfsは「次世代ファイルシステム」として、スナップショットや圧縮、重複排除、サブボリュームといった先進機能を内包しています。
これらの機能は、バックアップ運用に革命をもたらす可能性を秘めている一方で、長期的な運用ではフラグメンテーションやメモリ使用量の増加がリスクとして顕在化しやすい点に注意が必要です。

この表からも分かる通り、Btrfsは機能面で圧倒的にリッチですが、その代償として運用の複雑性が増すというトレードオフがあります。
特に、電源断やカーネルパニック後のマウント失敗は、Btrfsにおいて依然として現実的な脅威です。
一方、XFSはシンプルかつ高性能で、大容量単一ファイルの扱いや並列書き込みに強みを持ちます。
バックアップ先としてRAID構成と組み合わせる場合、XFSは予測可能な動作と安定したパフォーマンスを提供してくれるでしょう。

では、どちらを選ぶべきか。
重要なのは、バックアップデータの更新頻度と、障害時の許容ダウンタイムです。

• 毎日のように細かな差分バックアップを取り、過去バージョンへのアクセスが頻繁に必要なら、Btrfsのスナップショット機能は非常に強力な武器になる
• 大容量のアーカイブを一度書き込んで長期間保持するだけなら、シンプルなXFSのほうがメンテナンスコストが低く、予期せぬトラブルに遭遇する確率も下がる
• バックアップ自体をさらに別媒体に複製する仕組みがあるなら、Btrfsの自己修復機能は二次的なデータ腐敗対策として有効だが、その分、定期的なスクラブ処理とモニタリングが必須になる

結論として、私の見解は明確です。
「バックアップの主目的がバージョニングと高速リストアならBtrfs、安定性と予測可能性を最重視するならXFS」。
ただし、いずれの場合でも、ファイルシステムだけに依存せず、複数の物理メディアやオフサイトバックアップとの併用を強く推奨します。
最終的には、あなたの運用リソースとリスク許容度が判断基準となるでしょう。
まずは試験環境で実際のワークロードを流し、障害シナリオをシミュレーションしてから本導入を決めることをお勧めします。

バックアップ用途で考えるべきファイルシステム選択の基本軸

大容量データのバックアップ先としてファイルシステムを選ぶ際、多くの方が「速度」や「信頼性」といった漠然とした基準を持ちがちです。
しかし、バックアップという運用には、通常のワークロードとは異なる独自の評価軸が存在します。
単なるベンチマークスコアの高低ではなく、データの長期保存性、障害からの復旧容易性、そして運用管理の手間という三つの視点が、実際の現場ではより重みを持ちます。

まず、バックアップシステムに求めるべき第一の要件は、書き込んだデータが時間経過後も正しく読み出せることです。
これは「データの静的非整合性」への耐性と呼ばれ、ビットローテーションやストレージ媒体の経年劣化によって引き起こされるサイレントデータ破損をどう防ぐかが問われます。
この点で、ファイルシステムがチェックサムによる検証機能をネイティブで持つか否かは、極めて重要な分岐点となります。

次に考慮すべきは、バックアップ運用に特有の「バージョニング」の扱いです。
日常的な業務では、過去の特定時点のデータに遡ってリストアするケースが頻繁に発生します。
このとき、ファイルシステムレベルでスナップショットを取得できるか、あるいは外部ツールに依存するかは、リストア時間と運用の複雑性に直結します。
スナップショットが軽量かつ高速に作成できるならば、バックアップの世代管理は劇的に楽になるでしょう。

さらに、バックアップ先のストレージは、多くの場合、大容量かつ連続した書き込み負荷にさらされます。
この状況下で、ファイルシステムがフラグメンテーションをどの程度許容するか、また、長期運用後のパフォーマンス劣化がどの程度発生するかも、見逃せないポイントです。
特に、領域の動的割り当てやコピーオンライト（CoW）を採用するファイルシステムでは、断片化がパフォーマンスに与える影響が無視できません。

また、バックアップは「最後の砦」であるがゆえに、災害時や機器故障時の復旧手順が確立されているかどうかが、最終的な評価を左右します。
ファイルシステムが専用の修復ツールを提供しているか、そのツールの成熟度やドキュメントの充実度はどうか。
これらは、実際のトラブルシューティングにおいて、エンジニアの疲労度と復旧成功率に大きく寄与します。

以上の軸を整理すると、バックアップ用途でのファイルシステム選択は、以下のような評価項目に集約できます。

• データ整合性保証の仕組み（チェックサム、自己修復機能の有無）
• スナップショットやクローンといったバージョニング機能の使い勝手
• 大容量かつ長時間の書き込みに対する性能安定性と断片化耐性
• 障害発生時の復旧ツールの充実度と復旧手順の明確さ
• 運用管理に必要なメンテナンスコスト（定期スクラブ、再構築時間など）

これらの軸は、いずれも単独で判断するのではなく、相互にトレードオフの関係にある点に注意が必要です。
例えば、高度なデータ保護機能を備えるほど運用管理の複雑性が増し、シンプルな設計ほど復旧は容易になる反面、柔軟な世代管理は外部ツールに頼らざるを得なくなります。
重要なのは、自分の運用環境でどのリスクが許容できて、どのコストを払えるかという現実的な判断です。

次章以降では、この基本軸に沿って、BtrfsとXFSという二つの有力なファイルシステムを詳細に比較していきます。
それぞれの設計哲学や実装の特徴を理解することで、あなたのバックアップ運用に最適な選択肢が自ずと見えてくるはずです。

Btrfsが持つ先進機能とバックアップ運用での強み

Btrfsは、しばしば「次世代ファイルシステム」と称されるだけあって、従来のファイルシステムにはない先進的な機能を数多く内包しています。
バックアップ運用という観点から見た場合、その強みは単なる高性能にとどまらず、運用者の意図をダイレクトにファイルシステムレベルで実現できる柔軟性にこそあります。
スナップショット、チェックサム、圧縮、重複排除――これらの機能が統合的に提供されている点が、Btrfsを特別な存在にしているのです。

Btrfsのスナップショット機能をどう活用するか

Btrfsのスナップショットは、サブボリューム単位で瞬間的に作成できる、コピーオンライト方式の軽量な世代管理機能です。
この仕組みの何が優れているかというと、スナップショット作成時には実データを複製せず、メタデータの参照情報だけをコピーする点にあります。
そのため、大容量のバックアップボリュームであっても、スナップショットは数秒で完了し、ディスク消費量も変更差分のみで済みます。

実際の運用では、例えば毎時スナップショットを取得し、過去24時間分を保持するといった戦略がごく自然に実現できます。
リストア時には、任意のスナップショットをマウントして参照するか、サブボリュームとして丸ごと復元するかを選択可能です。
この柔軟性は、バックアップからの部分的なファイル復旧や、開発環境への即時反映など、現場の多様なニーズに応えます。

ただし、スナップショットを乱用すると、参照元のスナップショットが存在する限り、元のデータブロックが解放されなくなる点には注意が必要です。
不要なスナップショットを定期的に削除する運用ルールを併設することで、ストレージ容量の逼迫を防ぎつつ、安全な世代管理を実現できるでしょう。

データ整合性を支えるチェックサムと自己修復の仕組み

Btrfsのもう一つの大きな特徴は、データブロックとメタデータの両方に対してチェックサムを保持していることです。
多くのファイルシステムがメタデータのみを保護するのに対し、Btrfsは実データにもCRC32Cチェックサムを付与することで、サイレントデータ破損を検出できるように設計されています。

さらに、RAID1やRAID5/6などのミラーリング構成と組み合わせた場合、Btrfsはチェックサム不一致を検知すると、正常なコピーから自動的にデータを修復する「自己修復」機能を発揮します。
この仕組みは、バックアップデータの長期的な健全性を担保する上で極めて有効です。
ハードウェアのビットエラーや媒体の経年劣化によるデータ腐敗を、ファイルシステムが能動的に検出・修復してくれるのは、運用者の大きな安心材料となるでしょう。

定期的なスクラブ処理（オンラインでのチェックサム検証ジョブ）をcronなどでスケジュールしておけば、人が手を動かさずともデータ整合性を監視し続けられます。
この自動化された健全性チェックは、大規模なバックアップボリュームにおいて特にその真価を発揮します。

圧縮・重複排除がバックアップ容量に与える効果

Btrfsは、ファイルシステムレベルで透過的な圧縮機能（ZSTD、LZO、ZLIB）をサポートしています。
バックアップデータは特にテキストベースのログやデータベースダンプなど圧縮効率の高いものが多いため、この機能を有効にするだけでストレージ消費量を劇的に削減できるケースが少なくありません。

圧縮はファイル書き込み時にリアルタイムで適用され、読み出し時には自動的に展開されるため、アプリケーション側は圧縮の存在を意識する必要がありません。
また、圧縮レベルをデータの種類ごとに調整することも可能で、性能と容量のトレードオフを柔軟にコントロールできます。

さらに、重複排除（デデュプリケーション）機能もオンラインまたはオフラインで利用可能です。
バックアップには同一ファイルや類似ブロックが繰り返し現れる傾向があるため、重複排除による容量節約効果は非常に大きいと言えます。
特に、複数の仮想マシンイメージやコンテナイメージをバックアップする環境では、その効果は顕著に表れるでしょう。

ただし、圧縮と重複排除にはCPUリソースを消費するという代償があります。
バックアップウィンドウが厳しい場合や、CPUがボトルネックとなる環境では、これらの機能を無効化するか、オフライン処理に切り替える選択肢も検討に値します。
いずれにせよ、容量削減とパフォーマンスのバランスを実際のワークロードで測定した上で導入を決定するのが賢明です。

XFSが大容量バックアップで評価される安定性と性能

Btrfsが多機能で先進的であるのに対し、XFSは「よく磨かれた実用主義」の塊のようなファイルシステムです。
1990年代初頭からSGIによって開発され、現在ではLinuxカーネルに標準搭載される主要なファイルシステムの一つとして、エンタープライズ領域で圧倒的な採用実績を誇ります。
大容量バックアップの文脈でXFSが評価される理由は、そのシンプルさと予測可能性に尽きます。
多機能であるがゆえの複雑性を排し、特定のワークロードで一貫したパフォーマンスを発揮する設計は、バックアップのようなミッションクリティカルな運用において非常に頼りになる存在です。

シンプルな設計がもたらす予測可能な動作と復旧の容易さ

XFSの最大の美点は、その設計が極めてストレートであることです。
エクステントベースのマッピング、遅延アロケーション、そしてジャーナリングによるメタデータ保護――これらは決して目新しい機能ではありませんが、長年にわたって徹底的にテストされ、バグ修正が積み重ねられてきました。
その結果、XFSは想定外の動作をする確率が極めて低いファイルシステムとして知られています。

バックアップ運用において、この「予測可能性」は非常に大きな価値を持ちます。
例えば、ディスク使用率が90%に達したときの挙動、大量のファイル削除後のパフォーマンス回復、あるいはRAID再構築中の応答性など、あらゆるシナリオにおいてXFSはおおむね期待通りの動きを見せます。
これは、運用者が長年の経験則に基づいてシステム設計をできるということであり、不意のトラブルに遭遇するリスクを大幅に低減してくれます。

復旧の容易さもXFSの強みです。
xfs_repairツールは非常に成熟しており、ジャーナルログを活用した高速な復旧が可能です。
ファイルシステムが破損した場合でも、修復手順が明確でドキュメントも充実しているため、緊急時でもパニックに陥りにくいでしょう。
また、xfs_dbという低レベルデバッグツールも提供されており、経験豊富な管理者であればメタデータを直接解析して問題を特定することも可能です。
このような「ツール群の充実度」は、Btrfsがまだ発展途上にある部分と明確な差があります。

さらに、XFSはオンライン拡張（パーティションサイズの拡大に伴うファイルシステムの拡張）をサポートしています。
バックアップボリュームが逼迫した際に、ディスクを追加してシームレスに容量を増やせるのは実運用で非常に役立つポイントです。

大容量単一ファイルと並列書き込みにおけるパフォーマンス特性

XFSは、大規模なマルチスレッド環境でのスケーラビリティに特に優れています。
これは、バックアップ運用がしばしば複数のクライアントからの同時書き込みや、大規模なダンプファイルの並列転送を伴うことを考えれば、大きなアドバンテージです。
XFSのアロケーショングループという設計は、複数のCPUコアが同時に異なる領域にアクセスする際の競合を最小化し、結果として高い並列処理性能を実現しています。

また、大容量単一ファイルの扱いにおいてもXFSは定評があります。
データベースのベースバックアップや仮想マシンのディスクイメージなど、サイズが数百GBから数TBに及ぶファイルを扱うケースでは、XFSのエクステントベースの管理が効率的に働きます。
断片化が発生しにくく、シーケンシャルリード/ライトのスループットが非常に安定しているため、バックアップの転送速度が予測しやすいのも魅力です。

ただし、XFSには一つの顕著な制約があります。
それはファイルシステムの縮小がサポートされていないという点です。
一度拡張したボリュームを縮小するには、データを別領域に退避させて再構築するしかありません。
この制約は、バックアップ領域を柔軟にリサイズしたい運用ではネックになり得るため、設計段階で容量計画を慎重に行う必要があります。

全体的に見て、XFSは「何が起こるか分からない不安」を嫌う管理者にとって、非常に心強い選択肢であると言えるでしょう。
派手な機能はありませんが、その堅牢性と高性能は、大容量バックアップの基盤として文句のつけようがない実力を備えています。

運用リスクを徹底比較 – Btrfsの注意点とXFSの落とし穴

先進機能の裏には、必ず運用リスクが伴います。
BtrfsもXFSも、完璧なファイルシステムではありません。
それぞれに固有の弱点や制約が存在し、それを理解せずに導入すると、バックアップの信頼性を損なうどころか、最悪の場合、データそのものを危険に晒すことになりかねません。
ここでは、両ファイルシステムの「落とし穴」を具体的に洗い出し、実運用でどう対策すべきかを考えていきます。

Btrfs運用で直面しがちなフラグメンテーションとメモリ消費

Btrfsの最大の運用リスクは、コピーオンライト（CoW）設計に起因するフラグメンテーションと、それに伴うメモリ消費の増大です。
CoWはスナップショットやデータのバージョニングを可能にする核となる仕組みですが、書き込みのたびに新しいブロックを割り当てるため、長期間運用するとファイルの断片化が進行しやすくなります。

特に、バックアップ先として頻繁に差分書き込みを行うケースでは、この影響が顕著に現れます。
断片化が進むと、シーケンシャルリードであってもランダムアクセスに近い挙動を示し、リストア時のスループットが著しく低下する可能性があります。
Btrfsでは、定期的なデフラグ処理（btrfs filesystem defrag）が事実上の必須メンテナンスとなる点を認識しておくべきでしょう。

また、Btrfsはメタデータ管理にRed-Blackツリーやバックリファレンスといった複雑な構造を採用しているため、大量のスナップショットやサブボリュームを抱えると、カーネルメモリの消費量が際限なく増加する傾向があります。
特に、メモリが十分でない組み込み系や古いハードウェアでは、OOM（Out of Memory）によるシステムクラッシュを引き起こすリスクすらあります。
この問題は、バックアップサーバーに搭載するメモリ容量を当初の想定よりも余裕を持って設計することで緩和可能ですが、運用計画の段階で見過ごされがちなポイントです。

さらに、BtrfsのRAID5/6実装は依然として不安定な部分が残されており、本番バックアップ用途での採用は推奨されません。
パリティ計算の不具合や、ディスク障害時の再構築失敗事例が複数報告されています。
この点は、公式ドキュメントでも注意喚起がなされているため、ミラーリング（RAID1）またはシングル構成での利用を基本とするのが無難です。

XFSで縮小できない制約とRAID構成時の注意事項

XFSの最大の制約は、先述した通りファイルシステムの縮小が一切サポートされていないことです。
これは、設計上の決定であり、今後も実装される見込みはほぼありません。
バックアップボリュームを運用する際、当初の見積もりよりも実際のデータ量が少なかった場合でも、領域を縮小して別の用途に割り当てることはできません。
LVMと組み合わせて論理ボリューム単位で管理すれば、物理領域の再割り当ては可能ですが、ファイルシステム自体は拡張しかできないという制約は常に頭に入れておく必要があります。

また、XFSはメタデータのジャーナリングを採用していますが、このジャーナルサイズはファイルシステム作成時に固定されます。
大容量バックアップで多数のファイル書き込みが発生する環境では、ジャーナルが頻繁にラップすることでパフォーマンスが低下するケースがあります。
これを回避するには、mkfs.xfsのオプションでジャーナルサイズを適切に調整するか、外部ジャーナルデバイスを別途用意するといった工夫が求められます。

RAID構成との相性にも注意が必要です。
XFS自体はRAIDを意識しない設計ですが、アロケーショングループのサイズやストライプ単位をRAIDのブロックサイズに合わせないと、書き込みアライメントがずれて性能が大きく損なわれることがあります。
特に、RAID5やRAID6のようなパリティ構成では、パディッシュ（部分書き込みによるパリティ再計算）が頻発し、想定を下回るスループットしか得られないケースが少なくありません。
バックアップサーバーを構築する際は、mkfs.xfsの-suオプションや-sオプションを活用して、ストレージ構成に最適化したパラメータを設定することを強く推奨します。

さらに、XFSはディスク障害時にマウントができなくなる「フェイルドマウント」状態に陥ることがあります。
この場合、xfs_repairを実行すれば多くのケースで復旧可能ですが、修復中にさらに別の障害が発生すると、データの一部が失われるリスクも否定できません。
復旧手順を事前に文書化し、定期的に訓練しておくことが、XFS運用における現実的なリスク対策となるでしょう。

障害シナリオ別 – マウント失敗からの復旧手順を検証する

どんなに堅牢なファイルシステムを選んでも、ハードウェア障害や人為的ミス、あるいは予期せぬ電源断によって、バックアップボリュームがマウントできなくなる事態は起こり得ます。
そうした危機的シナリオにおいて、ファイルシステムごとの復旧手法の違いは、最終的なデータ救出の成否を分ける重大な要素です。
ここでは、BtrfsとXFSそれぞれの定期メンテナンス手法と、障害発生時の挙動の差異を詳しく見ていきます。

Btrfsスクラブとxfs_repair – 定期メンテナンスの実践比較

Btrfsにおける定期メンテナンスの要は、スクラブ（scrub） 処理です。
これは、ファイルシステム上の全データブロックとメタデータに対してチェックサムを検証し、不一致が発見された場合には、冗長構成（RAID1など）が有効であれば自動修復を試みるバックグラウンドジョブです。
スクラブはオンラインで実行でき、システムを停止する必要がないため、運用中のバックアップサーバーでも負荷をかけて実施できます。
頻度としては、週次または月次での実行が推奨されます。

スクラブの進捗状況はbtrfs scrub statusで確認でき、処理中に発見されたエラーはシステムログに記録されます。
重要なのは、スクラブはエラー検出に特化しており、ファイルシステム構造そのものの修復は行わないという点です。
構造的な不整合が疑われる場合は、別途btrfs checkコマンドを用いたオフライン修復を検討する必要があります。
ただし、このbtrfs check --repairは非常に危険な操作であり、公式ドキュメントでも「バックアップを取った上で実行せよ」と強く警告されています。
実際の現場では、不整合が発生した段階で、スクラブで修復できない場合はデータを退避させてファイルシステムを再構築する方が安全とされています。

一方、XFSの定期メンテナンスは、xfs_repairを中心に構成されます。
XFSはオンラインでのチェック機能は限定的なため、定期的なメンテナンスは基本的にアンマウント状態で実行します。
ファイルシステムを一度アンマウントし、xfs_repair -nでドライラン（実際の変更を加えずに問題を報告するモード）を実行し、問題がなければxfs_repairで修復を行うのが標準的な運用フローです。

xfs_repairの強みは、ジャーナルログを利用した高速復旧にあります。
通常のアンマウント後の修復では数分で完了することが多く、大規模ボリュームでも比較的短時間で処理が終わります。
また、xfs_repair -L（ログをゼロクリアして強制修復）という最終手段も用意されており、これはジャーナルが破損して通常の復旧ができない場合に有効ですが、最後の書き込みデータが失われるリスクを伴います。

両者を比較すると、Btrfsはオンラインでの継続的な健全性チェックが可能である反面、構造修復に踏み切るハードルが非常に高いのに対し、XFSはオフラインでの修復ツールが成熟しており、手順も確立されているという違いが明確です。

電源断やカーネルパニック後の挙動の違い

突然の電源断やカーネルパニックが発生した場合、ファイルシステムのジャーナル処理が途中で中断され、一貫性が失われるリスクがあります。
このシナリオでの挙動は、BtrfsとXFSで顕著な差が見られます。

Btrfsはコピーオンライト設計のため、書き込み途中での電源断に対して理論上は強いとされています。
つまり、中途半端な書き込みはアトミックに適用されず、直前の一貫した状態に戻るという考え方です。
しかし実際には、Btrfsは電源断後にマウントできなくなるケースが他のファイルシステムよりも多く報告されています。
この原因は、メタデータの複雑なツリー構造にあり、ツリーの一部が不整合を起こすと、マウントプロセス自体が失敗することがあるからです。
復旧にはbtrfs rescueコマンド群を使用しますが、これらのツールはまだ発展途上であり、成功するかどうかはケースバイケースと言わざるを得ません。

対照的に、XFSはジャーナリングによるメタデータ保護が非常に堅牢です。
電源断後でも、次回マウント時にジャーナルがリプレイされ、ほとんどのケースで自動的に一貫性が回復します。
この挙動は長年にわたる実績に裏打ちされており、予期せぬシャットダウン後のトラブルに遭遇する確率はBtrfsよりも明らかに低いと言えるでしょう。
万が一、自動リプレイが失敗した場合でも、xfs_repairによる復旧手順は確立されているため、管理者の対応に迷いが生じにくいのも大きな利点です。

以上の検証から、「障害からの自動復旧力」という点ではXFSに軍配が上がるものの、Btrfsは日常的なオンラインチェックで異常を早期発見できるという別の価値を持っていることが分かります。
どちらを選ぶかは、あなたが「予防重視」か「復旧確実性重視」かという運用ポリシーに依存すると言えるでしょう。

バックアップ更新頻度で変わる – ワークロード別の適正ファイルシステム

ファイルシステムの選択は、絶対的な優劣ではなく、運用ワークロードとの適合性で判断すべきものです。
同じ大容量バックアップでも、毎時取得する差分バックアップと、四半期に一度のフルアーカイブでは、求める要件がまったく異なります。
ここでは、バックアップの更新頻度という切り口から、BtrfsとXFSのどちらがどのシナリオで輝くのかを具体的に検討します。

頻繁な差分バックアップにはスナップショットが生きる

日次や時間単位で変更分を追跡するようなアクティブなバックアップ運用では、Btrfsのスナップショット機能が圧倒的なアドバンテージを発揮します。
例えば、データベースのトランザクションログや、バージョン管理システムのリポジトリ、あるいはコンテナイメージのレイヤー情報など、頻繁に細かな変更が発生するデータをバックアップする場合を想像してみてください。

Btrfsでは、変更前の状態をスナップショットとして保持しながら、新たな書き込みをCoWで別ブロックに記録するため、フルバックアップ相当の世代管理を数秒単位で実現できます。
この特性は、リストア時に「2時間前の状態に戻したい」といった要求に即座に応えることを可能にします。
しかも、各スナップショットは実データの差分のみを消費するため、ストレージ効率も極めて良好です。

また、Btrfsはサブボリューム単位でスナップショットを取得できるため、バックアップ対象を論理的に分割し、それぞれに異なる保持ポリシーを適用することも容易です。
例えば、システム領域は毎時スナップショットで24時間分保持し、ユーザーデータ領域は日次で1ヶ月分保持する、といった柔軟な運用がファイルシステムレベルで実現できます。

ただし、頻繁なスナップショット運用では、先述したフラグメンテーションやメモリ消費のリスクが顕在化しやすい点には留意が必要です。
スナップショットの数が増えすぎると、参照元のブロックが解放されず、見かけ上の空き容量が減少する「スナップショットスタック」現象も発生し得ます。
これを防ぐには、保持するスナップショットの上限を決め、不要な世代を定期的に削除する運用ルールを徹底することが求められます。

長期保存アーカイブにはシンプルなXFSが適する理由

一方、一度書き込んだらほとんど変更せず、長期間にわたって保存するだけのバックアップ――いわゆる「コールドアーカイブ」や「コンプライアンス用データ保存」においては、XFSのシンプルで安定した設計が大きな魅力となります。

こうしたワークロードでは、スナップショットや圧縮、重複排除といった高度な機能はほとんど活用されません。
代わりに重視されるのは、データが長期間にわたって正しく読み出せることと、保存中に不意な障害が発生しないことです。
XFSはメタデータのジャーナリングによる保護が堅牢で、しかも設計が単純なため、ファイルシステム自体に内在するバグや予期せぬ動作が非常に少ないという実績があります。

さらに、長期保存アーカイブでは、バックアップメディア自体の入れ替えや、ストレージシステムの移行が発生することが少なくありません。
XFSは異なるカーネルバージョン間での互換性が高く、古いカーネルで作成されたXFSボリュームでも、新しいカーネルで問題なくマウントできるケースがほとんどです。
この相互運用性の高さは、10年単位でのデータ保管を考える際に非常に重要な要素です。

また、XFSはアーカイブ用途で発生する大容量の単一ファイル（例：tarアーカイブやデータベースダンプ）の読み書きに非常に適しています。
エクステントベースの領域管理により、ファイルが断片化しにくく、リストア時の読み出し速度が安定しています。
定期的なメンテナンスも、ファイルシステムのチェックサム検証が不要なため、スクラブ処理のような負荷のかかるバックグラウンドジョブを実行する必要がありません。

以上の観点から、更新頻度が高く世代管理を重視するならBtrfs、書き込み後の静的な長期保存が目的ならXFSという明確な棲み分けが見えてきます。
両者は競合するというよりも、むしろ異なるレイヤーのニーズに応える補完的な関係にあるとさえ言えるでしょう。

実際の導入前にテスト環境で検証すべきポイント

どんなに素晴らしい理論や機能も、実際の運用環境にそのまま当てはまるとは限りません。
ハードウェア構成、ネットワーク帯域、同時アクセス数、そしてバックアップ対象データの特性――これらはすべて、ファイルシステムの振る舞いに影響を与える変数です。
したがって、本導入の前に必ずテスト環境を構築し、想定されるワークロードを再現した上で検証を実施することを強く推奨します。
ここでは、その具体的な進め方と、特に注意すべきポイントを整理します。

性能測定と障害シミュレーションの進め方

性能測定の第一歩は、実際のバックアップデータをサンプルとして用意し、それを用いた書き込み・読み込みテストを実施することです。
単なるシーケンシャルライトのベンチマーク（例：ddコマンドによる連続書き込み）だけでは不十分で、ランダムアクセスや小ファイルの大量書き込みなど、多様なパターンをカバーする必要があります。
ツールとしては、fioやbonnie++が定番です。
特にfioは、I/Oエンジンやブロックサイズ、キュー深度などを細かく設定できるため、実際のアプリケーション挙動を模擬したテストが可能です。

測定すべき指標は、スループット（MB/s）だけでなく、レイテンシの変動（最大応答時間）やI/O待ち時間の分布にも注目してください。
バックアップはバッチ処理ではありますが、リストア時にはユーザーが待つことになるため、ピーク時のレイテンシが大きいと運用上のストレスとなります。
また、ファイルシステムごとにキャッシュ戦略やライトバックのタイミングが異なるため、メモリ容量を変えた場合の挙動変化も検証しておくと良いでしょう。

障害シミュレーションも欠かせません。
電源断を模擬するために、テスト中のサーバーを強制的にシャットダウンし、再起動後のマウント可否とデータ整合性を確認します。
さらに、ディスク障害を模擬するために、RAIDアレイから1台のドライブを物理的に抜き差しし、再構築中のパフォーマンス低下や、ファイルシステムがどのように応答するかを観察してください。
Btrfsの場合は、スクラブが再構築中にどの程度の負荷をかけるかも実測ポイントです。
これらのテストを自動化し、複数回繰り返すことで、偶発的なエラーではなく再現性のある振る舞いを把握できます。

バックアップ媒体の冗長化構成とファイルシステムの相性

バックアップ用ストレージは、単一ドライブではなくRAIDや複数台のNASで構成されることが一般的です。
ここで見落としがちなのが、ファイルシステムの冗長化機能と、ハードウェア/ソフトウェアRAIDとの相性です。

Btrfsは独自のRAID1/RAID10/RAID5/RAID6を実装しており、mdadmなどの外部RAIDと組み合わせるよりも、BtrfsネイティブのRAID機能を利用する方が、チェックサムと連動した自己修復が期待できます。
しかし、前述の通りRAID5/6はまだ不安定なため、現実的な選択肢はBtrfs RAID1またはRAID10に限定されると考えてください。
また、BtrfsネイティブRAIDでは、ディスクの抜き差しや再構築の手順がmdadmとは異なるため、運用ドキュメントを事前に整備しておく必要があります。

一方、XFSはRAIDに対して中立的な設計であり、mdadmやハードウェアRAIDとの組み合わせが非常に安定しています。
ここでの検証ポイントは、アロケーショングループのサイズやストライプユニットを、RAIDのストライプサイズやチャンクサイズに合わせて適切に設定できているかです。
特に、RAID5/6ではパリティの配置とファイルシステムのブロック割り当てがずれると、ライトアンプリフィケーションが発生し、想定を大きく下回る書き込み速度になることがあります。
mkfs.xfsの-su（ストライプユニット）と-sw（ストライプ幅）オプションを活用し、テスト環境で複数のパラメータを試して最適値を探ることをお勧めします。

さらに、バックアップ媒体がネットワーク越しのNASやSANである場合、ネットワーク遅延や帯域制限がファイルシステムのパフォーマンスに与える影響も検証対象です。
iSCSIやNFS経由でマウントしたボリューム上で、BtrfsとXFSがどう振る舞うかを比較することで、実際の導入環境に近い条件での判断材料が得られます。
テスト環境での入念な検証こそが、本番運用でのトラブルを未然に防ぐ最大の投資であることを、ぜひ意識しておいてください。

まとめ – あなたの運用スタイルに最適なファイルシステムはどれか

ここまで、BtrfsとXFSの機能特性、運用リスク、障害復旧の実態、そしてワークロード別の適性について詳細に比較してきました。
最終的にどちらを選ぶべきかは、あなたのバックアップ運用が「何を最優先するか」に集約されます。
どちらが優れているかではなく、どちらがあなたの制約条件と目的により適合するかという視点が重要です。

まず、Btrfsを選ぶべきケースを明確にしておきましょう。
スナップショットによる頻繁な世代管理が必須であり、かつ運用チームにLinuxファイルシステムへの深い知見がある場合、Btrfsは非常に強力な選択肢となります。
データ整合性のチェックサム検証や自己修復機能は、長期的なデータ健全性への不安を軽減してくれます。
また、圧縮や重複排除による容量節約効果が、ストレージコストの削減に直結する環境では、導入メリットが大きいと言えます。
ただし、その代償として、フラグメンテーション対策やメモリ消費の監視、スナップショットの寿命管理といった追加の運用タスクを受け入れる覚悟が必要です。
Btrfsは「機能を活用する運用」が求められるファイルシステムであり、受動的な管理ではその真価を発揮しません。

一方、XFSが輝くのは、安定性と予測可能性を最優先する運用です。
バックアップは「最後の砦」である以上、不測の事態でファイルシステム自体が足かせになるリスクは極力避けたい――そう考える管理者には、XFSのシンプルで実績ある設計が心強い味方となります。
特に、長期保存アーカイブや、書き込み後の変更がほぼ発生しないバックアップ用途では、Btrfsの高度な機能がオーバースペックになるばかりか、かえって複雑性を増す要因になりかねません。
また、障害発生時の復旧ツールの成熟度や、電源断後の自動リカバリ性能は、XFSがBtrfsに対して明確に優位なポイントです。
XFSは「手をかけずに安定稼働させる」運用に適しており、リソースが限られた現場や、ファイルシステムに頻繁に介入したくない管理者にとって理想的な選択肢でしょう。

では、両者の選択基準をさらに実践的に整理するために、以下の判断フローを提示します。

• バックアップの更新頻度が高く（例：日次以上）、過去バージョンへのアクセスが頻繁に発生する → Btrfsを有力候補とする
• バックアップデータが大容量単一ファイル（例：データベースダンプ、VMイメージ）で構成され、書き込み後の変更が稀 → XFSを選択する
• 運用スタッフがBtrfsのトラブルシューティングに習熟しており、障害時の対応マニュアルを整備できる → Btrfsの機能をフル活用できる
• 管理者が一人または少人数で、ファイルシステムの運用負荷を最小化したい → XFSが無難で確実
• ストレージコストを極限まで抑える必要があり、圧縮や重複排除が効果的と見込める → Btrfsで容量削減を図る価値がある
• ハードウェアが古くメモリ容量が限られている、またはRAID5/6を必須とする → 現実的にはXFSを選ぶべき

最後に、どちらのファイルシステムを選んだとしても、バックアップは複数世代・複数媒体に分散させるという原則を忘れないでください。
ファイルシステムはあくまで手段であり、単一障害点（SPOF）を生まない設計が本来のデータ保護の要諦です。
Btrfsのスナップショットであれ、XFSの堅牢性であれ、それらは「バックアップ戦略全体」の中の一要素に過ぎません。
オフサイトバックアップやクラウドストレージとの併用、そして定期的なリストア訓練によって、はじめて真の安心が得られることを、最後に強調しておきます。

あなたの運用スタイルに照らし合わせて、両ファイルシステムの特性がどのようにフィットするか。
この比較記事が、その判断の一助となれば幸いです。