Comment sauvegarder la base de données de votre app (et la restaurer vraiment)

Pour sauvegarder la base de données de votre app, exportez-la dans un fichier selon un calendrier (pour Postgres, l'outil standard est pg_dump), conservez les copies ailleurs que dans la base de données et restaurez-en régulièrement une dans une base de données vide pour vérifier qu'elle fonctionne. Faites une sauvegarde supplémentaire juste avant tout changement risqué. Votre sauvegarde du code, qu'il s'agisse d'un dépôt GitHub ou d'une exportation, ne contient pas vos données.

Ce guide s'adresse aux personnes qui exploitent une petite app et qui veulent cesser de craindre de la perdre. Il utilise Postgres dans les exemples, car la plupart des apps créées avec l'IA l'utilisent, mais les principes s'appliquent à toute base de données.

Ce que doit couvrir une sauvegarde

Une app est plus que sa base de données. Sachez quelle partie chaque sauvegarde protège.

Les données sont la partie que vous ne pouvez pas recréer. Le code peut être réécrit et les paramètres saisis de nouveau; les commandes de vos clients, non.

Étape 1 : décider combien vous pouvez perdre

Deux questions déterminent votre plan de sauvegarde :

• Combien de données récentes pouvez-vous vous permettre de perdre? Si vous sauvegardez une fois par jour et que la base de données tombe en panne le soir, vous perdez les modifications de la journée. Pour une app de loisir, c'est acceptable. Pour une app qui prend des commandes, ce ne l'est peut-être pas.
• Combien de temps l'app peut-elle rester hors service pendant la restauration? Une petite base de données se restaure en quelques minutes. Une grosse peut prendre beaucoup plus de temps, et vous voulez le savoir avant d'en avoir besoin.

Pour la plupart des petites apps, une sauvegarde automatique quotidienne, plus une sauvegarde manuelle avant les changements risqués, est un bon point de départ. Les apps qui touchent à l'argent ou aux données de santé méritent des sauvegardes plus fréquentes, ou une base de données gérée offrant la récupération à un point précis dans le temps (la capacité de restaurer à n'importe quel moment, et pas seulement à la dernière sauvegarde).

Étape 2 : vérifier ce que fait déjà votre hébergeur

Beaucoup de fournisseurs de bases de données gérées effectuent des sauvegardes automatiques. Renseignez-vous sur :

• Les sauvegardes sont-elles activées pour votre forfait, et à quelle fréquence s'exécutent-elles?
• Combien de temps sont-elles conservées?
• Peut-on restaurer à un moment précis, ou seulement à un instantané quotidien?
• Peut-on télécharger une sauvegarde, ou seulement la restaurer dans leur système?

Les sauvegardes du fournisseur sont utiles, mais elles partagent un point de défaillance unique avec votre base de données : le compte. Si le compte est fermé, suspendu ou si le projet est supprimé, les sauvegardes peuvent disparaître avec lui. C'est pourquoi vous voulez aussi votre propre copie.

Étape 3 : créer une exportation avec pg_dump

pg_dump exporte une base de données Postgres vers un fichier. Il lit un instantané cohérent, de sorte que l'app peut continuer de fonctionner pendant l'opération.

Une commande type, qui utilise la chaîne de connexion que votre app possède déjà dans une variable d'environnement :

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Ce que font les options :

• --format=custom écrit un fichier compressé que pg_restore peut lire, et qui permet de restaurer plus tard une seule table. Utilisez --format=plain si vous voulez plutôt un fichier .sql lisible.
• --no-owner omet les commandes de propriété, ce qui simplifie la restauration dans une autre base de données.
• La date dans le nom du fichier permet de distinguer les sauvegardes.

La version de pg_dump doit être identique ou plus récente que la version de Postgres de votre base de données. Un pg_dump plus ancien peut refuser de s'exécuter.

Si vous créez votre app avec l'IA et que vous ne voulez pas toucher à la ligne de commande, vous pouvez demander :

Crée une sauvegarde de la base de données de l'app avec pg_dump au format custom, avec la date du jour dans le nom du fichier. N'affiche pas la chaîne de connexion ni aucun secret. Donne-moi le nom du fichier et sa taille une fois terminé.

Étape 4 : automatiser

Les sauvegardes manuelles finissent par être oubliées. Automatisez-les avec ce que votre configuration permet :

• Les sauvegardes planifiées de votre fournisseur de base de données, si elles sont offertes.
• Une tâche planifiée sur un serveur ou un service d'intégration continue qui exécute pg_dump et téléverse le fichier dans un espace de stockage.
• Un service de sauvegarde hébergé qui se connecte à votre base de données.

