Testez votre sauvegarde Supabase avant d'en avoir besoin

Quelque part, il y a un fichier qui contient votre base de données. Une GitHub Action en écrit un chaque nuit, ou vous avez lancé une fois les trois commandes de sauvegarde de Supabase, ou votre plan prend des copies quotidiennes. Il a le bon nom et à peu près la taille attendue. Personne ne l'a jamais ouvert.

Voici la partie que les guides d'installation remettent à plus tard : une sauvegarde qui n'a jamais été restaurée est une affirmation, pas une copie. La seule façon de tester une sauvegarde Supabase est de la restaurer, exprès, à un endroit où rien n'en dépend, et de regarder ce qui revient. Un dump coupé à mi-chemin, un dump sans aucune ligne et un dump du mauvais projet dorment tous dans le stockage avec exactement l'air d'un bon.

Pensez à un exercice d'évacuation. Un bâtiment l'organise un matin ordinaire, quand rien ne brûle, parce que personne ne devrait descendre cet escalier pour la première fois le jour où il se remplit de fumée. Dehors, quelqu'un compte les présents d'après la liste de ceux qui étaient à l'intérieur, et quelqu'un note la date sur la feuille près de la porte. Un exercice de restauration, c'est la même chose : faire le trajet, compter, noter.

Comment savoir si ma sauvegarde Supabase fonctionne vraiment ?

Restaurez-la et regardez. C'est le seul test qui existe, parce que rien dans le fichier lui-même ne sépare une bonne sauvegarde d'une sauvegarde cassée.

L'exercice prend votre copie la plus récente, la rejoue dans un projet qui ne compte pas, et pose trois questions au résultat. Chaque table est-elle là, avec à peu près autant de lignes qu'en production ? La ligne la plus récente date-t-elle de la nuit où la copie a été prise ? Pouvez-vous vous connecter en votre nom ? Un bon fichier répond oui aux trois, et chaque façon dont une sauvegarde tourne mal échoue à au moins une d'entre elles.

Cinq façons dont une sauvegarde est fausse et a pourtant l'air juste

Les cinq se terminent sans erreur dans la nuit, et les cinq laissent un fichier au nom habituel, à l'endroit habituel. Elles ne se distinguent qu'au moment où le fichier est rejoué.

La deuxième et la troisième sont le sujet de pourquoi votre dump Supabase ne contient aucun utilisateur, et toutes deux viennent d'une commande de dump lancée avec moins d'options qu'il ne lui en fallait. La première nous a surpris, elle a donc droit à une section à elle.

Un fichier de sauvegarde coupé échoue-t-il à la restauration ?

Pas toujours. Nous en avons coupé un au milieu d'une table, nous l'avons rejoué avec les options qu'utilise le guide de Supabase lui-même, et psql a terminé sans erreur.

Le test était petit et facile à refaire. Le 27 septembre 2026, nous avons fait le dump d'une base de deux tables, l'une de 5 000 lignes et l'autre de 300, coupé le fichier à trois endroits différents, et rejoué chaque version avec psql de Postgres 17.11. Chaque essai utilisait --single-transaction et --variable ON_ERROR_STOP=1, les deux options censées arrêter une restauration au premier problème et tout annuler.

• Coupé au milieu d'une valeur, psql s'est arrêté sur une erreur et n'a rien écrit. C'est le résultat qu'on espère.
• Coupé dans la dernière colonne d'une ligne, il a terminé avec le code de sortie 0, la façon dont un programme annonce qu'il a réussi. La première table est revenue avec 2 596 de ses 5 000 lignes, la dernière amputée de la moitié de son texte, et la seconde est revenue vide.
• Coupé exactement entre les deux tables, il a aussi terminé avec 0. La première table était complète et la seconde vide.

La raison tient à la façon dont un dump range les lignes. Les lignes de chaque table forment un bloc qui se termine par une ligne contenant seulement \., et quand le fichier s'arrête avant cette ligne, psql prend la fin du fichier pour la fin du bloc. Le seul signe qu'il devait y avoir une suite est une ligne qui aurait dû se trouver tout à la fin.

Cette ligne, c'est la signature de pg_dump. Un dump complet contient les mots PostgreSQL database dump complete vers sa fin, et un dump coupé ne les contient pas. Des trois fichiers qu'écrit la CLI Supabase, la ligne ne survit que dans data.sql, parce que la CLI retire tous les commentaires du fichier de schéma (vérifié avec la version 2.111 de la CLI). C'est donc data.sql qu'il faut fouiller, et cette recherche est la deuxième étape de l'exercice.

