Testmethodik und gemessene Ergebnisse

Dieser Artikel ist die maßgebliche Referenz für jede gemessene Leistungs- und Sicherheitskennzahl, die auf www.statewarden.com und in StateWarden-Materialien veröffentlicht wird. Er legt dar, was gemessen wurde, auf welchen Systemen und unter welchen Bedingungen.

1. Warum diese Seite existiert

StateWarden kennzeichnet jede öffentliche Leistungs- und Sicherheitsangabe mit ihrer Quelle. Es gibt vier Kennzeichnungen:

• Im Labor gemessen: Ein reproduzierbares Testergebnis, das auf den unten beschriebenen Referenzsystemen erzielt wurde; die Testmethode ist in diesem Artikel offengelegt.
• Entwicklungsziel: Ein Designziel, für das das System gebaut wird; es ist noch keine veröffentlichte Messung.
• Selbstbewertet: Unsere eigene Bewertung anhand eines veröffentlichten Rahmenwerks mit offengelegter Bewertungsmethode (zum Beispiel die SEAL-Bewertung).
• Extern verifiziert: Von einer externen Organisation bestätigt; der Umfang der Verifizierung ist neben der Angabe genannt.

Wenn eine Zahl auf einer StateWarden-Seite ohne eine dieser Kennzeichnungen erscheint, ist das ein redaktioneller Fehler - melden Sie ihn über ein Support-Ticket.

2. Testumgebung

Die Messungen stammen aus zwei Quellen.

On-Premises-Labor:

• Hypervisoren: Proxmox VE 9 und VMware ESXi/vCenter 8.0.3.
• Client-Systeme: Debian 13 und Windows 10/11.
• Referenz-Workstations: AMD Ryzen 7 7700X mit Kingston-NVMe-Speicher (Windows 11) und AMD Ryzen 9 9950X3D (Debian 13).
• Labornetzwerk: 1 Gbps.

Eigene Produktivflotte: 24 Maschinen (Workstations und Server, Windows und Linux), die gegen die produktive Control Plane laufen.

Verifizierungsmethode: Jede Messung wird über mehrere Läufe wiederholt. Die Ergebnisse werden gegen System-Journals und Datenbankeinträge abgeglichen; kein Ergebnis wird allein aufgrund einer UI-Bestätigung akzeptiert.

3. Ressourcenverbrauch des Agenten

Für diese Zahlen gelten zwei Randbedingungen. Erstens war das 1-Gbps-Labornetzwerk in jedem Backup-Lauf der Flaschenhals - der Agent war nie der limitierende Faktor. Zweitens wurde der Festplattendurchsatz mit und ohne installierten Agenten als identisch gemessen.

Der Schreibpfad-Overhead des Change-Tracking-Treibers wurde noch nicht gemessen. Er ist unten unter Entwicklungsziele aufgeführt, und keine Zahl dazu erscheint irgendwo in StateWarden-Materialien.

4. Wiederherstellungszeiten

Instant iSCSI Mount (siehe Instant Mount: Dateiwiederherstellung über natives iSCSI):

Die Mount-Dauer ist unabhängig von der Volume-Größe. Getestete Volumes: 30 GB, 500 GB, 10 TB und 1 PB.

Proxmox Instant Boot: Der Mount-Task war innerhalb von 15 s abgeschlossen; das Gastbetriebssystem erreichte seinen gebooteten Zustand in ~120 s.

Smart BMR Bare-Metal-Recovery (siehe Bare Metal Recovery: Schritt-für-Schritt-Anleitung), gemessen als tatsächlich verstrichene Zeit (Wall Clock) vom Booten des Recovery ISO bis zum Anmeldebildschirm des Betriebssystems, auf 2-TB-Referenzdisks:

Die Messung umfasst das Booten der Recovery-Umgebung, die Authentifizierung, das Neuerstellen des Disk-Layouts, die Übertragung der Systemdaten über die 1-Gbps-Verbindung und den ersten Boot des wiederhergestellten Betriebssystems bis zum Anmeldebildschirm. Nicht eingeschlossen sind Tätigkeiten nach der Wiederherstellung wie die Neukonfiguration von Anwendungen, der erneute Domänenbeitritt und die Wiederherstellung zusätzlicher Datenvolumes. In diesen Läufen gab der Operator den Recovery-Schlüssel manuell ein, was eine bekannte Varianzquelle ist - eine automatisierte Schlüsselbereitstellung wäre schneller.

5. Skalierung und Deduplizierung

• Größtes geschütztes Volume: ein 1-PB-Ceph-Cluster.
• Größter einzelner Realm: 24 Geräte.

Deduplizierung, gemessen auf produktiven Realms, als logische Wiederherstellungsgröße im Vergleich zum belegten physischen Speicher:

Ein inkrementelles Backup eines typischen Volumes mit ~5% täglicher Änderungsrate ist in etwa 2 Minuten abgeschlossen. Eine Referenz-VM wird alle 4 Stunden gesichert.

