Wie Restow tatsächlich entsteht

Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am 2026-10-16

Restow entsteht durch einen einzelnen Entwickler mit KI-Unterstützung, in einer automatisierten Umsetzen-Prüfen-Korrigieren-Schleife, die läuft, bis Tests und eine schriftliche Spezifikation beide bestehen, nicht in einem Schuss generiert.

Restow wird von Lucas Flores gebaut, einem IT-Systemtechniker und Inhaber eines kleinen Managed Service Providers bei Köln, kein Berufsentwickler. Der Code entsteht mit KI-Unterstützung (Claude), mit seinem eigenen Verständnis von Exchange, Graph und Speichersystemen, und mit einer Testdisziplin, die bei einem Backup-Werkzeug nicht verhandelbar ist. Wenn Sie das lesen und denken, das klingt nach einem Risiko, liegen Sie damit richtig; diese Seite ist der Beleg dafür, warum wir es für ein handhabbares Risiko halten. Kein Grund, blind zu vertrauen.

Ingenieure lassen sich nicht davon abbringen zu fragen, wie Software tatsächlich entsteht, und sie sollten auch nicht das Wort einer Marketingseite dafür nehmen müssen. Hier ist also der Prozess, mit echten Zahlen aus der aktuellen Beta, nicht die allgemeine Aussage, dass „KI uns hilft, schneller zu bauen“.

Die Loop, konkret

Jede Funktion durchläuft dieselbe Abfolge, und das ist kein Ein-Schuss-Verfahren: ein Agent implementiert sie gegen eine schriftliche Spezifikation, und ein separater Review-Durchgang prüft das Ergebnis gegen diese Spezifikation und gegen die automatisierte Testsuite (Lint, Typprüfung, und die Tests, tatsächlich gegen eine PostgreSQL-Datenbank ausgeführt, nicht gemockt). Schlägt eine Prüfung fehl, geht die Arbeit für eine weitere Runde zurück. Es gibt keine feste Rundenzahl; es wiederholt sich, bis die Prüfungen bestehen oder ein Mensch stoppt.

Konkret, für 0.1.0: Die vollständige automatisierte Suite, die vor jedem Release grün bestehen muss, umfasst 7.145 Tests über alle Pakete, darunter 918 dedizierte PostgreSQL-Integrationstests über 77 Testdateien, keiner übersprungen, die echtes Datenbankverhalten prüfen (Row-Level-Security, Migrationen, nebenläufige Jobs), das eine gemockte Datenbank verdecken würde. Diese Zahlen ändern sich mit jedem Release: Hier steht der Stand der letzten Aktualisierung dieser Seite, keine feste Behauptung. Der Produktions-Build wird zudem beim tatsächlichen Start in einem echten Browser geprüft, nicht nur angenommen, weil der Entwicklungsserver funktioniert.

Was ein Mensch tatsächlich tut

Die Loop entscheidet nicht allein, was gebaut oder ausgeliefert wird. Lucas setzt Prioritäten, genehmigt alles, was die Architektur, die Lizenzierung oder rechtliche Formulierungen des Produkts ändert, bevor es gebaut wird (nicht danach), und kann eine ganze Iteration anhalten, bis er zugestimmt hat. Entscheidungen mit rechtlichem oder finanziellem Gewicht (Preise, Lizenzbedingungen, was eine Funktion über GoBD-Konformität behaupten darf) sind seine Entscheidungen, protokolliert und datiert, nicht etwas, das ein Agent ableitet.

Wenn trotzdem etwas schiefgeht

Das ist passiert. Ein datiertes Beispiel, denn „wir testen alles“ ist ohne eines nicht viel wert: ein früher interner Build, vor dem ersten öffentlichen Release, erzeugte einen Produktions-Build, der in einem echten Browser eine leere Seite anzeigte, verursacht durch eine zirkuläre Abhängigkeit zwischen JavaScript-Chunks, die der Entwicklungsserver nie zutage förderte. Es wurde entdeckt, und ein Hotfix-Build noch am selben Tag behob sowohl den unmittelbaren Fehler als auch den Build-Prozess selbst, sodass er künftig bei einem zirkulären Chunk laut fehlschlägt, statt still wieder einen auszuliefern. Das ist der Maßstab, an dem wir uns messen: wenn etwas durchrutscht, gehört zur Behebung, dass genau dieser Fehler künftig nicht mehr still passieren kann.

Warum das bei einem Backup-Werkzeug mehr zählt als bei den meisten Programmen

