0800 71 20000
Kontakt
...
Veeam v13 Upgrade-Runbook: sichere Restores planen

Veeam v13 Upgrade-Runbook: sichere Restores planen

So planst Du das Upgrade, härtest Rechte, setzt Immutability um und weist Restore-Fähigkeit nach.

Ein grüner Backup-Job in Veeam Backup & Replication beantwortet nur eine Teilfrage: Der Job konnte Daten in ein Repository schreiben. Nach einem Ransomware-Angriff brauchst Du eine andere Antwort: Kannst Du saubere, priorisierte Systeme innerhalb der vereinbarten RTO und RPO wiederherstellen, ohne infizierte Identitäten, kompromittierte DNS-Einträge oder verschlüsselte Daten zurück in die Produktion zu bringen?

Dieses Veeam-v13-Upgrade-Runbook behandelt das Upgrade deshalb als Sicherheits- und Recovery-Projekt. Du prüfst Build-Stand, Abhängigkeiten, Berechtigungen, Immutability-Einstellungen, Repository-Design und Restore-Tests, bevor Du die Produktionsumgebung anfasst.

Warum das Veeam-v13-Upgrade ein Recovery-Projekt ist

Bei v13 ändert sich nicht nur die Setup-Datei. Funktionen wie Immutability, rollenbasierte Rechte, SSO/MFA, Web-Konsole und – je nach Deployment – die Veeam Linux Appliance verändern Zugriffswege, Betriebsprozesse und Wiederherstellungsszenarien. Prüfe deshalb nicht nur, ob das Setup erfolgreich durchläuft, sondern auch, ob Dein Team nach dem Upgrade mit den neuen Rollen, Konsolen und Repository-Regeln wirklich wiederherstellen kann.

Verwende keine abgeschriebene Buildnummer aus alten Runbooks. Prüfe am Patch-Tag die aktuellen Veeam Release Notes, den passenden KB-Artikel und die offizielle Upgrade-Dokumentation. Dokumentiere im Change-Ticket die ISO-Datei, die Signatur- oder Hash-Prüfung, den Ausgangsbuild, den Zielbuild und den Link zur verwendeten Veeam upgrade checklist.

Ein fehlgeschlagener Restore entsteht häufig nicht durch einen defekten Backup-Job, sondern durch eine ungeprüfte Abhängigkeitskette: Active Directory ist verschlüsselt, der DNS-Server fehlt, die Applikationsdatenbank startet mit inkonsistentem Transaktionsstand oder der Backup-Administrator meldet sich nur über einen kompromittierten Identity-Provider an.

Leitfrage für das Upgrade: Welche Systeme stellst Du in welcher Reihenfolge wieder her, aus welchem Repository, mit welchen Identitäten und mit welchem Nachweis, dass die Daten nicht erneut Schadsoftware enthalten?

Vor dem Upgrade: Inventar statt Blindflug

Starte mit dem Build-Stand. Prüfe in der offiziellen v13-Upgrade-Dokumentation, von welchen v12- oder v13-Builds ein direktes Upgrade unterstützt wird. Liegt Deine Installation darunter, plane zuerst den von Veeam vorgesehenen Zwischenpatch. Den lokalen Dateistand des Backup-Service kannst Du zusätzlich per PowerShell prüfen.

Get-Item 'C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Service.exe' |
  Select-Object -ExpandProperty VersionInfo

Dokumentiere vor dem Wartungsfenster alle Komponenten, die das Upgrade berührt. Dazu gehören Backup-Repositories, Hardened Repositories, Proxies, Backup-Copy-Jobs, Object-Storage-Ziele, Scale-out-Backup-Repositories, GFS-Policies, Verschlüsselungseinstellungen, Anmeldeinformationen, Plug-ins, Remote-Konsolen und angebundene Remote-Komponenten.

  • Konfigurationsdatenbank: Notiere, ob die Veeam-Konfiguration auf PostgreSQL oder Microsoft SQL Server liegt und ob die Datenbank lokal oder remote betrieben wird.
  • Konfigurations-Backup: Erstelle ein verschlüsseltes Veeam-Konfigurations-Backup und teste das Kennwort vor dem Upgrade durch eine dokumentierte Wiederherstellungsprobe.
  • Backup-Ketten: Prüfe, ob aktive Ketten, GFS-Punkte und Backup-Copy-Jobs fehlerfrei sind, bevor Du Setup-Dateien startest.
  • Restore-Prioritäten: Ordne kritische Workloads wie Domain-Controller, DNS, DHCP, Datenbanken, ERP-Systeme und Fileserver einer konkreten Wiederherstellungsreihenfolge zu.

Wenn Dein Team Veeam Backup & Replication, Hardened Repositories und Restore-Abläufe praktisch üben will, können Veeam Seminare interne Runbooks und Testumgebungen sinnvoll ergänzen.

Upgrade-Pfad sauber planen

