Slik sikkerhetskopierer du appdatabasen din (og får den faktisk gjenopprettet)

For å sikkerhetskopiere appdatabasen din eksporterer du den til en fil etter en fast plan (for Postgres er standardverktøyet pg_dump), lagrer kopiene et annet sted enn selve databasen, og gjenoppretter jevnlig én kopi i en tom database for å bevise at den fungerer. Ta en ekstra sikkerhetskopi rett før enhver risikabel endring. Kodesikkerhetskopien din, enten det er et GitHub-repositorium eller en eksport, inkluderer ikke dataene dine.

Denne guiden er for folk som driver en liten app og vil slippe å bekymre seg for å miste den. Den bruker Postgres i eksemplene, siden de fleste AI-bygde apper bruker det, men prinsippene gjelder for alle databaser.

Hva en sikkerhetskopi må dekke

En app er mer enn databasen. Vit hvilken del hver sikkerhetskopi beskytter.

Hva	Hvor det ligger	Hvordan sikkerhetskopiere
Kode	Prosjektfiler, Git	GitHub-synkronisering eller prosjekteksport
Data (brukere, poster)	Databasen	Databasedump etter en plan
Opplastede filer	Objektlagring	Kopier bøtten, eller oppbevar originalene et annet sted
Hemmeligheter og innstillinger	Prosjektinnstillinger, leverandørenes dashbord	En passordbehandler, holdt oppdatert

Dataene er den delen du ikke kan gjenskape. Kode kan skrives om, og innstillinger kan legges inn på nytt. Kundenes bestillinger kan ikke det.

Steg 1: Bestem hvor mye du kan miste

To spørsmål styrer sikkerhetskopiplanen din:

Hvor mye nylige data har du råd til å miste? Hvis du tar sikkerhetskopi én gang i døgnet og databasen feiler om kvelden, mister du endringene fra den dagen. For en hobbyapp er det greit. For en app som tar imot bestillinger kan det være for mye.
Hvor lenge kan appen være nede mens du gjenoppretter? En liten database gjenopprettes på minutter. En stor kan ta mye lengre tid, og du bør vite det før du trenger det.

For de fleste små apper er en daglig automatisk sikkerhetskopi, pluss en manuell kopi før risikable endringer, et fornuftig utgangspunkt. Apper der det står penger eller helsedata på spill bør ta kopier oftere, eller bruke en administrert database med gjenoppretting til et bestemt tidspunkt (muligheten til å gjenopprette til et hvilket som helst øyeblikk, ikke bare til siste kopi).

Steg 2: Sjekk hva verten din allerede gjør

Mange administrerte databaseleverandører tar automatiske sikkerhetskopier. Finn ut:

Er sikkerhetskopier slått på for abonnementet ditt, og hvor ofte kjøres de?
Hvor lenge oppbevares de?
Kan du gjenopprette til et bestemt tidspunkt, eller bare til et daglig øyeblikksbilde?
Kan du laste ned en sikkerhetskopi, eller kan du bare gjenopprette den inne i systemet deres?

Leverandørens sikkerhetskopier er nyttige, men de deler ett felles sårbart punkt med databasen din: kontoen. Hvis kontoen blir stengt, suspendert eller prosjektet slettes, kan sikkerhetskopiene forsvinne sammen med den. Derfor vil du også ha en egen kopi.

Steg 3: Lag en dump med pg_dump

pg_dump eksporterer en Postgres-database til en fil. Den leser et konsistent øyeblikksbilde, så appen kan fortsette å kjøre mens den jobber.

En typisk kommando, som bruker tilkoblingsstrengen appen din allerede har i en miljøvariabel:

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

Dette gjør alternativene:

--format=custom skriver en komprimert fil som pg_restore kan lese, og lar deg gjenopprette enkelttabeller senere. Bruk --format=plain hvis du vil ha en lesbar .sql-fil i stedet.
--no-owner utelater eierskapskommandoer, noe som gjør gjenoppretting i en annen database enklere.
Datoen i filnavnet holder sikkerhetskopiene fra hverandre.

Versjonen av pg_dump bør være den samme som, eller nyere enn, Postgres-versjonen i databasen din. En eldre pg_dump kan nekte å kjøre.

Hvis du bygger med AI og ikke vil røre kommandolinjen, kan du be om:

Lag en sikkerhetskopi av appens database med pg_dump i custom-format, med dagens dato i filnavnet. Ikke skriv ut tilkoblingsstrengen eller noen hemmelighet. Fortell meg filnavnet og størrelsen når den er ferdig.

Steg 4: Automatiser det

Manuelle sikkerhetskopier blir glemt. Automatiser dem med det oppsettet ditt støtter:

Databaseleverandørens planlagte sikkerhetskopier, hvis de tilbyr det.
En planlagt jobb på en server eller CI-tjeneste som kjører pg_dump og laster opp filen til lagring.
En hostet sikkerhetskopitjeneste som kobler seg til databasen din.

Uansett hva du velger, sørg for at den varsler deg når en sikkerhetskopi feiler. En sikkerhetskopijobb som stille har feilet i tre måneder er den klassiske skrekkhistorien.

Steg 5: Lagre kopier et annet sted

Tommelfingerregelen kalles ofte 3-2-1: tre kopier av dataene dine, på to ulike typer lagring, med én kopi utenfor stedet. For en liten app er en praktisk versjon:

