Så säkerhetskopierar du din apps databas (och återställer den på riktigt)

För att säkerhetskopiera din appdatabas exporterar du den till en fil enligt schema (för Postgres är standardverktyget pg_dump), lagrar kopiorna på en plats som är separat från databasen och återställer regelbundet en kopia i en tom databas för att bevisa att den fungerar. Ta en extra säkerhetskopia precis innan varje riskfylld ändring. Din kodsäkerhetskopia, oavsett om det är ett GitHub-repository eller en export, innehåller inte din data.

Den här guiden riktar sig till dig som kör en liten app och vill sluta oroa dig för att förlora den. Den använder Postgres i exemplen eftersom de flesta AI-byggda appar använder det, men principerna gäller för alla databaser.

Vad en säkerhetskopia måste omfatta

En app är mer än sin databas. Känn till vilken del varje säkerhetskopia skyddar.

Datan är den del du inte kan återskapa. Kod kan skrivas om och inställningar kan matas in igen; dina kunders beställningar kan inte det.

Steg 1: Bestäm hur mycket du kan förlora

Två frågor avgör din säkerhetskopieringsplan:

• Hur mycket av den senaste datan har du råd att förlora? Om du säkerhetskopierar en gång per dag och databasen havererar på kvällen förlorar du dagens ändringar. För en hobbyapp är det okej. För en app som tar emot beställningar kanske det inte är det.
• Hur länge kan appen vara nere medan du återställer? En liten databas återställs på några minuter. En stor kan ta mycket längre, och det vill du veta innan du behöver den.

För de flesta små appar är en daglig automatisk säkerhetskopia plus en manuell säkerhetskopia före riskfyllda ändringar en rimlig start. Appar som hanterar pengar eller hälsodata bör ha tätare säkerhetskopior, eller en hanterad databas med återställning till en viss tidpunkt (möjligheten att återställa till vilket ögonblick som helst, inte bara till den senaste säkerhetskopian).

Steg 2: Kontrollera vad din värd redan gör

Många hanterade databasleverantörer tar automatiska säkerhetskopior. Ta reda på:

• Är säkerhetskopiering påslagen för din plan, och hur ofta körs den?
• Hur länge sparas de?
• Kan du återställa till en viss tidpunkt, eller bara till en daglig ögonblicksbild?
• Kan du ladda ner en säkerhetskopia, eller bara återställa den inne i deras system?

Leverantörens säkerhetskopior är användbara, men de delar en gemensam svag punkt med din databas: kontot. Om kontot stängs, spärras eller projektet raderas kan säkerhetskopiorna följa med. Därför vill du också ha en egen kopia.

Steg 3: Gör en dump med pg_dump

pg_dump exporterar en Postgres-databas till en fil. Den läser en konsekvent ögonblicksbild, så appen kan fortsätta köra medan den arbetar.

Ett typiskt kommando, med anslutningssträngen din app redan har i en miljövariabel:

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

Vad alternativen gör:

• --format=custom skriver en komprimerad fil som pg_restore kan läsa, och låter dig återställa enskilda tabeller senare. Använd --format=plain om du vill ha en läsbar .sql-fil i stället.
• --no-owner utelämnar ägarkommandon, vilket gör det enklare att återställa i en annan databas.
• Datumet i filnamnet håller säkerhetskopiorna isär.

Versionen av pg_dump ska vara densamma som, eller nyare än, din databas Postgres-version. En äldre pg_dump kan vägra att köra.

Om du bygger med AI och inte vill röra kommandoraden kan du be om:

Skapa en säkerhetskopia av appens databas med pg_dump i custom-format, med dagens datum i filnamnet. Skriv inte ut anslutningssträngen eller någon annan hemlighet. Berätta filnamnet och dess storlek när det är klart.

Steg 4: Automatisera det

Manuella säkerhetskopior glöms bort. Automatisera dem med det din uppsättning stöder:

• Din databasleverantörs schemalagda säkerhetskopior, om de erbjuds.
• Ett schemalagt jobb på en server eller CI-tjänst som kör pg_dump och laddar upp filen till lagring.
• En värdbaserad säkerhetskopieringstjänst som ansluter till din databas.

