Kunden-Offboarding: Warum vor jedem Drop ein Dump gehört
Löschen ist leicht, Wiederherstellen unmöglich. Ein Offboarding braucht eine feste Reihenfolge: sichern, prüfen, dann abbauen. Und eine Aufbewahrungsregel, die jemand aufgeschrieben hat.
Das Onboarding eines Kunden bekommt Aufmerksamkeit: Es steht im Vertrieb, im Demo-Skript, in der Roadmap. Das Offboarding bekommt ein Ticket, das jemand freitags abarbeitet. Dabei ist es der gefährlichere Vorgang. Beim Onboarding kann man wiederholen. Beim Offboarding nicht.
Die drei typischen Unfälle
Der Export danach. Der Kunde kündigt, die Datenbank wird gelöscht. Drei Wochen später meldet sich sein Steuerberater und braucht die Rechnungen aus dem System. Es gibt sie nicht mehr.
Das halbe Löschen. Das Skript löscht die Datenbank, scheitert am Bucket, weil er nicht leer ist, und bleibt stehen. Der Bucket kostet weiter, der Hostname zeigt ins Leere, niemand merkt es.
Der falsche Kunde. Zwei Kunden mit ähnlichem Namen, ein Tippfehler im Skript, und die Datenbank des zahlenden Kunden ist weg. Ohne Backup gibt es dafür keine Entschuldigung, die hilft.
Alle drei haben dieselbe Ursache: Löschen war der erste Schritt.
In welcher Reihenfolge läuft ein Offboarding?
- Sichern. Jede Datenbank des Kunden als Dump, jeder gefüllte Bucket als Archiv, in einen Speicher, der dem Anbieter gehört und nicht dem Kunden.
- Prüfen. Liegt das Objekt wirklich dort? Ein HEAD-Request auf den Dump ist der Unterschied zwischen "der Upload lief durch" und "die Datei ist da".
- Abbauen. Erst jetzt: Workload, Records, Datenbank, Buckets, in umgekehrter Reihenfolge des Anlegens.
- Aufbewahren. Der Dump bleibt so lange, wie die Regel sagt, herunterladbar, mit Protokoll, wer ihn wann geladen hat.
Und die wichtigste Regel: Scheitert Schritt eins oder zwei, passiert Schritt drei nicht. Ein Offboarding, das ohne Sicherung weitermacht, ist kein Offboarding, sondern ein Datenverlust mit Ansage.
Wo läuft der Dump?
Ein Detail, das im Betrieb überrascht: Eine Managed-Datenbank mit privatem Endpunkt ist von außen nicht erreichbar, auch nicht von der Control Plane. Der Dump muss dort laufen, wo das Netz ist, also im Cluster. Ein Job mit pg_dump oder mariadb-dump, dessen Ergebnis er per signierter URL in den Backup-Bucket lädt, ist das übliche Muster. Passwort und URL kommen aus einem Secret, das mit dem Job stirbt.
Welches Format sollte das Backup haben?
Für PostgreSQL das Custom-Format von pg_dump: komprimiert, mit pg_restore selektiv wiederherstellbar. Für MySQL ein SQL-Dump, wiederherstellbar mit dem Client. Beides sind Standardformate, die man ohne den Anbieter lesen kann. Das ist wichtig: Ein Backup, das nur die Plattform lesen kann, ist ein halbes Backup.
Buckets sind das größere Problem
Datenbanken sind klein und strukturiert. Buckets sind groß und beliebig. Ein Kunde mit 40 GB Uploads braucht beim Offboarding ein Archiv, das größer ist als jede Datenbank, und ein Bucket lässt sich erst löschen, wenn er leer ist. Drei Regeln:
- Archivieren, bevor auch nur ein Objekt gelöscht wird, und das Archiv prüfen.
- Danach genau die archivierten Objekte löschen, nie den Bucket blind leeren. Was zwischen Archiv und Löschen dazukam, bleibt.
- Eine Obergrenze setzen. Ein Archiv jenseits von ein paar Gigabyte ist ein manueller Fall, keine Automatik.
Aufbewahrung ist eine Entscheidung, keine Voreinstellung
Wie lange bleibt der Dump? Datenschutz sagt: so kurz wie nötig. Der Kunde sagt: bis ich den Export habe. Das Handelsrecht sagt für manche Daten: Jahre. Es gibt keine allgemeingültige Zahl. Es gibt nur die Pflicht, eine festzulegen, sie pro Speicher zu konfigurieren und Löschungen zu protokollieren. Und die Regel, dass eine Automatik nur löscht, was sie selbst geschrieben hat. Fremde Objekte im selben Bucket bleiben unangetastet.
Ein Offboarding ist dann gut, wenn es sich langweilig anfühlt: sichern, prüfen, abbauen, protokollieren. Jedes Mal gleich.
Wie das in Clusterward aussieht
Das Offboarding eines Tenants beginnt mit dem Dump jeder Datenbank und dem Archiv jedes gefüllten Buckets, beides in den Backup-Bucket des Workspaces, beides per HEAD verifiziert. Erst dann läuft die Onboarding-Pipeline rückwärts. Ein Fehler beim Sichern stoppt alles, bevor etwas verändert wurde. Dumps bleiben nach der Aufbewahrungsregel der Instanz herunterladbar, jeder Download steht im Audit-Log. Die Details stehen unter Tenant-Pipelines und Managed Datenbanken. Solche geprüften Sicherungen gehören auch zu den Nachweisen, die NIS2 verlangt, siehe Audit & NIS2.
Die Checkliste für den Ablauf
- Steht die Aufbewahrungsdauer für Dumps fest, ist sie pro Speicher konfiguriert und irgendwo aufgeschrieben, wo der Datenschutzbeauftragte sie findet?
- Weiß das Offboarding, welche Ressourcen zum Kunden gehören? Eine Liste aus dem Onboarding, nicht ein Suchmuster über Namen.
- Läuft der Dump dort, wo die Datenbank erreichbar ist, und wird das Ergebnis geprüft, bevor gelöscht wird?
- Werden Buckets archiviert, bevor auch nur ein Objekt gelöscht wird, und gibt es eine Obergrenze für die Archivgröße?
- Wird der Ablauf bei jedem Fehler angehalten, statt zu überspringen?
- Steht jeder Schritt mit Zeitpunkt und Person im Protokoll, einschließlich späterer Downloads des Dumps?
- Kann der Ablauf nach einem Fehler wiederholt werden, ohne dass er die schon gesicherten Daten erneut anfasst?
Wer alle sieben mit Ja beantwortet, hat ein Offboarding. Wer bei einer zögert, hat einen Datenverlust, der noch nicht passiert ist.
Was der Kunde bekommt
Ein gutes Offboarding endet mit einer Nachricht an den Kunden: Ihre Daten wurden am Datum gesichert, der Export steht bis zum Datum bereit, danach wird er gelöscht. Der Export ist der Dump im Standardformat, herunterladbar über einen Link mit kurzer Gültigkeit. Das ist nicht nur Freundlichkeit. Es ist der Nachweis, dass Sie Daten weder verloren noch länger als nötig behalten haben, und es beantwortet die Anfrage des Steuerberaters, bevor sie kommt.
Das Offboarding testen
Der einzige Weg, ein Offboarding zu vertrauen, ist ein Testkunde, der regelmäßig angelegt und wieder abgebaut wird. Einmal im Monat einen Tenant onboarden, Daten eintragen, offboarden, den Dump herunterladen, in eine leere Datenbank einspielen. Zehn Minuten, die den Unterschied machen, wenn es ernst wird.
Den Wiederherstellungstest im Cockpit machen
Der monatliche Test wird einfacher, wenn die Wiederherstellung nichts Laufendes berührt. In Clusterward spielt „In neue Datenbank wiederherstellen“ ein Backup neben der laufenden Datenbank ein, mit eigenem Nutzer und Passwort. So prüfen Sie jedes Backup, ohne die Produktion anzufassen. Wie das mit Volumes und früheren Versionen zusammenspielt, steht unter Backups & Wiederherstellung.
Fazit
Schreiben Sie das Offboarding vor dem zehnten Kunden auf, mit fester Reihenfolge und fester Aufbewahrung. Danach wird es ein Ablauf, den jeder im Team ausführen kann, auch freitags.
Offboarding für Ihre App aufsetzen? Schreiben Sie uns, was ein Kunde bei Ihnen besitzt: Datenbanken, Buckets, Domains. Wir zeigen, wie Sicherung und Abbau als feste Reihenfolge laufen. Offboarding besprechen →
Quellen und weiterführende Links
Häufige Fragen
- Erst sichern, dann prüfen, dann abbauen, dann aufbewahren. Jede Datenbank wird als Dump und jeder gefüllte Bucket als Archiv gesichert, die Sicherung per HEAD-Request geprüft. Erst danach werden Workload, Records, Datenbank und Buckets in umgekehrter Reihenfolge des Anlegens entfernt. Scheitert Sichern oder Prüfen, wird nichts gelöscht.