Nutze für das Upgrade das aktuelle Veeam-v13-ISO, das Veeam für Deine Ausgangsversion freigibt, und arbeite die offizielle Veeam upgrade checklist in Deinem Change-Ticket ab. Ein belastbares Wartungsfenster enthält Zeit für den Setup-Lauf, Datenbankmigrationen oder Datenbankprüfungen, Updates für Remote-Konsolen, Aktualisierungen von Remote-Komponenten, Repository-Prüfungen und mindestens einen validierten Testlauf eines Backup-Jobs.

Phase Konkrete Prüfung Abbruchkriterium
Vorbereitung Ausgangsbuild im unterstützten Upgrade-Pfad, verschlüsseltes Konfigurations-Backup, geprüfte Backup-Ketten Fehlende Restore-Passwörter, defekte Backup-Ketten oder nicht dokumentierte Zielversion
Upgrade Aktuelles v13-ISO, lokale Administratorrechte, geprüfte Installationsdatei, kein aktiver Incident Ransomware-Verdacht, laufende Wiederherstellung oder ungeklärte Datenbankfehler
Nacharbeit Remote-Konsolen, Updates, Proxies, Repositories und Remote-Komponenten aktualisiert Nicht erreichbare Repositories, fehlgeschlagene Komponentenupdates oder nicht startende Jobs

Definiere ein Rollback-Szenario, bevor Du die Produktionsinstallation aktualisierst. Dazu gehören das verschlüsselte Konfigurations-Backup, dokumentierte Installationsmedien der Ausgangsversion, ein definierter Ansprechpartner für Applikationsverantwortliche und eine Nachrichtenvorlage für den Fall, dass das Wartungsfenster verlängert wird. Nutze VM-Snapshots des Veeam-Servers nur, wenn Datenbank und Dienste in einem konsistenten Zustand sind und der Herstellerpfad dieses Vorgehen für Deine Umgebung zulässt.

Windows-Installation oder Veeam Linux Appliance

Bei Windows-basierten Installationen aktualisierst Du die bestehende Veeam-Umgebung über das freigegebene ISO und danach alle Remote-Konsolen sowie Remote-Komponenten. Wenn Du eine Veeam Linux Appliance einführst, plane sie als eigenes Deployment mit separatem Zugriffskonzept, Monitoring und Restore-Test. Prüfe in der Veeam-Dokumentation, welche Rollen die Appliance in Deiner Version übernimmt und welche bestehenden Proxies, Repositories oder Verwaltungszugänge weiterhin separat gepflegt werden müssen.

Rechte und Identitäten härten

Prüfe im Upgrade-Projekt alle Konten mit Backup-Administratorrechten. Entferne persönliche Konten ehemaliger Administratoren, ersetze gemeinsam genutzte Admin-Logins durch namentliche Konten und trenne Service-Accounts, Operatoren, Backup-Administratoren und Break-Glass-Zugriff voneinander.

SSO, MFA und rollenbasierte Rechte gehören in denselben Change wie das Upgrade, weil ein späterer Rollout die Restore-Prozesse erneut verändert. Dokumentiere zusätzlich, wie Dein Team auf Veeam zugreift, wenn der Identity-Provider, Active Directory Federation Services oder eine Cloud-Identität während eines Ransomware-Incidents nicht verfügbar sind.

  • Lege Break-Glass-Zugangsdaten offline oder in einem getrennten Privileged-Access-Management-System ab.
  • Beschränke Service-Accounts auf die notwendigen Rollen für Hypervisor, Storage, Guest Processing und Repository-Zugriff.
  • Protokolliere Änderungen an Backup-Jobs, Repository-Einstellungen, Retention, Verschlüsselung und Rollenmitgliedschaften.
  • Nimm Veeam-Zugriffsrechte in Deinen Incident-Response-Prozess auf, einschließlich Freigabe, Eskalation und Sperrung kompromittierter Konten.

Wenn Backup-Team und Security-Team den Ablauf gemeinsam testen, helfen strukturierte IT-Security Schulungen dabei, Rollen, Eskalationswege und technische Kontrollen im selben Szenario zu prüfen.

Veeam immutable backup richtig verstehen

Immutability verhindert innerhalb des konfigurierten Zeitfensters das Ändern oder Löschen von Backup-Daten. Sie ersetzt keine Offline-Kopie und keinen Restore-Test. Ein Angreifer kann weiterhin produktive Systeme verschlüsseln, Credentials stehlen, Backup-Jobs deaktivieren oder nach Ablauf der Sperrfrist Löschvorgänge auslösen.

Lege das Lock-Fenster aus Deinem Incident-Ablauf ab: maximale Erkennungszeit, forensische Sicherung, Malware-Analyse, fachliche Freigabe, Restore-Test und Sicherheitszuschlag. Wenn Deine Erkennung in einem realistischen Szenario 72 Stunden dauern kann, ist ein Lock von nur einem Tag für Ransomware-Recovery zu kurz. Prüfe je Repository-Typ die von Veeam und dem Storage-Anbieter unterstützten Mindest- und Höchstwerte, statt pauschale Zahlen aus alten Präsentationen zu übernehmen.

Bei Object Storage musst Du Retention, GFS-Policies, Object Lock und Kosten zusammen betrachten. Gesperrte Objekte bleiben bis zum Ablauf der Sperrfrist erhalten; das kann Speicherkosten erhöhen und Löschroutinen blockieren, auch wenn der Backup-Job selbst korrekt konfiguriert ist.

