Pourquoi vous ne pouvez pas télécharger votre sauvegarde Supabase

Vous êtes sur un plan Supabase payant, donc vous avez des sauvegardes. Vous ouvrez Database, puis Backups, et elles sont là : une liste de copies quotidiennes datées, chacune avec un bouton Restore. Vous cherchez le bouton qui permet de télécharger votre sauvegarde Supabase et de la garder chez vous, et il n'existe pas.

Rien n'est cassé. Voici ce que les anciens guides présentent encore de travers : sur un projet récent, il n'y a aucune sauvegarde quotidienne à télécharger. Supabase a basculé ses copies quotidiennes vers un autre type de sauvegarde, que Supabase peut restaurer pour vous et ne peut pas vous remettre. Le bouton de téléchargement que décrivent ces guides appartenait à l'ancien type. Un fichier que vous détenez, vous le fabriquez désormais vous-même, et c'est un autre type de fichier.

Votre téléphone est le moyen le plus simple de voir la différence. La sauvegarde qu'il fait de lui-même chaque nuit est complète et exacte, et elle revient en une étape sur un téléphone connecté au même compte. Vous ne pouvez pas l'ouvrir sur un ordinateur portable et en sortir vos photos. Pour avoir des photos à garder n'importe où, vous les exportez, et vous obtenez un dossier de fichiers ordinaires. La sauvegarde quotidienne de Supabase est désormais du premier type. Le fichier que vous pouvez détenir est du second.

Puis-je télécharger ma sauvegarde Supabase ?

Pas la quotidienne, si votre projet tourne sous Postgres 15.8.1.079 ou plus récent. La documentation de Supabase sur les sauvegardes indique que tous les projets sur cette version et au-delà utilisent des sauvegardes physiques, et ses notes de dépannage indiquent qu'une fois les sauvegardes physiques activées, Supabase ne génère plus le fichier de sauvegarde téléchargeable. Vous pouvez restaurer ces copies quand vous voulez. Vous ne pouvez en emporter aucune.

La dernière ligne mérite d'être relue. Supabase indique que lorsqu'un projet est supprimé, il efface toutes les données associées, y compris les sauvegardes stockées dans S3. Supprimez le projet, et ses copies quotidiennes partent dans le même geste.

Quelle est la différence entre une sauvegarde physique et une sauvegarde logique ?

L'endroit d'où la copie est tirée. Une sauvegarde physique copie les fichiers que Postgres écrit lui-même sur disque, ce que Supabase décrit comme un instantané du répertoire sous-jacent de la base. Une sauvegarde logique demande à la base de se décrire elle-même en SQL, table par table et ligne par ligne, et écrit cette description dans un fichier texte.

Chacune est bonne à quelque chose de différent. Une copie physique se prend vite et se remet vite en place, et elle revient exactement telle qu'elle était. Elle ne peut être lue que par le même type d'installation Postgres que celle d'où elle vient, ce qui chez Supabase veut dire les machines de Supabase elles-mêmes. Une copie logique se rejoue plus lentement et prend plus de place, et n'importe quel Postgres de la même version ou plus récent peut la charger. C'est encore la sauvegarde du téléphone et le dossier exporté, et seul le second est un fichier que vous pouvez détenir.

Le bouton de téléchargement dont on se souvient était du type logique. La documentation de Supabase elle-même, en 2025, expliquait que la tâche quotidienne lançait pg_dumpall, compressait le fichier SQL et le stockait, et que les sauvegardes physiques chargent moins la base et évitent de verrouiller vos tables pendant de longues périodes. La même page précisait que les copies physiques ne peuvent pas être téléchargées depuis la section Backups du tableau de bord.

Comment savoir lequel mon projet utilise ?

Cherchez une option de téléchargement sur la page Backups. Ouvrez Database, puis Backups, dans votre tableau de bord Supabase. Si chaque copie datée propose un moyen de la télécharger, votre projet est encore sur des sauvegardes logiques. Si chacune propose Restore et rien d'autre, il est sur des sauvegardes physiques, et l'ancienne documentation de Supabase utilisait exactement ce test.

La seconde vérification est le numéro de version. Il est affiché sous Project Settings, puis General. Tout ce qui part de 15.8.1.079 signifie des sauvegardes physiques. Lisez-le de gauche à droite : une version qui commence par 17 est plus récente que n'importe quelle 15, et 15.8.1.100 est plus récente que 15.8.1.079.

Deux cas n'ont besoin d'aucune vérification :

