Organisationer som använder en självhanterad GitLab-instans förlitar sig vanligtvis på att de behåller sina källkod, projektledning och operativt verktyg. Det är viktigt att ha fungerande säkerhetskopior så att dina data skyddas vid maskinvarufel, misslyckad serveruppdatering eller skadlig kompromiss.
GitLab har en inbyggd säkerhetskopieringskomponent som kan skapa ett komplett arkiv med installationens data. Arkivet kan återställas en ny server som kör samma GitLab -version.
Så här ställer du in säkerhetskopior till ditt lokala filsystem eller en Amazon S3 -hink. Dessa steg är avsedda att användas med GitLab omnibusversioner. Du kommer att behöva ändra GitLab CLI-kommandona genom att prefixa dem med bunt exec rake om din instans byggdes från källan.
Gör en På -Krav backup
Det enklaste sättet att skapa en säkerhetskopia är med kommandot on-demand-skapande. Kör följande kommando i ditt skal:
sudo gitlab-backup skapa
Detta fungerar på GitLab 12.2 och nyare. Äldre versioner bör använda en alternativ version istället:
sudo gitlab-rake gitlab: backup: skapa annonsering
Säkerhetskopian sparas som ett tararkiv i katalogen som definieras av din GitLab -konfigurationsfil. Omnibusinstallationer är standard för att använda/var/opt/gitlab/backups. Varje backuparkiv har namnet med sin skapelsestämpel och GitLab-version.
Vad ingår i en säkerhetskopia?
GitLabs inbyggda säkerhetskopieringsverktyg exporterar data som skapats av användare på din GitLab-instans. Detta inkluderar allt i GitLab-databasen och dina Git-lagringsplatser på disken.
Om du återställer säkerhetskopian återställs dina projekt, grupper, användare, problem, uppladdade filbilagor och CI/CD -jobbloggar. Säkerhetskopian täcker också GitLab Pages -webbplatser och Docker -bilder som laddas upp till det integrerade behållarregistret.
Paket som läggs till i GitLabs paketregister stöds inte. Du bör konfigurera din installation för att spara paket till en extern objektlagringsleverantör om du behöver att de ska kunna återställas utan en manuell ombyggnad.
Skapa ett säkerhetskopieringsschema
Det finns ingen integrerad mekanism för att definiera ett automatiskt säkerhetskopieringsschema. Du bör konfigurera din egen cron -uppgift för att köra säkerhetskopian som visas ovan.
Kör sudo crontab -e för att öppna root ’ s crontab och lägg sedan till följande innehåll i filen:
0 21 * * */opt/gitlab/bin/gitlab -backup skapa CRON = 1 Annons
Spara och stäng filen för att tillämpa din crontab -ändring. Detta exempel skapar en ny säkerhetskopia kl 21.00 varje dag. Genom att ställa in miljövariabeln CRON instrueras GitLab att dölja visningen av säkerhetskopieringsförloppet så att du inte får redundanta cron -mejl med jobbutmatningen.
Att använda den här uppgiften som den kommer att behålla varje säkerhetskopia på obestämd tid tills du rensar dem manuellt. Detta kan snabbt förbruka mycket lagringsutrymme om du kör en aktiv GitLab -instans som innehåller stora projekt.
Med en valfri konfigurationsnyckel kan du ta bort gamla arkiv som en del av säkerhetskopieringsskriptet. Öppna din GitLab -konfigurationsfil på /etc/gitlab/gitlab.rb. Sök efter backup_keep_time, avmarkera raden och ställ in hur många sekunder du vill behålla varje backup för.
gitlab_rails [ 'backup_keep_time' ] = 432000
Här sparas säkerhetskopior i fem dagar. GitLab raderar alla kvalificerade arkiv i säkerhetskopian varje gång säkerhetskopian skapas.
Du måste omkonfigurera GitLab när konfigurationsfilen ändras. Kör sudo gitlab-ctl omkonfigurering för att tillämpa din nya inställning.
Exklusive Data Typer
Ibland kanske du vill köra en säkerhetskopia med en delmängd av de datatyper som stöds. Genom att definiera SKIP-miljövariabel kan du utesluta specifika operationer från att köra, minska ditt sista arkiv.
Annonsering
Miljövariabeln tar en kommaseparerad lista med datatyper. Du hittar de alternativ som för närvarande stöds i GitLab-wikin.
Så här säkerhetskopierar du allt utom behållarregistreringsbilder:
sudo gitlab-backup create SKIP = registry
Att utesluta registerinnehållet är ofta ett enkelt sätt att avsevärt minska din säkerhetskopieringsstorlek och påskynda dess skapandehastighet. Ett team med flera aktiva projekt som bygger flera Docker -bilder om dagen kan snabbt samla in gigabyte registerdata. Att utesluta dem från säkerhetskopiering är inte nödvändigtvis en alltför stor risk, eftersom du alltid kan bygga om bilderna med Dockerfilen i ditt förråd.
Säkerhetskopiera till S3
GitLab kan automatiskt spara dina säkerhetskopior till S3-kompatibla objektlagringsleverantörer. Ta bort kommentarerna till backup_upload_connection -raderna och lägg till dina anslutningsuppgifter:
gitlab_rails [ 'backup_upload_connection' ] = { & quot; leverantör & quot; = & gt; & quot; AWS & quot ;, & quot; region & quot; = & gt; & quot; eu-west-1 & quot ;, & quot; aws_access_key_id & quot; = & gt; & quot; access_key & quot ;, & quot; aws_secret_access_key & quot; = & gt; & quot; secret_key & quot ;, # & quot; slutpunkt & quot; = & gt; & quot; https: //…" }
Lägg till din egen åtkomstnyckel, hemliga nyckel och AWS -region -ID för att slutföra anslutningen. Du bör ställa in slutpunktsfältet också om du ansluter till en annan leverantör än AWS. Ange webbadressen till objektlagringsservern så att GitLab kan ladda upp den.
Du måste också ange en nyckel backup_upload_remote_directory. Hitta den här raden i konfigurationsfilen, avmarkera den och ange ett S3 -skopnamn för att ladda upp dina säkerhetskopior till:
gitlab_rails [ 'backup_upload_remote_directory' ] = 'gitlab-backup';
Kör sudo gitlab-ctl omkonfigurera för att tillämpa dina ändringar.
Kommandot för säkerhetskopiering kommer nu att ladda upp sina arkiv till din konfigurerade S3 -hink. Detta ger dig en mycket större redundans genom att lagra dina säkerhetskopior utanför webbplatsen och skydda dig mot fysiska maskinvarufel.
Annonsering
Se upp för att backup_keep_time-inställningen inte stöds när du använder ’ S3 lagring. Det gäller endast lokalt lagrade backuparkiv. Du kan uppnå något liknande genom att använda S3 ’ s inbyggda utgångspolicyer för att automatiskt ta bort uppladdningar efter att en viss tidsperiod har gått.
Kopiera backup Strategi
GitLabs standardstrategi för säkerhetskopiering är att strömma data kontinuerligt till tjärarkivet. Detta fungerar i allmänhet bra men kan ge problem på mycket aktiva GitLab -instanser. Data kan ändras i källkatalogen innan den når arkivet, vilket gör att tjära hoppar över den med en fil som ändras när vi läser den.
För att bekämpa detta introducerade GitLab en valfri kopieringsstrategi. Detta kopierar alla kvalificerade säkerhetskopierade data till en tillfällig katalog och strömmar sedan det kopierade innehållet till det slutliga tjärarkivet. Detta säkerställer att tar inte läser från en live GitLab-instans, men har en bieffekt av att tillfälligt öka GitLabs lagringskonsumtion. Säkerhetskopieringsprestanda kan också ta en märkbar träff, särskilt på långsammare lagringsenheter.
Kopieringsstrategin aktiveras genom att miljövariabeln STRATEGY ställs in när säkerhetskopian körs. Du bör se till att du har tillräckligt med ledigt diskutrymme. GitLab kör säkerhetskopieringen i datatypssteg så att du bara behöver dubbelt så stor som din största datatyp. Som ett exempel, om du har 5 GB Git-arkiv och 10 GB behållarregister behöver du ha 10 GB extra tillgängligt utrymme, inte 15 GB.
sudo gitlab-backup create STRATEGY = copy
Glöm inte: Säkerhetskopiera din konfigurationsfil!
GitLabs säkerhetskopieringsskript hanterar endast användarskapade data. Det finns två andra kritiska filer som är viktiga för driften av din GitLab -server. Dessa måste också säkerhetskopieras för att säkerställa en lyckad återställning av din instans.
- /etc/gitlab/gitlab.rb – Detta är din GitLab -konfigurationsfil. Alla utom de mest grundläggande installationerna kommer vanligtvis att få många modifieringar över tiden. Genom att säkerhetskopiera den här filen kan du släppa den till en ny GitLab-installation utan att behöva börja om från början.
- /etc/gitlab/gitlab-secrets.json – Den här filen måste säkerhetskopieras. Den innehåller din databas krypteringsnyckel, hemligheter som används för tvåfaktorsautentisering och andra icke-återställbara känsliga data. Om du felställer den här filen kan det bli omöjligt att återställa, även om du har ett fungerande backuparkiv tillgängligt.
Du kan använda en annan cron -uppgift för att säkerhetskopiera dessa två filer. De bör kopieras från din server så att du fortfarande kan komma åt dem om du stöter på ett maskinvarufel.
Slutsats
Säkerhetskopiering är avgörande för alla GitLab -administratörer. Programvaran är vanligtvis kritisk för alla team i en organisation, så oväntade driftstopp kan orsaka allvarliga driftsutmaningar.
Annonsering
GitLab levererar allt du behöver för att göra regelbundna säkerhetskopior. Det bästa sättet är att skapa en cron-uppgift som kör det inbyggda skriptet på ett vanligt schema. Spara dina backuparkiv till extern objektlagring för att skydda mot maskinvaruförlust, fel eller skada. Kom ihåg att manuellt säkerhetskopiera din GitLab -konfiguration och hemlighetsfiler också, annars blir återställningsprocessen betydligt mer komplicerad.