Typischer Fehler

Das Immutability-Fenster ist kürzer als die Zeit, die Du für Erkennung, Forensik, Malware-Analyse und Freigabe der Wiederherstellung brauchst.

Technische Folge

Backup-Punkte außerhalb des Lock-Zeitraums lassen sich löschen, obwohl frühere Restore-Punkte korrekt immutable gespeichert wurden.

Typischer Fehler

GFS-Wochen-, Monats- und Jahresstände werden mit Object Lock aktiviert, ohne die erwartete Speicherdauer und Kapazitätskosten zu berechnen.

Technische Folge

Gesperrte Objekte bleiben bis zum Ablauf der Sperrfrist erhalten und können geplante Lösch- oder Lifecycle-Prozesse verhindern.

Kombiniere immutable Repositories mit mindestens einer offline, logisch isoliert oder anderweitig ransomware-resilient geschützten Kopie. Aktiviere Backup-Verschlüsselung, beschränke Repository-Zugriffe und prüfe, ob Löschschutz, Retention und GFS-Policy dieselbe Recovery-Strategie abbilden.

Veeam Ransomware Recovery: Restore statt Jobstatus testen

Ein Veeam ransomware recovery Test beginnt nicht mit dem Zurückschreiben in die Produktion. Stelle ausgewählte Systeme zuerst in ein isoliertes Netzwerk wieder her. Verwende getrennte VLANs, deaktivierte Routen zur Produktion und eigene Test-DNS-Einträge, damit ein kompromittiertes System keine produktiven Dienste erreicht.

CISA empfiehlt offline und verschlüsselt geschützte Backups, regelmäßige Tests der Verfügbarkeit und Integrität sowie die Wiederherstellung in eine saubere Umgebung. Übertrage diese Vorgaben in Deinen Veeam-Runbook-Test: Scanne wiederhergestellte Systeme mit Deinem Malware-Schutz, prüfe Dateisystem- und Applikationsintegrität, validiere lokale und Domänen-Identitäten und dokumentiere den Zeitpunkt, an dem ein System fachlich freigegeben wurde.

  1. Stelle zuerst Identitätsdienste wie Domain-Controller, DNS und Zeitquelle wieder her.
  2. Starte danach Datenbank-Server und prüfe Transaktionslogs, Konsistenzprüfungen und Applikationsdienste.
  3. Verbinde Applikationsserver erst nach Malware-Scan und Identitätsprüfung mit den Datenbanken.
  4. Miss die Restore-Zeit je System und vergleiche sie mit den dokumentierten RTO- und RPO-Werten.
  5. Aktualisiere das Ransomware-Playbook, wenn ein Abhängigkeitsfehler, ein fehlendes Kennwort oder ein zu langsamer Restore auffällt.

Mini-Checkliste für Dein Admin-Team

  • Prüfe den aktuellen Veeam-Build und den unterstützten Upgrade-Pfad.
  • Lade das aktuelle v13-ISO herunter und prüfe Signatur oder Hash.
  • Arbeite die offizielle Veeam-Upgrade-Checkliste im Change-Ticket ab.
  • Erstelle und teste ein verschlüsseltes Konfigurations-Backup.
  • Inventarisiere Repositories, Proxies, Jobs, Policies, Credentials und Object-Storage-Ziele.
  • Bestätige die Anforderungen für Windows-Installation oder Veeam Linux Appliance.
  • Plane Updates für Remote-Konsolen und Remote-Komponenten.
  • Definiere Wartungsfenster, Kommunikationsweg und Rollback-Szenario.
  • Prüfe Admin-Rollen, Service-Accounts, MFA, SSO und Break-Glass-Zugriff.
  • Validiere Immutability-Einstellungen, Retention, GFS-Policies und erwartete Storage-Kosten.
  • Halte mindestens eine geschützte Kopie offline, isoliert oder anderweitig ransomware-resilient vor.
  • Teste Restores in einer isolierten Umgebung.
  • Scanne wiederhergestellte Systeme, bevor Du sie mit der Produktion verbindest.
  • Dokumentiere RTO, RPO, Restore-Reihenfolge und technische Abhängigkeiten.
  • Aktualisiere das Ransomware-Response-Playbook anhand der Testergebnisse.
  • Wiederhole Restore-Tests regelmäßig, statt Dich auf grünen Backup-Job-Status zu verlassen.

Konkreter nächster Schritt

Nimm vor dem nächsten Wartungsfenster drei Systeme aus unterschiedlichen Klassen: einen Domain-Controller, eine Datenbank und eine Fachanwendung. Dokumentiere Build-Stand, Repository, Immutability-Fenster, letzte erfolgreiche Sicherung, Restore-Dauer und Abhängigkeiten. Wenn Du diese drei Systeme nicht sauber in ein isoliertes Netzwerk wiederherstellst, ist das Veeam-v13-Upgrade noch nicht abgeschlossen, auch wenn der Setup-Assistent erfolgreich beendet wurde.