Zo maak je een back-up van je app-database (en herstel je hem echt)

Om een back-up van je app-database te maken, exporteer je die volgens een schema naar een bestand (voor Postgres is het standaardprogramma pg_dump), bewaar je kopieën ergens los van de database, en herstel je regelmatig een kopie in een lege database om te bewijzen dat het werkt. Maak een extra back-up vlak voor elke riskante wijziging. Je code-back-up, of dat nu een GitHub-repository of een export is, bevat je data niet.

Deze gids is bedoeld voor mensen die een kleine app draaien en zich geen zorgen meer willen maken over verlies. Er wordt Postgres gebruikt in de voorbeelden, omdat de meeste met AI gebouwde apps dat gebruiken, maar de principes gelden voor elke database.

Wat een back-up moet dekken

Een app is meer dan zijn database. Weet welk deel elke back-up beschermt.

De data is het deel dat je niet kunt terugmaken. Code kun je opnieuw schrijven en instellingen opnieuw invoeren; de bestellingen van je klanten niet.

Stap 1: Bepaal hoeveel je kunt verliezen

Twee vragen bepalen je back-upplan:

• Hoeveel recente data kun je missen? Als je één keer per dag een back-up maakt en de database in de avond uitvalt, verlies je de wijzigingen van die dag. Voor een hobby-app is dat prima. Voor een app die bestellingen aanneemt, misschien niet.
• Hoe lang mag de app offline zijn terwijl je herstelt? Een kleine database herstel je in minuten. Een grote kan veel langer duren, en dat wil je weten voordat je het nodig hebt.

Voor de meeste kleine apps is een dagelijkse automatische back-up plus een handmatige back-up vóór riskante wijzigingen een verstandige start. Apps waarbij geld of gezondheidsgegevens een rol spelen, verdienen vaker back-ups, of een beheerde database met point-in-time-herstel (het vermogen om terug te zetten naar elk moment, niet alleen naar de laatste back-up).

Stap 2: Kijk wat je host al doet

Veel beheerde databaseproviders maken automatisch back-ups. Ga na:

• Staan back-ups aan voor jouw abonnement, en hoe vaak lopen ze?
• Hoe lang worden ze bewaard?
• Kun je terugzetten naar een moment in de tijd, of alleen naar een dagelijkse snapshot?
• Kun je een back-up downloaden, of alleen binnen hun systeem herstellen?

Back-ups van providers zijn nuttig, maar ze delen één zwak punt met je database: het account. Als het account wordt opgezegd, geschorst of het project wordt verwijderd, kunnen de back-ups meeverdwijnen. Daarom wil je ook een eigen kopie.

Stap 3: Een dump maken met pg_dump

pg_dump exporteert een Postgres-database naar een bestand. Het leest een consistente momentopname, dus de app kan blijven draaien terwijl het werkt.

Een typisch commando, met de verbindingsstring die je app al in een omgevingsvariabele heeft:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Wat de opties doen:

• --format=custom schrijft een gecomprimeerd bestand dat pg_restore kan lezen, en laat je later afzonderlijke tabellen herstellen. Gebruik --format=plain als je liever een leesbaar .sql-bestand wilt.
• --no-owner laat de eigenaarscommando’s weg, wat herstellen in een andere database eenvoudiger maakt.
• De datum in de bestandsnaam houdt back-ups uit elkaar.

De versie van pg_dump moet gelijk zijn aan of nieuwer dan de Postgres-versie van je database. Een oudere pg_dump weigert soms te draaien.

Als je met AI bouwt en de opdrachtregel niet wilt gebruiken, kun je vragen:

Maak een back-up van de database van de app met pg_dump in het custom-formaat, met de datum van vandaag in de bestandsnaam. Toon de verbindingsstring of een geheim niet. Vertel me de bestandsnaam en de grootte als het klaar is.

Stap 4: Automatiseer het

Handmatige back-ups worden vergeten. Automatiseer ze met wat je setup ondersteunt:

• De geplande back-ups van je databaseprovider, als die er zijn.
• Een geplande taak op een server of CI-dienst die pg_dump draait en het bestand naar opslag uploadt.
• Een gehoste back-updienst die verbinding maakt met je database.