Quel que soit votre choix, faites en sorte qu'il vous avertisse en cas d'échec. Une tâche de sauvegarde qui a discrètement échoué pendant trois mois est l'histoire d'horreur classique.

Étape 5 : conserver des copies ailleurs

La règle empirique est souvent appelée 3-2-1 : trois copies de vos données, sur deux types de stockage différents, avec une copie hors site. Pour une petite app, une version pratique consiste à avoir :

• La base de données en production
• Les sauvegardes automatiques du fournisseur
• Vos propres exportations dans un espace de stockage séparé, comme un bucket de stockage d'objets dans un autre compte

Aussi :

• Limitez l'accès. Une sauvegarde contient les données de chaque utilisateur. Traitez-la comme la base de données en production.
• Définissez une politique de conservation. Par exemple, des sauvegardes quotidiennes pendant deux semaines et des sauvegardes mensuelles pendant un an. Supprimez les anciennes de façon délibérée, et rappelez-vous que les lois sur la protection de la vie privée peuvent exiger que vous supprimiez les données personnelles sur demande.
• Ne versionnez jamais les sauvegardes dans Git. Une exportation dans un dépôt est une fuite de données qui n'attend qu'à se produire.

Étape 6 : tester une restauration

Une sauvegarde ne vaut que votre dernière restauration réussie. Au moins tous les quelques mois, et après tout changement du processus de sauvegarde :

1. Créez une nouvelle base de données vide. Ne restaurez jamais par-dessus la base en production pour faire un test.
2. Restaurez la dernière sauvegarde dans cette base :

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Pour un fichier .sql brut, utilisez plutôt psql "$TEST_DATABASE_URL" -f backup.sql.

1. Vérifiez que chaque table existe, comparez le nombre de lignes avec la base en production et regardez quelques enregistrements récents.
2. Faites pointer une copie de l'app vers cette base et connectez-vous, si possible.
3. Notez combien de temps la restauration a pris. C'est votre véritable temps de reprise.

Étape 7 : sauvegarder avant les changements risqués

Faites une nouvelle sauvegarde juste avant :

• D'exécuter une migration de base de données qui supprime ou renomme des colonnes
• D'importer des données en lot
• De laisser un agent IA apporter de grands changements au modèle de données
• De supprimer d'anciens enregistrements

Dans une app créée avec l'IA, l'agent peut modifier la structure des tables dans le cadre d'une fonctionnalité. Les points de contrôle et le contrôle de version annulent vos modifications de code, mais ils ne restaurent pas les lignes supprimées. Une sauvegarde de trente secondes avant un gros changement est une assurance peu coûteuse.

Erreurs courantes

• Supposer que Git ou une exportation du code est une sauvegarde. Elle contient le code, pas les données.
• Ne jamais tester une restauration. Beaucoup de sauvegardes s'avèrent vides, partielles ou illisibles au moment où on en a besoin.
• Garder les sauvegardes dans le même compte que la base de données. Un seul compte compromis ou fermé fait perdre les deux.
• Oublier les fichiers téléversés. La base de données stocke le chemin du fichier; l'image elle-même se trouve dans le stockage.
• Laisser des secrets dans les scripts de sauvegarde. Lisez la chaîne de connexion depuis une variable d'environnement, jamais depuis le texte du script. Voir comment protéger vos clés d'API.

Sauvegardes et Mythex

Les projets Mythex peuvent avoir une base de données Postgres dédiée, dont les détails de connexion sont injectés dans l'espace de travail et dans l'app publiée. La documentation de Mythex ne décrit pas de fonctionnalité de sauvegarde ou de restauration de base de données; planifiez donc la vôtre : demandez à l'agent de créer une exportation, téléchargez-la et conservez-la en lieu sûr, surtout avant les gros changements. Une exportation de projet (Pro) contient votre code, sans les secrets ni node_modules; elle ne contient pas les lignes de la base de données. Voir Base de données et Propriété des données dans la documentation. Pour en savoir plus sur la base de données elle-même, lisez qu'est-ce que Postgres.

Liste de vérification des sauvegardes

• Décidé combien de données vous pouvez perdre et combien de temps vous pouvez être hors service
• Vérifié les sauvegardes automatiques offertes par l'hébergeur de votre base de données
• Votre propre exportation s'exécute selon un calendrier, et les échecs vous avertissent
• Copies conservées séparément de la base de données, avec accès restreint
• Politique de conservation rédigée et notée
• Fichiers téléversés sauvegardés en plus de la base de données
• Restauration testée dans une base de données vide, avec vérification du nombre de lignes
• Sauvegarde effectuée avant chaque changement risqué

Questions