Een back-up maken van uw GitLab-server

0
207

Organisaties die een zelfbeheerde GitLab-instantie gebruiken, vertrouwen er gewoonlijk op om hun broncode, projectbeheer en operationele tooling. Het is van vitaal belang om goed werkende back-ups te hebben, zodat uw gegevens beschermd zijn in geval van een hardwarestoring, mislukte serverupdate of kwaadwillende compromittering.

GitLab heeft een ingebouwde back-upcomponent die kan een compleet archief van de gegevens van uw installatie maken. Het archief kan worden hersteld op een nieuwe server met dezelfde GitLab-versie.

Hier leest u hoe u back-ups instelt naar uw lokale bestandssysteem of een Amazon S3-bucket. Deze stappen zijn bedoeld voor gebruik met GitLab omnibus-edities. U moet de GitLab CLI-commando's wijzigen door ze vooraf te laten gaan met bundel exec rake als uw instantie is gebouwd vanaf de broncode.

Een Aan maken -Back-up opvragen

De eenvoudigste manier om een ​​back-up te maken, is met de opdracht voor het maken op aanvraag. Voer het volgende commando uit in je shell:

sudo gitlab-backup create

Dit werkt op GitLab 12.2 en nieuwer. Oudere versies zouden in plaats daarvan een alternatieve versie moeten gebruiken:

sudo gitlab-rake gitlab:backup:create Advertisement

De back-up wordt opgeslagen als een tar-archief in de map die is gedefinieerd door uw GitLab-configuratiebestand. Omnibus-installaties gebruiken standaard /var/opt/gitlab/backups. Elk back-uparchief wordt genoemd met zijn aanmaaktijdstempel en GitLab-versie.

Wat zit er in een back-up?

Het ingebouwde back-uphulpprogramma van GitLab exporteert gegevens die door gebruikers zijn gemaakt op uw GitLab-instantie. Dit omvat alles in de GitLab-database en uw Git-opslagplaatsen op de schijf.

Als u de back-up herstelt, worden uw projecten, groepen, gebruikers, problemen, geüploade bestandsbijlagen en CI/CD-taaklogboeken hersteld. De back-up dekt ook GitLab Pages-websites en Docker-images die zijn geüpload naar het geïntegreerde containerregister.

Pakketten die zijn toegevoegd aan de pakketregisters van GitLab worden niet ondersteund. U moet uw installatie configureren om pakketten op te slaan naar een externe objectopslagprovider als u ze nodig hebt om ze te kunnen herstellen zonder handmatige heropbouw.

Een back-upschema maken

h2>

Er is geen geïntegreerd mechanisme om een ​​geautomatiseerd back-upschema te definiëren. U moet uw eigen cron-taak instellen om de hierboven getoonde back-upopdracht uit te voeren.

Voer sudo crontab -e uit om de crontab van root te openen en voeg vervolgens de volgende inhoud toe aan het bestand:

0 21 * * * /opt/gitlab/bin/gitlab-backup create CRON=1 Advertentie

Sla het bestand op en sluit het om je crontab-wijziging toe te passen. In dit voorbeeld wordt elke dag om 21:00 uur een nieuwe back-up gemaakt. Door de CRON-omgevingsvariabele in te stellen, geeft GitLab de opdracht om de voortgangsweergave van de back-up te verbergen, zodat u geen overbodige cron-e-mails met de taakuitvoer ontvangt.

Als u deze taak ongewijzigd gebruikt, wordt elke back-up voor onbepaalde tijd bewaard totdat u ze handmatig opruimt. Dit kan snel veel opslagruimte in beslag nemen als u een actieve GitLab-instantie gebruikt die grote projecten bevat.

Met een optionele configuratiesleutel kunt u oude archieven verwijderen als onderdeel van het script voor het maken van een back-up. Open uw GitLab-configuratiebestand op /etc/gitlab/gitlab.rb. Zoek naar backup_keep_time, verwijder commentaar op de regel en stel het aantal seconden in dat je elke back-up wilt bewaren.

gitlab_rails['backup_keep_time'] = 432000

Hier worden back-ups vijf dagen bewaard. GitLab verwijdert alle in aanmerking komende archieven in de back-upmap telkens wanneer de opdracht voor het maken van een back-up wordt uitgevoerd.

Je moet GitLab opnieuw configureren wanneer het configuratiebestand verandert. Voer sudo gitlab-ctl reconfigure uit om uw nieuwe instelling toe te passen.

Exclusief gegevenstypen

Soms wilt u misschien een back-up maken met een subset van de ondersteunde gegevenstypen. Door de omgevingsvariabele SKIP te definiëren, kunt u specifieke bewerkingen uitsluiten, waardoor uw uiteindelijke archief kleiner wordt.

Advertentie

De omgevingsvariabele heeft een door komma's gescheiden lijst met gegevenstypen. U kunt de momenteel ondersteunde opties vinden in de GitLab-wiki.

Hier leest u hoe u een back-up kunt maken van alles behalve containerregisterafbeeldingen:

sudo gitlab-backup create SKIP=registry

Het uitsluiten van de registerinhoud is vaak een gemakkelijke manier om uw back-upgrootte aanzienlijk te verkleinen en de aanmaaksnelheid te versnellen. Een team met verschillende actieve projecten die meerdere Docker-images per dag bouwen, kan snel gigabytes aan registergegevens verzamelen. Ze uitsluiten van back-up is niet per se een te groot risico, omdat je de afbeeldingen altijd opnieuw kunt opbouwen met behulp van de Dockerfile in je repository.

Back-up maken naar S3

h2>

