Supabase storage backup : votre copie de base n'a aucun fichier

Vous avez mis en place des sauvegardes pour votre application Lovable ou Bolt, ou vous payez le plan Supabase qui les prend, et le mot a fait son travail : vous avez cessé de vous inquiéter. Puis une restauration, ou un déménagement vers un nouveau projet, et l'application revient avec une image cassée là où chaque photo de profil se trouvait. Chaque table et chaque ligne est là. Les images ont disparu, avec chaque facture, chaque export et chaque pièce jointe qu'un utilisateur a jamais uploadés.

Voici la partie que le mot sauvegarde cache : un Supabase storage backup est une tâche à part, parce qu'une sauvegarde de base de données contient une ligne pour chaque fichier que vos utilisateurs ont uploadé et aucun des fichiers. La ligne est dans votre base de données. Le fichier est dans Storage, un service séparé, et aucune copie de base de données, sur aucun plan, n'y entre. Cet article explique comment prendre cette seconde copie, et dans quel ordre les deux moitiés reviennent, ce qui est la partie qui se passe mal même quand vous avez les deux.

Il est utile de penser à une bibliothèque. Le catalogue est un tiroir de fiches, une par livre, chacune indiquant sur quel rayon le livre se trouve. Les livres sont sur les rayons. Une sauvegarde de base de données copie le tiroir.

Supabase sauvegarde-t-il mes fichiers Storage ?

Non, sur aucun plan. La documentation des sauvegardes de Supabase indique que les sauvegardes ne contiennent pas les fichiers déposés via l'API Storage, seulement leurs métadonnées en base, et le point-in-time recovery est une fonction de la base de données, donc la même phrase le couvre.

Ce que chaque sauvegarde contient bel et bien, c'est la liste. Supabase tient dans votre base Postgres une table nommée storage.objects, avec une ligne par fichier dans chaque bucket : dans quel bucket il se trouve, son chemin, qui l'a uploadé, sa taille et la date de son arrivée. Cette table est copiée avec tout le reste, et c'est exactement pourquoi un projet restauré a l'air si complet. Chaque fiche est dans le tiroir.

Les octets de chaque fichier sont ailleurs. Ils vivent dans le stockage objet, un service séparé à côté de votre base de données, et un outil qui copie une base de données ne le lit jamais. Le plan gratuit ne prend aucune sauvegarde automatique, donc la question ne se pose même pas là ; à partir de Pro, la copie quotidienne contient vos lignes et aucun de vos uploads.

Où Supabase garde vos fichiers

À deux endroits, et une sauvegarde de base de données atteint l'un des deux.

Quand un utilisateur uploade un avatar, votre application confie le fichier à Storage. Storage écrit les octets dans le stockage objet sous le nom du bucket et le chemin, et dans la même opération écrit une ligne dans storage.objects qui le décrit. Votre application garde ensuite ce chemin dans l'une de ses propres tables, disons une ligne profiles avec une colonne avatar_url, et en construit un lien chaque fois que l'image est nécessaire.

Une image uploadée est donc trois choses : les octets dans le stockage objet, la ligne dans storage.objects que Storage entretient, et le chemin dans votre propre table. Une sauvegarde de base de données emporte les deux dernières. Restaurez-la et votre application a chaque chemin, Storage a chaque ligne, et le lien qu'ils construisent ensemble pointe vers un endroit où il n'y a rien.

C'est aussi pourquoi la panne est si silencieuse. Chaque ligne concorde avec chaque autre ligne, chaque décompte tombe juste, et chaque vérification qui lit la base de données passe, y compris l'étape de vérification de la plupart des outils de sauvegarde, parce que les fichiers n'ont jamais été dans ce qui était vérifié.

À quoi ressemble une restauration avec seulement la moitié

Un projet qui passe chaque vérification et affiche une image cassée partout où un fichier devrait apparaître.

La restauration annonce un succès parce qu'elle a fait ce qu'on lui demandait : les tables sont revenues et les décomptes de lignes concordent. Ouvrez le tableau de bord, et Storage liste chaque bucket et chaque fichier qu'il contient, avec tailles et dates, parce que cette liste est lue depuis la table que la restauration a remise en place. Le propre guide de Supabase pour restaurer une sauvegarde du tableau de bord dans un nouveau projet décrit exactement cet état : les buckets et les métadonnées des fichiers apparaissent, et les objets derrière eux non.

