Sådan sikkerhedskopierer du din apps database (og får den faktisk gendannet)

For at sikkerhedskopiere din app-database skal du eksportere den til en fil efter en plan (for Postgres er standardværktøjet pg_dump), gemme kopier et andet sted end databasen og jævnligt gendanne en kopi i en tom database for at bevise, at den virker. Tag en ekstra backup lige før enhver risikabel ændring. Din kodebackup, uanset om det er et GitHub-repository eller en eksport, indeholder ikke dine data.

Denne guide er til dig, der kører en lille app og vil holde op med at bekymre dig om at miste den. Den bruger Postgres i eksemplerne, fordi de fleste AI-byggede apps bruger det, men principperne gælder for enhver database.

Hvad en backup skal dække

En app er mere end sin database. Vid, hvilken del hver backup beskytter.

Hvad	Hvor det ligger	Sådan sikkerhedskopierer du det
Kode	Projektfiler, Git	GitHub-synkronisering eller projekteksport
Data (brugere, poster)	Databasen	Databasedump efter en plan
Uploadede filer	Objektlager	Kopiér bucketen, eller gem originalerne et andet sted
Hemmeligheder og indstillinger	Projektindstillinger, udbyderes dashboards	En adgangskodeadministrator, holdt opdateret

Dataene er den del, du ikke kan genskabe. Kode kan skrives om, og indstillinger kan indtastes igen; dine kunders ordrer kan ikke.

Trin 1: Beslut, hvor meget du kan miste

To spørgsmål fastlægger din backupplan:

Hvor meget nylig data har du råd til at miste? Hvis du tager backup én gang om dagen, og databasen fejler om aftenen, mister du dagens ændringer. For en hobbyapp er det fint. For en app, der modtager ordrer, er det måske ikke acceptabelt.
Hvor længe kan appen være nede, mens du gendanner? En lille database gendannes på få minutter. En stor kan tage meget længere, og det vil du vide, før du får brug for det.

For de fleste små apps er en daglig automatisk backup plus en manuel backup før risikable ændringer et fornuftigt udgangspunkt. Apps, hvor der er penge eller helbredsdata involveret, bør have hyppigere backups eller en administreret database med point-in-time recovery (muligheden for at gendanne til et hvilket som helst tidspunkt, ikke kun til den seneste backup).

Trin 2: Tjek, hvad din host allerede gør

Mange administrerede databaseudbydere tager automatiske backups. Find ud af:

Er backups slået til for din plan, og hvor ofte kører de?
Hvor længe gemmes de?
Kan du gendanne til et bestemt tidspunkt, eller kun til et daglig øjebliksbillede?
Kan du downloade en backup, eller kan du kun gendanne den inde i deres system?

Udbyderens backups er nyttige, men de deler et enkelt fejlpunkt med din database: kontoen. Hvis kontoen lukkes, suspenderes, eller projektet slettes, kan backuppene forsvinde med den. Derfor vil du også have din egen kopi.

Trin 3: Lav et dump med pg_dump

pg_dump eksporterer en Postgres-database til en fil. Det læser et konsistent øjebliksbillede, så appen kan køre videre, mens det arbejder.

En typisk kommando, der bruger den forbindelsesstreng, din app allerede har i en miljøvariabel:

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

Så gør valgmulighederne:

--format=custom skriver en komprimeret fil, som pg_restore kan læse, og lader dig gendanne enkelte tabeller senere. Brug --format=plain, hvis du i stedet vil have en læsbar .sql-fil.
--no-owner udelader kommandoer om ejerskab, hvilket gør det enklere at gendanne i en anden database.
Datoen i filnavnet holder backups adskilt.

Versionen af pg_dump bør være den samme som eller nyere end din databases Postgres-version. En ældre pg_dump kan nægte at køre.

Hvis du bygger med AI og ikke vil røre kommandolinjen, kan du spørge:

Lav en backup af appens database med pg_dump i custom-format, med dagens dato i filnavnet. Print ikke forbindelsesstrengen eller andre hemmeligheder. Fortæl mig filnavnet og størrelsen, når den er færdig.

Trin 4: Automatisér det

Manuelle backups bliver glemt. Automatisér dem med det, din opsætning understøtter:

Din databaseudbyders planlagte backups, hvis de tilbyder det.
Et planlagt job på en server eller en CI-tjeneste, der kører pg_dump og uploader filen til lagring.
En hostet backuptjeneste, der forbinder til din database.

Uanset hvad du vælger, skal den give besked, når en backup fejler. Et backupjob, der stille og roligt har fejlet i tre måneder, er den klassiske skrækhistorie.

Trin 5: Gem kopier et andet sted

Tommelfingerreglen kaldes ofte 3-2-1: tre kopier af dine data, på to forskellige slags lager, med én kopi uden for stedet. For en lille app er en praktisk version:

Den live database
Udbyderens egne automatiske backups
Dine egne dumps i separat lagring, fx en objektlagringsbucket i en anden konto