Den levende databasen
Leverandørens egne automatiske sikkerhetskopier
Dine egne dumper i separat lagring, for eksempel en objektlagringsbøtte i en annen konto

I tillegg:

Begrens tilgangen. En sikkerhetskopi inneholder alle brukernes data. Behandle den som den levende databasen.
Ha en oppbevaringspolicy. For eksempel daglige kopier i to uker og månedlige i ett år. Slett gamle kopier med vilje, og husk at personvernregler kan kreve at du sletter personopplysninger på forespørsel.
Legg aldri sikkerhetskopier i Git. En dump i et repositorium er en datalekkasje som venter på å skje.

Steg 6: Test en gjenoppretting

En sikkerhetskopi er bare så god som din siste vellykkede gjenoppretting. Minst hver tredje måned, og etter enhver endring i sikkerhetskopiprosessen:

Lag en ny, tom database. Gjenopprett aldri over den levende databasen for å teste.
Gjenopprett den siste sikkerhetskopien inn i den:

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

For en vanlig .sql-fil bruker du psql "$TEST_DATABASE_URL" -f backup.sql i stedet.

Kontroller at alle tabellene finnes, sammenlign antall rader med den levende databasen, og se på noen nylige poster.
Koble en kopi av appen til den og logg inn, hvis du kan.
Skriv ned hvor lang tid gjenopprettingen tok. Det er din faktiske gjenopprettingstid.

Steg 7: Ta sikkerhetskopi før risikable endringer

Ta en fersk sikkerhetskopi rett før du:

Kjører en databasemigrering som sletter eller gir nytt navn til kolonner
Importerer data i bulk
Lar en AI-agent gjøre store endringer i datamodellen
Sletter gamle poster

I en AI-bygd app kan agenten endre tabellstrukturen som en del av en funksjon. Sjekkpunkter og versjonskontroll ruller tilbake koden din, men de angrer ikke slettede rader. En sikkerhetskopi på tretti sekunder før en stor endring er billig forsikring.

Vanlige feil

Å anta at Git eller en kodeeksport er en sikkerhetskopi. Den har koden, ikke dataene.
Å aldri teste en gjenoppretting. Mange sikkerhetskopier viser seg å være tomme, ufullstendige eller uleselige først når de trengs.
Å oppbevare sikkerhetskopier i samme konto som databasen. Én kompromittert eller stengt konto mister begge.
Å glemme opplastede filer. Databasen lagrer filens sti; selve bildet ligger i lagring.
Å la hemmeligheter stå i sikkerhetskopiskript. Les tilkoblingsstrengen fra en miljøvariabel, aldri fra skriptets tekst. Se hvordan du holder API-nøkler trygge.

Sikkerhetskopiering og Mythex

Mythex-prosjekter kan ha en egen Postgres-database, og tilkoblingsdetaljene settes inn i arbeidsområdet og den publiserte appen. Mythex-dokumentasjonen beskriver ingen funksjon for sikkerhetskopiering eller gjenoppretting av databasen, så planlegg din egen: be agenten lage en dump, last den ned og oppbevar den trygt, spesielt før store endringer. En prosjekteksport (Pro) inneholder koden din, med hemmeligheter og node_modules utelatt; den inneholder ikke databaseradene. Se Database og Data ownership i dokumentasjonen. For mer om selve databasen, les hva er Postgres.

Sjekkliste for sikkerhetskopi

Bestemt hvor mye data du har råd til å miste, og hvor lenge du kan være nede
Sjekket hvilke automatiske sikkerhetskopier databaseverten din tilbyr
Din egen dump kjører etter en plan, og feil varsler deg
Kopier lagret separat fra databasen, med begrenset tilgang
Oppbevaringspolicy skrevet ned
Opplastede filer sikkerhetskopiert i tillegg til databasen
Gjenoppretting testet i en tom database, med radantall kontrollert
Sikkerhetskopi tatt før hver risikable endring

Spørsmål

Hvor ofte bør jeg ta sikkerhetskopi av appdatabasen min?

Tilpass det til hvor mye data du har råd til å miste. For de fleste små apper er en daglig automatisk sikkerhetskopi et fornuftig minimum, pluss en manuell kopi før risikable endringer, for eksempel en migrering, en import eller en stor ny funksjon.

Er det det samme å eksportere koden min som å sikkerhetskopiere dataene mine?

Nei. En kodeeksport eller et GitHub-repositorium inneholder appens filer, ikke radene i databasen. Brukerne, bestillingene og innleggene dine ligger i databasen og trenger en egen sikkerhetskopi.

Hva er pg_dump?

pg_dump er standardverktøyet for kommandolinjen som følger med Postgres, for å eksportere en database til en fil. Det kan skrive vanlig SQL eller et komprimert egendefinert format. De tilsvarende gjenopprettingsverktøyene er psql for SQL-filer og pg_restore for det egendefinerte formatet.

Hvordan vet jeg at sikkerhetskopien fungerer?

Gjenopprett den. Last sikkerhetskopien inn i en egen, tom database, og kontroller at tabellene finnes og at antall rader og noen nylige poster stemmer med de levende dataene. En sikkerhetskopi du aldri har gjenopprettet er bare en antagelse.

Hvor bør jeg lagre databasekopier?

Et annet sted enn selve databasen, helst hos en annen leverandør eller i en annen konto, og med tilgang begrenset til deg. Kopiene inneholder alle brukernes data, så behandle dem like nøye som den levende databasen.