Blog · Backups und Wiederherstellung ·
CRM-Backup wiederherstellen: Datenbank und Anhänge gemeinsam prüfen
Ein CRM ist erst wieder nutzbar, wenn Datensätze, Anhänge und Zugriffsregeln zusammenpassen. Ein erfolgreicher Datenbankimport allein beweist das nicht. Unser lokaler Restore-Versuch stellt zwei Kontakte und ihre Dateien wieder her, erkennt zunächst die fehlenden Anhänge und prüft anschließend Prüfsummen und ausgewählte Leserechte.
Was muss ein vollständiges CRM-Backup enthalten?
Der Wiederherstellungsumfang folgt den Datenwegen Ihrer Anwendung. Dazu können Datenbank, Dateiobjekte, Benutzerverwaltung, Konfiguration und Integrationen gehören. Eine Dateitabelle speichert möglicherweise nur den Namen eines Anhangs und seine Zuordnung zum Kontakt. Die Datei selbst liegt an einem anderen Ort und benötigt einen eigenen Sicherungs- und Wiederherstellungsweg.
Bei Supabase ist diese Grenze ausdrücklich dokumentiert: Datenbankbackups enthalten die Metadaten, aber nicht die über Storage gespeicherten Dateiobjekte. Ein Datenbank-Restore bringt einen gelöschten Anhang deshalb nicht automatisch zurück. Prüfen Sie beim konkreten Anbieter außerdem, welche Sicherungen, Aufbewahrungszeiten und Wiederherstellungsverfahren Ihr Projekt tatsächlich nutzt.
Unser ausdrücklich fiktives CRM hat zwei Organisationen, Alpha und Beta. Jede besitzt einen Kontakt und einen Textanhang mit synthetischen Daten. PostgreSQL speichert die Kontakte, Dateinamen, Verknüpfungen und SHA-256-Prüfsummen. Ein lokales Verzeichnis steht im Versuch für die Dateiablage. Es ist kein Test eines echten S3-Dienstes oder von Supabase Storage.
Warum ersetzt ein Deployment-Rollback kein Backup?
Ein Deployment-Rollback stellt einen früheren Stand des Anwendungscodes oder der statischen Dateien bereit. Veränderte Kundendaten bleiben davon grundsätzlich getrennt. Hat eine fehlerhafte Aktion einen Kontakt und seinen Anhang gelöscht, tauchen sie durch die frühere Oberfläche nicht wieder auf. Bei Datenbankschemata kann zudem ein alter Code-Stand mit dem neuen Schema unverträglich sein.
Beschreiben Sie im Betriebsplan deshalb getrennt, wie Sie einen fehlerhaften Code-Stand zurücknehmen und wie Sie Daten wiederherstellen. Testen Sie den vorgesehenen Anwendungscode gegen das wiederhergestellte Schema. Eine technische Rückkehr zu gestern kann fachlich unbrauchbar sein, wenn seitdem berechtigte Änderungen eingegangen sind, die niemand nachführen kann.
Der Leitfaden zur Website-Veröffentlichung ordnet statische Deployments ein. Für ein CRM kommt der Datenzustand als eigene Aufgabe hinzu. Die Rücknahme einer Version und die Wiederherstellung eines Datenstands brauchen jeweils einen benannten Verantwortlichen und einen beobachteten Erfolgsfall.
Datenbank und Dateien brauchen einen gemeinsamen Bezugspunkt
Ein Datenbank-Dump kann intern konsistent sein, während die Dateiablage währenddessen weiter verändert wird. Wenn eine Datei nach dem Dateibackup hochgeladen und vor dem Datenbankbackup referenziert wird, fehlt sie beim späteren Restore. Die umgekehrte Reihenfolge kann überzählige Objekte hinterlassen. Eine Uhrzeit im Dateinamen löst diese Abstimmung nicht.
Im Beispiel schreiben während der Sicherung keine Anwendung und kein Nutzer. Zuerst entsteht ein PostgreSQL-Dump im Custom-Format, anschließend eine Kopie der zwei Dateien mit Manifest. Dieser ruhende Zustand ist Teil der Versuchsanordnung. Für laufende Systeme brauchen Sie ein zum Schreibmodell passendes Verfahren, etwa ein kontrolliertes Wartungsfenster oder versionierte Objekte mit eindeutig dokumentiertem Wiederherstellungspunkt.
PostgreSQL dokumentiert den Umfang von pg_dump
als Datenbanksicherung. Rollen sind dabei gesondert zu betrachten. Die zwei
verwendeten Datenbankrollen werden in unserer isolierten Instanz ausdrücklich
angelegt; der Dump wird nicht als vollständige Sicherung einer ganzen
Infrastruktur ausgegeben.
So läuft der reproduzierbare Restore-Versuch ab
- Ausgangszustand anlegen: Ein neuer Docker-Container startet PostgreSQL 18.6 ohne veröffentlichten Port und ohne Netzwerk. Der Runner erzeugt zwei Kontakte, zwei Dateien, ihre Beziehungen und eine kleine Lesepolicy.
-
Sichern:
pg_dumpschreibt das Datenbankarchiv. Der Runner kopiert die ruhende Dateiablage und erfasst die Prüfsummen. - Änderung simulieren: Nach dem Sicherungspunkt wird ein Kontakt mit seiner Dateireferenz gelöscht; die zugehörige Datei verschwindet. Ein neuer Kontakt entsteht nach dem Backup.
-
Datenbank zurückholen:
pg_restoreimportiert das Archiv in eine frisch angelegte Zieldatenbank. Das Zielverzeichnis für Dateien ist noch leer. - Unvollständigkeit erkennen: Die wiederhergestellten Dateireferenzen zeigen auf zwei fehlende Objekte. Der Datenbankimport allein erfüllt die Wiederherstellungsprüfung nicht.
- Dateien ergänzen und prüfen: Beide Sicherungsdateien werden ins Ziel kopiert. Ihre SHA-256-Werte und Datenbeziehungen müssen stimmen; anschließend folgen ausgewählte Rechteprüfungen.
Quelle und Ziel sind getrennte Datenbanken derselben kurzlebigen PostgreSQL-Instanz. Es gibt kein Überschreiben einer Produktionsdatenbank und keinen Zugriff auf fremde Container oder Volumes. Der Runner entfernt seine eigene Instanz und das temporäre Dateiverzeichnis am Ende. Damit ist der Versuch einfach wiederholbar, aber kein Nachweis für einen Standortwechsel oder die Wiederherstellung eines ganzen Kundenkontos.
Den Versuch lokal ausführen
Benötigt werden Python 3.10 oder neuer, Docker und das in der Anleitung mit Digest benannte PostgreSQL-Image. Der Runner lädt es nicht automatisch nach. Verwenden Sie den dokumentierten Pull-Befehl einmalig, sofern das Image lokal fehlt, und starten Sie anschließend:
python3 run.py > results.json
Das Skript akzeptiert keine Zieladresse und keine Produktions-Zugangsdaten. Die
PostgreSQL-Werkzeuge laufen im Container in derselben Version wie der Server.
Die PostgreSQL-Dokumentation zu pg_restore
beschreibt die verwendete Wiederherstellung aus dem Archiv. Der Runner bricht bei
einem Importfehler ab.
Die aufgezeichneten Ergebnisse enthalten Zeitpunkt, Version, Image-Digest, Quelltext-Prüfsumme und die beobachteten Prüfungen. Die MIT-Lizenz erlaubt die Anpassung der Fixture. Verändern Sie für eine eigene Projektprobe zunächst nur eine getrennte Testumgebung und dokumentieren Sie ihren tatsächlichen Umfang.
Was ist nach der Wiederherstellung nachgewiesen?
Am 28. September 2026 bestanden 14 Prüfungen. Beide ursprünglichen Kontakte und ihre Dateireferenzen waren in der Zieldatenbank vorhanden. Der nach dem Backup angelegte Kontakt fehlte erwartungsgemäß. Das macht den Wiederherstellungspunkt sichtbar: Ein Restore kann erfolgreich sein und trotzdem spätere berechtigte Arbeit verlieren.
Vor der Dateikopie meldete die Gegenprobe zwei fehlende Objekte. Nach der Kopie stimmten beide Prüfsummen und beide Verknüpfungen zu den Kontakten. Eine anschließend absichtlich veränderte Datei wurde erkannt; nach erneuter Kopie aus der Sicherung war die Prüfung wieder erfolgreich. Ein grüner Prozess-Exit allein hätte diese Unterschiede nicht gezeigt.
Außerdem waren RLS und FORCE ROW LEVEL SECURITY der Kontakttabelle
wiederhergestellt. Die eingeschränkte Leserrolle sah im Alpha-Kontext nur Alpha,
im Beta-Kontext nur Beta und ohne Organisationskontext keine Kontakte. Ihr
fehlendes INSERT-Recht wurde separat geprüft. Das Testprogramm setzt den
Organisationskontext direkt in SQL; es implementiert damit keine sichere
Anwendungsauthentifizierung.
Die technische Teilmessung betrug im aufgezeichneten Kleinstversuch 0,31 Sekunden: von der Anlage der Zieldatenbank bis zu Import, Fehlstellenprüfung, Dateikopie und Hashprüfung. Vorfallerkennung, Abstimmung, die anschließenden Rechteprüfungen und ein Anwendungsneustart sind darin nicht enthalten. Zwei winzige Textdateien und zwei Datensätze liefern weder eine Kapazitätsaussage noch ein zugesagtes Wiederherstellungsziel.
Ein Restore darf entzogene Rechte nicht unbemerkt zurückbringen
Ein älterer Datenstand kann auch ältere Mitgliedschaften und Berechtigungen enthalten. Eine Person, deren Zugang nach dem Sicherungspunkt entzogen wurde, darf durch die Wiederherstellung nicht ungeprüft wieder Zugriff erhalten. Halten Sie deshalb fest, welche maßgeblichen Änderungen seit dem Sicherungspunkt vor einer Wiederöffnung erneut angewendet werden müssen.
Prüfen Sie Kontakte und Dateien über die später genutzten Zugriffswege. Die Fixture testet eine kleine Datenbank-Lesepolicy; sie testet keine Download-URLs, Storage-Regeln, Sitzungen oder Zugriffsrechte der Dateiablage. Für das echte CRM brauchen Sie auch dort erfolgreiche Kontrollanfragen und abgewiesene Gegenproben. Das ausführlichere RLS-Beispiel und der CRM-Zugriffsleitfaden ergänzen diese Aufgaben.
Auch ein technisch korrekt wiederhergestellter Auftrag kann Nebenwirkungen auslösen: Ein Worker könnte eine schon versandte E-Mail nochmals schicken oder einen externen Auftrag erneut starten. Öffnen Sie Hintergrundverarbeitung und externe Integrationen deshalb erst nach den dafür festgelegten Prüfungen. Die Fixture enthält solche Dienste nicht; eine vollständige Projektprobe muss sie ausdrücklich berücksichtigen.
RPO, RTO und Freigabe konkret vereinbaren
RPO beschreibt den tolerierbaren Datenverlust als Zeitraum; RTO die angestrebte Zeit bis zur Wiederherstellung des vereinbarten Betriebs. Legen Sie für das Projekt fest, wann diese Messung beginnt, wann sie endet und welche Funktionen dann tatsächlich verfügbar sein müssen. „Das Backup wurde eingespielt“ ist ein engerer Zustand als „Mitarbeiter können wieder vollständig arbeiten“.
Notieren Sie in einer Restore-Probe mindestens den Sicherungspunkt, die enthaltenen Datenarten, den Zielstand des Anwendungscodes, Start und Ende der einzelnen Schritte sowie alle offenen Abweichungen. Prüfen Sie die Erreichbarkeit und Nutzbarkeit mit einem berechtigten Testkonto. Erteilen Sie die Freigabe erst nach den fachlich vereinbarten Kontrollen und halten Sie fest, wer sie verantwortet.
- Daten: Erwartete Kontakte, Beziehungen und bekannte Änderungen seit dem Backup sind geklärt.
- Dateien: Referenzierte Objekte existieren, Inhalte stimmen und der Anwendungspfad kann sie öffnen.
- Rechte: Mitarbeiter, Partner und fremde Organisationen sehen jeweils nur ihren freigegebenen Umfang; Entzüge bleiben wirksam.
- Betrieb: Jobs, Integrationen und erneute Sicherungen funktionieren im Zielzustand.
- Zeit: Gemessene Teilzeiten und die vollständige Probe werden getrennt ausgewiesen; offene Schritte bleiben sichtbar.
Die editierbare Übergabe-Checkliste bietet bereits Platz für Verantwortliche und Wiederherstellungsnachweise. Ergänzen Sie dort das Protokoll Ihres tatsächlichen Projekts. Unsere Fixture liefert dafür ein überprüfbares Beispiel, keine automatische Sicherung Ihrer Kundenanwendung.
Wo passt obhut in das Kundenprojekt?
obhut entwickelt die Betriebsplattform für Agenturen mit Websites, Portalen, SaaS und internen Anwendungen. Statisches Hosting sowie HTTP/HTTPS-Proxy und Tunnel sind implementiert.
Identitätsbasierter Access, WAF und Rate Limits für Kundentraffic sowie Serverlaufzeiten sind geplant. Ein Frontend-Proxy konfiguriert keine Datenbankrechte und schützt keine API außerhalb seines Anfragewegs. Die hier gezeigten Beispiele sind eigenständige Lehrmaterialien und keine verfügbaren obhut-Sicherheits- oder Backupdienste.
Im Projektgespräch für Agenturen klären wir anhand Ihrer Anwendung Laufzeit, Nutzer, Datenwege und Zuständigkeiten. Die Anfrage dient dem Projektabgleich; sie ist keine Sicherheitsfreigabe oder Buchung eines Audits.
Quellen und Prüfstand
Primärquellen geprüft am 28. September 2026. Die lokalen Ergebnisse und ihre Grenzen stehen im verlinkten Beispiel; Aussagen über einen Kundenbetrieb werden daraus nicht abgeleitet.
