Gegevens waarvoor geen back-up bestaat, kun je ook zomaar verwijderen. Maar juist als het om code gaat, vertrouwen veel ontwikkelteams erop dat er bij GitHub e.a. niets verloren gaat. Met het kleine programmaatje Gickup heb je geen excuses meer om geen automatische back-up te maken.
Lees verder na de advertentie
Wat als GitHub morgen onbereikbaar is?
Git-hosts zoals GitHub of GitLab slaan allerlei soorten code veilig op en maken het werken aan projecten met meerdere ontwikkelaars een stuk makkelijker. De huidige stand van zaken ligt altijd in de repository bij de host; ontwikkelaars hebben alleen werkkopieën op hun computer en pushen hun wijzigingen naar de host zodra ze klaar zijn met werken.
Dit is dan wel handig, maar brengt ook een risico met zich mee, want op deze manier wordt een aanbieder als GitHub, GitLab of Gitea de centrale beheerder van het intellectuele eigendom van een ontwikkelteam of een heel bedrijf. Je wil er niet aan denken wat er zou kunnen gebeuren als er bij de dienstverlener gegevens verloren gaan of als de inloggegevens van een teamlid kwijtraken.
Even eerlijk: zouden jij of je collega’s morgenochtend gewoon verder kunnen werken als vannacht alle repository’s bij GitHub of GitLab zouden worden gewist, of als je de toegang voorgoed kwijt zou raken omdat de 2FA verdwenen is?
Één back-up is geen back-up
Net als bij alle gegevens geldt ook voor code-repository’s: een back-up is verplicht, het liefst op meerdere opslagmedia en met een kopie buiten het bedrijf. Met wat kennis van scripting kun je zo’n back-up voor Git-repository’s ook zelf in elkaar zetten, bijvoorbeeld door een lijst bij te houden van alle repository’s die je wilt back-uppen en git clone in een loop over die lijst uit te voeren.
Maar het kan eleganter en met minder onderhoud. De opensource-community heeft een handig hulpmiddel ontwikkeld dat het configureren van Git-back-ups flink vereenvoudigt: maak met Gickup gemakkelijk back-ups van verschillende Git-hosts naar een lokale harde schijf, naar andere Git-hosts of naar S3-storage.
Gickup is een project van de Oostenrijkse ontwikkelaar Andreas Wachter en is geschreven in de programmeertaal Go. Er is voor Windows, Linux en macOS elk een uitvoerbaar bestand, te vinden via de GitHub-repository (zie de link bij dit artikel). Als je deze direct wil uitvoeren, moet Git op je systeem geïnstalleerd zijn.
Daarnaast onderhoudt de beheerder een Docker-containerimage, dat onder de naam buddyspencer/gickup:latest op Docker Hub staat. Deze image is geschikt voor zowel ARM- als x86-processors. Als back-upcentrale komen dus gehuurde servers, een NAS met containerfuncties of zelfs een Raspberry Pi in aanmerking. Om de volgende handleiding voor Docker te kunnen volgen, heb je alleen een willekeurige Linux-machine nodig waarop Docker is geïnstalleerd.
Project opzetten
De beste manier is om een nieuwe map aan te maken voor het back-upsysteem. In deze map zet je twee bestanden: het ene heet docker-compose.yml en bevat de beschrijving voor de Gickup-container. Daarnaast zet je het bestand conf.yml. Dat wordt het configuratiebestand voor Gickup.
Maak naast deze twee bestanden een nieuwe map aan met de naam backup: daarin komen later de geback-upte repository’s terecht. Het Docker-Compose-bestand is overzichtelijk:
services:
runner:
image: buddyspencer/gickup:latest
volumes:
- ./conf.yml:/gickup/conf.yml
- ./backup:/backup
command: ["/gickup/conf.yml"]
environment:
- TZ=Europe/Amsterdam
#restart: alwaysEr wordt een container met de naam runner gedefinieerd op basis van de eerder genoemde image. De container krijgt twee volumes: het configuratiebestand en de nog lege map backup.
Voordat je de container start, heb je een eenvoudig configuratiebestand (conf.yml) nodig. Daarin staan twee belangrijke secties: source en destination. Om de opbouw van de configuratie te begrijpen, eerst een heel eenvoudig voorbeeld: Gickup moet alle openbaar toegankelijke repository’s van een gebruiker van GitHub downloaden en lokaal opslaan:
source:
github:
- user: <username>
destination:
local:
- path: /backup
structured: true
zip: false
keep: 5
bare: false
lfs: falseOnder source staat het object github, dat een lijst met bronnen op GitHub bevat. Als je dit wilt uitproberen, vervang <username> dan door een GitHub-gebruikersnaam die openbare repository’s heeft.
Onder destination staat het object local, dat de gedownloade repository’s op de lokale harde schijf opslaat. De map /backup is via het Docker-volume gekoppeld aan de map met dezelfde naam op de server.
Hieronder volgen nog meer configuratiemogelijkheden: met de parameter keep kun je bijvoorbeeld bepalen hoeveel back-ups er bewaard moeten worden. De parameter structured zorgt ervoor dat Gickup een submap aanmaakt voor elke bron, elke gebruikersnaam en elke repository.
Nu is het tijd voor de eerste back-up: navigeer via de commandline naar de map met het Docker-Compose-bestand en start de container:
docker compose upIn de uitvoer zou je moeten zien hoe de repository’s van de gebruiker één voor één worden geback-upt. In de map ‘backup’ verschijnen nieuwe mappen die zich vullen. In de mappen voor elke repository zit een map die is vernoemd naar de huidige Unix-timestamp.
Gickup overschrijft oude back-ups niet, maar slaat meerdere versies (zoveel als je met keep hebt ingesteld) naast elkaar op. Zodra de back-up is voltooid, wordt de container gepauzeerd. Dat is best handig tijdens de installatiefase; aan het einde van dit artikel wordt Gickup omgezet naar always-on.
Commerciële alternatieven
Back-ups van Git-repository’s worden ook als kant-en-klare dienst aangeboden door gespecialiseerde aanbieders, maar die zijn niet bepaald goedkoop. Gitprotect vraagt bijvoorbeeld in het goedkoopste tarief (Team) minimaal 24 dollar per maand voor maximaal 15 repository’s. Voor maximaal 40 repo’s betaal je al 50 dollar.
Dat is nogal onevenredig, want code neemt meestal niet zo veel opslagruimte in beslag. Met het starterspakket kun je back-ups maken van GitHub, GitLab en Bitbucket, maar niet van de zelfgehoste variant, daarvoor heb je het Enterprise-pakket nodig (vanaf 36 dollar per maand).
Met een zelfbeheerde Gickup-server ben je aanzienlijk goedkoper uit en heb je ook toegang tot je back-ups als de grote clouds van Amazon, Google en Microsoft wat langer niet bereikbaar zouden zijn: gehuurde virtuele servers bij hostingproviders met 100 GB of meer opslagruimte zijn er al vanaf 3 euro per maand, en de stroomkosten voor een NAS of Raspberry Pi thuis of op kantoor liggen daar nog eens onder.
Privérepository’s
Het wordt iets ingewikkelder als je privé-repository’s wilt back-uppen. Hiervoor heeft Gickup inloggegevens nodig, die je op verschillende manieren kunt doorgeven. Inloggen met een wachtwoord is absoluut niet aan te raden. Bij GitHub zou dat sowieso alleen werken als je nog geen 2FA hebt ingeschakeld, wat tegenwoordig grove nalatigheid zou zijn.
GitHub dwingt inmiddels een tweede factor af voor iedereen die code bijdraagt. Gebruik in plaats daarvan een toegangstoken dat in het beste geval alleen leesrechten heeft; een back-upsysteem heeft immers geen schrijfrechten nodig en het ‘least privilege’-principe heeft zijn waarde bewezen.
Ga als ingelogde GitHub-gebruiker naar github.com/settings/personal-access-tokens. Maak daar een nieuw ‘fine-grained’ token aan, geef het een naam en een vervaldatum en kies voor welke repository’s en organisaties het rechten moet hebben. Helemaal onderaan moet je de rechten selecteren. Wij hebben leesrechten ingeschakeld voor Commit statuses, Contents, Metadata en Pull requests.
Als je ook wiki’s en issues wilt back-uppen, geef je daar ook leesrechten voor. Maak het token aan en kopieer de tekenreeks. Deze wordt daarna nooit meer weergegeven: sla hem bij voorkeur op in een wachtwoordbeheerder, zodat je hem niet kwijtraakt. Met deze informatie kun je het gedeelte source uitbreiden:
source:
github:
user: <username destination>
username: <your username>
token: <token>
exclude:
- examplerepo
includeorg:
- my-example-org
wiki: trueNieuw is de parameter username, die aangeeft onder welke identiteit Gickup zich moet aanmelden. Deze waarde is meestal hetzelfde als die van user. Deze laatste geeft aan wiens repository’s er moeten worden opgeslagen. Het gegenereerde token komt in de parameter token.
Met exclude kun je een lijst met repository’s opgeven die niet moeten worden geladen. Deze instelling is net zo optioneel als includeorg. Als je lid bent van een organisatie en het token geldig is voor de repository’s daarvan, kun je die hier vermelden. Ook het vermelden van wiki is optioneel. Als je geen wiki’s gebruikt of deze niet wilt back-uppen, laat je de regel weg.
Als je de gegevens via SSH en niet via HTTP van GitHub wilt downloaden, kun je de parameter ssh: true toevoegen. Je kunt de nieuwe configuratie weer testen met docker compose up.
Als de back-up gelukt is, kun je de bronconfiguratie verder verfijnen. De Gickup-documentatie (zie de link bij dit artikel) beschrijft niet alleen de mogelijke parameters voor GitHub, maar ook voor hostingdiensten zoals GitLab, Gitea en Bitbucket. Voor al deze bronnen zijn er nog meer parameters, onder andere om te bepalen welke repository’s moeten worden opgeslagen.
Je kunt bijvoorbeeld filteren op programmeertalen of projecten met een minimum aantal sterren. De documentatie beschrijft ook hoe je andere hostingdiensten als doel kunt instellen en zo bijvoorbeeld repository’s van GitHub naar Gitea kunt spiegelen. De installatie spreekt voor zich; je hebt voor de betreffende bestemming vooral inloggegevens met schrijfrechten nodig.
Finetuning
Zodra je tevreden bent met de back-up, kun je het configuratiebestand conf.yml op het hoogste niveau uitbreiden met twee extra secties:
log:
timeformat: 2006-01-02 15:04:05
file-logging:
dir: /backup/log
file: gickup.log
maxage: 14
cron: 10 3 * * *De sectie log beschrijft hoe Gickup een logboek bijhoudt. In het voorbeeld komt een logbestand in de map backup/log terecht en wordt het altijd 14 dagen bewaard. De parameter cron maakt van het handmatige back-upsysteem ten slotte een volledig automatisch systeem. De parameter verwacht een opdracht in cron-syntaxis. Die geeft Gickup de opdracht wanneer de repository’s moeten worden geback-upt.
In het voorbeeld wordt er elke nacht om 3:10 uur een back-up gemaakt. Als je de cron-syntaxis niet zomaar uit je mouw kunt schudden, kunnen websites zoals crontab.guru je helpen. In het Docker-Compose-bestand aan het begin van het artikel staat al de regel #restart: always. Verwijder het hekje aan het begin, waardoor die tot nu toe werd genegeerd. Dan kan Docker de container steeds opnieuw starten als hij eens crasht of als de server opnieuw opstart.
Start vervolgens de container permanent:
docker compose up -dDe optie -d geeft Docker de opdracht om op de achtergrond op te starten en de commandline niet te blokkeren. Of Gickup werkt zoals gepland, kun je lezen in het logbestand. Als je via een pushbericht op de hoogte wilt worden gebracht zodra een back-up is voltooid of mislukt, vind je in de documentatie onder ‘Miscellaneous’ een configuratiefragment om bijvoorbeeld de dienst ntfy te koppelen.
Conclusie
Een automatische back-up van alle Git-repository’s is met Gickup snel geregeld: er zijn dus geen excuses meer om de back-up uit te stellen. Over uitstellen gesproken: als de configuratie eenmaal draait, moet je eens nadenken over hoe je de lokale back-ups, die Gickup in volumes opslaat, in je back-upstrategie kunt opnemen. In het beste geval verplaats je de gegevens automatisch en regelmatig naar een externe back-up. Maar dat is een ander verhaal.
Jan Mahn en Alieke van Sommeren
Praat mee