Restaurer une sauvegarde Supabase, et ce qui casse après

Quelque chose ne va pas dans votre base de données et, pour une fois, vous en avez une copie. Vous regardez maintenant un bouton que vous n’avez jamais pressé, sur un projet où il y a de vrais utilisateurs, en essayant de deviner ce qu’il s’apprête à leur faire.

Voici la partie que guide après guide laisse de côté. Presque tous les articles sur la façon de restaurer une sauvegarde Supabase s’arrêtent au moment où la restauration se termine, et c’est là que commencent la plupart des ennuis. Le dénouement habituel n’est pas une restauration qui échoue. C’est une restauration qui réussit et laisse l’application cassée quand même, parce qu’une sauvegarde de base n’a jamais contenu que la base.

Il est utile d’arrêter de se représenter cela comme récupérer vos données. Une restauration échange votre base contre une plus ancienne, plus proche du remplacement d’une armoire à dossiers entière que du reclassement d’une seule chemise. Tout ce qui suit en découle.

Comment restaurer une sauvegarde Supabase ?

Trois voies, et laquelle vous est ouverte aujourd’hui a été décidée avant aujourd’hui.

Les deux premières remettent vos données là où elles étaient déjà. La troisième est la seule qui puisse les mettre ailleurs, et c’est ce dont vous avez besoin le jour où le problème est votre compte plutôt que vos données.

Si vous ne savez pas laquelle vous avez, le plan Supabase sur lequel vous êtes règle les deux premières et cela prend environ deux minutes à vérifier.

Copiez ce que vous avez maintenant, avant de restaurer quoi que ce soit

Prenez d’abord une copie de la base dans son état cassé actuel. C’est une seule commande, et c’est ce qui rend réversible chaque décision suivante.

pg_dump "postgresql://…votre chaîne de connexion…" \
  --clean --if-exists --no-owner \
  --file before-restore-2026-08-24.sql

Il y a deux raisons, et la seconde, les gens l’apprennent en général après.

La première est qu’une restauration est un remplacement. Les tables de la copie reviennent exactement telles qu’elles étaient, donc chaque ligne écrite depuis part avec elles. Une cliente inscrite ce matin est une ligne que vous êtes sur le point de supprimer volontairement.

La seconde est que votre base cassée reste le seul endroit où une partie de vos données existe encore. Si la copie date de mardi et que le dégât a eu lieu jeudi, tout ce qui a été créé mercredi est devant vous en ce moment et nulle part ailleurs. Restaurez par-dessus et cela disparaît une deuxième fois, de votre main cette fois-ci et non par l’accident.

Pendant que vous travaillez, coupez tout ce qui écrit de nouvelles lignes. Le raisonnement est le même qu’après n’importe quelle suppression : l’écart entre la copie et maintenant coûte plus cher à mesure que l’app continue de le remplir.

Restaurer depuis le tableau de bord Supabase

Cela remplace la base de votre projet par la copie que vous choisissez, et le projet est indisponible pendant l’opération.

Ouvrez le projet auquel votre app parle, allez dans Database puis Backups, et choisissez la copie datée. Lisez les étapes exactes dans la documentation de sauvegarde de Supabase, parce que le tableau de bord est réorganisé et que cette page ne s’en apercevra pas.

La durée dépend de la taille de votre base, c’est la réponse de Supabase elle-même. Posez un avis de maintenance avant de lancer.

Le point-in-time recovery est la même opération avec un réglage plus fin. Au lieu de choisir la nuit dernière, vous nommez une minute et le projet y revient. Supabase le décrit comme destructif, et c’est le mot juste. Leurs notes de support ajoutent qu’une restauration point-in-time ne peut pas démarrer tant que les slots de réplication et les souscriptions existants ne sont pas retirés. Donc si quelque chose dans votre app suit les changements de la base à mesure qu’ils arrivent, c’est une étape à faire avant plutôt qu’une erreur à rencontrer à mi-parcours.

Aucune de ces deux voies ne peut mettre vos données dans un autre projet. Toutes deux agissent sur le projet où vous vous trouvez, ce qui veut dire qu’aucune n’est disponible le jour où ce qui a lâché, c’est votre accès au compte.

Restaurer un fichier de dump avec psql

Vous pointez psql vers un projet et rejouez le fichier dedans. Ce projet peut être celui que vous aviez, ou un projet tout neuf sur un compte ouvert ce matin.

psql -d "postgresql://…chaîne de connexion du projet cible…" \
  --variable ON_ERROR_STOP=1 \
  --single-transaction \
  --file backup-2026-08-09.sql

Deux de ces options méritent d’être comprises, parce que le comportement par défaut de psql est le surprenant.

ON_ERROR_STOP=1 s’arrête à la première erreur. Sans elle, psql lit l’erreur, l’affiche et passe à la ligne suivante, si bien qu’un fichier qui a échoué à la ligne 400 sur 30 000 se termine quand même sur une invite qui ressemble à une réussite, au-dessus d’une base à laquelle il manque tout ce qui suivait cette ligne. --single-transaction enveloppe le fichier entier dans une seule opération, de sorte qu’un échec laisse la base telle qu’elle était plutôt qu’à moitié modifiée.

Ensuite les identifiants, là où beaucoup se bloquent. Rejouer une sauvegarde, c’est écrire, donc il faut quelque chose qui puisse écrire. Une clé anon n’y arrivera pas, une clé en lecture seule non plus. Ce que psql veut, c’est le mot de passe de base du projet cible, qui se trouve dans les paramètres de votre projet Supabase, sous Database.

