Reeve Backups
Der Versionsverlauf ist kein Backup. Er holt keine Tabelle zurück.
Lovable und Bolt führen einen Versionsverlauf für deinen Code. Deine Datenbank ist ein eigener Dienst, und ein Rücksprung holt deine Daten nicht zurück.
Kurz gesagt
- Der Versionsverlauf stellt deinen Code wieder her. Deine Datenbank rührt er nie an, und dort liegen deine Nutzer, ihre Inhalte und ihre Bestellungen.
- Eine gelöschte Tabelle, eine überschriebene Zeile oder eine schiefe Migration überstehen einen Rücksprung also völlig unversehrt.
- Dein Code hat ein eingebautes Rückgängig. Deine Daten haben nur eines, wenn du es dort hinlegst.
Etwas ging kaputt, also hast du das Naheliegende getan. Du hast den Versionsverlauf in Lovable oder Bolt geöffnet, die Fassung von heute Morgen gesucht und auf Wiederherstellen geklickt. Die App kam exakt so zurück, wie sie war.
Die Daten nicht.
Hier ist der Punkt, an dem Leute hängen bleiben: dein Code und deine Daten sind zwei getrennte Systeme, und nur eines davon hat einen Rückgängig-Knopf. Dein Builder verwahrt die Baupläne deiner App. Deine Datenbank hält, was darin steht. Der Versionsverlauf baut die Pläne perfekt nach, bis ins letzte Detail, und gibt dir ein identisches, leeres Gebäude zurück.
Sichert der Versionsverlauf meines Builders meine Datenbank?
Nein. Er sichert deinen Code, und deine Daten liegen ganz woanders.
Lovable, Bolt, v0, Replit, Cursor und der Rest führen alle eine Historie deiner Projektdateien: deiner Seiten, deiner Komponenten, deiner Logik, deiner Gestaltung. Das sind die Pläne. Eine Fassung wiederherzustellen schreibt diese Dateien auf den Stand des gewählten Tages zurück.
Deine Datenbank ist ein anderer Dienst, fast immer Supabase, auf einem eigenen Konto. Nichts in deinem Projektverlauf greift dort hinein. Die Wiederherstellung hat keine Meinung zu deinen Daten, weil sie deine Daten nicht sehen kann.
Warum Code und Daten an zwei verschiedenen Orten liegen
Weil deine Daten genau das überstehen müssen, was dein Code ständig tut: sich ändern.
Dein Code wird bei jedem Ausliefern neu gebaut. Lägen die Bestellungen deiner Nutzer darin, wären sie jedes Mal weg, wenn du einen Knopf reparierst. Also werden beide bewusst getrennt gehalten: Der Code ist ersetzbar, die Daten sind es nicht, und deshalb versioniert sie unterschiedliches Werkzeug.
Der Preis dieser Trennung ist das Thema dieses Artikels. Jedes Werkzeug, das eines der beiden versioniert, ist für das andere blind. Dein Builder kann keine Tabelle zurückholen, und deine Datenbank kann keine kaputte Seite zurückholen.
Was beim Zurücksetzen tatsächlich passiert
Deine Bildschirme gehen zurück auf ihren alten Stand. Deine Daten bewegen sich überhaupt nicht.
| Was | Beim Zurücksetzen des Codes |
|---|---|
| Seiten, Komponenten, Gestaltung | Wiederhergestellt |
| Die Logik deiner App und ihre Fixes | Wiederhergestellt |
| Eine gelöschte Tabelle | Bleibt gelöscht |
| Von einem Skript überschriebene Zeilen | Bleibt überschrieben |
| Eine von einer Migration entfernte Spalte | Bleibt entfernt |
| Von Nutzern hochgeladene Dateien | So oder so unberührt |
Die Zeile mit der Migration überrascht Leute am meisten. Eine Migration, die du gegen deine Datenbank laufen ließest, ist bereits passiert; sie lebt in der Datenbank, nicht in deinem Repository, und die Datei zurückzunehmen, die sie beschrieb, ändert daran nichts.
Wo das wirklich zubeißt
In den zehn Minuten nach einem Fehler, wenn du das Rückgängig suchst und merkst, dass es keines gibt.
Die Formen, die es annimmt, sind ganz gewöhnlich:
- Ein Löschen im Supabase-Tabelleneditor, das mehr Zeilen traf als gemeint.
- Eine KI-gestützte Migration, die eine Spalte entfernte, damit ein Typfehler verschwindet.
- Ein Seed- oder Reset-Skript, das auf das Live-Projekt statt auf ein Testprojekt zeigte.
- Ein Aufräumen von scheinbaren Testdaten, die das echte Konto von jemandem waren.
Nichts davon rührt eine einzige Zeile deines Codes an. Jedes davon übersteht ein Zurücksetzen völlig unversehrt, und deshalb fühlt sich das Zurücksetzen an, als hätte es nichts getan. Es hat genau das getan, was es tut.
Wofür der Versionsverlauf wirklich gut ist
Für eine ganze Menge, und das gehört klar gesagt, denn die Antwort ist nicht „nichts".
Er ist ein echtes Rückgängig für echte Probleme: eine Gestaltungsänderung, die du bereust, ein Deploy, das eine Seite zerlegt hat, eine KI-Änderung, die einen funktionierenden Bildschirm schlechter geschrieben hat, eine Funktion, die die App am Ende schwerer bedienbar machte. All das liegt in deinem Code, und dafür funktioniert er genau wie versprochen.
Das Problem ist die stille Annahme, seine Aufgabe decke alles ab. Diese Annahme trifft niemand mit Absicht; sie ist die, mit der man zurückbleibt, wenn einem niemand sagt, dass es zwei Systeme gibt.
Wie du ein echtes Rückgängig für deine Daten bekommst
Du musst selbst eines hinlegen. Also eine Kopie der Datenbank, nach Zeitplan gezogen, aufbewahrt an einem Ort, den der Verlust des Kontos nicht mitnimmt.
Es gibt drei Wege dorthin, sie kosten unterschiedlich viel Geld und Aufmerksamkeit, und jedem entgeht etwas, das die anderen abdecken. Drei Wege, eine Supabase-Datenbank zu sichern geht alle drei durch, auch den, den die meisten zuerst anschalten sollten, und den Grund, warum er allein nicht reicht.
Genau dafür ist auch Reeve Care da: geplante Kopien deiner Supabase-Datenbank, außerhalb deines Supabase-Kontos aufbewahrt und geprüft, bevor sie als gemacht zählen. Verbinde deine Storage-Buckets, und die von deinen Nutzern hochgeladenen Dateien fahren mit, sodass eine Wiederherstellung die Zeilen zurückbringt und die Bilder, auf die sie zeigen.
Was eine solche Kopie enthält und was der Knopf tatsächlich tut, steht auf der Seite zu Supabase-Backups.
Was du diese Woche tun solltest
Was zu tun ist
- Finde heraus, ob deine Datenbank gerade überhaupt gesichert wird. Nicht dein Code. Deine Datenbank. Dauert die Antwort länger als eine Minute, lautet sie Nein.
- Schalte das Backup an, das dein Supabase-Tarif enthält. Es schützt dich vor deinen eigenen Fehlern, und um diesen Fall geht es hier.
- Halte zusätzlich eine Kopie anderswo, denn ein Backup im Konto hilft dir nicht, wenn du das Konto verlierst.
- Sichere hochgeladene Dateien getrennt. Sie liegen weder in deinem Code noch in deiner Datenbank.
- Spiel eine Kopie in ein Wegwerf-Projekt zurück, damit das erste Lesen dieser Datei nicht der Tag ist, an dem du sie brauchst.
Bevor du diesen Tab schließt: Öffne dein Supabase-Projekt und sieh nach, ob Backups an sind. Diese eine Prüfung ist die ganze Arbeit von heute. Die 10-Minuten-Sicherheitscheckliste deckt sie zusammen mit dem Übrigen ab, was bei einer frisch gestarteten App zu bestätigen ist, und der Supabase-Sicherheitsleitfaden geht durch, was sonst offen zu bleiben pflegt.
FAQ
Ich habe versehentlich eine Tabelle gelöscht. Bekomme ich sie zurück?
Nur aus einem Backup, das vor dem Löschen entstanden ist. Finde also zuerst heraus, ob es eines gibt. Deinen Code zurückzusetzen schafft das nicht, und dein Builder auch nicht. Auf einem bezahlten Supabase-Tarif gibt es tägliche Backups und, falls hinzugebucht, die Wiederherstellung auf einen Zeitpunkt. Auf dem kostenlosen Tarif gibt es nichts Automatisches. Prüfe das, bevor du irgendetwas anderes änderst: Manche Wege zurück werden schwerer, sobald neue Daten über die Lücke geschrieben werden.
Sichert Lovable meine Supabase-Datenbank?
Dein Builder versioniert deine Projektdateien. Deine Datenbank ist ein eigener Dienst auf deinem eigenen Supabase-Konto, und nichts im Projektverlauf greift dort hinein. Builder bekommen neue Funktionen, also schau in die Dokumentation deines eigenen Builders, statt es in die eine oder andere Richtung anzunehmen. Geh aber von Nein aus, bis du dort Ja gelesen hast.
Ist mein Git-Verlauf ein Backup?
Nein, aus genau demselben Grund, aus dem der Versionsverlauf keines ist. Git verfolgt die Dateien, aus denen deine App gebaut wird. Es hat nie eine einzige Zeile deiner Daten gesehen und kann keine zurücklegen. Ein Repository und eine Datenbank sind zwei verschiedene Dinge, die beide „dein Projekt" heißen.
Meine Daten sind alle noch da. Muss ich heute etwas tun?
Heute ist der billigste Tag, an dem du das je einrichten wirst, denn die Datenmenge ist klein und worauf es ankommt ist, dass die Gewohnheit existiert, bevor du sie brauchst. Die Verluste, die wehtun, sind selten dramatisch. Es ist ein vertippter Befehl bei einer nächtlichen Reparatur, in einem Projekt mit gerade genug echten Nutzern, dass Neuanfangen keine Option ist.