Replit tar nu en backup per dygn av produktionsdatabasen – välj lagringstid och bevisa återställningen

Vad Replit lade till den 4 september

Changeloggen den 4 september 2026 innehöll två punkter. Den ena var användningsstatistik för publicerade appar, som är en egen historia. Den andra är den här: schemalagda backuper skapar en full återställningspunkt per dygn för din produktionsdatabas. Du slår på dem genom att välja en lagringstid under Keep backups for i produktionsdatabasens inställningar, och lagringsgränserna beror på din plan.

Det är hela changeloggposten om saken – fyra meningar, ingen siffra. Detaljerna finns på Replits funktionssida för dataåterställning, och det är den sidan resten av den här texten bygger på.

Varför det spelar roll för dig som bygger utan kodbakgrund: din publicerade app har en annan databas än den du bygger mot. Enligt Replits egen dokumentation skapas produktionsdatabasen när du publicerar appen, och Agent kan inte ändra den – begränsningen finns uttryckligen för att hålla den säker. Det är bra. Men det betyder också att den data som verkligen skulle göra ont att förlora ligger på ett ställe som varken Agent eller en checkpoint rör. Är du osäker på vilken databas du har och varför, börjar den frågan i Vilken databas ska jag välja?.

Lagringstiden: läs av din egen nivå, ta ingen siffra på förhand

Här ligger den enda punkt i den här nyheten där du kan bli lurad av en artikel – den här inräknad. Changeloggen säger bara att gränserna beror på planen. Funktionssidan är mer preciserad och anger tak per plan: Core stöder upp till 7 dagar, Pro och Enterprise upp till 28 dagar. Lägg märke till orden upp till. Det är ett tak, inte en utfästelse.

Och så det som är lätt att missa: Replit skriver att varje plan börjar på 7 dagar, och att du ändrar fönstret i produktionsdatabasens inställningar. Sitter du på Pro och antar att du har 28 dagars marginal kan du alltså ha sju, tills du själv har ändrat. Sidan lägger till en detalj till för den som byter plan neråt: går du från Pro till Core sänks fönstret till 7 dagar.

Därför står det ingen siffra i den här artikelns instruktion. Siffran du ska handla efter är den som står i din egen meny, den dag du tittar. Skriv upp den. Det är den enda uppgiften som gäller ditt konto.

En sak till om vad backupen är och inte är. Replit har sedan tidigare återställning till en tidpunkt för produktionsdatabaser, och funktionssidan jämför de två rakt ut: återställning till en tidpunkt ger fler återställningspunkter inom sitt fönster, medan schemalagda backuper ger en punkt per dygn. Det ena ersätter inte det andra. Med en punkt per dygn är den värsta tänkbara dataluckan ett dygns arbete – och den siffran ska du känna igen innan du bestämmer om den räcker för din app.

Vad det kostar just nu, och varför det inte är samma sak som gratis

Replit prissätter lagringen per GiB och månad i tre separata rader: 0,35 dollar för den logiska databaslagringen, 0,20 dollar för lagring till återställning till en tidpunkt, och 0,09 dollar för lagring av schemalagda backuper. Under tabellen står en notis: kostnaderna för databaslagring är för närvarande rabatterade med 100 procent.

Alltså: i dag blir raden noll. Men källan skriver för närvarande och anger inget slutdatum, så det är inte en gratis funktion – det är en rabatterad funktion. Skillnaden märks den dag rabatten upphör, och då är det värt att veta att en längre lagringstid använder mer lagring och därmed ökar användningskostnaden. Vad en publicerad app kostar i övrigt behandlas i Vad kostar en publicerad AI-byggd app? och räknas inte om här.

När på dygnet punkten tas

Replit lägger backupen nära midnatt i din webbläsares tidszon vid det tillfälle då du slår på eller ändrar schemat. Något exakt klockslag anges inte, och ordet nära är källans eget. Schemat använder den UTC-förskjutning du hade då, vilket ger en konsekvens värd att notera: en sommartidsomställning kan flytta backuptiden en timme tills du uppdaterar schemat. Tidszoner med halvtimmesförskjutning läggs på närmaste hel timme.

Praktiskt betyder det att du inte ska planera en riskabel ändring med en marginal på tjugo minuter till backupfönstret. Notera själv ungefär när punkten dök upp första natten – den observationen är mer värd än vad någon dokumentation kan lova.

