Hinter dieser Frage verbergen sich drei unterschiedliche Aspekte – mit jeweils unterschiedlichen Antworten. Eine Löschung innerhalb der Anwendung lässt sich rückgängig machen: Es wird nichts wirklich gelöscht, sondern der Datensatz landet in einem Papierkorb, aus dem Sie ihn per Knopfdruck wiederherstellen können. Ihre Daten verlassen die Anwendung, wann immer Sie wollen – jede Liste bietet einen eigenen Export. Doch die Datenbank einer bereitgestellten Anwendung wird durch KEINEN automatischen Mechanismus des Produkts gesichert: Es gibt keinen Sicherungsbefehl in der gesamten Bereitstellungskette – diese Aufgabe liegt beim Hosting-Anbieter. Kurz gesagt: Ein falscher Klick lässt sich selbstständig korrigieren, eine verlorene Datenbank nicht. Auf dieser Seite erfahren Sie genau, wo die Grenze verläuft – damit Sie die richtigen Fragen stellen, bevor Sie echte Daten einfügen.
Löschen innerhalb Ihrer Anwendung zerstört nichts
Die Schaltfläche „Löschen“ löscht nicht wirklich: Sie markiert den Datensatz lediglich über eine eigens dafür vorgesehene Spalte als gelöscht. Er verschwindet daraufhin aus Listen, Summen und Kennzahlen – bleibt aber weiterhin in der Datenbank erhalten. Sobald mindestens ein Datensatz gelöscht wurde, erscheint in den Einstellungen eine Karte „Papierkorb“ mit einer Schaltfläche „Wiederherstellen“. Das lässt sich im ausgelieferten Code nachvollziehen: Keine der generierten Routen ruft eine endgültige Löschung aus der Datenbank auf.
Hinzu kommt eine zweistufige Bestätigung – ein erster Klick aktiviert die Löschung, ein zweiter bestätigt sie – statt der üblichen Browser-Bestätigung. Der häufigste Fall, nämlich der unbedachte Klick am Feierabend, lässt sich so innerhalb von dreißig Sekunden ohne fremde Hilfe rückgängig machen. Dies ist zudem die einzige der drei Ebenen, die die Anwendung vollständig eigenständig abdeckt – und daher steht sie ganz oben.
Sie können Ihre Daten jederzeit exportieren
Jede Liste verfügt über eine Schaltfläche zum Export im CSV-Format. Dabei werden ausschließlich die Datensätze exportiert, die Sie AUCH SEHEN – also bereits nach Suchbegriff und aktiven Filtern gefiltert. Die Beschriftung der Schaltfläche zeigt stets die genaue Anzahl der exportierten Zeilen an: Es werden niemals stillschweigend Daten exportiert, die gerade nicht auf Ihrem Bildschirm sichtbar sind. Die Datei ist so erstellt, dass sie problemlos in einer deutschen Tabellenkalkulation geöffnet werden kann – ohne jene fehlerhaften Umlaute, die bei vielen Exporten üblich sind.
Es handelt sich um eine Kopie, die Sie selbst in der Hand halten – und sie sollte auch so benannt werden: Technisch gesehen ist ein CSV-Export KEINE Sicherung. Ein CSV-File stellt keine Anwendung wieder her – es enthält weder die Verknüpfungen zwischen Ihren Tabellen, noch den Verlauf, noch gelöschte Einträge. Es dient vielmehr dazu, die Kontrolle zurückzugewinnen: Zahlen in einer Tabellenkalkulation öffnen, an Ihren Steuerberater weiterleiten oder in ein anderes Tool importieren. Es schützt Sie vor Abhängigkeit – nicht vor Ausfällen.
Was NICHT geschieht – und was Sie selbst klären müssen
Sobald Ihre Anwendung bereitgestellt ist, erhält sie eine eigene PostgreSQL-Datenbank. Doch in der gesamten Bereitstellungskette ist KEINE automatische Sicherung vorgesehen: Im Code des Produkts, der Anwendungen bereitstellt, findet sich kein einziger Sicherungsbefehl. Das ist kein vergessener Punkt, den wir verschweigen – sondern eine klare Grenze: Sicherung hängt vom Ort ab, an dem die Anwendung läuft, und gehört daher stets demjenigen, der sie hostet – sei das nun Ihr Unternehmen, Ihr Dienstleister oder wir, falls wir die Anwendung für Sie hosten.
Drei Fragen reichen aus, um diese Grenze zu klären – und sie sollten gestellt werden, bevor Sie erste echte Daten eingeben. Wo wird sie aufbewahrt – an einem anderen Ort als der Maschine, auf der die Anwendung läuft? Andernfalls würde dieselbe Störung beide Systeme gleichzeitig treffen. Und vor allem: Hat JEMAND diese Kopie bereits einmal erfolgreich RESTAURIERT? Diese dritte Frage wird oft übersehen – doch sie ist die einzige, die etwas beweist: Eine Sicherungskopie, die nie wiederhergestellt wurde, ist keine Sicherung – sondern eine Annahme.
Was sich ändert – je nachdem, was Sie darin speichern
Nicht alle Inhalte erfordern denselben Sicherheitsaufwand. Für ein Werkzeug, dessen Inhalt sich leicht neu erstellen lässt – etwa ein Wochenplan oder eine einfache Übersicht, die man in einer Stunde neu eintippen könnte – reicht ein monatlicher Export, der irgendwo archiviert wird. Für Register hingegen, die sich NICHT neu erstellen lassen – etwa Ihre Mitgliederdaten, die Historie Ihrer Serviceeinsätze oder laufende Akten – ist eine automatisierte Sicherung der Datenbank Voraussetzung, keine Option: Niemand rekonstruiert drei Jahre Verlaufsdaten ohne Zugriff auf die ursprüngliche Datenquelle.
Die gute Nachricht: Es gibt keinerlei technische Hürden. Der generierte Code basiert auf Standard-Next.js und Prisma mit einer PostgreSQL-Datenbank – ohne proprietäre Formate, die umgangen werden müssten. Die Sicherung einer PostgreSQL-Datenbank ist eine Routineaufgabe, die jeder professionelle Dienstleister beherrscht. Die Frage lautet daher nie „Ist das möglich?“, sondern „Wer macht das – seit wann – und hat es schon einmal jemand getestet?“.