• La restauration à un instant précis est activée. Elle repose par définition sur des sauvegardes physiques. Supabase précise aussi que si vous désactivez la restauration à un instant précis, il continue de prendre des sauvegardes physiques, donc le téléchargement ne revient pas.
• Vous êtes sur le plan gratuit. La page Backups n'a rien à télécharger ni à restaurer, parce que le plan gratuit ne vous donne aucune sauvegarde quotidienne utilisable. Faire une copie sans terminal est le point de départ.

Contre quoi chacune me protège-t-elle ?

La sauvegarde quotidienne vous protège contre ce qui tourne mal à l'intérieur du projet. Un fichier que vous détenez couvre aussi la perte du projet lui-même.

Le premier type de perte, c'est vous qui le causez. Une suppression qui a emporté plus de lignes que prévu, une migration écrite par un agent IA et que vous avez validée, un script pointé sur la mauvaise table. La copie quotidienne est exactement l'outil pour ça : vous choisissez hier, vous cliquez sur Restore, et le projet est remis en place. Jusqu'où elle remonte dépend de votre plan, et savoir sur quel plan vous êtes prend environ deux minutes.

Le second type n'implique aucune erreur dans la base. Une carte expirée pendant votre absence, un identifiant que vous ne pouvez pas récupérer, un projet que quelqu'un a supprimé. Les copies sont derrière la même porte que le projet, et c'est la porte qui s'est refermée. La sauvegarde de votre téléphone fonctionne pareil : elle vous sauve si le téléphone tombe à la mer, et elle ne vous sert à rien le jour où vous ne pouvez plus vous connecter au compte où elle se trouve. Supabase garde ses sauvegardes avec la plateforme parce que c'est ce qui permet une restauration en un seul bouton. Une copie qui survit au compte doit être stockée ailleurs, ce qui chez Supabase veut dire un dump logique sorti du compte.

Que veut dire restaurer, pour chacune ?

Pour la copie quotidienne, Supabase fait le travail et vous choisissez où elle atterrit. Pour un fichier que vous détenez, vous faites le travail, et il peut atterrir n'importe où.

Restaurer la copie quotidienne dans le même projet remplace la base par la copie que vous choisissez. Supabase indique que le projet est inaccessible pendant l'opération et qu'une base plus grosse prend plus de temps.

La restaurer dans un nouveau projet est une fonction payante que Supabase appelle Restore to a New Project, encore marquée bêta. Elle crée un projet distinct dans la même région, avec vos utilisateurs et leurs mots de passe hachés, et elle est facturée comme un second projet. Un avertissement sur la même page passe facilement inaperçu. Elle copie la base entière, y compris les extensions qui agissent vers l'extérieur comme pg_cron et pg_net, et ces tâches démarrent dès que la restauration est terminée. Si une tâche planifiée de votre app envoie des e-mails ou appelle une API de paiement, le nouveau projet se met à le faire aussi, dès l'instant où il existe.

Restaurer un fichier que vous détenez consiste à le rejouer avec psql dans ce que vous visez : un nouveau projet Supabase, un projet sur un autre compte, ou un Postgres sur votre propre ordinateur. Comment restaurer une sauvegarde Supabase passe en revue les commandes, et ce qui reste cassé une fois qu'elles ont fini.

Comment obtenir une copie de ma base Supabase sous forme de fichier ?

Faites vous-même un dump logique. Supabase le publie dans son guide de sauvegarde et de restauration sous la forme de trois commandes, chacune écrivant un fichier :

supabase db dump --db-url "postgresql://…" -f roles.sql --role-only
supabase db dump --db-url "postgresql://…" -f schema.sql
supabase db dump --db-url "postgresql://…" -f data.sql --use-copy --data-only

La chaîne de connexion se trouve derrière le bouton Connect en haut de votre projet, avec le mot de passe de votre base à la place de l'espace réservé. La CLI Supabase a besoin de Docker, car elle exécute pg_dump dans un conteneur au lieu d'utiliser celui de votre ordinateur.

Gardez les trois fichiers. Le deuxième seul est la forme de vos tables sans une seule ligne dedans, et vos utilisateurs ne sont que dans le troisième.

Vous pouvez aussi lancer pg_dump directement. Deux choses à savoir d'abord. Supabase indique qu'un pg_dump brut emporte les schémas internes de Supabase avec les vôtres, et que les rejouer provoque des erreurs de permissions au retour. Et Postgres documente que pg_dump refuse de faire le dump d'un serveur d'une version majeure plus récente que la sienne, donc une copie ancienne sur votre ordinateur refuse de démarrer plutôt que d'écrire un mauvais fichier.

Rangez les fichiers ailleurs que dans votre compte Supabase, et pas seulement sur votre portable.

Puis-je restaurer une sauvegarde Supabase sur ma propre machine ?

