Backup-strategie voor lokaal gedraaide modellen en data

Het opzetten van een lokale workflow met open-source taalmodellen biedt volledige controle over data en verwerkingssnelheid. Toch ontbreekt bij veel lokale installaties een doordachte backup-strategie. Bij een hardwaredefect, een beschadigde database-index of een foutieve configuratie-update kan er waardevolle informatie verloren gaan. Het simpelweg kopiëren van een complete schijf is bij lokale AI-systemen echter inefficiënt vanwege de enorme omvang van modelbestanden.

Een effectieve backup-strategie scheidt statische bronnen van unieke gegevens. In deze gids behandelen we welke componenten prioriteit hebben, hoe de 3-2-1-regel wordt toegepast op AI-omgevingen, wat de specifieke eisen zijn voor vectordatabases en hoe versleuteling en herstelprocedures ingericht moeten worden.

Onderscheid: Wat wel en niet backuppen?

Een van de grootste valkuilen bij het beheer van lokale LLM's is het opslaan van gigabytes aan ruwe modelgewichten in een dagelijkse backup. Om opslagruimte en bandbreedte efficiënt te benutten, is het essentieel om onderscheid te maken tussen reproduceerbare bestanden en unieke data.

Niet backuppen (herdownloadbaar)

Ruwe modelbestanden zoals .gguf, .safetensors of HuggingFace-repository's nemen tientallen gigabytes in beslag. Omdat deze bestanden onveranderlijk zijn en gedownload kunnen worden vanaf openbare bronnen, hoeven ze niet te worden opgenomen in periodieke backups. Het is wel verstandig om de exacte namen, revisies en bron-URL's vast te leggen. Raadpleeg voor meer details over efficiënt bestandsbeheer onze gids over modellen downloaden en beheren.

Wel backuppen (uniek en onvervangbaar)

De werkelijke waarde van een lokale AI-infrastructuur zit in de maatwerkonderdelen die door u of uw organisatie zijn opgebouwd:

• Configuratiebestanden en Modelfiles: Aangepaste systeemprompts, temperatuurinstellingen, stop-tokens en Ollama Modelfiles.
• Chatgeschiedenis en logboeken: Gespreksgegevens, geëxporteerde JSON-bestanden en applicatiedatabases van frontends zoals Open WebUI of LibreChat.
• Bron-documenten voor RAG: De originele PDF-bestanden, tekstbestanden en Markdown-notities die gebruikt worden voor kennisbanksystemen.
• Finetune-resultaten en LoRA-adapters: Zelf getrainde weights, LoRA-adapters en bijbehorende hyperparameters. Deze bestanden zijn relatief klein maar vertegenwoordigen aanzienlijke rekentijd.
• Vectordatabase-configuraties: Schema's en instellingen van vectorindexen.

De 3-2-1 regel toegepast op AI-data

De klassieke 3-2-1 backup-regel is onverminderd van toepassing op lokale AI-opstellingen. Dit principe houdt in:

• Bewaar minimaal 3 exemplaren van belangrijke data (het origineel en twee kopieën).
• Gebruik 2 verschillende drager-types (bijvoorbeeld een lokale NVMe-schijf en een netwerkopslag).
• Sla minimaal 1 kopie offsite op (een fysiek gescheiden locatie of een versleutelde cloud-opslag).

In de praktijk kan dit betekenen dat uw actieve werkbestanden op de lokale workstation staan, dat er elk uur een automatische momentopname wordt gemaakt naar een lokale NAS, en dat er nachtelijk een versleutelde backuprichting een externe opslaglocatie wordt verstuurd. Wie een NAS inzet binnen het netwerk, kan specifieke instellingen terugvinden in het artikel over een LLM op Synology NAS.

Vectordatabases: Herbouwen versus backuppen

Retrieval-Augmented Generation (RAG) maakt gebruik van vectordatabases zoals ChromaDB, Qdrant, Milvus of PGvector om documenten te doorzoeken. Een vectorindex vraagt om een specifieke benadering bij backups.

Een vectorindex is in feite afgeleide data: de index wordt gegenereerd door bron-documenten door een specifiek embeddingmodel te sturen. Er zijn twee manieren om hiermee om te gaan bij een calamiteit:

Strategie A: Volledige index-backup (Fast Recovery)

U backupt de complete datadirectory van de vectordatabase (bijvoorbeeld de SQLite-bestanden of binary indexen). Dit maakt een zeer snel herstel mogelijk, omdat de index direct ingeladen kan worden zonder dat er opnieuw embeddings berekend hoeven te worden.

Strategie B: Brongebaseerde reconstructie (Storage Efficient)

U backupt uitsluitend de bron-documenten, samen met het exacte versienummer van het gebruikte embeddingmodel en de specifieke chunking-parameters. Bij een crash bouwt u de index opnieuw op. Dit bespaart opslagruimte, maar kost tijd en rekenkracht bij het herstel.

Versiebeheer voor configuraties en prompts

Naast traditionele bestandsbackups is versiebeheer een onmisbare pijler voor het beheer van LLM-infrastructuur. Systeemprompts, agentic workflows, API-wrappers en docker-compose.yml bestanden veranderen regelmatig. Het opslaan van deze bestanden in een versiebeheersysteem zoals Git biedt belangrijke voordelen:

• Het maakt inzichtelijk welke aanpassing in een prompt zorgde voor een verandering in de output van het model.
• Het maakt het eenvoudig om direct terug te keren naar een eerder werkende staat bij configuratiefouten.
• Het scheidt de code en instellingen volledig van de omvangrijke data-bestanden.

