jsonscraper

En raderad Cloudflare D1-databas kan bara återställas inom sju dagar

Cloudflare har ändrat tidsfristen för återställning av raderade databaser. Så fungerar en undelete-begäran och så skiljer den sig från Time Travel.

Redaktionella riktlinjer Rapportera ett fel

Har du råkat radera en Cloudflare D1-databas? Nu har du sju dagar från raderingen på dig att återställa den via API:t. Ändringen publicerades den 23 oktober 2026: begäranden för databaser som raderats för mer än sju dagar sedan misslyckas. Vid en incident bör du bekräfta databasens ID och skicka en begäran om undelete-återställning så snart som möjligt.

Artikel: En raderad Cloudflare D1-databas kan bara återställas inom sju dagar
Sammanfattning: Från och med den 23 oktober 2026 accepterar Cloudflare D1 begäranden om återställning av en raderad databas endast inom sju dagar efter raderingen. Kontrollera tidsfristen, databasens ID och eventuella namnkonflikter innan du anropar API:t.
Bildens roll: omslagsbild – huvudidén
Avsnitt: 
Visuellt motiv: Koncept för återställning av Cloudflare D1-databas, en databaspost som återgår från raderat tillstånd inom ett kalenderfönster på sju dagar, ren teknisk de
© jsonscraper · AI-genererad illustration

Vad har ändrats?

Återställningsmetoden tar emot konto-ID och UUID för den raderade databasen. Du kan ange ett nytt namn i begärans innehåll. Som standard återställs databasen med sitt tidigare namn. Om en annan databas i kontot redan använder det namnet måste du ange new_name för att återställa databasen. Dessa villkor finns i referensen för D1:s undelete-API.

Tidsfristen är sju dygn, alltså 7 × 24 timmar. Därför räcker det inte att bara kontrollera kalenderdatumet: anteckna när databasen raderades och jämför tidpunkten med när begäran skickas. Om tidsfristen snart går ut bör du först skicka begäran om återställning och sedan kontrollera namn och data.

Så gör du

  1. Hitta den raderade databasen. Bekräfta konto-ID och databas-ID med hjälp av loggar, infrastrukturkod eller incidentuppgifter. API-sökvägen använder databasens UUID; det visningsnamn som visas räcker inte för begäran.
  2. Kontrollera tidsfönstret. Säkerställ att det har gått mindre än sju dygn sedan raderingen. Cloudflare rekommenderar att begäran skickas så snart den felaktiga raderingen upptäcks.
  3. Lös namnkonflikter. Om det tidigare namnet redan används anger du ett ledigt namn med new_name. Annars behöver du inte ändra namnet.
  4. Anropa den dokumenterade metoden. API:t använder POST /accounts/{account_id}/d1/database/{database_id}/undelete. Autentisera begäran med en API-token som har rätt behörighet och skriv inte hemligheter i loggar.
  5. Kontrollera resultatet. När du fått ett lyckat svar kontrollerar du att databasen visas i kontot med förväntat namn och att appen ansluter till rätt instans.

Undelete och Time Travel löser olika problem

Undelete återställer en raderad databas. Time Travel återställer en befintlig databas till ett tidigare tillstånd utifrån en tidpunkt eller ett bokmärke. Enligt Cloudflares dokumentation är historiken tillgänglig för de senaste 30 dagarna; den faktiska perioden beror på abonnemanget. Efter undelete kan Time Travel inte återställa databasen till en tidpunkt eller ett bokmärke från före återställningen. Om data i en aktiv databas har blivit fel använder du Time Travel, och för ett raderat objekt använder du undelete inom den angivna tidsfristen.

Ta med en kontroll av sjudagarsfönstret i incidentrutinen och spara databasens ID och raderingstid i incidentloggen. Då kan du snabbt skicka en korrekt begäran utan att förlora tid på att leta efter ID:n eller utreda namnkonflikter.

People

No people listed for this article yet.

Keep readingGoogle Cloud API Gateway får stöd för strömning: vad du bör kontrollera före migrering
Read the next article

Gör det du läser till en fungerande integration

Utforska jsonscrapers API:er för social data, testa anrop och bygg nästa arbetsflöde.

Utforska API:er