Une sauvegarde logique, oui, dans un Postgres de la même version majeure ou plus récent. La copie quotidienne physique ne se restaure nulle part ailleurs que chez Supabase.

La règle des versions vient de Postgres lui-même. Sa documentation indique qu'un dump devrait pouvoir se charger dans des versions plus récentes et qu'il n'est pas garanti qu'il se charge dans une plus ancienne, pas même celle dont il vient. Le guide de Supabase pour passer un projet de la plateforme à Supabase auto-hébergé montre à quoi cela ressemble. La plateforme peut tourner sous Postgres 17 alors que l'image auto-hébergée est en 15 par défaut, et le fichier de données contient alors une ligne, SET transaction_timeout = 0, que Postgres 15 ne reconnaît pas.

Ces trois mêmes fichiers sont aussi le moyen de quitter Supabase complètement. Ce guide est la voie pour faire tourner Supabase sur un serveur à vous, et le décalage de versions est la première chose contre laquelle il met en garde.

Sur votre propre ordinateur, la CLI Supabase lance une copie locale de Supabase dans Docker quand vous tapez supabase start. Rejouez-y les trois fichiers avec la commande psql du guide de sauvegarde et de restauration de Supabase, en visant postgresql://postgres:postgres@localhost:54322/postgres, et vos données sont lisibles sur votre propre ordinateur, sans aucun compte.

Il reste un endroit où Supabase propose encore une sauvegarde à télécharger. Un projet gratuit mis en pause au-delà de sa fenêtre de restauration remplace le bouton Restore par le téléchargement de la dernière copie prise avant la pause, et que faire de ce fichier est un article à part.

Qu'est-ce qui ne se trouve dans aucune des deux copies ?

Vos fichiers envoyés, vos Edge Functions et la plupart des réglages de votre projet.

Supabase indique que les sauvegardes de la base n'incluent pas les objets stockés via la Storage API. La base conserve une ligne qui décrit chaque fichier, et le fichier lui-même vit ailleurs, donc aucune sauvegarde de la base, sur aucun plan, ne contient ce que vos utilisateurs ont envoyé. Sauvegarder Storage est un travail à part.

La liste que donne Supabase pour Restore to a New Project est un bon inventaire du reste : Edge Functions, réglages d'authentification et clés d'API, réglages Realtime, réglages des extensions et réplicas en lecture sont tous à reconfigurer à la main.

Un manque ne concerne que le fichier que vous détenez. Si votre app garde des secrets dans Supabase Vault ou utilise des colonnes chiffrées, Supabase indique que les fichiers de sauvegarde ne contiennent jamais la clé racine, seulement les données chiffrées. Un nouveau projet démarre avec sa propre clé, donc ces valeurs arrivent illisibles tant que l'ancienne clé n'a pas été recopiée. Et l'ancienne clé ne peut être récupérée que tant que l'ancien projet est actif. Une fois ce projet mis en pause ou supprimé, la clé ne peut plus être récupérée, ni rien de ce qu'elle chiffrait.

Ce qu'il faut faire cette semaine

Où Reeve Care intervient

Care fait la copie logique pour vous, la garde hors de Supabase, et chaque copie est un fichier que vous pouvez télécharger.

• Téléchargez n'importe quelle copie en zip. Dedans : schema.sql, data.sql et roles.sql, un manifeste qui compte les lignes de chaque table, et une note expliquant comment la charger dans n'importe quel Postgres. C'est un dump standard, donc n'importe quel développeur peut l'ouvrir, et n'importe quel autre hébergeur aussi.
• Stockée hors de votre compte Supabase, chiffrée, donc toujours là le jour où le compte ne l'est plus.
• Relue avant de compter. La date affichée dans votre tableau de bord est celle de la dernière copie ouverte et vérifiée, jamais celle de la dernière tentative.
• Vos utilisateurs sont dedans. Le schéma auth voyage avec vos tables, et les fichiers envoyés par vos utilisateurs suivent dès que vous connectez un accès Storage.

Care garde une copie de votre base Supabase. Laissez les sauvegardes quotidiennes de Supabase activées à côté : elles sont le chemin le plus rapide pour revenir d'une migration ratée, et le fichier est ce qui reste si vous perdez le compte. La façon dont une copie est prise, vérifiée et téléchargée est dessinée étape par étape sur la page des sauvegardes Supabase, et ce que comprend chaque plan est sur la page des tarifs.

Avant de fermer cet onglet, ouvrez Database, puis Backups, et regardez à côté de votre copie la plus récente. S'il n'y a rien à télécharger, le prochain fichier que vous détiendrez est celui que vous ferez vous-même, et ce qui rend un dump complet est la chose à lire avant de le faire.