Où la restaurer ?

Dans un projet Supabase qui ne compte pas : un projet d'exercice dans votre compte, ou un Supabase qui tourne sur votre propre ordinateur. Jamais dans le projet qu'utilise votre app.

Un projet Supabase d'exercice est ce qui ressemble le plus à votre vrai projet, et c'est la cible pour laquelle le guide de sauvegarde et de restauration de Supabase est écrit : sa première étape consiste à créer un nouveau projet. Avec le plan gratuit, vous avez droit à deux projets gratuits actifs, et les projets en pause ne comptent pas, donc un projet d'exercice ne coûte en général rien tant que votre base tient dans le plan gratuit. Dans une organisation payante, le calcul d'un nouveau projet est facturé à l'heure : supprimez-le une fois l'exercice terminé.

Supabase sur votre propre ordinateur ne coûte rien et ne demande aucun compte. La CLI Supabase fait tourner toute la pile en local dans Docker : supabase init, puis supabase start, et elle affiche une adresse de base sur le port 54322 et une publishable key pour le projet local. Avant de le lancer, ouvrez supabase/config.toml et réglez major_version sur la version majeure de Postgres de votre projet. Le commentaire au-dessus de ce réglage précise qu'elles doivent correspondre, et la version de votre projet se trouve dans Project Settings, puis General.

Il y a un piège sur Postgres 15. Sauf si la tâche de sauvegarde a fixé une version, la CLI a pris la copie avec pg_dump 17, et le fichier de données contient alors, près du début, SET transaction_timeout = 0, un réglage que Postgres 15 ne reconnaît pas : le rejeu s'arrête sur cette ligne. Pour l'exercice, réglez major_version sur 17. Ajoutez ensuite à la tâche de sauvegarde la correction d'une ligne décrite dans l'article sur la GitHub Action, car le projet dans lequel vous restaureriez pour de vrai est toujours en 15.

Un Postgres nu dans Docker, sans rien de Supabase dedans, ne suffit pas. Un dump Supabase fait référence à des choses que seul Supabase crée, comme le schéma auth où vivent vos utilisateurs et le rôle authenticated que nomment vos règles de sécurité, et la restauration s'arrête à la première ligne qui en mentionne une.

Une précaution, parce que le projet d'exercice contient maintenant une vraie copie. Les adresses e-mail de vos utilisateurs y figurent : ne branchez ni votre app ni ses webhooks dessus, et supprimez-le quand vous avez fini.

Les tâches planifiées sont la partie qui ne suit pas. Si votre projet en exécute avec l'extension pg_cron, les trois fichiers de la CLI ramènent l'extension et aucune de ses tâches, parce que les tâches sont des lignes de cron.job et que le dump des données laisse ces lignes de côté. Nous l'avons vérifié le 4 octobre 2026 avec la version 2.119 de la CLI, en restaurant une base qui avait une tâche planifiée. Le projet d'exercice reste donc silencieux, et une vraie restauration à partir de ces fichiers démarre elle aussi sans aucune tâche planifiée : gardez vos appels à cron.schedule quelque part d'où vous pourrez les relancer.

Comment tester une sauvegarde Supabase, étape par étape

Six étapes, et les trois premières ont lieu avant de restaurer quoi que ce soit.

1. Trouvez la copie la plus récente et lisez sa date. Si elle est plus ancienne que la dernière exécution prévue, le job s'est arrêté, et c'est votre première découverte.
2. Cherchez dump complete dans data.sql. Une occurrence signifie que le fichier est allé jusqu'au bout. Aucune signifie qu'il a été coupé, quelle que soit sa taille. La recherche d'un éditeur de texte marche aussi bien qu'un terminal :

   grep -c 'dump complete' data.sql
   

3. Cherchez-y vos utilisateurs. Une ligne qui commence par COPY "auth"."users", suivie de lignes de données, signifie que vos comptes sont dans le fichier :

   grep -n 'COPY .*auth.*users' data.sql
   

4. Rejouez-le dans le projet d'exercice avec la commande du guide de Supabase, pointée vers la connection string du projet d'exercice. Pour un Supabase local, cette chaîne est postgresql://postgres:postgres@127.0.0.1:54322/postgres.

   psql \
     --single-transaction \
     --variable ON_ERROR_STOP=1 \
     --file roles.sql \
     --file schema.sql \
     --command 'SET session_replication_role = replica' \
     --file data.sql \
     --dbname "postgresql://…the spare's connection string…"
   

