Es gibt für einen Entwickler wohl nichts wichtigeres als seinen Quellcode. Dementsprechend sollte man sich auch um Backups seiner Versionierungssoftware kümmern. In meinem Fall ist das Gitlab.
Gitlab bietet von sich aus bereits einen Backupfunktion die manuell oder auch per Cronjob angestoßen werden kann, auch wird diese Funktion bei einem Versionsupgrade automatisch ausgeführt.
Ohne weitere Konfiguration wird jedoch nur ein lokales Backup erzeugt. Testen kann man das mit
sudo gitlab-rake gitlab:backup:create
oder für Installationen von Source mit
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
Nun wollen wir uns darum kümmern das dieser Job das erstellte Backup zusätzlich auf einen externen Server lädt. Konkret werde ich das Backup per CIFS Mount auf meinen Storage Server schieben, Gitlab unterstützt jedoch zahlreiche weitere Storageprovider wie Amazon S3 Bucket, Dropbox, etc.
Eine CIFS Freigabe zu mounten geht recht leicht:
mount -t cifs //—–.your-storagebox.de/backup /mnt/bx10 -o user=—,password=—-,noperm
Wichtig ist neben der korrekten Adresse, den richtigen Benutzername und Passwort auch die Option *noperm*.
Da ich eine Omnibus Installation von Gitlab habe muss ich nun in der Datei /etc/gitlab/gitlab.rb folgendes Eintragen:
gitlab_rails[‚backup_upload_connection‘] = {
‚provider‘ => ‚Local‘,
‚local_root‘ => ‚/mnt/bx10‘
}
gitlab_rails[‚backup_upload_remote_directory‘] = ‚gitlab‘
Das sind alle nötigen Einstellungen damit Gitlab zukünftig jedes Backup auch auf der Cifs Freigabe speichert.
Nun sollte das ganze so aussehen:
Als letztes erstellen wir noch einen Cronjob der unseren Quellcode täglich um 3 Uhr frühs sichert:
0 3 * * * sudo gitlab-rake gitlab:backup:create
*WICHTIG!*
Dies sichert nur die Gitlab Application Files, also euere Repositories, die Datenbank etc. Die Gitlab Konfiguration wird absichtlich nicht gesichert da dort Keys abgelegt sind die aus Sicherheitsgründen nicht zusammen mit den Repositories gespeichert werden sollten.
Hinterlasse jetzt einen Kommentar