GitLab kan uw back-ups automatisch opslaan bij S3-compatibele objectopslagproviders. Maak commentaar op de backup_upload_connection-regels en voeg uw verbindingsdetails toe:

gitlab_rails['backup_upload_connection'] = { “aanbieder” => “AWS”, “regio” => “eu-west-1”, “aws_access_key_id” => “access_key”, “aws_secret_access_key” => “geheime_sleutel”, # “eindpunt” => "https://…" }

Voeg uw eigen toegangssleutel, geheime sleutel en AWS-regio-ID toe om de verbinding te voltooien. U moet ook het eindpuntveld instellen als u verbinding maakt met een andere provider dan AWS. Geef de URL van uw objectopslagserver op zodat GitLab ernaar kan uploaden.

U moet ook een backup_upload_remote_directory-sleutel instellen. Zoek deze regel in het configuratiebestand, verwijder het commentaar en stel een S3-bucketnaam in om uw back-ups te uploaden naar:

gitlab_rails['backup_upload_remote_directory'] = 'gitlab-back-ups';

Voer sudo gitlab-ctl reconfigure uit om uw wijzigingen toe te passen.

De opdracht voor het maken van een back-up uploadt nu de archieven naar uw geconfigureerde S3-bucket. Dit geeft u veel meer redundantie door uw back-ups off-site op te slaan, waardoor u beschermd bent tegen fysieke hardwarestoringen.

Advertentie

Pas op dat de backup_keep_time-instelling niet wordt ondersteund wanneer u deze gebruikt S3-opslag. Het is alleen van toepassing op lokaal opgeslagen back-uparchieven. U kunt iets soortgelijks bereiken door het ingebouwde verloopbeleid van S3 te gebruiken om uploads automatisch te verwijderen nadat een bepaalde tijdsperiode is verstreken.

The Copy Backup Strategie

De standaard back-upstrategie van GitLab is om gegevens continu naar het tar-archief te streamen. Dit werkt over het algemeen goed, maar kan problemen opleveren bij zeer actieve GitLab-instanties. Gegevens kunnen in de bronmap veranderen voordat het het archief bereikt, waardoor tar het overslaat met een gewijzigd bestand terwijl we het lezen fout.

Om dit tegen te gaan heeft GitLab een optionele kopieerstrategie geïntroduceerd. Hiermee worden alle in aanmerking komende back-upgegevens naar een tijdelijke map gekopieerd en wordt de gekopieerde inhoud vervolgens naar het uiteindelijke tar-archief gestreamd. Dit zorgt ervoor dat tar niet leest van een live GitLab-instantie, maar het neveneffect heeft dat het opslagverbruik van GitLab tijdelijk toeneemt. Back-upprestaties kunnen ook een merkbare hit krijgen, vooral op langzamere opslagapparaten.

De kopieerstrategie wordt geactiveerd door de omgevingsvariabele STRATEGY in te stellen bij het uitvoeren van de back-upopdracht. U moet ervoor zorgen dat u voldoende schijfruimte beschikbaar heeft. GitLab voert de back-up uit in fasen van het gegevenstype, zodat u slechts het dubbele van uw grootste gegevenstype nodig heeft. Als u bijvoorbeeld 5 GB Git-opslagplaatsen en 10 GB containerregisters hebt, moet u 10 GB extra beschikbare ruimte hebben, niet 15 GB.

sudo gitlab-backup create STRATEGY=copy

Vergeet niet: maak een back-up van uw configuratiebestand!

Het back-upscript van GitLab beheert alleen door de gebruiker gemaakte gegevens. Er zijn twee andere kritieke bestanden die essentieel zijn voor de werking van uw GitLab-server. Hiervan moet ook een back-up worden gemaakt om een ​​succesvol herstel van uw instantie te garanderen.

  • /etc/gitlab/gitlab.rb – Dit is uw GitLab-configuratiebestand. Alle, behalve de meest elementaire installaties, zullen in de loop van de tijd meestal veel wijzigingen ondergaan. Door een back-up van dit bestand te maken, kunt u het in een nieuwe GitLab-installatie plaatsen zonder helemaal opnieuw te hoeven beginnen.
  • /etc/gitlab/gitlab-secrets.json– Van dit bestand moet een back-up worden gemaakt. Het bevat uw databasecoderingssleutel, geheimen die worden gebruikt voor tweefactorauthenticatie en andere niet-herstelbare gevoelige gegevens. Het verkeerd plaatsen van dit bestand kan elke herstelpoging onmogelijk maken, zelfs als je een functionerend back-uparchief beschikbaar hebt.

Je zou een andere cron-taak kunnen gebruiken om een ​​back-up van deze twee bestanden te maken. Ze moeten van je server worden gekopieerd, zodat je er nog steeds toegang toe hebt als je te maken krijgt met een hardwarefout.

Conclusie

Back-ups zijn essentieel voor elke GitLab-beheerder. De software is meestal van cruciaal belang voor elk team in een organisatie, dus elke onverwachte uitvaltijd kan ernstige operationele uitdagingen veroorzaken.

Advertentie

GitLab wordt geleverd met alles wat je nodig hebt om regelmatig back-ups te maken. De beste aanpak is om een ​​cron-taak te maken die het ingebouwde script volgens een regelmatig schema uitvoert. Sla uw back-uparchieven op in externe objectopslag om te beschermen tegen hardwareverlies, defecten of schade. Vergeet niet om ook handmatig een back-up te maken van uw GitLab-configuratie- en geheimenbestanden, omdat het herstelproces anders aanzienlijk gecompliceerder zal zijn.