Im Juli 2025 baut der Gründer Jason Lemkin zwölf Tage lang mit dem KI-Tool Replit an einer App. Am neunten Tag löscht die KI die Datenbank. Mit allen Einträgen, die er bis dahin gesammelt hatte, rund 1.100 Kontakte. Er hatte der KI vorher ausdrücklich gesagt, sie solle nichts ändern. Sie hat es trotzdem getan.
Danach behauptete die KI, eine Wiederherstellung sei nicht möglich. Das stimmte nicht. Es gab einen Weg zurück, er war nur nicht offensichtlich. heise hat damals darüber berichtet.
Ich erzähle dir das nicht, um über KI zu lästern. Ich nutze sie selbst jeden Tag. Ich erzähle es, weil es zeigt, was beim Vibe Coding anders ist: Die Dinger arbeiten schnell, sie ändern viel auf einmal, und du verstehst nicht jede Änderung. Das ist der Deal. Und bei diesem Deal ist ein Backup keine Kür, sondern die Voraussetzung.
Warum ein Backup (nicht nur) beim Vibe Coding so wichtig ist
Wer klassisch programmiert, ändert Dinge langsam und weiß meistens, was er gerade tut. Wer mit KI baut, bekommt in Minuten hundert Zeilen Änderungen und klickt auf “Übernehmen”. Wenn dabei etwas kaputtgeht, merkst du das oft erst Tage später.
Dazu kommt ein zweites Problem. Das Backup, das dein Tool oder dein Hoster mitbringt, liegt meistens beim selben Anbieter und am selben Konto. Wird das Konto gesperrt, gehackt oder gekündigt, ist das Original weg und die Kopie gleich mit.
Ein Backup, das am selben Ort liegt wie das Original, ist kein Backup. Es ist ein zweites Exemplar derselben Gefahr.
Wenn du noch nicht genau weißt, wo dein Projekt eigentlich steht, lies erst was Vibe Coding ist und wo die Grenzen liegen. Wenn dein Prototyp schon echte Nutzer hat, hilft dir auch das Vibecoding Cleanup.
Was du überhaupt sichern musst
Bei einem Projekt gibt es drei Dinge, die weg sein können. Sie brauchen unterschiedliche Behandlung.
1. Der Code. Das ist die App selbst, also das, was die KI für dich geschrieben hat. Dafür gibt es ein bewährtes Werkzeug: GitHub. Das ist ein Online-Speicher für Code, der jede Änderung festhält. Du kannst jederzeit zu einem früheren Stand zurück, auch wenn die KI etwas kaputtgemacht hat.
2. Die Daten. Das ist die Datenbank. Da stehen deine Kunden, Anfragen, Bestellungen und Nutzerkonten drin. Das ist der Teil, der sich nicht neu erzeugen lässt. Code kann eine KI in einer Stunde neu schreiben. Deine Kunden nicht.
3. Die Dateien. Hochgeladene Bilder, PDFs, Rechnungen, Anhänge. Sie liegen oft nicht in der Datenbank, sondern daneben, und werden deshalb gern vergessen.
Dazu kommt ein vierter Punkt, den fast alle übersehen: die Zugangsdaten und Einstellungen. Wenn dein Server weg ist, brauchst du nicht nur die Daten, sondern auch das Wissen, wie alles zusammenhängt. Schreib das auf.
Wichtig: GitHub ist ein Backup für Code, nicht für Daten. Wer glaubt, mit GitHub sei “alles gesichert”, hat nur ein Drittel abgedeckt.
Die 3-2-1-Regel in einem Absatz
Die Faustregel für Backups heißt 3-2-1. Sie besagt: Du hast drei Kopien deiner Daten, auf mindestens zwei verschiedenen Speichern, und eine davon liegt an einem anderen Ort, bei einem anderen Anbieter.
Die drei Kopien sind das Original und zwei Sicherungen. Die zwei Speicher heißen zum Beispiel: dein Server und ein Online-Speicher. Der andere Ort schützt dich vor dem Fall, dass der Anbieter selbst ausfällt, dein Konto gesperrt wird oder ein Angreifer alles löscht, was er erreichen kann.
Profis erweitern das gern zu 3-2-1-1-0: eine Kopie, die niemand mehr verändern kann, und null Fehler beim Test, ob sich das Backup auch zurückspielen lässt. Für den Anfang reicht 3-2-1. Aber den Teil mit dem Zurückspielen solltest du von Anfang an ernst nehmen. Dazu unten mehr.
Voll, inkrementell, differentiell: Welche Backup-Arten es gibt
Du wirst diese drei Wörter in jeder Anleitung lesen. Sie bedeuten weniger, als sie klingen:
- Vollbackup: Jedes Mal wird alles gesichert. Das ist einfach und übersichtlich, braucht aber viel Platz und Zeit.
- Inkrementelles Backup: Gesichert wird nur, was seit dem letzten Backup neu oder geändert ist. Das spart Platz und geht schnell. Zum Zurückspielen braucht es die ganze Kette der Sicherungen.
- Differentielles Backup: Gesichert wird alles, was sich seit dem letzten Vollbackup geändert hat. Das ist ein Mittelweg zwischen den beiden.
In der Praxis musst du dir das nicht selbst zusammenbauen. Moderne Programme wie restic sichern inkrementell, also sparsam, fühlen sich beim Zurückspielen aber an wie ein Vollbackup. Du wählst einen Stand aus und bekommst alles, was an diesem Tag da war.
Wo kannst du Backups ablegen?
Es gibt nicht den einen richtigen Ort. Aber es gibt eine klare Bedingung: Das Backup muss bei einem anderen Anbieter liegen als dein Original.
| Ort | Wofür gut | Worauf du achten musst |
|---|---|---|
| HiDrive (Strato) | Deutscher Anbieter, einfach, gut für automatische Sicherungen | Prüf vorher, ob dein Tarif den automatischen Zugriff erlaubt |
| Google Drive | Hast du vermutlich schon, schnell eingerichtet | Google kann den Inhalt lesen, solange du nicht selbst verschlüsselst |
| AWS (Amazon), Speicher-Bucket | Sehr robust, bietet eine Sperre, die Dateien unveränderbar macht | Etwas komplizierter einzurichten, Kosten im Blick behalten |
| Externe Festplatte | Offline und damit sicher vor Angriffen über das Internet | Du musst daran denken, sie anzuschließen und regelmäßig zu tauschen |
| Backup deines Hosters | Besser als nichts | Liegt beim selben Anbieter, zählt deshalb nicht als “anderer Ort” |
Ich persönlich halte HiDrive für ein ziemlich gutes Medium für Backups. Mir gefällt, dass der Anbieter in Deutschland sitzt, was beim Thema Kundendaten und Datenschutz die Sache einfacher macht. Aber das ist meine Meinung für meinen Fall. Google Drive oder ein AWS-Bucket sind genauso legitim, wenn du das sauber aufsetzt.
Sobald Daten von deinen Kunden im Backup liegen, gehört der Anbieter in deine Datenschutz-Unterlagen. Du brauchst mit ihm einen Auftragsverarbeitungsvertrag. Bei den großen Anbietern ist das ein Klick im Kundenbereich, aber du musst ihn machen.
Welche Werkzeuge gibt es dafür?
Du musst nicht alles selbst erfinden. Es gibt eine ganze Reihe bewährter Programme, die sich in ihrem Anspruch deutlich unterscheiden:
| Werkzeug | Was es macht | Für wen |
|---|---|---|
| rsync | Gleicht Ordner ab und überträgt nur Änderungen. Läuft auf fast jedem Server | Wer sich mit der Kommandozeile wohlfühlt |
| rclone | Wie rsync, aber für Cloud-Speicher wie Google Drive oder AWS. Kann verschlüsseln | Wer in eine Cloud sichern will |
| restic, Borg | Richtige Backup-Programme: verschlüsseln, speichern Versionen, sparen Platz | Wer ein Backup mit Rückweg will, nicht nur eine Kopie |
| Acronis, Veeam | Komplettlösungen mit Oberfläche, Support und Lizenzkosten | Firmen mit vielen Rechnern und Servern, für ein kleines Web-Projekt meist überdimensioniert |
| Time Machine, Windows-Sicherung | Sichern deinen eigenen Rechner | Dein Laptop, nicht dein Server |
| Backup-Plugins | Sichern eine WordPress-Seite per Klick. Mehr dazu im Artikel über WordPress-Sicherheit | WordPress-Seiten |
| NAS (zum Beispiel Synology) | Ein kleiner Speicher-Rechner im Büro, der Sicherungen vor Ort ablegt | Eine Kopie zu Hause, die zweite muss trotzdem woanders liegen |
Eine Sache lohnt sich besonders zu verstehen: Synchronisieren ist kein Sichern. Tools wie rsync oder auch der Ordner-Abgleich bei Google Drive spiegeln den aktuellen Stand. Löscht die KI aus Versehen eine Datei oder zerschießt sie deine Datenbank, wird dieser kaputte Zustand beim nächsten Abgleich brav in die “Kopie” übertragen. Dann hast du zwei kaputte Stände statt einem.
Ein echtes Backup behält ältere Versionen. Genau deshalb nutze ich für meine Projekte restic und nicht nur einen Abgleich. Du kannst rsync oder rclone als Transport nutzen, aber das Versionieren muss irgendwer übernehmen.
Verschlüsselung und der Schlüssel, den du nie verlieren darfst
Das ist der Teil, bei dem die meisten Anleitungen zu locker sind.
Ein Backup enthält alles, was auch dein Original enthält. Also deine Kunden, ihre Mailadressen, Rechnungen. Wenn das unverschlüsselt in irgendeiner Cloud liegt, ist es ein Datenleck, das nur darauf wartet, dass jemand das Passwort errät.
Es gibt zwei Arten von Verschlüsselung, und der Unterschied ist groß:
- Der Anbieter verschlüsselt. Dann hat der Anbieter den Schlüssel. Er kann den Inhalt lesen, und jeder, der sein System oder dein Konto knackt, auch.
- Du verschlüsselst selbst, bevor die Daten deinen Rechner oder Server verlassen. Dann liegt beim Anbieter nur unlesbarer Datensalat. Nur wer dein Passwort hat, kommt an die Daten.
Nimm die zweite Variante. Und dann kommt die Kehrseite, die ich dir ehrlich sagen muss: Wenn du das Passwort verlierst, sind deine Backups wertlos. Es gibt keinen “Passwort vergessen”-Knopf. Das ist kein Fehler, das ist der Sinn der Sache.
Deshalb gehört das Passwort in einen Passwortmanager, nicht in eine Notiz auf dem Desktop und nicht in dieselbe Cloud wie das Backup. Leg zusätzlich eine Notfallkopie an einem zweiten Ort ab, zum Beispiel ausgedruckt in einem Safe oder bei einer Vertrauensperson. Und schreib die Adresse des Backup-Speichers dazu, sonst findest du in einem Jahr selbst nicht mehr, wo du suchen musst.
Weitere Sicherheitsregeln, die wenig Aufwand machen:
- Eigener Zugang nur für das Backup. Nutze nie dein Hauptpasswort, sondern einen eigenen Benutzer oder Schlüssel, den du einzeln sperren kannst.
- Zwei-Faktor-Anmeldung auf dem Konto, auf dem das Backup liegt. Sonst reicht ein erratenes Passwort, um alles zu löschen.
- Mehrere Stände aufheben, nicht nur den von gestern. Wenn der Fehler drei Tage unbemerkt blieb, sind alle jüngeren Backups schon kaputt.
- Wenn möglich, eine unveränderbare Kopie. Manche Anbieter, zum Beispiel AWS, haben eine Funktion, die Dateien für eine festgelegte Zeit sperrt. Auch ein Angreifer mit Zugriff kann sie dann nicht löschen.
Ein Beispiel-Workflow: So sichere ich meine Projekte
Damit das nicht abstrakt bleibt, zeige ich dir, wie das bei mir aussieht. Das ist kein Standard, den du übernehmen musst. Es ist ein Beispiel, damit du eine Vorstellung hast.
- Der Code liegt auf GitHub. Jede Änderung wird dort festgehalten. Dazu liegt eine Kopie auf meinem Rechner udn auf einer Backup-Platte, sowie in Nextcloud (Achtung auch hier immer verschlüsseln!).
- Jede Nacht um die gleiche Uhrzeit sammelt ein automatischer Job die Daten ein: die Datenbanken und die hochgeladenen Dateien all meiner Projekte.
- Verschlüsselt wird, bevor etwas den Server verlässt. Dafür nutze ich ein kostenloses Programm namens restic. Es verschlüsselt, spart Platz, weil es nur Änderungen überträgt, und räumt alte Stände von selbst auf.
- Das Paket geht zu HiDrive. Das ist ein anderer Anbieter als mein Server, also genau der “andere Ort” aus der 3-2-1-Regel.
- Aufgehoben werden sieben tägliche, vier wöchentliche und sechs monatliche Stände. So komme ich im Notfall auch noch auf den Zustand von vor ein paar Wochen zurück.
- Jeden Morgen bekomme ich eine Mail. Entweder “OK” mit einer Aufstellung, was gesichert wurde und wie groß es war. Oder “Fehler” mit der Stelle, an der es hakte. Oder “Kein Lauf”, wenn der Job gar nicht gestartet ist. Der letzte Fall ist der gefährlichste, weil man ihn sonst nie bemerkt.
- Das Passwort für die Verschlüsselung liegt in meinem Passwortmanager. Nirgends sonst.
Dasselbe Prinzip funktioniert mit einem Google-Drive-Ordner oder einem AWS-Bucket als Ziel. Der Speicherort ist austauschbar. Die Schritte nicht: automatisch, verschlüsselt, an einem anderen Ort, mit Alarm.
Das Wichtigste: Teste, ob du zurückspielen kannst
Ein Backup ist erst ein Backup, wenn du es einmal zurückgespielt hast. Vorher ist es eine Hoffnung.
Es kann sein, dass die Datei leer ist. Dass sie sich nicht öffnen lässt. Dass dir ein Teil der Daten fehlt, weil ein Ordner nicht mitgesichert wurde. Das merkst du nur beim Test, und der Test sollte passieren, bevor du das Backup brauchst.
So geht das ohne großen Aufwand: Leg dir eine Testumgebung an, spiel das Backup dort ein und schau, ob deine Daten vollständig da sind. Einmal beim Einrichten, danach in regelmäßigen Abständen. Wer das nie macht, lernt im Ernstfall, dass das Backup nie funktioniert hat.
Wenn du kein Entwickler bist: Das fragst du dein Tool
Nicht jeder baut sein Projekt auf einem eigenen Server. Wenn du mit einem KI-Baukasten arbeitest, stell dir diese Fragen und such die Antworten in den Einstellungen:
- Wo genau liegen meine Daten, und bei welchem Anbieter?
- Kann ich sie als Datei herunterladen, zum Beispiel als Export?
- Gibt es automatische Sicherungen, und wie weit reichen sie zurück?
- Was passiert, wenn mein Konto gesperrt wird?
Wenn die Antwort auf die zweite Frage “nein” lautet, ist das dein erstes Problem. Wer seine Daten nicht herausbekommt, hat sie nicht wirklich.
Deine Checkliste
- Ich weiß, was bei mir gesichert werden muss: Code, Daten, Dateien, Zugangsdaten.
- Es gibt mindestens eine Kopie bei einem anderen Anbieter.
- Das Backup ist verschlüsselt, und zwar von mir, nicht erst vom Anbieter.
- Das Passwort liegt im Passwortmanager und zusätzlich an einem Notfallort.
- Der Backup-Zugang ist ein eigener, nicht mein Hauptpasswort, mit Zwei-Faktor-Schutz.
- Ich hebe mehrere Stände auf.
- Ich bekomme eine Nachricht, wenn ein Backup fehlschlägt oder gar nicht läuft.
- Ich habe mindestens einmal ein Backup zurückgespielt.
Wenn du bei mehr als zwei Punkten nicht “ja” sagen kannst, fang heute mit dem ersten an. Nicht nächste Woche.
Fazit
Vibe Coding macht es leicht, schnell etwas zu bauen. Es macht es auch leicht, schnell etwas zu verlieren. Ein Backup kostet dich einmal einen Nachmittag und danach fast nichts. Der Verlust deiner Daten kostet dich im Zweifel das ganze Projekt.
Wenn du schon einen Prototyp hast, der läuft, und dir bei der Checkliste oben nicht sicher bist: Genau dafür gibt es mein KI-Code-Audit. Ich schaue mir dein Projekt an und sage dir ehrlich, wo es steht. Läuft es später bei mir, sind deutsche Server, automatische Backups und Monitoring mit dabei, inklusive Alarm, wenn etwas schiefgeht. Der erste Schritt, der System-Check, ist kostenlos und unverbindlich.
Kommentare