5. Comptez les lignes et lisez la plus récente, dans les deux bases. La requête est dans la section suivante.
6. Connectez-vous en votre nom au projet d'exercice. La commande est dans la section d'après.

Si l'étape 4 s'arrête sur une erreur, l'exercice a fait son travail en avance. Les notes de dépannage en bas du guide de Supabase couvrent les deux erreurs les plus fréquentes, toutes deux liées aux rôles, et comment restaurer une sauvegarde Supabase explique ce dont chaque option de cette commande vous protège.

Deux autres arrêts dans roles.sql manquent à ces notes. Nous les avons rencontrés tous les deux le 4 octobre 2026, en rejouant les fichiers de deux bases Postgres 17, dont un projet Supabase, dans une copie locale neuve de Supabase : "supabase_admin" is a reserved role, only superusers can modify it, sur une ligne qui commence par ALTER ROLE "supabase_admin", et permission denied for parameter log_min_messages, sur une ligne qui commence par GRANT SET ON PARAMETER. Ces deux lignes configurent des rôles que Supabase crée lui-même dans chaque projet : mettez -- au début de chacune pour la transformer en commentaire, puis relancez la commande. Notre Action de sauvegarde les met en commentaire dès qu'elle prend la copie.

Quoi compter, et par rapport à quoi

Comptez chaque table dans le projet d'exercice et dans votre projet en production avec la même requête, et mettez les deux listes côte à côte. La copie doit avoir une nuit de retard sur la production : un peu plus basse sur une table qui grandit, et jamais à zéro sur une table qui avait des lignes.

C'est l'appel des présents d'après la liste de ceux qui étaient à l'intérieur. Collez la requête dans l'éditeur SQL de chaque projet et appuyez sur Run. Elle compte les lignes de chaque table de votre propre schéma et de auth :

select table_schema, table_name,
       (xpath('/row/n/text()',
         query_to_xml(format('select count(*) as n from %I.%I', table_schema, table_name),
                      false, true, '')))[1]::text::bigint as row_count
  from information_schema.tables
 where table_schema in ('public', 'auth')
   and table_type = 'BASE TABLE'
 order by table_schema, table_name;

Elle lit chaque ligne de chaque table : sur une grosse base, lancez-la en dehors de vos heures les plus chargées.

Lisez ensuite la ligne la plus récente d'une table que vous connaissez, dans le projet d'exercice seulement. N'importe quelle table avec une colonne created_at fera l'affaire ; mettez son nom à la place de orders :

select max(created_at) from public.orders;

La réponse doit être proche de l'heure à laquelle la sauvegarde a tourné. Une date plus ancienne de plusieurs semaines, ou des lignes que vous ne reconnaissez pas, signifient que le fichier vient d'un autre projet.

Pourquoi la connexion est le test qui prouve vos comptes

Un comptage de auth.users prouve que les lignes sont arrivées. Une connexion prouve qu'elles fonctionnent : que le mot de passe enregistré, le service de connexion du projet d'exercice et votre adresse e-mail s'accordent encore.

Utilisez votre propre compte, avec un mot de passe que vous connaissez. L'adresse du projet et la publishable key du projet d'exercice sont dans son panneau Connect, ou dans la sortie de supabase start pour un Supabase local :

curl -X POST 'https://…the spare's project ref….supabase.co/auth/v1/token?grant_type=password' \
  -H "apikey: sb_publishable_…" \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com", "password": "…"}'

C'est l'appel de connexion de la documentation de Supabase elle-même, dirigé vers le projet d'exercice. Une réponse qui contient access_token signifie que votre compte est arrivé avec un mot de passe qui marche. Invalid login credentials, pour un compte qui se connecte sans problème sur votre app en production, signifie qu'il n'est pas arrivé, et pourquoi un dump arrive sans les comptes est l'article pour ce résultat.

Si tout le monde se connecte à votre app avec Google, cet appel n'a rien à tester, parce que le projet d'exercice n'a pas de connexion Google configurée. Cherchez plutôt votre propre e-mail dans auth.users après la restauration. Cela montre que la ligne du compte est arrivée, mais pas que son mot de passe fonctionne.

Les fichiers : la moitié qu'une restauration de base ne peut pas tester

La copie de la base contient une ligne pour chaque fichier envoyé, et aucun des fichiers. Si vous copiez vos buckets Storage avec un job à part, ce qui est la seule façon dont ils sont copiés, faites faire l'exercice à cette copie aussi.