Oavsett vilket du väljer, se till att det larmar dig när en säkerhetskopia misslyckas. Ett säkerhetskopieringsjobb som tyst har misslyckats i tre månader är den klassiska skräckhistorien.

Steg 5: Förvara kopior på en annan plats

Tumregeln kallas ofta 3-2-1: tre kopior av din data, på två olika typer av lagring, med en kopia utanför platsen. För en liten app är en praktisk version:

• Den levande databasen
• Leverantörens egna automatiska säkerhetskopior
• Dina egna dumpar i separat lagring, till exempel en objektlagringsbucket i ett annat konto

Dessutom:

• Begränsa åtkomsten. En säkerhetskopia innehåller varje användares data. Behandla den som den levande databasen.
• Ha en policy för hur länge kopior sparas. Till exempel dagliga säkerhetskopior i två veckor och månadsvisa i ett år. Radera gamla kopior medvetet, och kom ihåg att integritetslagar kan kräva att du raderar personuppgifter när någon begär det.
• Committa aldrig säkerhetskopior till Git. En dump i ett repository är ett dataläckage som bara väntar på att hända.

Steg 6: Testa en återställning

En säkerhetskopia är bara så bra som din senaste lyckade återställning. Minst var fjärde månad, och efter varje ändring i säkerhetskopieringsprocessen:

1. Skapa en ny, tom databas. Återställ aldrig över den levande databasen för att testa.
2. Återställ den senaste säkerhetskopian i den:

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

För en vanlig .sql-fil använder du i stället psql "$TEST_DATABASE_URL" -f backup.sql.

1. Kontrollera att varje tabell finns, jämför antalet rader med den levande databasen och titta på några av de senaste posterna.
2. Peka en kopia av appen mot den och logga in, om du kan.
3. Skriv ner hur lång tid återställningen tog. Det är din verkliga återhämtningstid.

Steg 7: Säkerhetskopiera före riskfyllda ändringar

Ta en färsk säkerhetskopia precis innan du:

• Kör en databasmigrering som tar bort eller byter namn på kolumner
• Importerar data i bulk
• Låter en AI-agent göra stora ändringar i datamodellen
• Raderar gamla poster

I en AI-byggd app kan agenten ändra tabellstrukturen som en del av en funktion. Checkpoints och versionshantering återställer din kod, men de återskapar inte raderade rader. En säkerhetskopia på trettio sekunder före en stor ändring är en billig försäkring.

Vanliga misstag

• Att anta att Git eller en kodexport är en säkerhetskopia. Den har koden, inte datan.
• Att aldrig testa en återställning. Många säkerhetskopior visar sig vara tomma, ofullständiga eller oläsbara först när man behöver dem.
• Att förvara säkerhetskopior i samma konto som databasen. Ett komprometterat eller stängt konto förlorar båda.
• Att glömma uppladdade filer. Databasen lagrar filens sökväg; själva bilden finns i lagringen.
• Att lämna hemligheter i säkerhetskopieringsskript. Läs anslutningssträngen från en miljövariabel, aldrig från skriptets text. Se hur du håller API-nycklar säkra.

Säkerhetskopior och Mythex

Mythex-projekt kan ha en dedikerad Postgres-databas, och dess anslutningsuppgifter läggs in i arbetsytan och i den publicerade appen. Mythex dokumentation beskriver inte någon funktion för säkerhetskopiering eller återställning av databaser, så planera din egen: be agenten göra en dump, ladda ner den och förvara den på ett säkert ställe, särskilt före stora ändringar. En projektexport (Pro) innehåller din kod, med hemligheter och node_modules utelämnade; den innehåller inte databasposter. Se Database och Data ownership i dokumentationen. Om databasen i sig läs vad är Postgres.

Checklista för säkerhetskopiering

• Bestämt hur mycket data du har råd att förlora och hur länge du kan vara nere
• Kontrollerat vilka automatiska säkerhetskopior din databasvärd erbjuder
• Din egen dump körs enligt schema, och misslyckanden larmar dig
• Kopior lagras separat från databasen, med begränsad åtkomst
• Policy för hur länge kopior sparas är nedskriven
• Uppladdade filer säkerhetskopieras lika väl som databasen
• Återställning testad i en tom databas, med kontrollerade radantal
• Säkerhetskopia tagen före varje riskfylld ändring

Frågor