Replikation ist kein Backup
Viele Hypervisor- und auch diverse Backupprodukte unterstützen die Replikation einer virtuellen Maschine vom primären Hypervisor, auf dem das System produktiv läuft, zu einem zweiten Hypervisor. Das zweite System kann entweder im gleichen Raum, im gleichen Gebäude in einem zweiten Raum oder auch viel weiter entfernt stehen, zum Beispiel in einem Rechenzentrum. Nach einer initialen Übertragung aller Daten werden die Änderungen am Live-System kontinuierlich zum zweiten System transferiert und dort eingepflegt. Dies passiert entweder in sehr kurzen Intervallen (etwa alle 30 Sekunden, alle fünf Minuten oder alle 15 Minuten wie bei Hyper-V) oder nur ein oder zwei Mal am Tag. Mit Hilfe dieser Technik haben Sie ein annährend identisches System auf einem zweiten Hypervisor laufen, häufig ohne Bedarf an massiver Bandbreite zwischen den beiden Systemen.

Gegen eine Replikation ist grundsätzlich nichts einzuwenden, Sie sollten sich aber immer über eine Sache im Klaren sein: Ein Replikat ist kein Backup! Da Änderungen am Live-System immer auf das sekundäre übertragen werden, unterliegen auch ungewollte Änderungen wie das Löschen von Dateien oder eine ungewollte Verschlüsselung der Daten durch Ransomware diesem Vorgang. Trotzdem kann es sinnvoll sein, diese Technik einzusetzen, zum Beispiel für ein Backup der VMs auf dem zweiten Hypervisor-Host. Dies führt zu einer Entlastung des primären Systems, trotzdem haben Sie eine Sicherung (und Archivierung) der Daten.

Steht zum Beispiel der Umzug auf neue Hardware an, die an einem anderen Standort betrieben wird, lassen sich, um die Downtime möglichst klein zu halten, im Vorfeld alle VMs auf den neuen Hypervisor replizieren. Dieser Vorgang kann einige Zeit in Anspruch nehmen, stellt aber kein Problem dar, da sich mit dem Live-System weiter arbeiten lässt. Zum Zeitpunkt des Umzugs werden die Server am Standort A heruntergefahren (dadurch sind die Daten konsistent und werden nicht mehr geändert), danach ein weiterer Replikationsvorgang initiiert, bevor dann die VMs an Standort B wieder starten.

• Nutzen Sie ein bewährtes und den Anforderungen Ihrer Infrastruktur entsprechendes Backupprogramm.
• Kaufen Sie Backupspeicher mit ausreichend Performance und Durchsatz.
• Testen Sie regelmäßig Ihre Backups.
• Simulieren Sie regelmäßig eine Wiederherstellung.

Beherzigen Sie diese Empfehlungen, haben Sie einige Vorteile während eines Recovery-Vorgangs. Durch eine Backupsoftware, die sich auf eine Sicherung einer virtuellen Infrastruktur spezialisiert hat, haben Sie hier ganz anderen Möglichkeiten und Zeitfenster als etwa bei einem Backup mit Windows-Bordmitteln oder bei einer Sicherung mittels Skript. Sie können mit einer guten Software einen Teil Ihrer VMs bereits aus dem Backupspeicher heraus starten, ohne dass die Daten auf den Hypervisor oder den Storage zurück kopiert werden müssen. Dies ermöglicht Ihnen eine Wiederherstellung von unternehmenskritischen Systemen innerhalb von wenigen Minuten. Die Daten dieser VMs werden dann im Hintergrund wieder an den ursprünglichen Speicherort verschoben, ohne dass Mitarbeiter etwas davon mitbekommen. Ausgenommen vielleicht eine geringere Performance als im Regelbetrieb, aber schließlich kümmern Sie sich aktuell um einen massiven Ausfall, nicht um den Regelbetrieb.

Je besser Ihr Backupspeicher und die Anbindung an das Netzwerk, desto schneller können Sie die Daten wiederherstellen. Genau in solch einem Moment lohnt sich die Investition in Backupspeicher mit mehr als 1 GBit/s, auch wenn diese Bandbreite fast nie benötigt wird – außer in dieser kritischen Situation! Haben Sie Ihre Backups regelmäßig validiert und getestet, können Sie sicher sein, dass die Wiederherstellung selbst bei Daten, die vielleicht auf zehn oder mehr inkrementellen Backup-Dateiketten aufgeteilt sind, funktioniert.

