Einführung
Nach einer versehentlichen SQL-Löschung verschwindet ein Ticket, obwohl die Konfiguration der Anwendung weiterhin korrekt ist. Sie erstellen ein D1-Time-Travel-Lesezeichen, reproduzieren den Verlust mit einem synthetischen Datensatz und stellen dieselbe Datenbank wieder her, während ein nicht betroffenes Ticket erhalten bleibt.
Diese eigenständige Wiederherstellungsübung verwendet eine entfernbare Remote-Datenbank und einen bereitgestellten schreibgeschützten Worker. Sie überprüfen zunächst den fehlenden Zustand, bevor Sie die Wiederherstellung durchführen, und testen anschließend den Zugriff der Anwendung.
Verwenden Sie Ihr eigenes Lernkonto und eine frische VM. Die Einrichtung installiert zuerst Node.js 22.22.0 und führt anschließend npm install für Wrangler 4.131.1 im Projektverzeichnis sowie alle Abhängigkeiten für die Bewertung unter /home/labex/project/ticket-database aus. Die direkten Abhängigkeiten sind versioniert; bei der Installation wird eine eigene Lockdatei erstellt. Während der Einrichtung findet keine Cloud-Anmeldung und keine bewertete Datenbankarbeit statt. Installieren Sie auf einem persönlichen Rechner dieselbe Wrangler-Version mit npm install --save-dev wrangler@4.131.1 in Ihrem Projekt.
Diese Übung verwendet kleine synthetische Datensätze innerhalb der kostenlosen D1-Kontingente. Die bestehende Nutzung Ihres Kontos wird auf diese Kontingente angerechnet. Eine gekaufte Domain ist nicht erforderlich. Behalten Sie diese VM, bis Sie sowohl die Ressourcenlöschung als auch die Abmeldung überprüft haben.
Diese VM autorisieren und das Konto auswählen
In diesem Schritt verbinden Sie dieses frische Terminal mit Ihrem eigenen Lernkonto. Eine Anmeldung im Dashboard allein autorisiert die VM nicht. Die D1-Berechtigung erlaubt das Erstellen, Ändern und Löschen von Datenbanken. Die Workers-Berechtigung erlaubt Bereitstellungen, und die KV-Berechtigung unterstützt die Bereinigung durch Wrangler. Prüfen Sie die tatsächliche Zustimmungsseite einschließlich Background Access, bevor Sie die Autorisierung bestätigen.
Öffnen Sie das vorbereitete Projekt und prüfen Sie die festgelegte CLI-Version:
cd /home/labex/project/ticket-database
npx wrangler --version
Erwarten Sie 4.131.1. Starten Sie die Geräteautorisierung. Mit --device wird ein Browsercode angezeigt, und --browser=false überlässt Ihnen die Wahl des Browsers:
npx wrangler login --device --browser=false --scopes account:read user:read d1:write workers_scripts:write workers_kv:write
Öffnen Sie die angezeigte URL im Browser, geben Sie den aktuellen Code ein, bestätigen Sie Ihr Lernkonto und die Berechtigungen und autorisieren Sie den Zugriff. Warten Sie, bis das Terminal den Erfolg bestätigt. Fügen Sie niemals Passwörter oder Token in Projektdateien ein.
npx wrangler whoami --json
Prüfen Sie loggedIn: true. Lesen Sie anschließend den Kontonamen name und die Konto-ID id, auch wenn nur ein Konto aufgelistet wird. Kopieren Sie die gewünschte ID in die folgende Konfiguration. Die folgende Shell-Variable verwendet 6 zufällige Bytes, also 12 hexadezimale Zeichen, um Kollisionen mit anderen Lernenden zu vermeiden. Ein Here-Dokument schreibt den JSON-Inhalt zwischen den Zeilen JSON; $RUN wird darin expandiert.
Der umgekehrte Schrägstrich vor $schema erhält diesen JSON-Schlüssel unverändert; $RUN wird weiterhin durch den eindeutigen Namen dieses Durchlaufs ersetzt.
RUN=labex-c04-d07-$(openssl rand -hex 6)
cat > wrangler.jsonc <<JSON
{
"\$schema": "./node_modules/wrangler/config-schema.json",
"name": "$RUN",
"account_id": "YOUR_ACCOUNT_ID",
"main": "src/index.js",
"compatibility_date": "2026-09-15",
"workers_dev": true,
"preview_urls": false
}
JSON
Ersetzen Sie YOUR_ACCOUNT_ID, bevor Sie den Block ausführen. Lassen Sie dieses Terminal geöffnet, damit RUN verfügbar bleibt. name identifiziert diesen Durchlauf; account_id bestimmt das Konto für Cloud-Vorgänge. Die Datei ist gewöhnliches JSON und damit auch gültiges JSONC. Durch das Schreiben der Datei wird kein Worker bereitgestellt.
Einen bekannten Wiederherstellungspunkt erstellen
In diesem Schritt erstellen Sie die entfernbare Datenbank und eine bereitgestellte schreibgeschützte Ticket-API. Time Travel stellt einen früheren Zustand einer Datenbank direkt wieder her. Es erstellt keine Ersatzdatenbank und kann Änderungen überschreiben, die nach dem ausgewählten Zeitpunkt vorgenommen wurden. Verwenden Sie die Funktion hier nur für diese neu erstellte Laborressource.
Erstellen Sie eine entfernbare Cloud-Datenbank. --binding DB gibt dem Anwendungscode einen kurzen Namen, --update-config speichert den tatsächlichen Namen und die UUID in wrangler.jsonc, und --use-remote=false hält die Entwicklung lokal:
npx wrangler d1 create "$RUN-db" --binding DB --update-config --use-remote=false
Lesen Sie den erstellten Namen und die ID und prüfen Sie anschließend die gespeicherte Bindung:
cat wrangler.jsonc
Der Eintrag DB muss die Datenbank dieses Durchlaufs angeben. Eine Bindung ist eine konfigurierte Verbindung zwischen dem Code und einer Ressource. Ihre UUID identifiziert die Cloud-Datenbank, während --local eine separate SQLite-Datenbank in dieser VM verwendet. Geben Sie bei SQL-Befehlen immer entweder --local oder --remote an.
npx wrangler d1 execute DB --remote --file schema.sql
npx wrangler deploy
Kopieren Sie die URL der Bereitstellung und lesen Sie beide synthetischen Tickets:
URL='YOUR_DEPLOYED_HTTPS_URL'
curl -i "$URL/tickets/1"
curl -i "$URL/tickets/2"
Erwarten Sie für Ticket 1 den Status 200 mit (Cannot sign in, offen) und für Ticket 2 den Status 200 mit (Invoice copy, geschlossen). Wenn die Bereitstellung noch verteilt wird, wiederholen Sie die Lesezugriffe bis zu einer Minute lang, bis Status und JSON übereinstimmen.
Prüfen Sie die Datenbankinformationen und speichern Sie anschließend ihr aktuelles Lesezeichen als Wiederherstellungsartefakt. Ein Lesezeichen ist eine undurchsichtige Position in der Datenbankhistorie. Die Umleitung mit > schreibt die JSON-Antwort in die angegebene Datei:
npx wrangler d1 info DB
npx wrangler d1 time-travel info DB --json > recovery.json
cat recovery.json
Vergewissern Sie sich, dass die Datenbank das Produktions-Backend verwendet und recovery.json ein nicht leeres bookmark enthält. Lassen Sie diese Datei während der gesamten Übung unverändert. Time Travel ist für D1 in der Produktion immer aktiviert; Free behält Daten 7 Tage und Paid 30 Tage auf. Für die Wiederherstellung innerhalb dieser Sitzung werden nur wenige Minuten Historie benötigt. Eine CLI-Hilfezeile mit dem Hinweis auf 30 Tage setzt die Aufbewahrungsdauer Ihres Tarifs nicht außer Kraft.
Eine begrenzte versehentliche Löschung reproduzieren
In diesem Schritt entfernen Sie ausschließlich das synthetische Ticket 1 aus dieser Labordatenbank und weisen das entsprechende Anwendungssymptom nach. Prüfen Sie zuerst wrangler.jsonc und gleichen Sie DB mit dem gerade erstellten Namen und der UUID ab. Führen Sie diesen Befehl nicht gegen eine bestehende Anwendungsdatenbank aus.
cat wrangler.jsonc
npx wrangler d1 execute DB --remote --command "DELETE FROM tickets WHERE id = 1;"
Lesen Sie die API und den nicht betroffenen Datensatz:
curl -i "$URL/tickets/1"
curl -i "$URL/tickets/2"
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
Ticket 1 muss den Status 404 mit {"error":"not_found"} zurückgeben. Ticket 2 muss weiterhin seine ursprüngliche 200-Antwort liefern; die SQL-Abfrage darf nur Ticket 2 enthalten. Ein Netzwerkfehler oder eine 404-Seite der Plattform beweist nicht, dass die Löschung stattgefunden hat.
Schließen Sie die Überprüfung dieses Schritts ab, bevor Sie die Wiederherstellung durchführen. Sie prüft den tatsächlich fehlenden Datensatz. Wenn Sie wiederherstellen, ohne den Fehler beobachtet zu haben, überspringen Sie den Nachweis des Vorfalls.
Historie wiederherstellen und den Anwendungszugriff prüfen
In diesem Schritt stellen Sie dieselbe Datenbank auf ihr gespeichertes Lesezeichen zurück. Lesen Sie recovery.json, kopieren Sie die exakte Zeichenfolge aus bookmark in BOOKMARK und prüfen Sie erneut die Identität der konfigurierten Datenbank:
cat recovery.json
BOOKMARK='YOUR_SAVED_BOOKMARK'
cat wrangler.jsonc
npx wrangler d1 time-travel restore DB --bookmark "$BOOKMARK"
Der Befehl warnt, dass Daten überschrieben und laufende Abfragen abgebrochen werden. Bestätigen Sie ausschließlich diese entfernbare Datenbank. Erwarten Sie eine Erfolgsmeldung zur Wiederherstellung und ein Undo-Lesezeichen. Erstellen Sie die Datenbank nicht neu, importieren Sie das Schema nicht erneut und fügen Sie die fehlende Zeile nicht manuell ein: Dadurch würden Sie die Wiederherstellungstechnik umgehen.
Fragen Sie die wiederhergestellte Datenbank und die bestehende Anwendungsbindung ab:
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
curl -i "$URL/tickets/1"
curl -i "$URL/tickets/2"
Beide ursprünglichen Zeilen und beide API-Antworten müssen wieder vorhanden sein. Der Worker verweist weiterhin auf dieselbe UUID und benötigt keine Ersatzbindung. Falls ein Lesezugriff während der Wiederherstellung kurzzeitig nicht verfügbar ist, wiederholen Sie ihn. Ersetzen Sie die Wiederherstellung nicht stillschweigend durch ein neues Seed-Verfahren.
Öffnen Sie im Dashboard genau diese D1-Datenbank, bestätigen Sie ihre unveränderte ID und prüfen Sie die wiederhergestellten Tickets in einer schreibgeschützten Ansicht. Dieser Kontrollpunkt verbindet die wiederhergestellten Daten mit der Ressource; die SQL- und API-Ergebnisse sind der funktionale Nachweis. Filtern Sie in den Audit Logs des Kontos Resource ID nach der UUID dieser Datenbank und wählen Sie einen Zeitraum, der die Wiederherstellung umfasst. Öffnen Sie das Ereignis über seinen Zeitstempel, klappen Sie Resource in den Details auf und prüfen Sie type: database.time_travel.restore. Gleichen Sie die Ressourcen-ID und den erfolgreichen Vorgang mit Ihrer Ausgabe zur Wiederherstellung ab. Audit-Einträge können verzögert erscheinen. Leiten Sie aus einer vorübergehend leeren Liste keinen Fehler ab. Die Datenprüfungen belegen den wiederhergestellten Zustand, während die tatsächliche Ausgabe der Wiederherstellung und das Audit-Ereignis den Wiederherstellungsvorgang dokumentieren.
Dieses Beispiel zeigt beide ursprünglichen Tickets nach der Wiederherstellung in derselben Datenbank. Der generierte Name kennzeichnet diesen Beispieldurchlauf; dein Name und deine UUID werden abweichen. Der Screenshot zeigt die wiederhergestellten Zeilen. Die SQL/API-Prüfungen belegen den wiederhergestellten Zugriff; die tatsächliche Ausgabe des Time-Travel-Befehls und das passende Audit-Ereignis belegen den Wiederherstellungsvorgang.
Die Überschrift verwendet die allgemeine Aktion create. Im aufgeklappten Abschnitt Resource kennzeichnet type: database.time_travel.restore die Wiederherstellung. Prüfen Sie den Erfolg, die genaue Datenbank-UUID und den Zeitpunkt; diese Werte gehören zu diesem Beispieldurchlauf.
Die entfernbaren Ressourcen löschen
In diesem Schritt entfernen Sie ausschließlich die Ressourcen dieses Labors, solange die VM noch autorisiert ist. Schließen Sie zuerst alle funktionalen Prüfungen ab. Behalten Sie die Konfiguration, bis die Löschung überprüft wurde.
npx wrangler delete
Bestätigen Sie ausschließlich den Worker-Namen aus der Konfiguration dieses Durchlaufs.
npx wrangler d1 delete DB
Prüfen Sie die Eingabeaufforderung und bestätigen Sie ausschließlich die Datenbank dieses Durchlaufs. Listen Sie anschließend die Datenbanken auf:
npx wrangler d1 list --json
Der aufgezeichnete Datenbankname und die UUID müssen in einer erfolgreichen Antwort fehlen. Andere Ressourcen dürfen weiterhin vorhanden sein. Ein Authentifizierungs- oder Netzwerkfehler ist nicht aussagekräftig: Stellen Sie den Zugriff wieder her und wiederholen Sie die Abfrage, bevor Sie fortfahren. Führen Sie die Überprüfung dieses Schritts aus, solange Sie noch angemeldet sind.
Die Autorisierung dieser VM beenden
In diesem Schritt beenden Sie die Autorisierung erst, nachdem die unabhängige Löschprüfung erfolgreich war. Die Abmeldung entfernt die auf dieser VM gespeicherte Wrangler-Autorisierung. Das bloße Schließen einer VM bereinigt keine Cloud-Ressourcen.
npx wrangler logout
npx wrangler whoami --json
Erwarten Sie loggedIn: false. Diese nicht authentifizierte Abfrage kann mit einem Fehlercode beendet werden. Das ist nur dann erwartungsgemäß, wenn die strukturierte Antwort ausdrücklich angibt, dass Sie abgemeldet sind. Schließen Sie die Überprüfung ab und beenden Sie anschließend die Laborumgebung.
Zusammenfassung
Sie haben die Wiederherstellung eines versehentlich gelöschten Tickets geübt. Sie haben die beobachtbaren Datenbankergebnisse geprüft, das ausgewählte Konto und den lokalen Zustand eindeutig festgelegt und die entfernbaren Ressourcen vor der Abmeldung gelöscht.
