Backup av GitHub
Koden finns på varje utvecklares dator. Därför slutar samtalet om backup för GitHub ofta innan det börjat — och slutsatsen är rimlig så länge man bara tänker på filerna.
Men ett repository är inte bara kod. Issues, pull requests med sina granskningar, workflows, branch protection-regler, team och behörigheter finns bara hos GitHub. Försvinner de går koden att klona tillbaka från vilken utvecklardator som helst. Arbetssättet runt den gör det inte.
ARJ Distribution säljer uteslutande via återförsäljare och MSP:er i Norden — Sverige, Norge, Danmark, Finland och Island — aldrig direkt till slutkund.
Frågan är sällan om koden finns kvar. Den gör den. Frågan är om allt runt koden gör det — och om det kommer tillbaka i samma skick.
Vad som faktiskt kan försvinna
Git är distribuerat. Varje klon är en fullständig kopia av historiken, och just det är skälet till att många avfärdar frågan. Men det som gör GitHub till mer än en filserver ligger utanför den klonen.
Ett raderat repository tar med sig allt som aldrig låg i Git: issues med sina diskussioner, pull requests med granskningar och godkännanden, workflows, branch protection-regler, teamstrukturen och vem som hade vilken behörighet. Det går inte att klona tillbaka från en utvecklardator, för det har aldrig funnits där.
Och det vanligaste ärendet är inte en katastrof. Det är någon som rensade fel, en integration med för vida rättigheter, ett konto som togs bort när en konsult slutade, eller ett skript som körde mot fel organisation. I de fallen är plattformen fullt frisk — det är innehållet som är borta, och då hjälper ingen driftgaranti.
Det är värt att ställa frågan rakt till kunden: om organisationen på GitHub var tom i morgon bitti, vad skulle ni sakna utöver koden? Svaret brukar bli längre än frågeställaren väntat sig.
Det här skyddas
GitProtect listar själv vad som omfattas. Av de plattformar vi gått igenom är GitHubs lista den bredaste, och det här är de grupper som brukar avgöra ett samtal:
| Område | Vad som ingår |
|---|---|
| Repository | Branches, commits med meddelande och skapare, taggar, refs, objekt, loggar, LFS, wiki, deploy keys, webhooks, webbplatsfältet, namn och beskrivning — samt de allmänna inställningarna: merge- och squash-alternativ, standardbranch, automatisk radering av head-branch och mallrepository. |
| Issues | Öppna och stängda, med tilldelade personer, kommentarer, beskrivning, bilagor, etiketter, milstolpar, kopplade projekt, skapare och skapandedatum. |
| Pull requests | Öppna, stängda och mergade, med kommentarer, commits, tilldelade personer, beskrivning, etiketter, milstolpar, skapare och skapandedatum. |
| Behörigheter | Team med medlemmar, roller, föräldrateam, repositorybehörigheter, notifieringar och synlighet — plus direkta och externa collaborators med sina roller. |
| Branch protection | Samtliga regler: branchmönster, krav på pull request, på lösta konversationer, på linjär historik, på signerade commits och på godkända statuskontroller, samt låst branch och om radering eller force push tillåts. |
| Automatik | Workflows i GitHub Actions. Dependabot med alerts, dependency graph och säkerhetsuppdateringar. |
| Planering | Projects v2 i detalj — egna kolumner för datum, iteration, tal, enkelval och text, utkast-issues, länkade pull requests, granskare, status och statusuppdateringar. Dessutom etiketter, milstolpar och releaser med assets. |
Vad den långa listan egentligen betyder: det går att återskapa inte bara koden utan hur arbetet var organiserat runt den. Det är skillnaden mellan att ha filerna och att ha projektet.
Vad som inte ser likadant ut efteråt
En täckningslista svarar på frågan säkerhetskopieras det här? Den svårare frågan — och den som faktiskt avgör om kunden blir nöjd — är vad som ser likadant ut efter en återställning. Vi ställer den frågan till varje plattform vi säljer skydd för, och på GitHub är svaret ovanligt bra.
En sak ska ni ändå känna till: stödet för att säkerhetskopiera Projects (classic) är borttaget. Gamla säkerhetskopior går fortfarande att återställa, men de konverteras då till Projects v2. Har kunden kvar classic-projekt är det alltså inte en fråga om att få tillbaka dem som de var, utan om att få tillbaka innehållet i den nya formen. De projekt som är kvar i classic hos en kund är ofta de äldsta och minst underhållna — kontrollera om något av dem fortfarande används innan ni lovar något.
I övrigt anger leverantören inga begränsningar för GitHub. Det är värt att notera, för andra plattformar har tydliga sådana. Kommer samma kund med GitLab eller Azure DevOps i nästa mening ser bilden annorlunda ut, och det går vi igenom på respektive sida.
GitHub Enterprise
GitProtect har en egen dokumentationssida för GitHub Enterprise self-hosted. När vi hämtade den fick vi tillbaka samma resurslista som för vanliga GitHub — men vi kunde inte avgöra om det beror på att listorna faktiskt är identiska eller på att sidan pekar vidare till GitHub-sidan. Därför påstår vi ingenting om Enterprise här.
Kör kunden Enterprise Server i egen regi stämmer vi av täckningen med leverantören innan ni offererar, och återkommer med ett besked ni kan luta er mot. Frågan ligger redan hos dem. Det här är precis en sådan sak där en skillnad kan finnas utan att stå skriven — och då vill vi hellre vara långsamma än att ni lovar fel.
Fyra frågor att ställa kunden
- Vad skulle ni sakna utöver koden om organisationen var tom i morgon? Svaret visar om kunden tänker på repositories eller på arbetssättet. Det är hela samtalet i en fråga.
- Vem har rättighet att radera ett repository eller ett team? Och hur många integrationer har skrivrättigheter mot organisationen? Det är därifrån de verkliga incidenterna kommer.
- Använder ni fortfarande Projects (classic)? I så fall — vad händer om de kommer tillbaka som Projects v2?
- Molnet eller Enterprise i egen regi? Kör de Enterprise i egen regi vill vi stämma av täckningen med leverantören innan ni lovar något.
Därför via distributör
Vi säljer inte till slutkund. Det är inte en artighet utan affärsmodellen: allt går via er, och vi konkurrerar aldrig med er hos kunden.
Vad ni får utöver licenserna: teknisk försäljningshjälp innan affären, hjälp i proof of concept, support på svenska och engelska, och en kontaktperson som känner er affär i stället för ett ärendenummer. Hur licensen räknas för just den här kundens uppsättning går vi igenom tillsammans med er innan ni offererar.
Kom igång
Berätta hur kundens GitHub ser ut — hur stor organisationen är, om de kör i molnet eller Enterprise i egen regi, och vad som måste kunna återställas i oförändrat skick. Då säger vi vad som går att lova och vad det kostar.
Läs vidare
Berätta om ert projekt
eller boka ett kort tekniskt samtal
Om innehållet på den här sidan. Det här är en säljinriktad översikt — inte fullständig produktdokumentation. Uppgifterna är hämtade ur GitProtects egen dokumentation i oktober 2026 och vi ser över dem löpande, men funktioner och stöd ändras — och en ändring kan passera oss. Stäm därför alltid av mot leverantörens aktuella dokumentation innan något utlovas till en kund: GitProtects kunskapsbas. Är ni osäkra är det snabbare att fråga oss — vi tar frågan med leverantören och återkommer med ett besked ni kan luta er mot i en offert. Och fungerar något inte som det står — här eller i leverantörens dokumentation — säg till oss. Vi anmäler det till leverantören och rättar sidan.