Wie sichere ich mein Projekt? Backup Schritt für Schritt

Wie sichere ich mein Projekt? Backup Schritt für Schritt

Sichern Sie drei Dinge getrennt: den Quelltext über den Export nach GitHub, die Daten über Ihr eigenes Supabase-Konto und die Originale Ihrer Inhalte auf Ihrem Rechner. Eine veröffentlichte Adresse auf zugo.run ist keine Sicherung, sondern die laufende Fassung. Erst die Kopie außerhalb des Builders ist ein Backup.

Diese Dreiteilung ist der ganze Trick. Fast jeder Datenverlust, von dem man später hört, entsteht daran, dass jemand eine der drei Ebenen für gesichert hielt, weil eine andere gesichert war.

Was genau muss gesichert werden?

Ein Projekt besteht aus mehr als der Seite, die man im Browser sieht. Vier Ebenen, und jede hat ihren eigenen Ort.

Die letzte Zeile wird am häufigsten vergessen und macht im Ernstfall die meiste Arbeit. Wer Quelltext und Daten hat, aber nicht mehr weiß, welche DNS-Einträge gesetzt waren und über welche Adresse die Bestätigungsmails liefen, verliert einen Tag mit Rekonstruktion.

Warum ist die veröffentlichte Seite kein Backup?

Weil sie den aktuellen Zustand zeigt, nicht die Zustände davor. Ein Backup ist immer eine Antwort auf die Frage „Wie war es gestern?", und eine laufende Seite kann diese Frage nicht beantworten.

Der praktische Fall ist nicht der Serverausfall, an den alle zuerst denken. Es ist die Änderung, die einen Bereich kaputtmacht, der wochenlang funktioniert hat, und die erst auffällt, wenn sich jemand beschwert. In diesem Moment brauchen Sie den Stand von vorher, und den hat nur, wer ihn selbst abgelegt hat.

Dasselbe gilt für Daten. Wenn eine falsch formulierte Änderung eine Tabelle leert, sind die Einträge weg, obwohl die Seite tadellos lädt. Deshalb wird die Datensicherung getrennt von der Codesicherung geführt.

Wie sichere ich den Quelltext?

Über den Export nach GitHub, und zwar bevor Sie ihn brauchen. Der Ablauf ist kurz genug, um ihn beim ersten ernsthaften Stand einmal zu erledigen.

Legen Sie ein GitHub-Konto an, wenn Sie noch keins haben, und verbinden Sie es mit dem Projekt. Exportieren Sie den Quelltext in ein privates Repository. Der wichtige Punkt ist das Wort „privat": Ein öffentliches Repository ist für jeden lesbar, und in einem Projektordner landen erfahrungsgemäß schneller Zugangsdaten, als einem lieb ist.

Wiederholen Sie den Export immer dann, wenn ein Stand erreicht ist, zu dem Sie zurückkehren wollen: vor einem größeren Umbau, nach einer Runde, mit der Sie zufrieden sind, vor dem Verbinden der Domain. Jeder Export ist ein Punkt auf der Zeitachse, zu dem Sie zurückkönnen.

Der Nebeneffekt ist mindestens so wertvoll wie die Sicherung selbst: Ein exportiertes Projekt lässt sich einer Entwicklerin übergeben, ohne dass sie erst eine fremde Oberfläche lernen muss. Wie der Export im Einzelnen abläuft, steht in Kann ich den Code exportieren und in KI-App-Builder mit GitHub.

Wie sichere ich die Daten?

Getrennt, denn Daten leben nicht im Build. Sobald Ihr Projekt Anmeldungen, Buchungen oder Bestellungen speichert, liegen diese Einträge in Ihrem Supabase-Konto, und die Sicherung findet dort statt.

Zwei Wege sind üblich, und sie schließen sich nicht aus. Der eine ist die Sicherungsfunktion Ihres Datenbankprojekts, deren Umfang von Ihrem dortigen Tarif abhängt. Der andere ist ein regelmäßiger Export der wichtigen Tabellen in eine Datei, die Sie ablegen wie jedes andere Dokument. Für kleine Projekte ist der zweite Weg oft der ehrlichere, weil Sie das Ergebnis sehen und anfassen können.

Ein Punkt, der in Deutschland dazugehört: In diesen Sicherungen stecken personenbezogene Daten. Sie unterliegen denselben Pflichten wie die Datenbank selbst, also Zugriffsschutz, Aufbewahrungsfrist und ein Verfahren für Löschanfragen. Ein Backup auf einem privaten USB-Stick in der Schublade ist technisch eine Sicherung und organisatorisch ein Problem. Was Datensicherheit im Builder generell bedeutet, steht in Sind meine Daten sicher.

Was gehört außer Code und Daten noch dazu?

Die unscheinbaren Dinge, die im Ernstfall den Unterschied zwischen zwei Stunden und zwei Tagen machen.

