btrfsはバックアップファイルシステムとして適していますか？

現在、ext4の上にかなり伝統的なバックアップファイルシステム構造があります。バックアップがbackup-DATE作成されるたびに、ファイルがrsyncされる新しいフォルダーが作成されます（rsyncの--link-destオプションを使用してハードリンクが作成されます）。

bitrotについて読んだので、すべてのファイルのチェックサムを透過的にしたいと思います。どうやらext4はそれができないようですが、btrfsはデータチェックサム（さらには組み込みのRAID1モード）のサポートを提供します。まず、btrfsRAID、サブボリュームスナップショット、送受信などの高度な機能を使用せずにデータチェックサムをサポートする「ダム」ファイルシステムとして使用したいと思います。

しかし、彼らのウィキは、バックアップの目的でファイルシステムへの信頼を実際に刺激するものではありません。

「多くの人が信頼してそれを使用していますが、まだ問題が発見されています。データのバックアップを保持してテストし、それらを使用する準備をする必要があります。」- はじめに

「btrfsは安定していますか？長い答え：[..]何をする場合でも、テスト済みの適切なシステム外（およびサイト外）のバックアップを保持することをお勧めします。」- よくある質問。

私の使用例は、オフラインバックアップを使用することです。そのため、ディスクはほとんど使用されず（時間単位など）、頻繁にプラグ/アンプラグされます（eSATAまたはUSB 3.0）。信頼できるファイルシステムを持つことは必須です。ext4 wrtよりも悪くなってはいけません。停電、汚れたシャットダウンなど

バックアップのためにファイルシステムとしてbtrfsを使用することが実際に推奨されますか？btrfsの適切性を低下（または向上）させる可能性のある他のプロパティはありますか？

私はこれが過大評価されていると思うので、短い答えを提供します。

btrfs（サブ）コマンドに関するメインカーネルWikiを読むと、次の2つのコマンドがあることがわかります。

1. 「バックアップ」を作成する：btrfs-send
2. そして復元：btrfs-restore

念のため、これはバックアップではない（設計されている）ことを意味しますが、スナップショットファイルシステムであることを意味します。

したがって、いいえ、バックアップとして使用しないでください。バージョン管理されたファイルシステムとして使用して、テストして戻ってください。それに依存しないでください。

最近、最新のカーネル4.10.0でbtrfsファイルシステムに問題がありました。TRIMはどこかに正しく実装されていないようで、ファイルシステムはvirtualbox VMで破壊されました。VMwareに切り替えた後も、ファイルシステムは破損しており、驚くべきbtrfs checkことに、エラーを検出して修正することができませんでした。最後に、ext4に切り替えました。

良い点：データは失われませんでした。btrfsは、少なくとも読み取りに関しては常に一貫しているように見えますが、実動の準備がまだ遠いことを示しています。

とにかく、重複排除用の牛コピーの機能が必要なため（正確にはユースケース）、サーバーではまだバックアップボリュームとして使用しています。従来のファイルシステムでは、データのサイズが大きすぎます。

更新

私はまだサーバーにファイルシステムを持っています（上記を参照）が、これをここに投稿した直後に壊れました。現在、700Gの大きな読み取り専用バックアップボリュームがあり、を使用してすべてをコピーしようとすると、ext4で最大7TBに拡張されますtar|tar。時間がないため、新しいカーネルバージョンで処理できるかどうかはまだ確認していません。実際の問題は、「トランザクションのアボート」で、書き込み可能でマウントしてから約2秒後にボリュームを読み取り専用で再マウントします。元の原因は、おそらく、btrfs-convertこのボリュームを作成したときに何年も前に使用したの壊れたバージョンであり、トランザクションの中断につながる再現可能なボリュームのすべての損傷btrfs checkを見つけることができる、現在の限られた機能セットです。ファイルシステムが正常であると言うのではなく、その他の問題。