La façon dont vous l'apprenez est ordinaire. La page de l'équipe affiche une rangée d'icônes d'image cassée là où étaient les avatars. Un client répond au courriel de facture du mois dernier pour dire que le lien ouvre sur une erreur. Quelqu'un clique sur un fichier dans le navigateur Storage et le téléchargement échoue. La fiche dit rayon quatre, troisième en partant de la gauche, et le rayon quatre est vide.

Rien ne vous prévient avant ce moment, parce que chaque alerte dont vous disposez est branchée sur la base de données. Comment restaurer une sauvegarde Supabase passe en revue les cinq façons dont une restauration revient cassée, et les fichiers sont la ligne de ce tableau sans solution, à moins que vous n'en ayez fait une copie.

Pendant que la page Storage est ouverte, il vaut la peine de savoir ce qu'elle montre à un inconnu. Notre scan gratuit lit votre application en ligne depuis l'extérieur et demande à chaque bucket sa liste de fichiers, avec rien d'autre que la clé déjà présente dans le code de votre application. En août 2026, il a obtenu une liste de 792 des 27 269 applications qu'il pouvait vérifier, un chiffre tiré de notre propre étude. Il lit des noms et ne télécharge jamais un fichier, prend environ 20 secondes et ne demande aucun compte : scannez votre application.

Comment sauvegarder un bucket Supabase Storage ?

Par le point d'accès compatible S3, avec une seule commande qui copie un bucket entier dans un dossier que vous détenez.

Supabase Storage parle le protocole S3, ce qui veut dire que les outils ordinaires construits pour le stockage d'Amazon fonctionnent contre le vôtre. C'est la seule étape de cet article qui se passe dans une ligne de commande, et elle vaut la peine d'être faite une fois à la main, pour que vous sachiez de quoi la copie est faite.

1. Dans votre tableau de bord Supabase, ouvrez les réglages Storage et activez le protocole S3. La même page affiche l'URL du point d'accès et la région de votre projet ; copiez les deux depuis là plutôt que depuis ici.
2. Sur cette page, créez une paire de clés d'accès S3. Le secret n'est affiché qu'une fois, alors mettez-le dans un gestionnaire de mots de passe avant de fermer la boîte de dialogue.
3. Installez la ligne de commande AWS, donnez-lui les deux clés sous forme de profil, et lancez une synchronisation par bucket :

aws s3 sync s3://avatars ./supabase-files/avatars \
  --endpoint-url https://<project-ref>.storage.supabase.co/storage/v1/s3 \
  --region <region>

Relancez-la demain et elle ne copie que ce qui a changé. rclone fait le même travail si vous le préférez ; sur un gros bucket, la note de dépannage de Supabase dit de passer --s3-list-version 2, sinon le listage peut s'arrêter trop tôt.

Deux choses sur cette clé. La page d'authentification S3 de Supabase indique qu'une clé d'accès S3 a un accès complet à chaque bucket et contourne Row Level Security, donc elle a sa place sur un serveur ou sur votre propre machine et jamais dans votre application. Et elle peut écrire autant que lire, parce que Supabase n'émet aucune clé en lecture seule pour Storage ; quiconque la détient peut supprimer des fichiers aussi facilement que les copier. Traitez-la comme vous traiteriez votre clé service_role.

Puis rangez le dossier quelque part hors de votre compte Supabase, pour la même raison qu'une copie de base de données devrait vivre en dehors : un projet suspendu ou un identifiant perdu emporte avec lui chaque copie rangée dans ce compte.

Les fichiers d'abord, ou les lignes d'abord ?

La base de données d'abord, puis les fichiers, et les fichiers reviennent par Storage pour que Storage écrive les lignes.

Chaque upload qui passe par Storage, depuis votre application, depuis le point d'accès S3 ou depuis la CLI Supabase, fait deux choses en une seule opération : il enregistre les octets et il écrit la ligne de storage.objects qui les décrit. Le livre est rangé sur le rayon et la fiche est écrite par la même main. Remettez les fichiers de cette façon et les lignes arrivent avec eux, et les deux ne peuvent pas diverger.

