Gitlabを大規模にバックアップするには？

オンプレミスのGitlabで3TBのバックアップを行う方法についてGitlabのサポートに尋ねるとき、彼らはtarballを生成するツールを使用して返信します。

これはすべてのレベルで間違っているように思えます。このtarballには、postgresダンプ、dockerイメージ、リポジトリデータ、GIT LFSなどの構成などが含まれています。KBの非常に動的なデータと一緒にTBの静的データをバックアップすることは適切ではありません。そして、1時間ごとにバックアップを取りたいという問題があります。

質問

一貫性のあるバックアップを取得するために、他の人からどのようにそれを行っているのかを本当に知りたいです。

Linux上のZFSは、それがソリューションの一部であるなら、私にとっては問題ないでしょう。

バックアップ間のこのような短い時間（1時間）については、ファイルシステムレベルのスナップショットと send/recvサポートに頼ることが最善の策です。

ZoLの使用が環境で問題にならない場合は、使用することを強くお勧めします。ZFSは非常に堅牢なファイルシステムであり、ZFSが提供するすべての追加機能（例：圧縮）が本当に好きになるでしょう。と組み合わせるとsanoid/syncoid、非常に強力なバックアップ戦略を提供できます。主な欠点は、メインラインカーネルに含まれていないことです。したがって、個別にインストール/更新する必要があります。

あるいは、本当にメインラインに含まれるものに制限する必要がある場合は、BTRFSを使用できます。しかし、その（多くの）欠点とピタを必ず理解してください。

最後に、代替ソリューションを使用することですlvmthin：（と例えば定期的にバックアップを取るためにsnapper：（たとえば、サードパーティ製のツールに頼って、） bdsync、blocksync/船デルタのみをコピーするなど）。

別のアプローチは、2つの複製されたマシン（経由DRBD）を使用して、経由で独立したスナップショットを取得することですlvmthin。

バックアップ対象を確認し、「マルチパス」アプローチを使用する可能性があります。たとえば、バックアップサーバーでGitプルを常に実行することにより、Gitリポジトリをバックアップできます。これにより、差分のみがコピーされ、すべてのGitリポジトリの2番目のコピーが残ります。おそらく、APIを使用して新しいリポジトリを検出できます。

そして、「組み込み」のバックアップ手順を使用して問題などをバックアップします。3TBがこの部分から来ているので、非常に少ないコストで非常に頻繁にバックアップを実行できるとは思えません。また、レプリケーションを備えたウォームスタンバイでPostgreSQLデータベースをセットアップすることもできます。

おそらく、3TBはDockerレジストリのコンテナーイメージから取得されます。それらをバックアップする必要がありますか？もしそうなら、そのためのより良いアプローチがあるかもしれません。

基本的に、バックアップを構成し、さまざまな部分のデータをバックアップするのは何かを実際に検討することをお勧めします。

GitLabのバックアップツールにも、Dockerレジストリなどのシステムの特定の部分を含める/除外するオプションがあります。