it-swarm.com.de

Wie kann man Gitlab in großem Maßstab sichern?

Wenn sie den Gitlab-Support fragen, wie ein 3-TB-Backup für ein lokales Gitlab erstellt werden soll, antworten sie mit nserem Tool , das einen Tarball erzeugt.

Das kommt mir auf allen Ebenen einfach falsch vor. Dieser Tarball enthält den Postgres-Dump, Docker-Images, Repo-Daten, GIT LFS usw. config und so weiter. Sichern TB von statischen Daten zusammen mit sehr dynamischen KB-Daten funktioniert nicht richtig. Und dann kommt das Problem, dass wir jede Stunde ein Backup durchführen möchten.

Frage

Ich würde wirklich gerne von anderen wissen, wie sie es machen, um ein konsistentes Backup zu erhalten.

ZFS unter Linux wäre für mich in Ordnung, wenn das Teil der Lösung ist.

13
Sandra

Für eine so kurze Zeit zwischen den Sicherungen (1 Stunde) ist es am besten, sich auf die Unterstützung von Snapshots auf Dateisystemebene und send/recv Zu verlassen.

Wenn die Verwendung von ZoL in Ihrer Umgebung kein Problem darstellt, würde ich dringend empfehlen, es zu verwenden. ZFS ist ein sehr robustes Dateisystem und Sie werden alle Extras (z. B. Komprimierung), die es bietet, wirklich mögen. In Verbindung mit sanoid/syncoid kann eine sehr starke Sicherungsstrategie bereitgestellt werden. Der Hauptnachteil ist, dass es nicht im Mainline-Kernel enthalten ist, sodass Sie es separat installieren/aktualisieren müssen.

Alternativ können Sie BTRFS verwenden, wenn Sie sich wirklich auf Hauptinhalte beschränken müssen. Aber seien Sie sicher, seine (viele) Nachteile und Pita zu verstehen.

Schließlich besteht eine alternative Lösung darin, lvmthin zu verwenden, um regelmäßige Sicherungen (z. B. mit snapper) zu erstellen, wobei auf Tools von Drittanbietern zurückgegriffen wird (z. B. bdsync =, blocksync , etc) nur zum Kopieren/Versenden von Deltas.

Ein anderer Ansatz wäre, zwei replizierte Maschinen (via DRBD ) zu haben, über die Sie unabhängige Snapshots machen lvmthin.

10
shodanshok

Ich würde überprüfen, was Sie sichern, und möglicherweise einen "Multi-Path" -Ansatz verwenden. Sie können beispielsweise die Git-Repositorys sichern, indem Sie ständig Git-Pulls auf einem Sicherungsserver ausführen. Das würde nur den Diff kopieren und Ihnen eine zweite Kopie aller Git-Repositories hinterlassen. Vermutlich könnten Sie mit der API neue Repos erkennen.

Und verwenden Sie die "integrierten" Sicherungsverfahren, um die Probleme usw. zu sichern. Ich bezweifle, dass die 3 TB von diesem Teil stammen, sodass Sie sehr oft Sicherungen zu sehr geringen Kosten durchführen können. Sie können die PostgreSQL-Datenbank auch mit einem Warm-Standby mit Replikation einrichten.

Möglicherweise stammen Ihre 3 TB aus Container-Images in der Docker-Registrierung. Müssen Sie diese sichern? Wenn ja, dann gibt es vielleicht einen besseren Ansatz dafür.

Grundsätzlich würde ich empfehlen, wirklich zu prüfen, was Ihre Sicherung ausmacht, und die Daten in verschiedenen Teilen zu sichern.

Sogar das Backup-Tool von GitLab bietet Optionen zum Ein- und Ausschließen bestimmter Teile des Systems, z. B. der Docker-Registrierung.

14
ETL