Ein Fehler in einem Backup-Produkt verhält sich nicht nur falsch: Er kann bedeuten, dass Daten, die Sie für sicher hielten, es nicht sind. Deshalb behandelt Restow „bewiesen wiederherstellbar“ als das Produkt, nicht als Feature: ein Backup, das nie über den Restore-Pfad zurückgelesen wurde, wird als unbewiesen angezeigt, nicht als erledigt. Deshalb muss ein Release mehr bestehen als die eigenen Tests der Build-Loop. Jedes Release durchläuft eine Pipeline: den vollständigen CI-Lauf auf dem getaggten Commit, das vom Maintainer signierte Agent-Release, beide Builds (die vollständigen Images und die Community-Images) für amd64 und arm64, auf nativen Runnern gebaut, und einen Release-Smoke-Lauf je Build und Architektur, den das Release bestehen muss: Was nicht alle besteht, wird nicht veröffentlicht. Der Smoke-Lauf startet eine frische Installation und prüft die Health-Endpunkte, meldet sich in einem echten Browser per Passkey an, sichert und stellt ein IMAP-Postfach wieder her und vergleicht jede Nachricht Byte für Byte, nimmt einen Journal-Bericht entgegen und prüft die Hash-Kette, stellt mit dem eigenständigen Werkzeug wieder her, während der Server gestoppt ist und der Container kein Netzwerk hat, schreibt auf S3-, lokalen und NFS-artigen Speicher, liest zurück und scrubbt, führt einen Trivy-Scan aus, sichert und stellt einen Ordner mit dem Restow-Agent wieder her, importiert und exportiert Mail-Dateien und sichert, durchsucht und stellt seit 0.4.0 eine von Samba bereitgestellte SMB-Dateifreigabe mit ihren Berechtigungen wieder her, samt Kopierjob, und archiviert seit 0.4.4 ein IMAP-Konto (vorhandene Mail übernommen, neue Mail per IMAP IDLE, beim Transport weitergeleitete Kopien, dieselbe Mail nur einmal aufbewahrt, die Hash-Kette geprüft) gegen einen Dovecot (der Community-Lauf überspringt die Journal-, die Archiv-Erfassungs- und die Speicherziel-Prüfung, die die Business-Module oder einen zweiten Mandanten brauchen). Erst danach werden die vier Images mit cosign signiert und erhalten eine SBOM.

Die Grenzen nennen wir hier, statt sie zu verstecken. Der abschließende Release-Smoke-Lauf vom 1. Oktober 2026 hat für den vollständigen Build 9 seiner 11 Prüfungen vollständig bestanden, 1 teilweise und 1 übersprungen; für den Community-Build 7 vollständig, 1 teilweise und 3 übersprungen, zwei davon planmäßig (die Journal-Prüfung und die Prüfung der Speicherziele brauchen die Business-Module oder einen zweiten Mandanten und laufen im vollständigen Build). In beiden übersprungen wurde die Microsoft-365-Prüfung: Sie läuft gegen einen Entwickler-Mandanten und nur, wenn dafür Zugangsdaten konfiguriert sind, und für 0.1.0 waren keine konfiguriert. Microsoft-365-Backup und -Restore wurden in den Release-Prüfungen daher noch nicht gegen einen echten Microsoft-365-Mandanten ausgeführt; sie sind durch Tests gegen eine simulierte Graph-API abgedeckt. Teilweise bestanden ist die Installationsprüfung: Das Upgrade vom vorherigen Release kann für 0.1.0 nicht laufen, weil es kein früheres öffentliches Release gibt. Die Endpunkt-Prüfung hat das echte Installationsskript des Agents nur in einem Linux-Container ausgeführt; der macOS-Agent wird ausgeliefert, sein Installer war aber nicht Teil der Release-Prüfungen (die eigenen Tests des Agents liefen nativ auf macOS). Kritische Trivy-Funde, für die es noch keine Korrektur gibt und auf die man nicht reagieren kann, werden im Bericht aufgelistet, nicht versteckt. Die Smoke-Berichte hängen an jedem GitHub-Release, und die Release Notes tragen jeweils einen Abschnitt „Verification“, der genau nennt, was für dieses Release gelaufen ist, nicht, was die Pipeline irgendwann abdecken soll.

Open Source, damit Sie uns nichts davon glauben müssen

Alles außerhalb von ee/ ist Open Source unter der Apache License 2.0. Die Business- und Service-Provider-Module liegen in ee/, im selben Repository, stehen unter den Restow-Lizenzbedingungen und werden per Lizenzschlüssel freigeschaltet. Der Quellcode, einschließlich ee/, ist öffentlich auf GitHub, dort erscheint jedes Release. Version 0.1.0, das erste öffentliche Release, ist jetzt verfügbar, sodass Sie die oben beschriebenen Tests, die Restore-Nachweise und das Speicherformat selbst prüfen können, statt dieser Seite zu vertrauen. Siehe Open Source für die Lizenzdetails, einschließlich der Begründung, warum der Schlüssel der bezahlten Editionen ein Fair-Play-Mechanismus ist und kein DRM.

Sehen Sie, was dieser Prozess bisher tatsächlich ausgeliefert hat →