Wie Restow tatsächlich entsteht
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, aus dem jüngsten abgeschlossenen Durchgang über die Beta (intern „Iteration 1“): 12 Funktionen wurden gebaut und angenommen, und 13 separate, vom Review-Schritt aufgeworfene Probleme wurden vor der Veröffentlichung behoben: nicht 13 trotzdem ausgelieferte fehlerhafte Funktionen, sondern 13 Runden „das trägt noch nicht, beheben“, bevor das Tag hinausging. Die vollständige automatisierte Suite, die vor jedem Release grün bestehen muss, umfasst zum aktuellen Release (0.303.0): 4.168 Tests insgesamt, darunter 536 dedizierte PostgreSQL-Integrationstests über 45 Testdateien, 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. Zum Zeitpunkt der letzten Aktualisierung dieser Seite ist die nächste Iteration pausiert und startet planmäßig, nachdem das aktuelle Release erschienen ist. 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 Beta-Release lieferte einen Produktions-Build aus, 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-Release 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 „Restore tatsächlich getestet“ 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, Images für amd64 und arm64, auf nativen Runnern gebaut, und einen Release-Smoke-Lauf, den das Release bestehen muss: Was ihn nicht 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 und importiert und exportiert Mail-Dateien. Erst danach werden die Images mit cosign signiert und erhalten eine SBOM.
Die Grenzen nennen wir hier, statt sie zu verstecken. Die Microsoft-365-Prüfung läuft gegen einen Entwickler-Mandanten und nur, wenn dafür Zugangsdaten konfiguriert sind; sie wurde noch nicht gegen einen echten Mandanten ausgeführt, und frühere Tests liefen gegen simulierte Graph- und IMAP-Server. 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 läuft nur unter Linux. 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/ steht unter AGPL-3.0 mit der
Restow Module Exception, einer zusätzlichen Erlaubnis, den Kern mit
Modulen zu kombinieren. Die Funktionen von Business und Service
Provider liegen in ee/, im selben Repository, unter der
einsehbaren Restow Enterprise License, einer eigenen Lizenz, 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 →