• Originale Ihrer Bilder. Nicht die verkleinerten Fassungen aus dem Projekt, sondern die Dateien aus der Kamera oder vom Gestalter, samt Lizenznachweis.
• Texte in einem eigenen Dokument. Wer seine Leistungsbeschreibungen nur auf der Seite stehen hat, schreibt sie beim Umzug neu.
• DNS-Einträge. Ein Screenshot des Registrar-Panels dauert zehn Sekunden und erspart später das Rätselraten.
• Absender und Empfänger. Über welche Adresse laufen Bestätigungsmails über Resend, an welche Adresse gehen Formulare?
• Konten und Zugänge. Registrar, GitHub, Supabase, Stripe, Analytics, Vercel. In einen Passwortmanager, nicht in eine Textdatei auf dem Desktop.
• Rechtstexte. Impressum, Datenschutzerklärung und bei Verkauf die Widerrufsbelehrung als Dokument, mit dem Datum der letzten Prüfung.

Diese Liste einmal anzulegen dauert eine halbe Stunde. Sie im Schadensfall zu rekonstruieren dauert deutlich länger, und zwar an einem Tag, an dem Sie ohnehin schon Ärger haben.

Wie oft sollte gesichert werden?

Nach Bewegung, nicht nach Kalender. Ein Projekt, das sich nicht ändert, braucht keine wöchentliche Sicherung; eines mit täglichen Bestellungen sehr wohl.

Die einfachste Regel, die sich im Alltag durchhält: Sichern Sie immer vor einem Umbau, nicht danach. Nach dem Umbau ist der alte Stand bereits verloren, und genau den wollten Sie ja aufheben.

Woran erkenne ich, dass ein Backup taugt?

Daran, dass Sie es einmal zurückgespielt haben. Eine Sicherung, die nie geprüft wurde, ist eine Hoffnung mit Dateinamen.

Der Test ist unspektakulär und dauert eine halbe Stunde. Nehmen Sie den Export, richten Sie daraus eine zweite, nicht öffentliche Fassung ein, spielen Sie eine Datensicherung in eine Testdatenbank ein und schauen Sie, ob die Seite mit diesen Daten öffnet. Was dabei fehlt, fehlt auch im Ernstfall, nur haben Sie jetzt Zeit, es zu ergänzen.

Häufig fehlen genau zwei Dinge: Konfigurationswerte, die nur im laufenden Projekt standen, und Dateien wie hochgeladene Bilder, die nicht in der Datenbank liegen. Beides merkt man nur beim Zurückspielen.

Was kann der Builder dabei nicht für mich übernehmen?

Drei Dinge, und sie ehrlich zu benennen ist der Sinn dieses Abschnitts.

Er kann nicht entscheiden, welcher Stand für Sie der richtige ist. Vor der Übergabe läuft jeder Build in einer Sandbox, und was nicht startet, wird nicht ausgeliefert. Diese Prüfung sagt, dass ein Projekt öffnet, nicht dass es inhaltlich der Stand ist, den Sie behalten wollten.

Er kann Ihre fremden Konten nicht für Sie sichern. Supabase, Stripe und Ihr Registrar gehören Ihnen, und das ist der Preis der Unabhängigkeit: mehr Kontrolle, mehr Pflicht.

Und er ersetzt bei einem großen Produkt kein Entwicklungsteam, das Sicherungen überwacht und Wiederherstellungen übt. Für ein Projekt, das ein Unternehmen trägt, ist die Routine oben das Minimum und nicht das Ziel.

Wie sieht eine Routine aus, die man durchhält?

Kurz genug, um sie nicht zu umgehen. Legen Sie einmal einen Ordner an, in dem Inhalte, Rechtstexte und die Notiz mit DNS-Einträgen liegen. Exportieren Sie den Quelltext nach jeder Änderungsrunde, die Ihnen gefällt. Sichern Sie die Daten in dem Rhythmus, den die Tabelle oben für Ihre Projektart vorschlägt. Prüfen Sie zweimal im Jahr, ob sich das Ganze zurückspielen lässt.

Zur Einordnung des Aufwands: Änderungen kosten 3 Credits, ein frischer Build 6, eine mehrseitige Plattform 12 für die ersten drei Seiten und 3 je weiterer Seite. Free enthält 5 Credits, Pro kostet 25 $ im Monat mit 200 Credits, Business 99 $ im Monat mit 800, abgerechnet in US-Dollar. Der Export selbst verbraucht davon nichts, das Wiederaufbauen eines verlorenen Projekts dagegen schon.

Wenn Sie noch am Anfang stehen, richten Sie die Sicherung gleich beim ersten brauchbaren Stand ein: zugo.dev. Das ist der einzige Zeitpunkt, an dem diese halbe Stunde nicht nervt.