L'autre sens n'a pas de mécanisme de ce genre. Recopier des lignes de storage.objects avec un outil de base de données écrit des fiches et ne range rien. Cela complique aussi l'étape suivante : par défaut, Storage refuse un upload vers un chemin qui a déjà une ligne, avec une erreur disant que la ressource existe déjà, et le guide des uploads de Supabase dit qu'on la contourne en activant l'écrasement. Donc quand la restauration de la base a déjà ramené les lignes, ce que le propre guide de migration de Supabase vous fait faire, la copie des fichiers qui suit doit être autorisée à écraser.

L'ordre, donc :

1. Restaurez la base de données, comme cet article le décrit.
2. Recopiez les fichiers par Storage, avec aws s3 sync lancé dans l'autre sens (le dossier d'abord, le bucket ensuite) ou avec supabase storage cp -r, et l'écrasement activé. Un bucket qui n'existe plus doit être créé avant, avec le même nom et le même réglage public.
3. Ouvrez un fichier, puis plusieurs autres.

La version la plus propre de tout cela ne rejoue pas du tout storage.objects dans l'étape base de données et laisse les uploads écrire chaque ligne à neuf, de sorte que rien n'a jamais à être écrasé. C'est ainsi que notre propre restauration procède. Il faut pour cela filtrer la copie avant de la rejouer, ce qui est une étape pour l'outil qui fait la restauration.

Comment vérifier que vous avez les deux

En ouvrant des fichiers, parce que chaque liste que vous pouvez tirer est lue depuis la table.

Le navigateur de fichiers du tableau de bord, une requête sur storage.objects et le décompte de lignes d'un rapport de sauvegarde décrivent tous le tiroir, et après une restauration de la base seule, le tiroir est parfait. La seule requête qui touche le rayon est une requête pour le fichier lui-même.

Donc après une restauration, et après la première copie que vous prenez, ouvrez des fichiers. Prenez-en une poignée dans chaque bucket, les plus anciens compris, et ouvrez-les à travers l'application, comme un utilisateur le ferait. Un fichier qui s'ouvre est revenu. Un fichier qui renvoie une erreur n'a jamais été là, quoi qu'en dise la liste.

Ce qu'il faut faire cette semaine

Où Reeve Care trouve sa place

Care copie les fichiers avec la base de données, dans l'ordre que cet article décrit, et les remet en place de la même façon.

• Les fichiers que vos utilisateurs ont uploadés sont copiés aussi, dès que vous connectez les buckets Storage de votre application Supabase. C'est une seconde clé, demandée séparément, parce que la clé que Supabase émet pour Storage peut écrire autant que lire, et nous préférons demander plutôt que de la mêler à la clé de base de données, qui ne le peut pas.
• La copie des fichiers tourne après que la copie de la base a été relue et vérifiée, jamais à côté, de sorte qu'un point de restauration ne revendique jamais des fichiers qu'il n'a pas copiés. Une copie qui a manqué de temps est marquée partielle, avec les vrais décomptes.
• Chaque point de restauration note quel chemin contenait quel fichier. Une base remise à mardi reçoit les fichiers de mardi, et un fichier encore en place est laissé tranquille.
• La restauration remet les fichiers par Storage, de sorte que chaque ligne est écrite par l'upload qui porte le fichier. Rien de ce qui existe aujourd'hui n'est écrasé ni supprimé, ce qui veut dire qu'appuyer sur le bouton dans la panique ne peut pas détruire ce que vous essayiez de sauver.
• La restauration est un bouton, et elle prend un instantané de l'état actuel avant de commencer, de sorte que la restauration elle-même a une annulation.

Care démarre à €49 par mois pour une application. C'est un prix catalogue, et la page des tarifs est parfois en dessous du chiffre indiqué ici et jamais au-dessus.

Comment une copie est prise, vérifiée et remise en place, fichiers compris, est dessiné pas à pas sur la page des sauvegardes Supabase.

Avant de fermer cet onglet, ouvrez Storage dans votre tableau de bord et comptez les buckets. Chacun est un ensemble de fichiers qu'aucune sauvegarde prise par Supabase ne contiendra jamais, et la commande de synchronisation ci-dessus est tout ce qu'il faut pour changer cela. Si un bucket s'est aussi révélé listable, ce qu'un inconnu obtient de cette liste est la prochaine chose à lire.