Wat je ook kiest, zorg dat het je waarschuwt als een back-up mislukt. Een back-uptaak die al drie maanden stilletjes faalt, is het klassieke horrorverhaal.

Stap 5: Bewaar kopieën op een andere plek

De vuistregel wordt vaak de 3-2-1-regel genoemd: drie kopieën van je data, op twee verschillende soorten opslag, met één kopie buiten de deur. Voor een kleine app is een praktische versie:

• De live database
• De eigen automatische back-ups van de provider
• Je eigen dumps in aparte opslag, zoals een objectopslag-bucket in een ander account

Verder:

• Beperk de toegang. Een back-up bevat de data van elke gebruiker. Behandel hem als de live database.
• Houd een bewaarbeleid aan. Bijvoorbeeld dagelijkse back-ups twee weken en maandelijkse een jaar. Verwijder oude back-ups bewust, en onthoud dat privacywetgeving kan vereisen dat je persoonsgegevens op verzoek verwijdert.
• Zet nooit back-ups in Git. Een dump in een repository is een datalek dat wacht om te gebeuren.

Stap 6: Test een herstel

Een back-up is alleen zo goed als je laatste geslaagde herstel. Doe dit minstens elke paar maanden, en na elke wijziging in het back-upproces:

1. Maak een nieuwe, lege database. Herstel nooit over de live database heen om te testen.
2. Herstel de laatste back-up erin:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Voor een gewoon .sql-bestand gebruik je in plaats daarvan psql "$TEST_DATABASE_URL" -f backup.sql.

1. Controleer of elke tabel bestaat, vergelijk het aantal rijen met de live database en kijk naar een paar recente records.
2. Richt een kopie van de app erop en log in, als dat kan.
3. Noteer hoe lang het herstel duurde. Dat is je echte hersteltijd.

Stap 7: Maak een back-up vóór riskante wijzigingen

Maak een verse back-up vlak voor:

• Het uitvoeren van een databasemigratie die kolommen verwijdert of hernoemt
• Het in bulk importeren van data
• Een AI-agent grote wijzigingen laten maken aan het datamodel
• Het verwijderen van oude records

In een met AI gebouwde app kan de agent de tabelstructuur wijzigen als onderdeel van een functie. Checkpoints en versiebeheer draaien je code terug, maar ze halen geen verwijderde rijen terug. Een back-up van dertig seconden vóór een grote wijziging is goedkope verzekering.

Veelgemaakte fouten

• Aannemen dat Git of een codeexport een back-up is. Die bevat de code, niet de data.
• Nooit een herstel testen. Veel back-ups blijken pas leeg, onvolledig of onleesbaar als je ze nodig hebt.
• Back-ups bewaren in hetzelfde account als de database. Eén gecompromitteerd of opgezegd account verliest beide.
• Geüploade bestanden vergeten. De database slaat het pad van het bestand op; de afbeelding zelf staat in opslag.
• Geheimen in back-upscripts laten staan. Lees de verbindingsstring uit een omgevingsvariabele, nooit uit de tekst van het script. Zie hoe je API-sleutels veilig houdt.

Back-ups en Mythex

Mythex-projecten kunnen een eigen Postgres-database hebben, en de verbindingsgegevens worden ingevoegd in de werkruimte en de gepubliceerde app. De Mythex-documentatie beschrijft geen functie voor back-up of herstel van de database, dus plan het zelf: vraag de agent om een dump te maken, download die en bewaar hem veilig, vooral vóór grote wijzigingen. Een projectexport (Pro) bevat je code, met geheimen en node_modules weggelaten; het bevat geen databaserijen. Zie Database en Data-eigendom in de documentatie. Lees voor meer over de database zelf wat is Postgres.

Checklist voor back-ups

• Bepaald hoeveel data je kunt missen en hoe lang je offline kunt zijn
• Nagekeken welke automatische back-ups je databasehost biedt
• Je eigen dump draait volgens schema, en fouten sturen je een melding
• Kopieën zijn los van de database opgeslagen, met beperkte toegang
• Bewaarbeleid is opgeschreven
• Geüploade bestanden zijn net zo goed geback-upt als de database
• Herstel getest in een lege database, met gecontroleerd aantal rijen
• Back-up gemaakt vóór elke riskante wijziging

Veelgestelde vragen