Von Tagen zu Sekunden

28. April 2026 6 Min. Lesezeit #FromDaysToSeconds

Sicherung-Wiederherstellung dauert Stunden. Self-Service-Klonen dauert Sekunden. Wir haben uns hingesetzt und beides ordentlich gemessen — Ende-zu-Ende, auf einer Last, die ziemlich genau so aussieht wie die, die unsere Kunden tatsächlich fahren. Hier ist, was dabei herauskam.

Der Aufbau

Wir wollten keinen Benchmark, der irgendjemandem schmeichelt, also haben wir etwas gebaut, das aussieht wie das, was wir auf echten Kundenbeständen sehen: eine einzelne SQL-Server-2022-OLTP-Datenbank, rund 500 GB Zeilendaten, gut 320 Tabellen — und sechs davon mit ernsthaften PII (Benutzer, Kunden, Audit-Logs, Zahlungen, Support-Tickets, Marketing-Kontakte). Nichts Exotisches. Nichts Spielzeuggroßes.

Wir haben eine einzige Zahl gemessen, und nur diese eine: Anfrage abgeschickt → Klon nutzbar. Das ist die Zahl, die ein Entwickler tatsächlich spürt — alles andere ist Buchhaltung.

Der traditionelle Weg: sichern, kopieren, wiederherstellen, maskieren

1. Quelle sichern. ~30–45 Minuten für eine Vollsicherung, je nach Komprimierung und Disk-Durchsatz.
2. .bak kopieren. ~10–60 Minuten über das Netzwerk, je nach Größe und Verbindungsqualität.
3. Auf Ziel wiederherstellen. ~25–60 Minuten für eine 500-GB-Datenbank, länger mit Verifizierung.
4. Maskierungs-Skripte ausführen. ~30+ Minuten zum Aktualisieren der PII-Spalten, oft mit Tabellensperren.
5. Konfiguration nach dem Klonen. Verbindungszeichenfolgen, umgebungsspezifische Seed-Daten, Konfigurationstabellen.

Auf dem Papier schafft selbst eine gut abgestimmte Wiederherstellungspipeline das Ganze selten unter zwei Stunden. Im echten Leben — mit einem DBA, der nebenher noch vier andere Tickets jongliert, einem Netzwerk-Share, der gerade einen schlechten Tag hat, und jemandem im Nebenraum, der ruft „hat irgendwer das Maskierungsskript gestartet?" — dehnt sich das routinemäßig auf einen halben Tag aus. Und das, bevor wir die Läufe mitzählen, die still scheitern, weil der Ziel-SQL-Server zwei Versionen zurückliegt oder weil die .bak kopiert wurde, während sie noch geschrieben wurde.

Der DataTamed-Weg: scannen, einmal importieren, für immer klonen

1. Nach Sicherungen scannen. Richten Sie den Sicherungsdatei-Scanner auf einen beliebigen Ordner. ~Sekunden.
2. Einmal importieren. Ein Vier-Schritte-Assistent verwandelt die .bak in ein wiederverwendbares, maskiertes Datenbank-Image. PII werden automatisch erkannt und maskiert. Das Image ist typischerweise unter 50 MB groß. ~10–20 Minuten für eine Quellsicherung von mehreren hundert GB, einmalig ausgeführt.
3. Danach in Sekunden klonen, immer wieder. Image wählen, Zielserver wählen, optional ein SQL-Skript-Set für die Umgebungseinrichtung. Klone werden in Sekunden fertig, weil sie 70 MB sind, nicht 500 GB.

Der Trick ist unspektakulär: Wir erledigen den teuren Teil — Reduzieren und Maskieren — genau einmal, beim Import. Danach ist jeder Klon im Grunde gratis. Teams fahren routinemäßig zwanzig frische Umgebungen in der Zeit hoch, die der alte Workflow für eine einzige brauchte — und reißen sie am Ende des Sprints wieder ab, ohne überhaupt nachzudenken.

„Aber was ist mit all den Massendaten?"

Das ist mit Abstand die häufigste Frage, die wir bekommen — meistens mit einem leicht besorgten Blick. Die ehrliche Antwort ist: Fast jedes Team, das es einmal ausprobiert, entdeckt, dass es diese Daten gar nicht wirklich verwendete. Der Klon behält das vollständige Schema, die Einschränkungen, die Beziehungen und eine repräsentative Stichprobe von Zeilen. Wenn es einen bestimmten Datensatz gibt, den Sie wirklich brauchen (einen bestimmten Kunden, eine bestimmte Zeilenzahl für einen Lasttest, eine bekannte fehlgeschlagene Zahlung, um einen Bug zu reproduzieren), skripten Sie ihn einmal über den SQL-Skript-Set-Schritt — und er wird automatisch auf jeden zukünftigen Klon angewendet. Niemand muss sich daran erinnern.

Die Zahlen, über die niemand spricht

Beim Klonen geht es nicht nur um die Zeit, die der Klon selbst braucht. Es geht um alles, was nachgelagert schneller wird, wenn das Klonen schneller wird:

• Wanduhrzeit von CI-Builds sinkt, weil Integrationstests gegen eine frische Datenbank für jeden Build laufen.
• Sprint-Kapazität steigt, weil Feature-Branches sich keine einzelne Dev-DB mehr teilen und sich nicht mehr gegenseitig stören.
• DBA-Bandbreite öffnet sich für echte DBA-Arbeit — Kapazitätsplanung, Abfrage-Tuning, DR-Tests.
• Audit-Zeit schrumpft, weil jedes Maskierungsereignis in einem einzigen exportierbaren Bericht protokolliert wird.

Verwenden Sie unseren Klon-Zeit-Rechner, um eine Zahl auf das zu setzen, was speziell Ihr Team zurückgewinnen würde. Die meisten Bestände gewinnen zwischen 12 und 40 Engineering-Tage pro Jahr zurück — für ein Werkzeug, das in der Regel weniger kostet als die Cloud-Rechnung, die sie ohnehin schon für die Speicherung von Klonen in Originalgröße zahlten.

← Zurück zu allen Artikeln