Introduction
Une sauvegarde n’est utile que si elle permet de récupérer les données de l’application. Vous allez exporter une petite base de données D1 vers SQL, reconstruire une deuxième base temporaire à partir du fichier exporté, puis comparer les données et les contraintes tout en laissant la base d’origine inchangée.
Ce lab commence de manière autonome avec deux tickets synthétiques et utilise au maximum deux bases de données D1. La sauvegarde reste dans votre VM LabEx ; aucun compte ni bucket de stockage d’objets n’est utilisé.
Utilisez votre propre compte d’apprentissage et une VM fraîche. La configuration installe d’abord Node.js 22.22.0, puis exécute npm install pour installer Wrangler 4.131.1 au niveau du projet ainsi que les dépendances nécessaires à l’évaluation dans /home/labex/project/ticket-database. Les versions des dépendances directes sont verrouillées ; l’installation crée son propre fichier lock. La configuration n’effectue aucune connexion au cloud et aucune opération évaluée sur la base de données. Sur une machine personnelle, installez la même version de Wrangler avec npm install --save-dev wrangler@4.131.1 dans votre projet.
Cet exercice utilise de petites données synthétiques qui respectent les limites gratuites de D1. L’utilisation existante du compte est prise en compte dans ces limites. Aucun domaine acheté n’est nécessaire. Conservez cette VM jusqu’à ce que la suppression des ressources et la déconnexion aient toutes deux été vérifiées.
Autoriser cette VM et sélectionner le compte
Dans cette étape, vous connectez ce terminal fraîchement configuré à votre propre compte d’apprentissage. Une connexion au Dashboard ne suffit pas à autoriser la VM. Les permissions D1 permettent de créer, modifier et supprimer des bases de données. Consultez attentivement la page réelle de consentement, notamment la section Background Access, avant d’autoriser l’accès.
Ouvrez le projet préparé et vérifiez la version de la CLI :
cd /home/labex/project/ticket-database
npx wrangler --version
La commande doit afficher 4.131.1. Démarrez l’autorisation par appareil ; --device affiche un code à saisir dans le navigateur et --browser=false vous laisse choisir vous-même comment ouvrir le navigateur :
npx wrangler login --device --browser=false --scopes account:read user:read d1:write
Ouvrez l’URL affichée dans votre navigateur, saisissez le code actuel, vérifiez votre compte d’apprentissage et les permissions demandées, puis autorisez l’accès. Attendez que le terminal confirme la réussite. Ne collez jamais de mots de passe ni de jetons dans les fichiers du projet.
npx wrangler whoami --json
Vérifiez que loggedIn: true est présent, puis relevez le name et l’id du compte, même si un seul compte est affiché. Copiez l’ID du compte voulu dans la configuration ci-dessous. La variable shell suivante utilise 6 octets aléatoires, soit 12 caractères hexadécimaux, afin d’éviter les collisions avec les autres apprenants. Un document here-document écrit le JSON situé entre les lignes JSON ; $RUN est développé à l’intérieur de ce document.
La barre oblique inverse devant $schema conserve cette clé JSON littérale ; $RUN est toujours remplacé par le nom unique de cette exécution.
RUN=labex-c04-d06-$(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
Remplacez YOUR_ACCOUNT_ID avant d’exécuter le bloc. Gardez ce terminal ouvert afin que RUN reste disponible. La clé name identifie cette exécution ; account_id sélectionne le compte utilisé pour les opérations cloud. Le fichier est un fichier JSON standard, également valide comme JSONC. Le fait de l’écrire ne déploie aucun Worker.
Préparer la base de données à préserver
Dans cette étape, vous créez une petite base de données d’origine. La configuration fournit le schéma des tickets ; votre travail consiste à l’exporter et à la reconstruire, contraintes comprises, sans modifier la base d’origine.
Créez une base de données cloud temporaire. --binding DB fournit un nom court utilisable par le code, --update-config enregistre son vrai nom et son UUID dans wrangler.jsonc, et --use-remote=false conserve le développement en local :
npx wrangler d1 create "$RUN-db" --binding DB --update-config --use-remote=false
Lisez le nom et l’ID créés, puis inspectez la liaison enregistrée :
cat wrangler.jsonc
L’entrée DB doit désigner la base de données de cette exécution. Une liaison est une connexion configurée entre le code et une ressource. Son UUID identifie la base de données cloud, tandis que --local utilise une base SQLite distincte dans cette VM. Incluez toujours --local ou --remote dans les commandes SQL.
cat schema.sql
npx wrangler d1 execute DB --remote --file schema.sql
Lisez les données sources et le schéma avant l’exportation :
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id; SELECT sql FROM sqlite_master WHERE type = 'table' AND name = 'tickets';"
La base contient deux tickets. Notez le résultat attendu : l’ID 1 correspond à Cannot sign in et son statut est open ; l’ID 2 correspond à Invoice copy et son statut est closed. Les deux tickets ont la source seed. Le schéma contient une clé primaire, des valeurs obligatoires et une contrainte sur le statut.
Exporter une sauvegarde SQL complète
Dans cette étape, vous créez un fichier SQL portable. Un export décrit les définitions des tables et les données en SQL ; l’importation de ce fichier peut reconstruire une base de données ailleurs. Cette opération est différente de D1 Time Travel, qui restaure l’historique sur place.
--remote sélectionne la source cloud et --output indique le fichier à écrire dans cette VM. Conservez le schéma et les données en omettant --no-schema et --no-data :
npx wrangler d1 export DB --remote --output backup.sql
Si une confirmation vous est demandée, vérifiez qu’il s’agit bien de la base de données source. Inspectez le petit fichier exporté :
cat backup.sql
Recherchez les instructions CREATE TABLE et les instructions INSERT contenant les tickets. Le format de l’export, la citation des colonnes et les instructions internes peuvent différer du SQL écrit manuellement à l’origine. Un téléchargement réussi ne prouve pas à lui seul que la récupération fonctionnera ; l’étape suivante vérifie l’artefact en reconstruisant la base. Ce fichier contient uniquement des données synthétiques. Conservez-le dans la VM ; aucun bucket R2 n’est nécessaire.
Reconstruire une base de données distincte
Dans cette étape, vous restaurez les données dans une deuxième base vide, sans toucher à la base d’origine. Une cible distincte vous permet de comparer les données récupérées avant de modifier une liaison utilisée par l’application.
Créez une deuxième ressource avec la liaison REBUILT. La mise à jour de la configuration l’ajoute à côté de DB :
npx wrangler d1 create "$RUN-copy" --binding REBUILT --update-config --use-remote=false
cat wrangler.jsonc
Vérifiez que les deux liaisons ont des UUID de bases de données différents et les noms -db et -copy attendus. Importez uniquement dans REBUILT :
npx wrangler d1 execute REBUILT --remote --file backup.sql
Cette commande exécute le SQL exporté sur la nouvelle cible cloud. Confirmez cette cible lorsque l’invite vous le demande. Interrogez-la :
npx wrangler d1 execute REBUILT --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id; PRAGMA table_info(tickets);"
Les lignes et les définitions des colonnes doivent correspondre à celles de la base d’origine. Testez l’une des contraintes restaurées avec une insertion invalide :
npx wrangler d1 execute REBUILT --remote --command "INSERT INTO tickets (id, subject, status, source) VALUES (3, 'Invalid', 'lost', 'probe');"
Le résultat attendu est CHECK constraint failed. Cet échec volontaire ne doit pas ajouter de troisième ligne. Relisez les deux bases de données :
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
npx wrangler d1 execute REBUILT --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
Les deux bases doivent toujours contenir exactement les deux lignes d’origine. Ouvrez dans le Dashboard les deux noms de ressources exacts pour effectuer un contrôle en lecture seule ; vérifiez que leurs ID sont différents avant d’inspecter la table reconstruite. Ne remplacez jamais une autre base de données pour tester une récupération.
Cet exemple montre les deux tickets restaurés dans la base -copy. Le nom généré identifie cette exécution d’exemple ; vos noms de ressources et UUID seront différents. La capture confirme uniquement les lignes visibles. Les commandes CLI d’export et d’import et les vérifications indépendantes ci-dessus établissent la reconstruction, la correspondance du schéma et la conservation des contraintes.
Supprimer les ressources temporaires
Dans cette étape, vous supprimez uniquement les ressources de ce lab, alors que la VM est encore autorisée. Terminez d’abord toutes les vérifications fonctionnelles. Conservez la configuration jusqu’à la fin de la vérification de la suppression.
npx wrangler d1 delete REBUILT
npx wrangler d1 delete DB
Lisez l’invite et confirmez qu’elle concerne uniquement la base de données de cette exécution. Listez ensuite les bases de données :
npx wrangler d1 list --json
Les deux noms de bases de données et les deux UUID enregistrés doivent être absents d’une réponse réussie. D’autres ressources peuvent rester présentes. Une erreur d’authentification ou de réseau ne permet pas de conclure : rétablissez l’accès et répétez la lecture avant de continuer. Effectuez la vérification de cette étape pendant que vous êtes encore connecté.
Mettre fin à l’autorisation de cette VM
Dans cette étape, vous mettez fin à l’autorisation uniquement après la réussite de la vérification indépendante de la suppression. La déconnexion supprime l’autorisation Wrangler enregistrée sur cette VM ; fermer simplement une VM n’effectue pas le nettoyage dans le cloud.
npx wrangler logout
npx wrangler whoami --json
Le résultat attendu est loggedIn: false. Cette requête non authentifiée peut se terminer avec un code différent de zéro ; cela est attendu uniquement si la réponse structurée indique explicitement que vous êtes déconnecté. Terminez la vérification, puis fermez l’environnement du lab.
Résumé
Vous avez appris à exporter et à reconstruire une base de données. Vous avez vérifié les résultats observables de la base, conservé explicitement le compte sélectionné et l’état local, puis supprimé les ressources temporaires avant de vous déconnecter.