Ce qui revient dépend de ce que contient le fichier, et cela a été réglé au moment du dump. Vos comptes de connexion sont la partie à vérifier avant de compter dessus. Ils vivent dans un schéma appelé auth à côté des mots de passe hachés, et Supabase documente leur déplacement entre projets comme un travail avec ses propres étapes. Si vous restaurez dans un nouveau projet et voulez que les gens se connectent avec le mot de passe qu’ils ont déjà, lisez cette page avant de commencer.

Et un nouveau projet a une nouvelle URL et de nouvelles clés. Votre app pointe toujours vers l’ancien tant que vous ne le changez pas, ce qui est la première ligne de la section suivante.

La restauration a marché, et l’app est toujours cassée

C’est le dénouement ordinaire. C’est presque toujours l’une de cinq choses, et la première coûte une minute.

La quatrième mérite l’attention. Le droit de lire et le droit d’écrire sont accordés séparément, et une restauration peut réussir l’un et manquer l’autre. Les pages se remplissent donc de vos données, tout a l’air récupéré, et la première personne qui envoie un formulaire reçoit une erreur. Regarder l’app ne vous le montrera jamais, parce que regarder, c’est lire.

Comment savoir si la restauration a vraiment fonctionné

Connectez-vous, trouvez une ligne que vous pouvez nommer, puis écrivez-en une. Dans cet ordre, et la dernière est la vérification qui compte.

• Connectez-vous par l’app comme le ferait un utilisateur, plutôt que d’ouvrir l’éditeur de tables de Supabase. Cela teste l’app, la connexion et les comptes d’un seul coup.
• Trouvez une ligne dont vous vous souvenez. Une commande précise, un client nommé, la dernière chose ajoutée avant la panne. « Les données ont l’air d’être là » est une impression ; une ligne que vous pouvez nommer est une vérification.
• Comparez un décompte à ce que vous attendiez. Ouvrez votre plus grosse table dans l’éditeur Supabase et lisez le nombre de lignes. Une restauration arrêtée à mi-chemin se voit en général ici, sous la forme d’un nombre trop petit.
• Puis écrivez quelque chose. Créez une ligne comme le fait un utilisateur : passez une commande de test, enregistrez un profil, publiez un commentaire. C’est la vérification qui échoue quand les trois autres passent, et la seule qui prouve que la restauration est terminée.
• Ouvrez quelque chose qu’un utilisateur a envoyé. Si votre app a des images ou des pièces jointes, cliquez sur l’une d’elles. Savoir si vos fichiers sont revenus est une question distincte de celle de vos lignes.

Quoi faire maintenant

Avant de fermer cet onglet, découvrez si vous avez seulement quelque chose à partir de quoi restaurer, et où cela se trouve. Cette réponse unique décide de quelle moitié de cet article vous aurez un jour besoin. La check-list de sécurité en 10 minutes le couvre à côté du reste de ce qui mérite d’être vérifié sur une app fraîchement lancée, et le guide de sécurité Supabase passe en revue ce qui reste ouvert d’habitude.

Ce que fait Reeve Care le jour où vous restaurez

La copie existe déjà, elle a déjà été relue et vérifiée, et elle se trouve hors de votre compte Supabase. L’heure décrite plus haut devient donc un choix de copie, et un bouton.

Quatre choses que cela change à cet article en particulier.

La copie est vérifiée avant que vous en ayez besoin. Chaque sauvegarde est relue et comptée face à ce qui est entré, et la date affichée dans votre tableau de bord est celle de la dernière copie qui a passé le contrôle, pas celle de la dernière tentative. La restauration à moitié faite contre laquelle cet article met en garde est un problème que nous trouvons un après-midi ordinaire, avant qu’il devienne le vôtre.

La copie de sécurité n’est pas une étape à retenir. Appuyer sur restaurer prend d’abord une copie fraîche de l’état actuel, de sorte que la restauration elle-même peut être annulée.

Vos fichiers envoyés reviennent aussi, une fois vos buckets Storage connectés. C’est la ligne du tableau plus haut qui n’a pas de bonne réponse autrement.

La clé de base que nous détenons ne peut que lire. Une restauration doit écrire, donc elle demande votre mot de passe de base à chaque fois et n’en garde aucun. La clé optionnelle pour vos fichiers peut écrire, parce que Supabase n’émet pas de clé en lecture seule pour Storage, et la page où vous la confiez le dit avant que vous le fassiez.

Les limites vont dans la même phrase, parce qu’il vaut mieux les connaître avant de payer que pendant une panne :

• Cela fonctionne avec Supabase et rien d’autre aujourd’hui.
• Vous restaurez vers une copie qui existe, pas vers une minute quelconque. Au pire vous perdez un intervalle, soit jusqu’à une nuit sur le plan d’entrée et moins sur les deux au-dessus.
• Les comptes de connexion ne sont jamais touchés. Personne n’est déconnecté, supprimé ni ramené.

Gardez vos sauvegardes Supabase activées dans tous les cas. Deux copies à deux endroits, c’est toute l’idée, et la moins chère des deux est déjà dans votre plan. Ce que couvre chaque plan Care est sur la page d’accueil.

Si vous préférez ne payer pour rien de tout cela, tout ce qui précède fonctionne encore. Un pg_dump selon un rythme que vous tenez vraiment, gardé quelque part que la perte de votre compte Supabase n’emporterait pas, plus une restauration d’entraînement par trimestre, vous mène presque au bout. Les trois voies et ce que chacune laisse de côté traite cela sans argumentaire de vente.

Le cycle complet est dessiné étape par étape sur la page des sauvegardes Supabase : la copie qui quitte Supabase, le contrôle qui la suit, et le bouton qui la remet en place.