Provet: tio numrerade poster och en avläsning som inte rör appen

Nu till det som gör skillnad mellan en påslagen inställning och en backup du litar på. Metoden i sig – hitta datan, gör kontrollposter, jämför innehåll och inte bara antal rader, mät datalucka och återställningstid – hör hemma i Prova att återställa appen från en backup innan du behöver det, som täcker den generellt över olika tjänster. Den upprepas inte här. Det som är nytt är att du nu har en dygnsvis återställningspunkt hos Replit att pröva den mot, och en viktig begränsning i hur du får pröva den.

Så här ser provet ut i Replits fall:

Dag ett, före backupfönstret. Skapa tio poster i produktionsdatabasen som är omöjliga att förväxla med riktig data och lätta att räkna: numrera dem 1 till 10 och lägg in ett igenkännbart ord i varje. Skriv upp klockslaget då du la in den tionde. Du redigerar produktionsdatan genom att öppna Database-verktyget, välja produktionsdatabasen, öppna My Data och slå på Edit.

Dag två. Öppna Scheduled backups i produktionsdatabasens inställningar och välj View all backups. Där ska det stå en återställningspunkt med en tidsstämpel som ligger efter ditt klockslag. Har den kommit har du bevisat det första ledet: schemat går, och punkten omfattar dina tio poster. Har den inte kommit har du också fått ett svar, och det är bättre att få det nu än i mars.

Vill du se hela återställningen: gör det i en egen testapp

Publicera en liten separat app som bara finns för det här ändamålet. Den får sin egen produktionsdatabas när du publicerar, och där kostar ett misstag ingenting. Slå på schemalagda backuper på den, lägg in samma tio numrerade poster, och vänta över natten.

Dagen därpå gör du två avsiktliga ändringar efter att punkten har tagits: lägg till en elfte post och ändra ordet i post nummer 3. Sedan återställer du – Scheduled backups, View all backups, Restore på den punkt du vill ha, skriv restore och välj Continue.

Nu vet du vad du letar efter, och det är därför det här provet duger som bevis: post 1 till 10 ska finnas och post 3 ska ha sitt ursprungliga ord tillbaka, medan post 11 ska saknas. Saknas post 11 är det inte ett fel – det är hela poängen, och det är beviset på att punkten faktiskt är en ögonblicksbild från i natt och inte en löpande spegling av nuläget. Stämmer alla tre har du sett funktionen fungera, och du har sett den i en app där ingen användare märkte något.

Räkna gärna tiden från att du klickade på Continue till att posterna såg rätt ut. Den siffran är din återställningstid, och den är värd att veta innan du behöver den. Är din app dessutom tom eller halvtom av andra skäl än en förlorad backup, är det en annan felsökning, och den finns i Appens tomma lägen.

Databasen och koden återställs var för sig

Det sista är den fallgrop som kostar mest när den slår till, och Replit skriver ut den själv i en varning: att återställa databasen återställer inte appens kod, och att rulla tillbaka appen återställer inte databasen. Vill du ha tillbaka båda till samma ögonblick anger Replit ordningen – återställ databasen, rulla sedan tillbaka till den checkpoint som hör till samma tidpunkt, och publicera appen på nytt.

Det är också svaret på varför den här nyheten behövdes. Sajtens tidigare genomgång konstaterade att en checkpoint i Replit inte täckte produktionsdatabasen. Det gäller fortfarande – checkpointen rullar tillbaka appen. Det nya är att det nu finns en dygnsvis punkt för den andra halvan, och att de två halvorna är två separata åtgärder som du gör i rätt ordning.

Den här texten anger med avsikt ingen lagringstid som gäller alla läsare – Replit anger tak per plan och ett utgångsläge på sju dagar, och den siffra du ska handla efter är den som står i din egen meny. Ordet gratis används inte om funktionen: lagringspriserna är enligt Replits egen notis rabatterade med 100 procent för närvarande, utan angivet slutdatum. Ingen läst källa beskriver en återställning till en kopia eller en väg tillbaka till datan som fanns före en återställning, vilket är skälet till att provet i texten görs i en separat testapp. Kontrollera Replits changelog på nytt den dag backupen ska bära en app med riktiga användare.