Tag backup af GitLab – objektlageret følger ikke altid med arkivet

Skal en backup af GitLab Self-Managed dække mere end kildekoden, skal den omfatte både projektets repository, wiki, LFS-objekter og de øvrige data, installationen bruger. GitLabs vejledning til instansbackup beskriver et arkiv med blandt andet database, repositories, uploads og CI-artefakter. Filer i eksternt objektlager kommer derimod ikke med i backupkommandoens arkiv.

Det afgørende er derfor, hvor hver datatype ligger. Et wiki-repository følger med en instansbackup, medmindre repositories er fravalgt. LFS-objekter og vedhæftninger, der ligger lokalt, kan komme med i arkivet; ligger de i objektlager, skal de sikres særskilt. En projekt­eksport løser en anden opgave: Den kan flytte udvalgte projektdata, men dækker ikke alt, hvad en installation skal bruge ved gendannelse.

GitLab.com: Eksportér et afgrænset projekt

På GitLab.com kan en bruger med rollen Maintainer eller Owner eksportere et projekt via Settings, General, Advanced og Export project. GitLabs oversigt over projekt­eksport angiver projektets repository, wiki-repository, LFS-objekter, uploads, issues og merge requests blandt de dele, der kan følge med. Når eksporten er dannet, skal filen downloades; tjenesten sletter eksportfiler fra sit eksportområde løbende.

Eksporten er beregnet til at flytte projektdata, og indholdet afhænger af GitLab-versionen. CI-joblogs og artefakter, CI/CD-variabler, webhooks samt pakke- og containerimages er blandt de dele, der ikke eksporteres. Har projektet brug for dem efter en flytning, må de håndteres separat. Ved import kan også brugertilknytninger og adgangsindstillinger ændre sig, så en eksportfil alene er ikke et løfte om en identisk kopi af projektet.

Et almindeligt clone af kildekoden er endnu snævrere. Wiki ligger i sit eget Git-repository, mens LFS bruger objektfiler ved siden af de pointere, der findes i Git-historikken. Hvis formålet er at bevare mere end kildekoden, skal de dele indgå i valget af eksport- eller backupmetode.

Self-Managed: Medtag instansens database og filer

For en GitLab Self-Managed-installation fra Linux-pakken opretter sudo gitlab-backup create som udgangspunkt et tar-arkiv. Backupen omfatter databasedata, Git-repositories inklusive wiki, samt lokalt lagrede LFS-objekter, uploads, CI-joblogs og artefakter. Databasen rummer blandt andet indhold fra issues og merge requests, kommentarer og adgangsrettigheder. Den kan derfor ikke erstattes af et clone af projektets repository.

Se på backupjobbets SKIP-indstillinger. Værdier som db, repositories, lfs, uploads og artifacts udelader hver sin del; repositories omfatter også wiki. Et job kan dermed afsluttes uden fejl og stadig producere en bevidst begrænset kopi. Hvis installationen bruger andre datatyper, eksempelvis pakkeregister eller containerregister, skal deres lagringssted og eventuelle fravalg også indgå i planen.

Konfigurationsfilerne ligger uden for backupkommandoens arkiv. Ved en Linux-pakke skal især /etc/gitlab/gitlab.rb og /etc/gitlab/gitlab-secrets.json gemmes separat og sikkert. Secrets-filen indeholder nøgler til krypterede databaseværdier; uden de rigtige nøgler kan værdierne ikke dekrypteres efter gendannelse. Backupkommandoen gemmer heller ikke Redis-data, herunder ventende Sidekiq-job, så aktive baggrundsjob kræver opmærksomhed ved en konsistent backup.

Objektlager: Kopiér data uden for arkivet

GitLab kan opbevare LFS-objekter, uploads, CI-artefakter og andre filer enten på det lokale filsystem eller i eksternt objektlager. Backupkommandoen kopierer kun de lokalt lagrede filer ind i instansarkivet. Bruger containerregistret objektlager, kommer dets data heller ikke med. At tar-filen selv uploades til fjernlager, ændrer ikke på, hvilke projektfiler den indeholder.

Gennemgå derfor installationens lagringsindstillinger datatype for datatype. Registrér, hvilke buckets der rummer LFS, uploads, artefakter og eventuelle registerdata, og sørg for en særskilt kopi gennem objektlagerets backupmuligheder. Kopien skal kunne gendannes sammen med den relevante instansbackup. Hvis databasen og objektlageret repræsenterer forskellige tidspunkter, kan en gendannet database henvise til en fil, som mangler i den valgte lagerkopi.

Tjekliste for en gendannelig kopi

Notér lagringssted og backupmetode for hver del. Listen gør det muligt at se, om en projekt­eksport er tilstrækkelig til en flytning, eller om en Self-Managed-installation kræver både instansarkiv og særskilte kopier.

• Repository og wiki: Bekræft, at både kildekodens repository og det særskilte wiki-repository indgår. Et clone af kildekoden dækker ikke automatisk wiki.
• LFS: Find de faktiske objektfiler, ikke kun pointerne i Git-historikken. Registrér, om objekterne ligger lokalt eller i objektlager.
• Uploads: Medtag vedhæftninger og øvrige uploadede projektfiler, og kontrollér deres lagringssted.
• CI: Skeln mellem pipelineoplysninger, joblogs og artefaktfiler. Projekt­eksporten medtager ikke joblogs og artefakter.
• Database: Kontrollér, at instansbackupen indeholder databasedata, og at db ikke er udeladt med SKIP.
• Konfiguration: Opbevar konfiguration og secrets separat fra arkivet, og registrér indstillingerne for objektlageret.
• Gendannelse: Afprøv arkiv, konfiguration og eventuelle objektlagerkopier sammen i et særskilt miljø.

Prøvegendan hele kæden

En prøvegendannelse afgør, om kopierne faktisk passer sammen. GitLabs vejledning til gendannelse kræver samme GitLab-version og samme udgave, CE eller EE, som backupen blev oprettet med, samt de tilhørende secrets. En frisk testinstallation mindsker risikoen for at forveksle eksisterende data med data fra backupen. Ved gendannelse bliver indholdet i objektlagerets buckets heller ikke automatisk ryddet.

Åbn derefter et repræsentativt projekt og kontrollér både repository og wiki. Hent en LFS-fil, åbn en vedhæftning og prøv et CI-artefakt, hvis projektet bruger dem. Efter gendannelse findes der desuden integritetstjek for artifacts, lfs og uploads samt et tjek af, om databaseværdier kan dekrypteres. Når de relevante filer kan læses fra testinstallationen, er både arkivets indhold og de særskilte kopier prøvet i den sammenhæng, de skal bruges i.

Læs også:

• Tag backup af et GitHub-repository – LFS kræver et ekstra trin
• MobilePay bliver til Vipps – aftaler og historik følger med
• Eksportér Google-data med Takeout – arkivet udløber efter syv dage