Wenn Sie eine laufende GitLab-Instanz auffordern, mit dem folgenden Befehl ein vollständiges Sicherungsarchiv zu erstellen gitlab-rake gitlab:backup:create:
- Führt GitLab etwas aus, um den Anwendungsstatus einzufrieren?
- Besteht das Risiko, dass ein technisch funktionierendes Backup erstellt wird, das einen inkonsistenten Zustand aufweist?
Im Detail:
- Was passiert, wenn während der Backup-Generierung neue Commits gepusht werden?
- Was kann grundsätzlich passieren, wenn während der Sicherung eine Änderung vorgenommen wird?
- Gibt es einen Cache, der Änderungen in die Warteschlange stellt, um sie auf die Datenbank anzuwenden oder in Dateien/Repositorys zu schreiben?
Im Moment habe ich keine Ahnung, was passiert, wenn Sie ein geändertes Repository archivieren oder wenn eine Sicherung einer Datenbank mit laufenden Transaktionen durchgeführt wird?
Ich habe mir heute den Backup-Code von GitLab durchgelesengitlab.com/gitlab-org/gitlab-ce/tree/master/lib/backupkonnte aber keinen Hinweis auf meine Fragen finden.Ich programmiere nicht mit Ruby, also hilft mir das nicht ...
GitLab führt den tarBefehl einfach für die zu sichernden Dateien aus.
In der GitLab-Dokumentationdocs.gitlab.com/ee/raketasks/backup_restore.html#backup-strategy-optiones wird angegeben, daß:
Wenn sich Daten ändern, während sie von tar gelesen werden, kann die Fehlerdatei „beim Lesen geändert“ auftreten und dazu führen, dass der Sicherungsvorgang fehlschlägt. Um dies zu verhindern, führt 8.17 eine neue Sicherungsstrategie namens „Kopieren“ ein. Die Strategie kopiert Datendateien an einen temporären Speicherort, bevor tar und gzip aufgerufen werden, wodurch der Fehler vermieden wird.
Das STRATEGY=copyArgument bewirkt, dass gitlab-rake gitlab:backup:createein rsync -aBefehl zum Kopieren aller Dateien ausgeführt wird, bevor das Archiv mit erstellt wird tar.
Nach meinem Verständnis der Dokumentation heißt es, dass copyGitLab mit der Strategie niemals ein technisch beschädigtes Archiv erstellen wird und bei dessen Erstellung niemals ein Fehler auftritt. Ich gehe davon aus, dass diese Strategie sicherstellt, dass das erstellte Archiv wiederherstellbar ist, aber wie steht es um den Konsistenzzustand der Daten?
Können wir sicherstellen, dass das Backup-Archiv einen konsistenten/sauberen Snapshot-Status der GitLab-Instanz enthält?
In der Dokumentation kann ich hierzu keine Angaben finden.
Ich möchte GitLab ohne Unterbrechung sichern.
Ich weiß, dass ich GitLab für einige Sekunden anhalten und einen Snapshot des LVM-Volumes oder Dateisystems erstellen könnte, anstatt den integrierten Backup-Mechanismus zu verwenden, aber ich möchte GitLab nicht unterbrechen.
Sie können ein Backup von GitLab ausführen und dabei alle Dienste außer diesem unterbrechen postgresql, sodass während der Sicherung mit dem integrierten Mechanismus von GitLab keine Änderungen vorgenommen werden können. Dennoch müssen Sie den Dienst für Ihre Benutzer einige Zeit sperren.
Bonus: Meine Fragen gelten auch für das Snapshotten des LVM-Volumes oder -Dateisystems!
Antwort1
Es gibt viele Fragen zum konsistenten Erstellen von Backups von Gitlab, aber ich habe keine gute Antwort gefunden.
Einige der Fragen:
- https://stackoverflow.com/questions/24066283/wie-erstelle-man-ein-konsistentes-gitlab-backup
- https://stackoverflow.com/questions/15825735/gitlab-ist-die-backup-rake-task-atomic
Ich kann dich zitieren@SørenLøvborgDie Antwort von scheint richtig zu sein:
Die Repos selbst werden mit gesichert
git bundle, daher sollten sie ebenfalls sicher sein. Uploads sind einfache Dateien und können nur einmal geschrieben werden, daher sollte es auch hier keine Probleme geben. Die Datenbank ist möglicherweise nicht perfekt mit Repos und Dateien synchronisiert, aber nicht auf eine Weise, die zu Datenverlust führen sollte. Alles in allem scheint es völlig sicher zu sein, ein Backup durchzuführen, während GitLab ausgeführt wird, auch wenn es nicht atomar ist.
Bearbeiten:Sie haben bereits eine offizielle Antwort erhalten vonGitlab Team.