Prenez les trois lignes les plus récentes dans la base restaurée :

select bucket_id, name from storage.objects order by created_at desc limit 3;

Retrouvez ces trois chemins dans votre copie des fichiers et ouvrez chacun d'eux. Un chemin sans fichier derrière est une image que vos utilisateurs verraient cassée après une vraie restauration.

Peut-on tester les sauvegardes que Supabase fait pour vous ?

Avec un plan payant, oui, avec Restore to a New Project. C'est la seule façon d'ouvrir l'une des copies quotidiennes de Supabase, car sur les projets actuels vous ne pouvez pas les télécharger.

Supabase présente la fonction comme un moyen de tester sans risque. Choisissez une copie dans l'onglet Restore to a New Project de la page Backups, et Supabase en construit un nouveau projet avec vos utilisateurs et leurs mots de passe hachés, prêt pour les mêmes comptages et la même connexion. Deux choses à savoir avant d'appuyer. Le nouveau projet est facturé comme un projet à part entière, et Supabase vous en montre le coût avant de commencer. Et il copie tout, tâches planifiées comprises : Supabase indique que les tâches de pg_cron, pg_net et des wrappers démarrent dès la fin de la restauration, sans moyen de les mettre en pause avant. Si une tâche de votre app envoie des e-mails ou débite une carte, le projet de test le fera aussi.

Si vous gardez aussi un fichier hors du compte, ce fichier a besoin de son propre exercice.

À quelle fréquence tester une restauration ?

Une fois maintenant, puis tous les trois mois, et de nouveau dès que quelque chose change dans la façon dont la sauvegarde est prise.

Les changements qui comptent sont ceux qui cassent une sauvegarde sans bruit : un workflow nouveau ou modifié, un mot de passe de base réinitialisé, un passage à un nouveau plan ou à une nouvelle version de Postgres, une nouvelle table dans laquelle votre app s'est mise à écrire. Après chacun d'eux, l'exercice du trimestre dernier ne décrit plus le fichier de ce trimestre.

Ensuite, notez-le : c'est la feuille près de la porte. Une ligne par exercice, à un endroit que vous pouvez atteindre sans ce qui est tombé en panne : la date, quel fichier, les comptages qui comptaient, si la connexion a marché, et combien de temps a duré l'exercice entier. Un fichier texte dans le dépôt de sauvegarde suffit, tout comme une entrée d'agenda récurrente où vous collez les résultats. La date répond à « quand l'avons-nous prouvé pour la dernière fois » dans l'heure où quelqu'un a besoin de le savoir, et la durée est votre première estimation du temps pendant lequel une vraie restauration mettrait votre app à l'arrêt.

Où Reeve Care intervient

Care garde des copies de votre base Supabase hors de votre compte Supabase, selon l'horaire de votre plan, vérifie chaque copie au moment où elle est prise, et la remet en place d'un bouton.

• Les copies suivent l'horaire de votre plan, d'une fois par jour à toutes les six heures.
• Une copie coupée est repérée au moment où elle est prise. La ligne de fin de pg_dump doit être dans le fichier, sinon la copie échoue à la vérification et ne devient jamais la date affichée dans votre tableau de bord.
• Chaque table est comptée pendant que la copie s'écrit. Quand une table qui avait des lignes dans la copie précédente n'en a plus aucune dans celle-ci, une personne chez Reeve en est informée.
• Vos comptes sont dans la copie, et vos fichiers envoyés suivent dès que vous connectez un accès Storage.
• Restaurer, c'est un bouton, et une copie de l'état actuel est prise avant que quoi que ce soit ne soit remplacé.
• Chaque copie se télécharge en zip avec schema.sql, data.sql, roles.sql et un manifeste qui donne le nombre de lignes de chaque table : la moitié « par rapport à quoi » de cet article, déjà écrite.

Un exercice trimestriel prouve la copie que vous avez choisie ce jour-là, et la vérification porte sur chaque copie au moment où elle est prise. La copie, la vérification et la restauration sont dessinées étape par étape sur la page des sauvegardes Supabase, et ce que comprend chaque plan, horaire compris, est sur la page des tarifs.

Que faire cette semaine

Avant de fermer cet onglet, cherchez dump complete dans votre data.sql le plus récent. C'est une seule recherche, et elle vous dit si le fichier que vous appelez une sauvegarde atteint sa propre dernière ligne. Si vous n'avez pas encore de fichier à fouiller, une GitHub Action gratuite est la façon la plus rapide de commencer à en produire.