Desuden:

Begræns adgangen. En backup indeholder alle brugeres data. Behandl den som den live database.
Hav en opbevaringspolitik. Fx daglige backups i to uger og månedlige i et år. Slet gamle backups bevidst, og husk, at privatlivslovgivning kan kræve, at du sletter persondata på anmodning.
Commit aldrig backups til Git. Et dump i et repository er en datalæk, der venter på at ske.

Trin 6: Test en gendannelse

En backup er kun så god som din seneste vellykkede gendannelse. Mindst hver få måneder og efter enhver ændring af backupprocessen:

Opret en ny, tom database. Gendan aldrig over den live database for at teste.
Gendan den seneste backup i den:

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

Til en almindelig .sql-fil bruger du i stedet psql "$TEST_DATABASE_URL" -f backup.sql.

Kontroller, at alle tabeller findes, sammenlign antallet af rækker med den live database, og kig på et par nyere poster.
Peg en kopi af appen på den, og log ind, hvis du kan.
Skriv ned, hvor lang tid gendannelsen tog. Det er din reelle genopretningstid.

Trin 7: Tag backup før risikable ændringer

Tag en frisk backup lige før:

Du kører en databasemigrering, der sletter eller omdøber kolonner
Du importerer data i bulk
Du lader en AI-agent lave store ændringer i datamodellen
Du sletter gamle poster

I en AI-bygget app kan agenten ændre tabelstrukturen som en del af en funktion. Checkpoints og versionskontrol ruller din kode tilbage, men de gør ikke slettede rækker synlige igen. En backup på tredive sekunder før en stor ændring er billig forsikring.

Almindelige fejl

At antage, at Git eller en kodeeksport er en backup. Den har koden, ikke dataene.
Aldrig at teste en gendannelse. Mange backups viser sig at være tomme, ufuldstændige eller ulæselige først, når man har brug for dem.
At gemme backups i samme konto som databasen. Én kompromitteret eller lukket konto mister begge.
At glemme uploadede filer. Databasen gemmer filens sti; selve billedet ligger i lagringen.
At lade hemmeligheder ligge i backupscripts. Læs forbindelsesstrengen fra en miljøvariabel, aldrig fra scriptets tekst. Se sådan holder du API-nøgler sikre.

Backups og Mythex

Mythex-projekter kan have en dedikeret Postgres-database, og dens forbindelsesoplysninger indsættes i workspace'et og den publicerede app. Mythex-dokumentationen beskriver ikke en funktion til databasebackup eller gendannelse, så planlæg din egen: bed agenten om at lave et dump, download det, og gem det et sikkert sted, især før større ændringer. En projekteksport (Pro) indeholder din kode, med hemmeligheder og node_modules udeladt; den indeholder ikke databasens rækker. Se Database og Dataejerskab i dokumentationen. For mere om selve databasen, læs hvad er Postgres.

Tjekliste for backup

Besluttet, hvor meget data du har råd til at miste, og hvor længe du kan være nede
Tjekket, hvilke automatiske backups din databaseudbyder tilbyder
Dit eget dump kører efter en plan, og fejl giver dig besked
Kopier gemt adskilt fra databasen, med begrænset adgang
Opbevaringspolitik skrevet ned
Uploadede filer sikkerhedskopieret, ikke kun databasen
Gendannelse testet i en tom database, med antal rækker kontrolleret
Backup taget før hver risikabel ændring

Spørgsmål

Hvor ofte bør jeg sikkerhedskopiere min apps database?

Vælg en frekvens, der matcher, hvor meget data du har råd til at miste. For de fleste små apps er en daglig automatisk backup et fornuftigt minimum, plus en manuel backup før enhver risikabel ændring, fx en migrering, en import eller en stor ny funktion.

Er det det samme at eksportere min kode som at sikkerhedskopiere mine data?

Nej. En kodeeksport eller et GitHub-repository indeholder din apps filer, ikke rækkerne i din database. Dine brugere, ordrer og opslag ligger i databasen og skal have deres egen backup.

Hvad er pg_dump?

pg_dump er det standardkommandolinjeværktøj, der følger med Postgres, til at eksportere en database til en fil. Det kan skrive almindelig SQL eller et komprimeret brugerdefineret format, og de tilsvarende gendannelsesværktøjer er psql til SQL-filer og pg_restore til det brugerdefinerede format.

Hvordan ved jeg, at min backup virker?

Gendan den. Indlæs backuppen i en separat, tom database, og kontroller derefter, at tabellerne findes, og at antallet af rækker og et par nyere poster matcher de live data. En backup, du aldrig har gendannet, er et gæt.

Hvor bør jeg gemme databasebackups?

Et andet sted end selve databasen, helst hos en anden udbyder eller i en anden konto, og med adgang begrænset til dig. Backups indeholder alle dine brugeres data, så behandl dem lige så omhyggeligt som den live database.