Reeve Backups
Un agent IA a supprimé mes données Supabase. Que puis-je récupérer ?
Un agent IA a supprimé des données de votre base. Ce que vous pouvez récupérer était déjà décidé avant, et les prochaines minutes décident du reste.
En bref
- Si un agent IA a supprimé des données de votre base, vous pouvez récupérer ce que contenait la dernière copie prise avant. Ce qui a été créé ensuite n'a jamais été écrit ailleurs.
- Coupez tout ce qui écrit de nouvelles lignes avant de faire quoi que ce soit d'autre. Une restauration retire tout ce qui a été ajouté après la copie, donc une inscription qui arrive maintenant est une ligne que vous supprimerez vous-même.
- L'agent ne peut pas remettre les lignes. Il ne les a jamais eues, et le relancer sur une base en production est une occasion supplémentaire de perdre davantage.
Vous avez demandé à l'agent de nettoyer quelques lignes de test, ou de réparer une migration qui refusait de passer. Il a écrit le SQL lui-même, l'a exécuté sur le projet que votre application en production utilise, et vous a annoncé que c'était fait. L'application se charge toujours. La table est vide.
Quand un agent IA a supprimé des données de votre base, ce que vous pouvez récupérer était déjà décidé avant qu'il ne s'exécute. Les prochaines minutes décident de ce qui en restera.
Voici ce que la plupart des réponses à cette question ratent. Elles vous disent de revenir en arrière sur le code, ou de demander à l'agent d'annuler. Ni l'un ni l'autre ne touche vos données, et pendant que vous essayez, la seule chose qui reste entre vos mains se dégrade en silence : ce que votre application écrit dans la base en ce moment.
Que puis-je récupérer après qu'une IA a supprimé mes données ?
Ce qui se trouvait dans la dernière copie de votre base prise avant la suppression, et rien de ce qui a été créé après.
C'est toute la réponse, et l'essentiel s'est joué il y a des semaines. Il n'y a
pas d'enquête à mener ici, rien à dé-supprimer, aucun journal qui attendrait
dans Supabase qu'on le rejoue. Une ligne retirée par un DELETE ou un
DROP TABLE a quitté la base à l'instant où l'instruction est validée. Ce qui
revient, c'est une copie, et une copie existe ou n'existe pas.
Vous avez donc deux tâches devant vous. Savoir quelles copies existent. Et empêcher l'écart entre la plus récente et maintenant de coûter plus cher qu'il ne coûte déjà.
Arrêtez d'abord tout ce qui écrit dans la base
Avant de partir chercher une sauvegarde, coupez tout ce qui écrit de nouvelles lignes. La lecture ne pose pas de problème.
Il y a deux raisons, et la seconde surprend.
La première : une restauration n'est pas une fusion. Remettre une copie remplace les tables qu'elle contient par ce qu'elles contenaient alors, et tout ce qui a été écrit après part avec. Un client qui s'inscrit pendant l'heure que vous passez à lire ceci est une ligne que vous supprimerez vous-même, plus tard, dans une étape que vous avez déjà décidé de faire.
La seconde : certaines voies se dégradent pendant que vous attendez. La restauration à un instant donné de Supabase ramène le projet entier à une minute que vous choisissez, donc plus l'application s'éloigne de l'erreur, plus ce retour en arrière jette de travail réel en même temps que les dégâts.
Une heure derrière un message de maintenance ne coûte pas grand-chose. Expliquer à quelqu'un que sa commande a été créée puis retirée volontairement coûte beaucoup plus.
Puis-je demander à l'agent d'annuler ?
Non. Il n'a jamais eu vos lignes.
L'agent a écrit une instruction et votre base l'a exécutée. Ce qu'il possède maintenant, c'est la transcription de cette conversation, ce qui n'est pas la même chose qu'une copie de la table. Demandez-lui d'annuler la suppression et vous obtiendrez une réponse assurée, du SQL plausible et aucune donnée.
Le risque mérite d'être décrit précisément, parce que la demande paraît inoffensive. Relancer l'agent, c'est une deuxième session sans surveillance sur une base en production qui a déjà perdu quelque chose. S'il décide que la bonne façon de réparer une table manquante est d'en créer une, vous avez maintenant une nouvelle table vide là où se trouvait l'ancienne, et vous avez rendu la perte plus difficile à décrire à la personne qui vous aidera ensuite.
Retirez-le du projet jusqu'à ce que vous sachiez où vous en êtes. Même chose pour l'historique des versions de votre builder : revenir sur le code de ce matin restaure vos pages et laisse vos données exactement là où elles sont, pour des raisons qu'il vaut la peine de comprendre une fois.
Où chercher, dans cet ordre
Descendez cette liste et arrêtez-vous à la première entrée qui existe. Elle est classée selon la quantité de vos données qui revient, et non selon la facilité.
| Où chercher | Ce qui peut revenir | Ce qui devait déjà être vrai |
|---|---|---|
| Restauration Supabase à un instant donné | La base telle qu'elle était à une minute que vous choisissez, y compris celle avant la suppression | Une offre payante avec l'option PITR, souscrite avant aujourd'hui |
| Sauvegarde quotidienne Supabase | La base telle qu'elle était à la dernière copie automatique | Une offre payante |
| Un service de sauvegarde géré | La base telle qu'elle était à la dernière copie vérifiée par ce service | Vous en avez branché un avant aujourd'hui |
Un pg_dump que vous avez lancé | Tout ce que contient le fichier, aussi ancien que la dernière fois où vous y avez pensé | Le fichier existe et son écriture s'est terminée |
| Une table de suppression douce ou d'audit | Uniquement les lignes dont votre application tenait déjà une trace | Vous l'avez construite ainsi volontairement |
| L'historique des versions de votre builder | Rien | Il versionne votre code, et vos données vivent dans un autre service. |
| Redemander à l'agent | Rien | Il n'a jamais détenu de copie de vos lignes. |
Toutes les voies qui rendent quelque chose ont la même exigence, et c'est elle qui tranche : il fallait qu'elle existe avant la suppression. Aucune ne s'allume maintenant pour atteindre le passé. L'offre Supabase que vous avez décide des deux premières, et la vérification prend environ deux minutes.
Ce qui revient, et ce qui tombe dans l'écart
La copie, telle qu'elle était, et rien de ce qui s'est passé après.
Les lignes créées entre cette copie et la suppression ne sont pas abîmées et ne se cachent pas dans un recoin. Elles n'ont jamais été écrites ailleurs que dans la base dont elles ont été retirées. C'est la partie difficile à accepter devant une table vide, parce que perdre quelque chose veut d'habitude dire que la chose est encore quelque part.
La largeur de cette bande dépend entièrement de ce qui prenait les copies. Une sauvegarde nocturne peut y mettre une journée de travail entière. La restauration à un instant donné la réduit à une minute, ce qui explique l'essentiel de son coût. Un dump que vous avez lancé le jour où vous y avez pensé y met tout le temps écoulé depuis.
Il existe une version où l'écart compte à peine, sur une application dont les données sont surtout vos propres contenus et changent lentement. Et il en existe une où il compte beaucoup : tout ce qui contient des commandes, des messages ou des inscriptions, où une journée de lignes est une journée de gens qui vont le remarquer.
L'agent en a supprimé une partie, pas tout
Vous avez alors un vrai choix à faire, et aucune des deux réponses n'est propre.
Une restauration ne remet pas les lignes manquantes en laissant le reste tranquille. Elle remplace les tables de la copie par ce que ces tables contenaient alors, intégralement. Restaurer ramène ce que l'agent a retiré et annule chaque bonne ligne écrite depuis. Ne pas restaurer garde les bonnes lignes et laisse le trou.
Le bon choix dépend de la quantité de travail réel posée après la copie. Si la réponse est presque rien, restaurez et passez à votre journée. Si la réponse est trois jours de fiches clients, la voie lente gagne en général : exporter d'abord les lignes survivantes, restaurer, puis remettre les lignes exportées par-dessus. C'est fastidieux, et c'est le seul chemin qui ne perd rien.
C'est aussi l'argument pour copier la base dans son état cassé actuel avant de toucher à quoi que ce soit. Quelle que soit votre décision, vous voulez pouvoir revenir à l'état d'où vous êtes parti.
Comment se passe la même heure quand une copie existe déjà
Plus court, et plutôt une décision qu'une recherche. Vous choisissez une copie, vous regardez ce qu'elle contenait, et vous appuyez sur le bouton.
C'est ce que fait Reeve Care : des copies vérifiées de votre base Supabase selon un calendrier, chiffrées et conservées hors de votre compte Supabase, avec une restauration en un clic derrière. Avant qu'une restauration démarre, elle prend une copie fraîche de l'état actuel, pour que la restauration elle-même puisse être annulée.
Les limites tiennent dans la même phrase, parce que les connaître est la façon de décider si cela vous convient :
- Cela copie votre base de données, et les fichiers que vos utilisateurs ont téléversés dès que vous connectez vos buckets Storage. C'est facultatif et cela demande une seconde clé.
- Cela fonctionne aujourd'hui avec Supabase et rien d'autre.
- Vous restaurez vers une copie qui existe, pas vers n'importe quelle minute que vous nommez. Au pire vous perdez un intervalle, soit jusqu'à une nuit sur l'offre 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é ou ramené.
- La clé de base de données conservée ne sait que lire, et c'était la promesse au moment où vous l'avez branchée. Réécrire des données demande une clé qui sait écrire, donc une restauration demande votre mot de passe de base à chaque fois et n'en garde aucun. La clé facultative pour vos fichiers sait écrire, parce que Supabase n'en émet aucune en lecture seule pour Storage, et la page où vous la remettez le dit avant.
Ce que couvre chaque offre se trouve sur la page d'accueil. Si vous
préférez ne rien payer pour cela, la version simple de la même protection est un
pg_dump selon un calendrier que vous tenez vraiment, conservé quelque part que
la perte de votre compte Supabase n'emporterait pas.
Les trois voies et ce qui échappe à chacune
passe cela en revue sans argumentaire commercial.
Cette heure-là est détaillée, copie par copie, sur la page des sauvegardes Supabase.
Ce qu'il faut faire tout de suite
Que faire
- Arrêtez tout ce qui écrit dans la base. C'est la seule étape ici qui coûte plus cher à mesure que vous la laissez traîner.
- Établissez quelles copies existent avant de décider quoi que ce soit : votre offre Supabase d'abord, puis le moindre dump que vous auriez pris vous-même, puis la question de savoir si votre application tient une trace des lignes supprimées.
- Copiez la base telle qu'elle est maintenant, cassée et tout. Quoi que vous fassiez ensuite, vous voulez un chemin de retour vers ici.
- Après une restauration, vérifiez que l'application peut encore écrire. Une base qui lit correctement et refuse un insert est une restauration à moitié faite, et seul un insert le prouve.
- Une fois l'urgence passée, mettez en place la copie qui aurait fait de tout ceci un problème de dix minutes au lieu d'une matinée.
Avant de fermer cet onglet, ouvrez votre projet Supabase et cherchez si quoi que ce soit copie votre base, puis notez où cette copie se trouve. La checklist de sécurité en 10 minutes le couvre avec le reste de ce qu'il vaut la peine de confirmer sur une application fraîchement lancée.
FAQ
Un agent IA a supprimé des lignes dans ma base Supabase. Puis-je les récupérer ?
Seulement à partir d'une copie prise avant son exécution, donc la première chose à établir est de savoir s'il en existe une. Regardez ce que comprend votre offre Supabase, puis cherchez le moindre dump que vous auriez pris vous-même, puis vérifiez si votre application tient par hasard une trace des lignes supprimées. Si rien de tout cela n'existe, les lignes sont perdues, et aucun travail sur l'application n'y changera quoi que ce soit. Établissez cela avant d'écrire quoi que ce soit de nouveau dans la base.
Puis-je demander à l'agent de remettre les données ?
Non. L'agent n'a jamais eu vos lignes. Il a envoyé une instruction à votre base et la base l'a exécutée, donc ce qu'il possède maintenant est la transcription de la conversation et non une copie de la table. Lui demander d'annuler la suppression vous donne une réponse assurée et aucune donnée. Cela signifie aussi une deuxième session sans surveillance sur une base qui a déjà perdu quelque chose.
Je suis sur l'offre gratuite de Supabase. Y a-t-il quelque chose à récupérer ?
Pas chez Supabase. Les sauvegardes automatiques commencent avec les offres payantes, et la restauration à un instant donné est une option au-dessus, donc un projet gratuit n'a de copie d'hier nulle part. Il reste un dump que vous auriez pris vous-même, ou une table de suppression douce ou d'audit que votre application écrivait déjà. Vérifiez les deux avant de supposer le pire, et vérifiez-les avant de continuer à utiliser l'application.
Dois-je laisser l'application tourner pendant que je réfléchis ?
Coupez tout ce qui écrit. La lecture ne pose pas de problème. Les nouvelles lignes posent deux fois problème : restaurer une copie retire tout ce qui a été ajouté après, donc une commande qui arrive maintenant est une donnée que vous supprimerez vous-même plus tard, et un retour à un instant donné a d'autant plus de travail réel à jeter que vous attendez. Un message de maintenance pendant une heure coûte moins cher que la seconde perte.
L'agent a supprimé certaines lignes mais pas toutes. Dois-je quand même tout restaurer ?
C'est le cas inconfortable, et il n'y a pas de réponse propre. Une restauration remplace intégralement les tables de la copie, donc elle ramène ce que vous avez perdu et annule en même temps chaque bonne ligne écrite depuis. Le bon choix dépend de la quantité de travail réel posée après la copie. Si elle est importante, exporter d'abord les lignes survivantes et les remettre par-dessus la restauration est plus lent et ne perd rien.