Deduplizierungsraten sind workload-abhängig. Die obigen Zahlen beschreiben vier konkrete Produktiv-Realms; sie sind keine Prognose für andere Workloads.

6. Zuverlässigkeit der Flotte (eigener Produktiveinsatz)

StateWarden schützt seine eigene Produktivflotte mit derselben Software, die an Kunden ausgeliefert wird:

• 24 Maschinen seit 6 Monaten unter kontinuierlichem Schutz.
• 100% Backup-Erfolgsquote über 30 Tage in der gesamten Flotte.
• ~40 Agent-OTA-Updates seit April 2026 ausgeliefert.
• Längster unterbrechungsfreier Lauf: 6 Monate.

7. Active-Defense-Testergebnisse

Die folgenden Ergebnisse stammen aus Live-Tests des entropiebasierten Ransomware-Detektors und seiner Reaktionsoptionen (siehe Ransomware Protection: Reaktionsrichtlinien):

• Simulierte Angriffsdaten wurden mit einer durchschnittlichen Entropie von 7.51/8 gemessen, im Vergleich zu 3.73 für gewöhnliche Daten.
• Der Alarm wurde 5 Sekunden nach der Erkennung versendet.
• Das betroffene Backup wurde automatisch unter Quarantäne gestellt und markiert.
• Der optionale Netzwerk-Lockdown hielt den Management-Kanal aufrecht und blieb über einen harten Reset hinweg bestehen, bis er durch eine MFA-bestätigte Entsperrung aufgehoben wurde.
• Bei aktiviertem Smart CBT erfolgte die Erkennung nach etwa 500 MB verschlüsselt geschriebener Daten.
• Die Reaktionsoption zum erzwungenen Ausschalten wurde ebenfalls getestet.

Alle Ergebnisse wurden auf produktiven Live-Systemen reproduziert.

8. Glossar zu den Angaben

• RTO (Recovery Time Objective): Die angestrebte maximale Zeit zwischen einem Ausfall und der erneuten Verfügbarkeit des wiederhergestellten Dienstes. Instant-Mount-Zeit und vollständige BMR-Zeit sind unterschiedliche Metriken: Instant Mount misst den Zugriff auf Backup-Daten auf einem laufenden System, während BMR den vollständigen Neuaufbau einer Maschine bis zum Anmeldebildschirm misst. Eine Mount-Zeit als RTO für die vollständige Systemwiederherstellung anzugeben wäre irreführend, daher veröffentlicht StateWarden beide Zahlen getrennt.
• Instant Mount: Einbinden eines Backup-Snapshots in ein laufendes System über iSCSI, sodass Dateien sofort gelesen oder kopiert werden können, ohne das gesamte Volume wiederherzustellen.
• Instant Boot: Starten einer virtuellen Maschine direkt aus ihrem Backup auf dem Hypervisor, bevor Daten zurück auf lokalen Speicher übertragen werden.
• Smart BMR: Das Bare-Metal-Recovery-Verfahren von StateWarden: Die Maschine wird vom Recovery ISO gebootet und authentifiziert, ein Wiederherstellungspunkt wird ausgewählt; das Disk-Layout wird neu erstellt und die Systemdaten werden zurückgeschrieben.
• Incremental-Forever-Backup: Nach einem initialen Vollbackup überträgt jeder weitere Lauf nur geänderte Blöcke; Wiederherstellungspunkte werden aus dem deduplizierten Chunk-Store synthetisiert, sodass kein periodisch wiederholtes Vollbackup erforderlich ist.
• "Gemessen" vs. "Entwicklungsziel": "Gemessen" bedeutet eine Zahl aus dem in diesem Artikel beschriebenen Testprozess; "Entwicklungsziel" bedeutet ein Designziel, das noch nicht als Messung veröffentlicht wurde und überall, wo es erscheint, als solches gekennzeichnet ist.

9. Entwicklungsziele (noch nicht gemessen)

Die folgenden Punkte sind Designziele, keine veröffentlichten Messungen:

• Garantien für Wiederherstellungszeiten im Rahmen einer vertraglichen SLA.
• Schreibpfad-Overhead des Change-Tracking-Treibers.
• Ressourcen-Overhead des Agenten in Netzwerken mit mehr als 1 Gbps.
• Durchsatzzahlen der Krypto-Schicht.
• Eine Deduplizierungsrate für einen bestimmten Kunden-Workload.

Wenn eine StateWarden-Seite eine Zahl ohne die Kennzeichnung "Im Labor gemessen" nennt, gehört sie zu dieser Liste.

10. Verifikationsmöglichkeiten

• Die Security Challenge beschreibt, wie externe Forscher und Kunden die Sicherheitsaussagen von StateWarden direkt testen können.
• Das SEAL-Souveränitäts-Whitepaper dokumentiert die Selbstbewertung gegenüber dem EU Cloud Sovereignty Framework, einschließlich der Bewertungsmethode.