Neben den technischen Voraussetzungen und Abhängigkeiten sollten Sie vor allem mit dem Prozess und der Wiederherstellung vertraut sein. Je besser Sie den Prozess kennen und je öfter Sie ihn durchgeführt haben, desto weniger Bauchschmerzen haben Sie im Ernstfall. Fällt ein Teil oder Ihre gesamte IT aus und Sie müssen sich mehr oder weniger das erste Mal mit einem Recovery-Prozess auseinandersetzen, kann dies entweder zu einer enormen Verzögerung führen oder Sie machen die Sache im schlimmsten Fall noch hoffnungsloser als sie eh schon ist, wenn Sie ungewollt Backupdateien löschen oder überschreiben lassen.

Ein Ausfall von wichtigen IT-Systemen ist immer mit Stress verbunden. Diese zusätzliche Belastung führt dazu, dass eher Fehler gemacht werden als wenn Sie in aller Ruhe eine Aufgabe erledigen. Im schlimmsten Fall steht jemand während der Wiederherstellung dauerhaft hinter Ihnen und beobachtet den Fortschritt. Dass dies nicht förderlich ist und die Sache nicht beschleunigt, ist eigentlich logisch, passiert aber leider trotzdem immer wieder. Wenn Sie in solchen Situationen Ihr Programm kennen und genau wissen, welche Schritte notwendig sind, ist das Gold wert. Es lässt sich gar nicht genug betonen, wie wichtig dieser Punkt ist.

Neben einer guten Dokumentation Ihrer Infrastruktur sollten Sie ein Notfallhandbuch erstellen, das alle wichtigen Schritte aufführt und ausführlich beschreibt. In einer IT-Abteilung gibt es immer Leute, die sich besser mit dem Backup und einer möglichen Wiederherstellung auskennen, als andere. Das ist normal und meist auch nicht anders realisierbar. Daher sollten die Personen, die sattelfest beim Thema Backup und Recovery sind, ihr Wissen und die Vorgehensweise in einer speziellen Form der Dokumentation festhalten. Sie sollten hier sogar darüber nachdenken, dieses Handbuch auszudrucken und redundant vorzuhalten. Das mag vielleicht ein bisschen altmodisch klingen, aber wenn die gesamte IT-Infrastruktur steht und das Notfallhandbuch in einem Wiki gespeichert ist, was ebenfalls nicht mehr zur Verfügung steht, hilft dies niemandem. Denken Sie auch daran, das Handbuch bei einer Änderung in der Infrastruktur zu aktualisieren.

Der Betrieb einer Monitoringlösung auf einer eigenen Hardware außerhalb Ihrer Hypervisor-Infrastruktur sorgt zusätzlich dafür, dass Sie beim Ausfall des Failover-Clusters oder der HA-Umgebung immer noch sehen können, welche Systeme weg und welche noch verfügbar sind. Weiterhin entdecken Sie vielleicht auch noch, was kurz vor dem Ausfall passiert ist. Erscheinen die ersten Fehler durch den Ausfall des Storage-Systems und tauchen erst kurze Zeit später Fehler der Hypervisoren auf, ist es nicht sinnvoll auf den Hypervisor-Hosts nach Fehlern zu suchen. Haben Sie diese Informationen nicht, weil sich beim Ausfall auch das Monitoring verabschiedet hat, wird eine Fehlersuche vermutlich länger dauern als mit konkreten Informationen und Hinweisen vom Monitoring.

Fazit
Ein gutes Monitoring ermöglicht es Ihnen im Idealfall im Vorfeld, ein Problem erst gar nicht auftreten zu lassen. Hierzu sollten Sie die gesamte Infrastruktur betrachten und eine Lösung wählen, die Ihnen die benötigten Daten liefert und die Anforderungen erfüllt. Reagieren Sie zeitnah bei Meldungen, vor allem bei möglichen Performance-Engpässen. Mit einem guten Backupprogramm sowie einer guten Dokumentation können Sie selbst große Ausfälle in kurzer Zeit zielgerichtet kompensieren und die Umgebung wieder in Betrieb nehmen. Dabei hilft Ihnen nicht nur ein fundiertes Wissen über die genutzten Programme und Arbeitsweisen, sondern auch eine gute Dokumentation und ein Notfallhandbuch, in dem die Schritte und Abhängigkeiten dokumentiert sind.

Seite 2: Desaster-Recovery vorbereiten

Im ersten Teil des Workshops beschäftigten wir uns mit der Ausfallsicherheit von Servern, der Hochverfügbarkeit von Storage-Systemen und der Redundanz im Netzwerk. In der zweiten Folge gingen wir darauf ein, warum USV-Systeme Pflicht sind, wie Sie beim Storage auf IOPs und Latenz achten und warum Sie beim Monitoring auch Temperatur und Wasser erfassen sollten.

<< Vorherige Seite

Seite 2 von 2

jp/ln/Jan Kappen