Eine größere Herausforderung bei Disaster-Szenarien ist, dass Backup-Lösungen wie Veeam häufig nicht redundant ausgelegt sind. Dies hat zur Folge, dass beispielsweise Hardwarefehler oder auch fehlerhafte Updates Backup-Systeme lahmlegen und somit auch Wiederherstellungen in einem gewissen Zeitraum unmöglich machen.
Neben Patchmanagement und entsprechenden Hardware-Carepacks sollte die Architektur an aktuelle Anforderungen angepasst werden. Hierfür muss die RTO von Veeam selbst betrachtet und definiert werden, um die RTO für gesamte Infrastrukturen im Umkehrschluss so gering wie möglich halten zu können.
Hierzu setze ich bei Kunden folgende Varianten je nach Möglichkeit und Interesse des Kunden um:
Variante 1: Config Backup mit vorbereitetem VBR-Server
Variante 2: Veeam Replication (präferiert)
Variante 1:
Wenn der Kunde beispielsweise den Veeam Backupserver nicht virtualisieren kann oder möchte, so wird die Veeam-Instanz inkl. der zugehörigen Datenbank auf einer physikalischen Maschine installiert sein. Dies bedeutet aber auch, dass man den Zugriff auf Veeam verliert, sobald die betroffene Hardware ausfällt oder fehlerhaft ist. Im Umkehrschluss kann man mit weiteren Backup-Repositories (NAS, Cloud, etc.) nicht sofort wieder weiterarbeiten, da eben die Instanz von Veeam selbst fehlt.
Um dies zu umgehen bzw. die RTO so gering wie möglich zu halten, so kann man entweder auf einer weiteren physikalischen, aber auch auf einer virtuellen Maschine eine Veeam-Instanz vorbereiten. Dieses „Standby-System“ wird vollständig installiert, jedoch noch nicht konfiguriert. Man richtet sämtliche Funktionen ein, installiert Veeam inkl. der darunterliegenden Datenbank und führt auch Netzwerkkonfigurationen und Härtung durch, sodass man im Fehlerfall lediglich das Configuration Backup von Veeam einspielen muss und mit der neuen Instanz dann direkt weiterarbeiten kann.
Es muss natürlich sichergestellt werden, dass ein Zugriff auf das Veeam Configuration Backup möglich ist, demnach sollte dieses auf einem externen Repository gespeichert werden und eben nicht auf dem Server, der auch die Veeam-Instanz trägt.
Wichtig:
Bei dieser Variante muss beachtet werden, dass ein vorbereitetes „Standby-System“ natürlich nicht die selbe IP-Adresse und den selben Hostnamen tragen kann wie das Produktivsystem. Dies hat zur Folge, dass man die IP-Adresse im Fehlerfall auf die des Produktivsystems ändern muss, was widerum die Veeam-Instanz beschädigen kann bzw. zusätzliche Konfigurationen erforderlich macht.
Wenn das System eine andere IP-Adresse und einen anderen Hostnamen trägt, so gilt es entsprechende Firewallregeln vorzubereiten, sodass auch dieses System im Fehlerfall nach Einspielen des Configuration Backup voll handlungsfähig ist. Ebenfalls kann es sein, dass innerhalb von Veeam zusätzliche Konfigurationen erforderlich sind.
Variante 2:
Veeam bietet die Möglichkeit der Replikation von VMs. Bei den meisten Kunden virtualisiere ich die Veeam-Installation (Veeam Backupserver), sodass Veeam selbst von den Vorteilen eines Clusters profitieren kann. Dies beinhaltet Loadbalancing, virtuelles Anpassen von Ressourcen und auch die Nutzung von Replikation als RTO-Minimierung.
Wichtig: Diese Variante wurde zwar getestet, ist jedoch kein offizielles Vorgehen von Veeam!
Vom Vorgehen her wird die VM, auf der sich die Veeam-Installation befindet, mittels Veeam Replication auf lokale Datastores von Hypervisor-Servern in unterschiedlichen Rechenzentren repliziert. Je nach Umgebung und Anzahl an Backup-Jobs und abhängig vom Aubau ist hier ein Intervall von 15-60 Minuten zu empfehlen, wobei die Retention nicht sonderlich lang sein muss.
Falls also nun das Storage ausfällt, auf dem dann u.a. die Veeam-VM betrieben wird, so kann man nach einem vorab festgelegten Notfallplan die Veeam-VM direkt auf einem der Hypervisor-Server starten, da sie dort als Replika, also als startfähige VM liegt.
Veeam sieht üblicherweise vor, dass eine Replika über die Veeam-Konsole gestartet wird, was in diesem Fall jedoch nicht möglich ist.
Folgendes habe ich exemplarisch in einer vSphere-Umgebung konfiguriert:
Als Replikationsintervall habe ich 30 Minuten konfiguriert:
Die fertige Replikation kann außerdem in Veeam überwacht werden:
Wichtig: Die Replika darf von hier natürlich nicht gestartet werden, da der hierfür benötigte Dienst auch von Veeam gesteuert wird – jedoch wird die VM – somit der Dienst – im Rahmen des Failover heruntergefahren.
Auf dem Host sieht das Ganze dann folgendermaßen aus:
Die lauffähige, replizierte und startbereite VM liegt auf dem lokalen ESXi-Host und kann auch von dort gestartet werden, sollte das vCenter ausfallen:
Hinweis: Anlage der ESXi-Hosts in Veeam:
Im K-Fall ist davon auszugehen, dass auch vCenter und Domaincontroller ausfallen und somit zentrale Dienste wie DNS und die Verbindung von Veeam zur Virtualisierungsumgebung nicht zur Verfügung stehen.
Üblicherweise – das ist nach wie vor in den meisten Fällen der beste Weg – wird die Umgebung über ein vCenter an Veeam angebunden. Das bedeutet aber auch, dass Veeam die Verbindung zur Wiederherstellung über das vCenter sucht. Steht das nicht zur Verfügung, führt der Restore zu Fehlern.
Um dies zu vermeiden, binde ich jeden Host neben dem vCenter auch als Standalone-Host per IP-Adresse an, um im Notfall eine Wiederherstellung unabhängig vom DNS auf einen dedizierten Host durchführen zu können. Für das o.g. Szenario verwende ich ebenfalls als Ziel-Host das per IP-Adresse angelegte Element. In der Veeam-Konsole sieht das folgendermaßen aus:
Dies wende ich auch in Hyper-V Umgebungen an!
Entsprechende Tests in Kooperation mit verschiedenen Kunden – in verschieden großen Umgebungen – haben gezeigt, dass keine offensichtlichen Fehler auftreten, die die Funktionalität von Veeam beim Betrieb der Replika-VM beeinträchtigen.
Wichtig: Ein Configuration Backup in Veeam ist in jedem Fall unumgänglich!