Zorg ervoor dat gevoelige gegevens zoals API-sleutels of wachtwoorden in .env-bestanden staan en dat deze bestanden zijn opgenomen in de .gitignore om onbedoelde publicatie te voorkomen.

Snapshots versus echte backups

Het is belangrijk om het verschil te begrijpen tussen een snapshot en een volwaardige backup. Veel virtualisatieplatformen (zoals Proxmox of Docker volume-snapshots) bieden de mogelijkheid om snel een status op te slaan.

Een snapshot is een bevroren toestand van het bestandssysteem op een specifiek moment op dezelfde fysieke opslag. Dit is ideaal als herstelpunt vlak vóór een software-update of een ingrijpende wijziging. Het beschermt echter niet tegen fysieke hardwaredefecten of corruptie van de opslagdrager.

Een echte backup is een onafhankelijke kopie van de data die is losgekoppeld van de bron, bij voorkeur op een ander medium of een andere locatie. Een robuuste strategie gebruikt snapshots voor snelle lokale rollback-acties en echte backups voor rampenherstel.

Automatisering van het backup-proces

Handmatige backups worden in de praktijk vaak vergeten. Automatisering zorgt voor continuïteit en betrouwbaarheid. Gebruik bij voorkeur tools die incrementele backups, compressie en versleuteling ondersteunen, zoals Restic, BorgBackup of Duplicati.

Een typisch geautomatiseerd proces voor een lokaal AI-station omvat de volgende stappen:

1. Pre-backup script: Zet databases tijdelijk in een consistente staat of maak een consistente database-dump (bijvoorbeeld via sqlite3 database.db ".backup 'dump.db'").
2. Inclusie en Exclusie: Configureer het backup-programma om de data-mappen van de frontend en bron-documenten mee te nemen, maar mappen zoals ~/.ollama/models of HuggingFace cache-mappen expliciet uit te sluiten.
3. Retentiebeleid: Stel regels in voor het opschonen van oude backups (bijvoorbeeld: 7 dagelijkse, 4 wekelijkse en 12 maandelijkse backups bewaren).
4. Logging en Notificaties: Zorg dat de uitkomst van de backup-taak wordt geregistreerd en dat er een melding verschijnt bij fouten.

Privacy en beveiliging van de opslag

Wanneer u lokaal modellen draait om privacyredenen, moet het backup-proces dezelfde privacygaranties bieden. Chatgeschiedenis en ingelezen bedrijfsdocumenten bevatten vaak vertrouwelijke informatie.

Let bij het inrichten van de backup op de volgende aspecten:

• Zero-Knowledge Versleuteling: Zorg dat backups altijd client-side worden versleuteld (bijvoorbeeld met AES-256) voordat ze over het netwerk worden verstuurd of op een externe locatie worden opgeslagen.
• Sleutelbeheer: Bewaar de encryptiesleutels en wachtzinnen op een veilige plek, gescheiden van de backup-data. Zonder de sleutel is de backup waardeloos.
• Compliancy: Indien de chat-data persoonsgegevens bevat, moet de bewaartermijn van backups in overeenstemming zijn met de geldende privacywetgeving. Lees voor aanvullende richtlijnen ons artikel over privacyvriendelijk AI.

Testen van de restore-procedure

Een ongeteste backup biedt geen zekerheid. Veel organisaties en beheerders ontdekken pas tijdens een calamiteit dat een backup corrupt is, onvolledig blijkt te zijn of dat de herstelprocedure te lang duurt.

Voer periodiek (bijvoorbeeld halfjaarlijks) een hersteltest uit op een geïsoleerd systeem of in een virtuele machine:

• Herstel de configuratiebestanden en de databasedumps.
• Start de lokale LLM-interface op en controleer of de chatgeschiedenis correct wordt ingeladen.
• Koppel de vectordatabase en voer een test-query uit om te verifiëren of de index goed functioneert. Aanvullende informatie over lokale zoekfunctionaliteit is te vinden bij documenten doorzoeken lokaal en lokale RAG Mac.
• Documenteer het herstelproces in een beknopt Disaster Recovery Plan, zodat u in geval van nood exact weet welke stappen u moet doorlopen.

Checklist per categorie

Gebruik deze checklist om uw huidige backup-inrichting te controleren:

1. Modellen en Weights

• [ ] Exclusieregels ingesteld voor grote base-model bestanden (GGUF, Safetensors).
• [ ] Documentatie of scripts aanwezig om benodigde modellen automatisch te herbewaken of opnieuw te downloaden.
• [ ] Eigen LoRA-adapters en finetuning-datasets opgenomen in de actieve backup.

2. Configuratie en Code

• [ ] Modelfiles, system prompts en container-definities opgeslagen in een Git-repository.
• [ ] Gevoelige variabelen (API-sleutels, wachtwoorden) afgeschermd via .env-bestanden en uitgesloten van Git.

3. Data en Databases

• [ ] Bron-documenten van de RAG-kennisbank veiliggesteld op minimaal twee locaties.
• [ ] Dagelijkse incrementele backup ingesteld voor chatgeschiedenis en gebruikers-databases.
• [ ] Keuze gemaakt tussen index-backup of herbouw-script voor de vectordatabase.

4. Beveiliging en Herstel

• [ ] Client-side versleuteling actief voor alle offsite backups.
• [ ] Encryptiesleutels veilig opgeslagen op een externe locatie.
• [ ] Restore-procedure succesvol getest op een secundair systeem.