Ein vorhandenes Backup ist notwendig – aber kein hinreichender Beweis dafür, dass sich Ihre Systeme im Ernstfall auch tatsächlich wiederherstellen lassen. Genau diese Lücke schließt der Veeam-SureBackup-Test: Er startet Ihre gesicherten virtuellen Maschinen automatisiert in einer vollständig isolierten Umgebung, prüft Betriebssystem, Netzwerk und Anwendungen – und erzeugt am Ende einen nachvollziehbaren Prüfbericht.
Diese Seite dokumentiert einen realen, anonymisierten Testlauf aus unserem Betrieb, Schritt für Schritt, mit Screenshots der tatsächlich durchgeführten Prüfung. Kein Marketing, keine Simulation – sondern der konkrete technische Ablauf, den wir für unsere vServer.HOST-Kunden regelmäßig durchführen.
Voraussetzungen zum Verständnis: Grundkenntnisse in Servervirtualisierung (VMware/vSphere), IP-Netzwerken und Datensicherung. Spezifisches Veeam-Wissen wird nicht vorausgesetzt – technische Begriffe werden an Ort und Stelle erklärt.
Überblick: Wie ein SureBackup-Test technisch funktioniert
Das Prinzip: Backup starten, prüfen, verwerfen
SureBackup arbeitet nach einem klaren Prinzip: Die gesicherten VM-Daten werden nicht zurück auf den Produktionsspeicher geschrieben. Stattdessen stellt Veeam die Backup-Dateien über einen eigenen NFS-Dienst (vPower NFS) temporär als virtuellen Datenspeicher bereit. VMware ESXi kann die VMs daraus direkt starten – als wären sie normale Produktivmaschinen.
Das Testnetzwerk ist vollständig vom Produktivnetz getrennt. Schreibvorgänge der laufenden Testmaschinen landen in temporären Änderungsdateien und berühren die originalen Backup-Daten nicht. Nach Abschluss des Tests wird die gesamte Testumgebung automatisch bereinigt.
Der folgende Ablauf zeigt alle sieben Phasen unseres Testlaufs – jeweils mit Screenshot und technischer Erläuterung.
Netzwerkarchitektur des Tests: Vom Repository ins isolierte Lab
Phase 1: Das isolierte Virtual Lab wird bereitgestellt
Bevor eine einzige Test-VM startet, richtet Veeam die Testumgebung ein. Herzstück ist das sogenannte Virtual Lab – in unserem Fall DemoLab01. Es besteht aus zwei Komponenten:
- Virtual-Lab-Proxy-Appliance: Eine schlanke, Linux-basierte VM, die Veeam automatisch auf dem VMware-Cluster bereitstellt. Sie übernimmt die Netzwerkvermittlung zwischen dem isolierten Testnetzwerk und dem Veeam-Server – ohne dabei eine Brücke zum Produktivnetz zu schaffen.
- Isolierte virtuelle Netzwerke: Veeam legt eigene VMware-Portgruppen an, die ausschließlich für den Testbetrieb genutzt werden. Diese Portgruppen sind nicht mit dem produktiven Switch-Uplink verbunden.
Der entscheidende Vorteil dieser Isolation: Die Test-VMs können mit ihren originalen IP-Adressen starten – also genau so, wie sie in der Produktion konfiguriert sind. Würden dieselben IPs gleichzeitig im Produktivnetz aktiv sein, entstünden sofort Adresskonflikte. Im isolierten Virtual Lab ist das kein Problem, weil die Testumgebung vom produktiven Netz vollständig abgeschirmt ist.
Die Proxy-Appliance im Virtual Lab ist kein Sicherheitsrisiko, sondern eine bewusst schmale, kontrollierte Brücke: Sie ermöglicht Veeam die Steuerung der Testumgebung, ohne das Produktivnetz zu berühren.
— Technischer Hintergrund: Veeam Virtual Lab Proxy Appliance
Phase 2: Backup direkt als Datastore bereitstellen – vPower NFS
Eine klassische Wiederherstellung würde bedeuten: Die VM-Daten aus dem Backup werden vollständig auf den Produktionsspeicher zurückgeschrieben – das kann je nach Datenmenge Stunden dauern. SureBackup geht einen anderen Weg.
Veeam aktiviert seinen internen vPower NFS-Dienst: Dabei werden die Backup-Dateien im Repository (SAN_Backup_Repository) über ein NFS-Protokoll direkt als virtueller Datenspeicher für VMware ESXi bereitgestellt. ESXi sieht diesen Speicher wie jeden anderen Datastore – und kann die enthaltenen VMs direkt daraus starten.
Was passiert mit Schreibvorgängen? Wenn eine laufende Test-VM Daten schreibt (z. B. weil Windows einen Dienst initialisiert), werden diese Änderungen nicht in die originalen Backup-Dateien geschrieben. Stattdessen legt Veeam für jede Test-VM eine eigene temporäre Änderungsdatei an. Die Backup-Daten selbst bleiben zu jeder Zeit unverändert. Nach dem Test werden die temporären Dateien verworfen.
Screenshots 2a und 2b (anonymisiert): Links: NFS-Datastore SAN_Backup_Repository in der VMware-Infrastrukturansicht. Rechts: Veeam zeigt den Mount-Status der bereitgestellten VM-Daten.
Veeam vPower NFS ist ein integrierter NFS-Server-Dienst, der auf dem Veeam Backup & Replication Server läuft. Er exportiert Backup-Dateien (VBK/VIB) als NFS-Volume direkt an den ESXi-Host. ESXi registriert diesen Datastore und kann die enthaltenen VM-Konfigurationsdateien (VMDK) einlesen. Die VMDK-Dateien selbst werden dabei nicht entpackt oder kopiert – ESXi liest die Blöcke direkt aus der komprimierten Backup-Datei. Schreibzugriffe der laufenden VM werden in einem Redo-Log (temporäre Delta-Datei) auf dem Veeam-Server zwischengespeichert. Nach dem Test werden diese Logs gelöscht.
Phase 3: Domain Controller und Testserver starten
In unserem Testlauf wurden drei virtuelle Maschinen geprüft: zwei Domain Controller (DC01 und DC02) sowie ein weiterer Server (SRV01). Alle drei wurden aus ihren aktuellen Restore Points getestet.
Veeam registriert die Test-VMs der Reihe nach im vCenter – nicht unter ihrem originalen Namen, sondern als temporäre SureBackup-Instanzen, erkennbar an einem automatisch vergebenen Präfix. Die VMs werden der isolierten Virtual-Lab-Portgruppe zugewiesen, nicht dem produktiven VM-Netzwerk.
Die IP-Konfiguration bleibt dabei vollständig erhalten – DC01 startet im Test mit derselben IP-Adresse wie in der Produktivumgebung. Innerhalb des isolierten Labs entstehen dadurch keine Konflikte. Eine Verbindung zum Produktivnetz besteht nicht.
Screenshots 3a–3c (anonymisiert): Startsequenz der drei Test-VMs (DC01, DC02, SRV01) im Virtual Lab DemoLab01. Die VMs werden in der isolierten Portgruppe registriert, nicht im Produktivnetz.
Phase 4: Betriebssystemstart und Netzwerk prüfen
Heartbeat und Ping: Zwei unterschiedliche Prüfschritte
Veeam prüft in Phase 4 zwei unabhängige Dinge – und das ist wichtig zu verstehen:
1. Betriebssystemstart (VMware-Tools-Heartbeat): VMware Tools ist ein Agentenprogramm, das innerhalb der VM läuft. Sobald das Betriebssystem hochgefahren ist und VMware Tools aktiv ist, sendet die VM regelmäßige Heartbeat-Signale an den ESXi-Host. Veeam wertet diese aus. Ein erfolgreicher Heartbeat bedeutet: Das Betriebssystem ist gestartet und die VMware-Integration funktioniert.
2. Netzwerkerreichbarkeit (Ping): Der Heartbeat läuft über den VMware-internen Kommunikationskanal – er funktioniert auch ohne Netzwerkverbindung. Der anschließende Ping-Test prüft zusätzlich, ob die VM auch über das (isolierte) Netzwerk erreichbar ist. Beide Tests zusammen belegen, dass die VM nicht nur gestartet ist, sondern auch im Netzwerk kommuniziert.
Screenshots 4a und 4b (anonymisiert): Links: Heartbeat-Status aller drei Test-VMs in der Veeam-Jobansicht. Rechts: Ping-Testergebnis im Log – alle drei Maschinen erreichbar.
▶ Technischer Hintergrund: Warum ist der Unterschied relevant?Es gibt Szenarien, in denen ein Betriebssystem startet, aber keine Netzwerkkommunikation möglich ist – zum Beispiel wenn ein Netzwerktreiber fehlt, die IP-Konfiguration beschädigt ist oder ein Firewall-Dienst den Ping blockiert. Genau deshalb prüft Veeam beides separat. Nur eine VM, die sowohl Heartbeat als auch Ping erfolgreich abschließt, gilt als netzwerkfähig gestartet. Eine ausschließlich erfolgreiche Heartbeat-Prüfung wäre kein ausreichender Nachweis für Netzwerkkonnektivität.
Phase 5: Active Directory und Anwendungen validieren
Über Heartbeat und Ping hinaus führt Veeam anwendungsspezifische Skripttests durch. Diese prüfen, ob bestimmte Dienste innerhalb der VM tatsächlich funktionieren – nicht nur ob das Betriebssystem läuft.
In unserem Testlauf wurden auf beiden Domain Controllern (DC01 und DC02) drei Dienste erfolgreich geprüft:
Für SRV01 waren Anwendungsskripte in diesem Testlauf deaktiviert – Heartbeat und Ping wurden dennoch erfolgreich geprüft.
Veeam unterstützt grundsätzlich weitere Anwendungsprüfungen, zum Beispiel für Mail-Server oder Datenbankdienste. Welche Tests tatsächlich konfiguriert und ausgeführt werden, hängt vom jeweiligen SureBackup-Job und den eingesetzten Systemen ab. Die oben genannten Ergebnisse beziehen sich ausschließlich auf den dokumentierten Testlauf.
Screenshots 5a und 5b (anonymisiert): Anwendungsskript-Ergebnisse für DC01 und DC02 – DNS, Domain Controller und Global Catalog jeweils erfolgreich.
▶ Technischer Hintergrund: Wie funktionieren Veeam-Anwendungsskripte?Veeam führt die Anwendungstests über die Virtual-Lab-Proxy-Appliance aus. Die Appliance kommuniziert mit den Test-VMs im isolierten Netzwerk und führt vordefinierte Prüfskripte aus – zum Beispiel eine LDAP-Abfrage gegen den Domain Controller oder eine DNS-Auflösung gegen den DNS-Dienst. Die Skripte sind in Veeam integriert und müssen für Standarddienste wie Active Directory nicht manuell erstellt werden. Bei spezialisierten Anwendungen können eigene Skripte hinterlegt werden.
Phase 6: Testmaschinen automatisch herunterfahren und Umgebung bereinigen
Nach Abschluss aller Prüfungen übernimmt Veeam die vollständige Bereinigung – ohne manuellen Eingriff:
- Die Test-VMs werden geordnet heruntergefahren (kein harter Abbruch).
- Veeam hebt ihre Registrierung im vCenter auf – die VMs verschwinden aus der Inventarliste.
- Die temporären Änderungsdateien (Redo-Logs) werden gelöscht. Die originalen Backup-Daten im
SAN_Backup_Repositorysind unverändert. - Der vPower-NFS-Datastore wird ausgehängt.
Wichtig für das Verständnis: Die Test-VMs und die produktiven Maschinen existierten zu keiner Zeit parallel im selben Netzwerk. Während die Tests liefen, arbeiteten DC01, DC02 und SRV01 in der Produktivumgebung normal weiter – die Testläufe hatten darauf keinen Einfluss.
Die Virtual-Lab-Konfiguration (DemoLab01) bleibt nach dem Test erhalten und steht für den nächsten geplanten oder manuellen SureBackup-Job sofort wieder zur Verfügung.
Screenshots 6a–6c (anonymisiert): Herunterfahrsequenz – Veeam fährt die Test-VMs nacheinander herunter, hebt die vCenter-Registrierung auf und bereinigt den NFS-Mount.
Phase 7: Der fertige technische Prüfbericht
Ergebnis des Testlaufs: 3 von 3 – alle Maschinen erfolgreich
Der automatisch erzeugte Prüfbericht fasst alle Testergebnisse strukturiert zusammen. Das Ergebnis unseres Testlaufs:
✔ 3 von 3 virtuellen Maschinen erfolgreich abgeschlossen
✔ Gesamtdauer: 30 Minuten und 51 Sekunden
✔ Heartbeat: alle drei Maschinen erfolgreich
✔ Ping: alle drei Maschinen erfolgreich
✔ Anwendungsskripte (DC01, DC02): DNS Server, Domain Controller, Global Catalog – jeweils erfolgreich
– Anwendungsskripte (SRV01): deaktiviert
– Zusätzliche Validierungs-, Antivirus- und YARA-Prüfungen: in diesem Testlauf deaktiviert
Dieser Bericht dokumentiert die geprüften Funktionen des jeweiligen Restore Points nachvollziehbar und revisionssicher.
Screenshot 7 (anonymisiert): Veeam SureBackup Prüfbericht – Gesamtergebnis mit Einzelergebnissen je VM, Zeitstempeln und Testablaufprotokoll.
Hinweis zur fachlichen Einordnung: Ein erfolgreicher SureBackup-Test belegt, dass die geprüften Funktionen des getesteten Restore Points – Betriebssystemstart, Netzwerkkommunikation und konfigurierte Anwendungsdienste – zum Zeitpunkt des Tests funktioniert haben. Er liefert damit einen technisch nachvollziehbaren Nachweis über die Qualität der Datensicherung. Er garantiert weder eine vollständige Wiederherstellung sämtlicher Anwendungen noch eine bestimmte Dauer im Ernstfall – diese hängen von weiteren Faktoren wie verfügbarer Hardware, Netzwerkkonfiguration und Wiederherstellungsreihenfolge ab.
Prüfbericht als Nachweis: Audit, DSGVO und NIS-2-Dokumentation
IT-Audit und interne Dokumentation
Der Veeam-Prüfbericht dokumentiert mit Zeitstempel, welche VMs geprüft wurden, welche Tests konfiguriert waren und welche Ergebnisse erzielt wurden. Er eignet sich als technischer Nachweis in internen IT-Audits und Revisionen.
DSGVO-relevante TOM
Die DSGVO fordert technische und organisatorische Maßnahmen zur Datenverfügbarkeit und -wiederherstellbarkeit. Der SureBackup-Bericht unterstützt die Dokumentation dieser Maßnahmen – er ersetzt jedoch keine rechtliche Prüfung durch einen Datenschutzbeauftragten.
NIS-2-orientierte Maßnahmen
NIS-2 fordert von betroffenen Unternehmen unter anderem Maßnahmen zur Aufrechterhaltung des Betriebs und zur Wiederherstellung nach Sicherheitsvorfällen. Regelmäßige, dokumentierte Restore-Tests wie SureBackup sind ein technisch nachvollziehbarer Beitrag zur Cyber-Resilienz.
SureBackup als monatliche Leistung für vServer.HOST-Kunden
opticom führt SureBackup-Tests für Kunden unserer vServer.HOST-Plattform als buchbare Leistung durch. Der Test umfasst die automatisierte Prüfung der gesicherten VMs im isolierten Virtual Lab, die Auswertung der Ergebnisse und die Bereitstellung des Prüfberichts – wahlweise monatlich oder in einem anderen vereinbarten Rhythmus.
Die Konfiguration, Durchführung und Dokumentation übernehmen wir – Sie erhalten den fertigen Bericht und können ihn für Ihre interne Dokumentation, IT-Audits oder als Beleg für Ihre DSGVO- und NIS-2-relevanten Maßnahmen verwenden.
Sprechen Sie uns an, wenn Sie SureBackup-Tests für Ihre bei opticom gehosteten virtuellen Maschinen einrichten möchten.
