btrfs対応のバックアップソリューション

btrfsが今月14日にOracle ELで本番稼働を開始しました（Linux 3.2からfsckとスクラブを実行することで）それを利用するために現在のバックアップソリューションを再設計することを考えていました。10TB未満の少量のデータに対してそれを行うことを考えていることに注意してください。これはかなり静的です（毎日1％未満の変更）。要するにSMB / SOHOバックアップソリューション。

バックアップがすべきこと：

1. 本番サーバーでext [234] / XFS / JFSのLVMスナップショットを作成します
2. rsync/変更されたデータをバックアップサーバー上のbtrfsに転送
3. btrfsファイルシステムのスナップショット
4. 空き領域が少なくなったときに古いスナップショットを削除する

長所：

• すべてのファイルが簡単に利用でき、解凍やループマウントは不要
• 過去のスナップショットも簡単に入手できます...
• ...そのため、読み取り専用のSamba共有として共有できます（シャドウコピーのサポート付き）
• コピーオンライトのおかげで、スナップショットのスペースは最小限に抑えられます（変更のないスナップショットは、ディスク上で文字通りほとんどKiBを消費しません）
• 高いバックアップ一貫性：ファイルのチェックサム、すべてのデータのスクラブ、および組み込みの冗長性

質問：

• コピーオンライトファイルシステムを認識している、または簡単に作成できるバックアップソリューション（Bacula、BackupPCなどの形式）はありますか？
• または、ホームrsyncソリューションを使用する必要がありますか？
• バックアップ専用のZFSボックスを持っている人は、Linuxマシンをバックアップするために何をしますか？

私は先週、似たようなものを広範囲に検索しました。4つのステップすべてを実行する解決策は見つかりませんでした。「rsync to btrfs」タイプのバックアップを試みるホームユーザーからのブログが多数あり、主要なBtrfsウィキのすべてがBtrfsスナップショットの実行方法をカバーしています。

Btrfsスナップショットを回転させるさまざまな方法を試みている人もかなりいます 。ただし、ディスクスペースに基づいてスナップショットをローテーションしたいのは、私が初めて見た人です。私は1時間ごと、1週間ごと、1か月ごとのスナップショットのセットを作成するbtrfs-snapを自分で遊んでいます。

Dirvishプロジェクトは、要件の多くを満たすように思われます。一部の開発者は、DirvishとBtrfsの統合を試みています。ただし、Dirvishプロジェクトは少し停止しているようです。

この時点で、あなたは曲線の先を行っています。

Avi Miller（LinuxConf.AUでの講演）によると、btrfsの送受信が進行中です。ファイルの変更を見つけるためにディレクトリを走査する必要がないため、rsyncよりも高速になります。リリース予定日がまだあるかどうかはわかりません。

ただし、スナップショットなどで変更されたすべてのファイルをリストするユーティリティがbtrfs-progsに組み込まれています。btrfsサブボリュームfind-new

BackupPCに似たOSバックアップシステムで作業しています。私はこれについて考えました。私が実際に実装するのを妨げてきたのは、サブボリューム間でハードリンクできないことです。サブボリュームのスナップショットのみを作成することもできます->バックアップクライアントごとに1つのサブボリューム。したがって、ファイルレベルの重複排除機能は、このアプローチと共存できません。そして、そのファイルレベルの重複排除は通常、多くのスペースを節約します。1つのサーバーのみをバックアップしますか？

btrfsにブロックレベルの重複排除がある場合は、この問題はおそらく回避できますが、通常はあまりにも遅いです...

そして、そのようなアプローチはもちろん、1つのファイルシステム（btrfs）との緊密な統合を必要とするため、これはオプションの機能である必要があります。

私はそのような牛の機能を追加することを考えているので私は尋ねていますが、上記の欠点のためにすべきかどうかわからない。

編集：UrBackupは、Linuxカーネル> = 3.6（クロスボリュームreflinkサポートあり）での質問で説明されているバックアップをサポートします。設定方法をご覧ください。

btrfs wikiページ「ユースケース」には、SnapBtr、Snapper、btrfs-time-machine、UrBackupなどのツールがリストされています。

autosnapと呼ばれる組み込みツールの提案があります：

自動スナップ機能を使用すると、定期的またはイベントベースのスナップショットを作成し、さらにスナップショットを自動的に管理するようにbtrfsを構成できます。

自動スナップは、スナップショットを取得するだけでなく、作成されたスナップショットを管理することでもあります。現在、ファイルシステムの使用スペースに基づいて自動スナップを設定してスナップショットを削除できます。

ただし、2013年10月の時点で、wiki は「autosnap機能は現在、btrfsのアップストリームバージョンに含まれていません」と述べています。

似たような不満があったので、私はsnazzerと呼んでいるいくつかのスクリプトを作成することになりました。ともに、スナップショット、プルーニング、測定、およびsshを介した転送を提供します（ただし、今日の時点では、ローカルファイルシステムとの間でも送受信できます）。測定値は、スナップショットパスのsha512sumおよびPGP署名のレポートです。リリースの準備はまだできていませんが、この早い段階でレビューする時間がある人がいたらフィードバックをお聞かせください。

この時点でCLIのみが、私は多くのbtrfsのサブボリュームを備えたシステムで使用して簡単にそれを作るためにいくつかの時間を取った-通常、私はのために別々のサブボリュームを持っている/var/cache、/homeなどのスナップショットから除外される必要がある以上/以下であってもよいです積極的なプルーニングスケジュール。

プルーニングアルゴリズムは、スナップショットのセットとその日付の存在を純粋に決定するのではないかと心配しています。ディスク使用制限が満たされるまでプルーニングを維持するものはありません。最初に削除するのはどれですか。最初に毎時の数を減らしますか、それとも日ごとの数を減らしますか？おそらく最も古いものを落としてください。毎年？展開ごとに優先順位が異なります。そして、これが唯一のバックアップ層（この場合、法的/保険の義務の場合、最も古いバックアップを削除するべきではない）か、単に中間のもの（その場合、おそらくそれらの年次データを安全な場所にアーカイブするかその他）。

ZFSサポートや相互運用性をいつか追加します。現時点では「ゼロ」依存性への強い欲求のため、ほとんどがPOSIX風のシェルとperlで書かれています。