btrfsはバックアップファイルシステムとして適していますか？
現在、ext4の上にかなり伝統的なバックアップファイルシステム構造があります。バックアップが作成されるたびに、ファイルがrsyncされる新しいフォルダーbackup-DATEが作成されます（rsyncの--link-destオプションを使用してハードリンクが作成されます）。
Bitrotについて読んだので、すべてのファイルのチェックサムを透過的に取得したいと思います。どうやらext4はそれを行うことができませんが、btrfsはデータチェックサム（および組み込みのRAID1モード）のサポートを提供します。まず、btrfsを、RAID、サブボリュームスナップショット、送受信などの高度な機能を使用せずにデータチェックサムをサポートする「ダム」ファイルシステムとして使用したいと思います。
ただし、彼らのwikiは、バックアップの目的でファイルシステムへの信頼を実際に刺激するものではありません。
「多くの人が確実に使用していますが、それでも問題が見つかります。データのバックアップを保持してテストし、使用する準備をしておく必要があります。」 - はじめに
「btrfsは安定していますか？長い答え：[..]何をするにしても、テスト済みの適切なオフシステム（およびオフサイト）バックアップを維持することをお勧めします。」 - [〜＃〜]よくある質問[〜＃〜] 。
私のユースケースは、オフラインバックアップを作成することです。そのため、ディスクは（数時間のように）ほとんど使用されず、頻繁に接続/切断されます（eSATAまたはUSB3.0）。信頼できるファイルシステムを持つことは必須です。 ext4wrtより悪くてはいけません。停電、汚れたシャットダウンなど.
バックアップの目的でファイルシステムとしてbtrfsを使用することを実際に推奨していますか？ btrfsのその他のプロパティにより、適切性が低下（または上昇）する可能性がありますか？
これは見過ごされていると思うので、簡単な答えを提供します。
btrfs（sub-）commands についてメインのカーネルwikiを読むと、次の2つのコマンドがあることがわかります。
- 「バックアップ」を作成 ：
btrfs-send - および 復元 ：
btrfs-restore
念のため、これはバックアップではない（設計されている）スナップショットファイルシステムであることを意味します。必要に応じて、バックアップではなく「柔軟」にロールバックすることを想定しています。
したがって、—いいえ、バックアップとして使用しないでください—テストして戻ることができるバージョン管理されたファイルシステムとして使用してください。それに頼らないでください。
最近、最新のカーネル4.10.0でbtrfsファイルシステムに問題がありました。 virtualboxでファイルシステムが破壊されましたVM TRIMはどこかに正しく実装されていないようであり、AFAIKはサブボリュームのインデックス番号と関係があるためです。VMwareに切り替えた後、ファイルシステムはまだ壊れていて、驚くべきことにbtrfs checkはエラーを見つけて修正することができませんでした。最後に、ext4に切り替えました。
良いこと：私はデータを失いませんでした。 btrfsは、少なくとも読み取りに関しては常に一貫しているように見えますが、それでも本番環境の準備にはほど遠いことがわかりました。
とにかく、重複排除のために牛のコピー機能が必要なため、サーバーではまだバックアップボリュームとして使用しています（まさにあなたのユースケース）。データは、従来のファイルシステムにはサイズが大きすぎます。
更新
サーバーにはまだファイルシステムがありますが（上記を参照）、これをここに投稿した直後に壊れました。現在、700Gの大きな読み取り専用バックアップボリュームがあり、tar|tarを使用してすべてをコピーしようとすると、ext4で最大7TBに拡大します。時間が足りなかったため、新しいカーネルバージョンで処理できるかどうかはまだ確認していません。実際の問題は、「トランザクションのアボート」で、書き込み可能でマウントしてから約2秒後に発生し、ボリュームを読み取り専用で再マウントします。元の原因はおそらく、このボリュームを作成したときに数年前に使用したbtrfs-convertのバージョンが壊れていることと、現在のbtrfs checkの機能セットがまだ限られていることですfindファイルシステムが正常であると言うだけでなく、トランザクションの中止やその他の問題を再現可能に引き起こすボリュームのすべての損傷。