解決策 1:
バックアップしているものを確認し、「マルチパス」アプローチを使用する可能性があります。たとえば、バックアップ サーバーで Git プルを常に実行することで、Git リポジトリをバックアップできます。これにより、差分のみがコピーされ、すべての Git リポジトリの 2 つ目のコピーが残ります。おそらく、API を使用して新しいリポジトリを検出できます。
そして、「組み込みの」バックアップ手順を使用して、問題などをバックアップします。3 TB がこの部分から来ているとは思えないため、非常に頻繁にバックアップを行うことができ、コストはほとんどかかりません。また、レプリケーションを使用してウォーム スタンバイを使用して PostgreSQL データベースをセットアップすることもできます。
3 TB は、Docker レジストリのコンテナー イメージに由来する可能性があります。それらをバックアップする必要がありますか？もしそうなら、そのためだけにもっと良いアプローチがあるかもしれません.
基本的に、バックアップを構成しているものを実際に見て、さまざまな部分でデータをバックアップすることをお勧めします。
GitLab のバックアップ ツールにも、Docker レジストリなどのシステムの特定の部分を含める/除外するオプションがあります。
解決策 2:
バックアップ間の短い時間 (1 時間) の場合、最善の策は、ファイルシステム レベルのスナップショットに依存することです。および send/recv サポート。
ご使用の環境で ZoL の使用が問題にならない場合は、ZoL を使用することを強くお勧めします。 ZFS は非常に堅牢なファイルシステムであり、ZFS が提供するすべての追加機能 (圧縮など) が気に入るはずです。 sanoid/syncoid と組み合わせると 、非常に強力なバックアップ戦略を提供できます。主な欠点は、メインライン カーネルに含まれていないため、個別にインストール/更新する必要があることです。
または、本当にメインラインに含まれるものに制限する必要がある場合は、BTRFS を使用できます。ただし、その (多くの) 欠点とピタを必ず理解してください。
最後に、代替ソリューションは lvmthin を使用することです 定期的なバックアップを取る (例:snapper を使用) )、サードパーティのツールに依存 (例:bdsync 、 blocksync など) デルタのみをコピー/出荷します。
別のアプローチは、2 にすることです。 レプリケートされたマシン (DRBD 経由) ) lvmthin を介して独立したスナップショットを取得する場所 .