web-dev-qa-db-ja.com

Gitlabを大規模にバックアップする方法は?

オンプレミスのGitlabで3TBのバックアップを行う方法についてGitlabのサポートに質問すると、返信に 当社のツール が使用され、tarballが生成されます。

これはすべてのレベルで私に間違った縫い目です。このtarballには、postgresダンプ、dockerイメージ、レポデータ、GIT LFSなどの構成などが含まれています。 TBの静的データとKBの非常に動的なデータを一緒にバックアップすることは適切にシームできません。その後、毎時間バックアップを実行したいという問題があります。

質問

一貫性のあるバックアップを取得するために、他のユーザーからその方法を知りたいです。

Linux上のZFSは、それがソリューションの一部であれば、私には問題ありません。

13
Sandra

バックアップ間の短い時間(1時間)の場合、最善の策は、ファイルシステムレベルのスナップショットおよびsend/recvサポートに依存することです。

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

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

最後に、代替ソリューションは、lvmthinを使用して定期的なバックアップを取得することです(例:snapperを使用)、サードパーティのツールに依存します(例: bdsync =、 blocksync など)デルタのみをコピー/配布します。

別のアプローチは、two複製されたマシン( DRBD を介して)を使用することです。 lvmthin

10
shodanshok

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

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

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

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

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

14
ETL