Prova att återställa appen från en backup innan du behöver det

Börja med att hitta var datan faktiskt ligger

Appens byggverktyg, webbplats och databas kan vara tre olika tjänster. Att du kan återställa projektfiler enligt guide 4 om att backa en trasig ändring betyder därför inte att användarnas bokningar, formulärsvar eller uppladdade bilder följer med. På samma sätt provar reservlägesartikeln ett pågående leverantörsavbrott, inte om en äldre datakopia går att läsa. Öppna appens inställningar och leta efter ord som ”Database”, ”Data”, ”Storage”, ”Backups” eller ”Production”.

Be sedan byggverktyget beskriva lagringskartan utan att ändra något. Svaret är en ledtråd, inte beviset. Kontrollera att tjänstens namn och projekt-id går att hitta i den verkliga kontrollpanelen.

Ändra ingenting i appen.

Lista varje plats där appen sparar bestående information:
1. databasposter,
2. användarkonton,
3. uppladdade filer och bilder,
4. betalnings- eller mejlhistorik,
5. inställningar och hemliga nycklar.

För varje punkt: ange tjänstens namn, projektets identifierare och var jag
kan se informationen i tjänstens kontrollpanel. Markera sådant du inte kan
verifiera som OKÄNT. Påstå inte att något ingår i backup utan en länk till
leverantörens aktuella dokumentation.

Prov: välj en känd post i appen och hitta samma post i datavyn. Ladda sedan upp en ofarlig testbild och kontrollera om den syns på en annan plats än databasposten. Om du bara hittar metadata men inte själva filen har du redan upptäckt att återställningen behöver mer än ett underlag.

Kontrollera backupen för just din nivå

Ordet ”backup” på en funktionssida räcker inte. Kontrollera tre saker i samma inloggade projekt: om automatiska kopior ingår i din aktuella nivå, hur långt bak de sparas och om de kan återställas till en ny kopia. Skriv ned kontrolldatumet, eftersom både funktioner och abonnemang kan ändras.

Supabases dokumentation anger den 12 augusti 2026 att automatiska dagliga databasbackuper finns för betalnivåerna Pro, Team och Enterprise, medan gratisnivån inte har automatisk backup. Den separata funktionen ”Restore to a New Project” kräver en betalplan och påslagna fysiska backuper. Det nya projektet blir en databaskopia; lagrade filer, Edge Functions, Auth-inställningar, API-nycklar och flera andra inställningar måste hanteras separat.

Replit illustrerar varför produktnamnet inte räcker. Agentens checkpoint kan återställa en utvecklingsdatabas om du uttryckligen väljer databasen, men den gör inte automatiskt samma sak med produktionsdatabasen. Replits aktuella dokumentation skiljer uttryckligen på utvecklingsdata och den produktionsdata som den publicerade appen använder.

Gör tio kontrollposter som avslöjar rätt fel

Använd aldrig riktiga personuppgifter i provet. Skapa i stället tio poster med värden som är lätta att jämföra: ”ÅTERSTÄLLNINGSPROV 01” till ”ÅTERSTÄLLNINGSPROV 10”. Fördela dem över appens viktigaste typer: till exempel fem bokningar, tre kommentarer och två uppladdningar. Om appen bara har en sorts post räcker tio av samma typ.

Ta skärmbilder eller exportera en lista som visar alla tio. Notera klockslag och tidszon. Vänta tills kontrollpanelen visar en backup som är tagen efter dessa poster. Lägg därefter till ”EFTER BACKUP 11” och ändra post 03. De två förändringarna är din kontrollgrupp: de ska inte finnas i en kopia från den tidigare tidpunkten.

Prov: före återställningen ska du kunna visa ett protokoll med tio förväntade poster, två förväntat saknade ändringar, backupens tidpunkt och namnet på den separata målmiljön. Saknas någon av de fyra delarna är startläget inte tillräckligt kontrollerat.

Beställ och följ en återställning till en kopia

Om tjänsten har en knapp för att återställa till nytt projekt följer du leverantörens kontrollpanel, granskar kostnaden och väljer backupen närmast före den tänkta dataförlusten. Koppla inte den publika webbadressen, riktiga mejlutskick eller betalningar till kopian. Supabase varnar exempelvis för att externa operationer via vissa tillägg bör stängas av i en klon för att undvika oönskade åtgärder.

Finns ingen säker knappväg är nästa steg inte att klistra in terminalkommandon du inte förstår. Skicka en avgränsad beställning till leverantörens support eller den som ansvarar tekniskt för appen:

Jag vill prova dataåterställning utan att ändra produktionsmiljön.

Källprojekt: [projekt-id]
Önskad backup: [datum, tid och tidszon]
Mål: en ny, isolerad testkopia utan publik trafik, mejlutskick eller betalningar
Förväntat innehåll: testpost 01–10
Förväntat att saknas: EFTER BACKUP 11 och ändringen av testpost 03

Bekräfta före start:
- exakt vad som ingår och inte ingår,
- beräknad kostnad och vem som debiteras,
- hur externa integrationer hålls avstängda,
- hur testkopian tas bort efter godkänt prov.

Starta inte återställningen förrän jag har godkänt svaren.

Prov: målmiljön ska ha ett annat projekt-id än produktionen, och den publika appen ska fortfarande visa den aktuella datan under hela provet. Om samma id visas på båda ställena har du inte fått en separat kopia.

Jämför innehåll, inte bara antalet rader

”Återställningen lyckades” i kontrollpanelen betyder att processen avslutades, inte att appen är hel. Öppna testkopians datavy och bocka av post 01–10 en i taget. Kontrollera både identifierare och ett innehållsfält. Bekräfta sedan att post 11 saknas och att post 03 har sitt äldre värde.

Gå vidare till användarkonton och filer. Supabases databasbackup innehåller metadata om Storage-objekt men inte själva filobjekten; en raderad fil kommer därför inte tillbaka bara för att databasraden gör det. Motsvarande gräns kan finnas hos andra leverantörer. Prova att öppna de två testuppladdningarna från kopian, inte bara att deras namn syns i en tabell.

Mät datalucka och återställningstid

Två tider avgör om planen duger. Dataluckan är tiden mellan backupens senaste innehåll och den händelse du vill återhämta dig från. Med en daglig backup kan nästan ett dygns ändringar i värsta fall ligga efter kopian. Återställningstiden är tiden från ditt beslut tills den kontrollerade kopian går att använda.

En liten testdatabas ger inte en säker prognos för en stor produktionsdatabas. Supabase anger att nertiden beror på databasens storlek. Skriv därför provets verkliga tid och märk uppskattningar tydligt. Det viktiga är att du nu känner till arbetsstegen: hitta kopian, starta, vänta, kontrollera data, koppla om och verifiera appen.

DATUM OCH TIDSZON: [åååå-mm-dd, klockslag, zon]
KÄLLPROJEKT: [id]
MÅLPROJEKT: [annat id]
BACKUPENS TIDPUNKT: [datum, tid, zon]
PROVET STARTADE / KOPIAN VAR KLAR: [två tider]

TESTPOSTER 01–10: [10/10 eller lista avvikelser]
POST 11 SAKNAS: [ja/nej]
POST 03 HAR ÄLDRE VÄRDE: [ja/nej]
TESTKONTO FUNGERAR: [ja/nej]
TVÅ TESTFILER GÅR ATT ÖPPNA: [ja/nej/ingår inte]
EXTERNA HÄNDELSER SKICKADE: [ska vara 0]

DATALUCKA: [timmar och minuter]
ÅTERSTÄLLNINGSTID I PROVET: [timmar och minuter]
KOSTNAD SOM VISADES: [belopp, valuta och period]
SAKNAS I BACKUPEN: [filer, inställningar, nycklar eller annat]
NÄSTA OMPROV SENAST: [datum]

Prov: be en annan person läsa protokollet och peka ut senaste säkra återställningstidpunkt, förväntad datalucka och vilka delar som måste återställas separat. Kan personen inte svara utan din muntliga förklaring är planen inte färdig.

Tre stoppregler

Radera testkopian först när protokollet är sparat och alla avvikelser är dokumenterade. Sätt sedan ett nytt provdatum. Gör om provet när datatjänst, abonnemang, filhantering eller inloggning ändras – eller minst när den ansvariga personen inte längre kan beskriva återställningsvägen.