Synchron oder Asynchron: Backup und Replikation im Vergleich
Erfahren Sie hier, ob eine Replikation das Backup ersetzen kann oder sich beides kombinieren lässt, und was die Vor- und Nachteile der synchronen und asynchronen Sicherung sind.
Backups, Snapshots, Klonen und Replikation sind allesamt wertvolle Methoden zum Schutz der Daten der Organisation.
In diesem Artikel werden wir uns mit der Replikation befassen, insbesondere zwischen Speicher-Arrays. Sie finden hier eine Definition des Begriffs sowie die Vor- und Nachteile der Replikation mit Bezug auf andere Methoden der Datensicherung.
Der Beitrag soll Klarheit über verschiedene Technologien liefern und erklären, ob und wie sie zusammenpassen.
Replikation vs. Snapshots
Die Replikation ist im Grunde eine Methode zur Herstellung eines Klons einer Speichereinheit. Mit anderen Worten, es handelt sich beispielsweise um eine Replik eines Laufwerks, Volumes oder einer Logical Unit Number (LUN). In den meisten Fällen wird eine exakte Kopie angestrebt. Oft wird diese sofort bei der Datenerstellung, in anderen Fällen mit Zeitverzögerung angelegt.
Dadurch unterscheidet sich ein Klon oder eine Replik von einem Snapshot, denn Schnapshots können in den meisten Fällen erst nach einem gewissen Wiederherstellungs-Prozess zu einer brauchbaren Replik werden. Der Grund dafür ist, dass die Snapshots aus einer Originalkopie des Laufwerks oder Volumes plus Aktualisierungen sowie eventuell gelöschten Blöcken bestehen, die wieder eingefügt werden müssen, um eine genaue Kopie eines früheren Zeitpunkts zu erstellen.
Die Idee dahinter ist, dass Snapshots ziemlich schnell neu erstellt und wiederhergestellt werden können, aber sie sind nicht als alternative, brauchbare Kopie des Quellmediums vorhanden. Dies wird von Klonen und Replikaten gewährleistet.
Der einfachste Klon ist, wenn ein Entwickler zum Beispiel eine Datenbank benötigt, auf der er einige Testabfragen durchführen kann. Er kann eine exakte Kopie einer bestehenden Produktionsdatenbank klonen (oder replizieren) und in der Testumgebung damit machen, was er will. Dieser Klon wird eine exakte Replik der Datenbank zum Zeitpunkt ihrer Erstellung sein, aber er spiegelt keine weitere Änderungen an der Quellkopie wider.
Am anderen Ende der Skala in Bezug auf die Erstellung eines verfügbaren, funktionierenden Klons steht jedoch die synchrone Replikation. Dabei werden die Daten in zwei oder mehr Speichereinheiten so weit wie möglich gleichzeitig geschrieben, um eine Arbeitskopie zu erstellen, die sofort für ein Failover genutzt werden kann.
Natürlich hat dies seinen Preis, was die Kosten und die technische Komplexität betrifft, und es gibt Grenzen, wie wir sehen werden. Aber das ist es oft, was wir meinen, wenn wir über Replikation sprechen.
Replikation vs. Backup
Kann Replikation Backups ersetzen? Die einfache Antwort ist nein. Backups und Replikation (und vielleicht auch Snapshots) müssen sich gegenseitig ergänzen.
Da die Replikation fast kontinuierlich erfolgen kann und eine nahezu in Echtzeit erstellte Kopie anlegt, kann sie auch eine Replik beschädigter oder infizierter Dateien erstellen. In diesem Fall benötigen Sie eine Version, auf die Sie ihre Daten zurücksetzen können.
Das könnte aus einem Snapshot abgeleitet werden, aber dann müssen sie auch durch Backups untermauert werden – und die Replikation ist oft kostspielig, so dass es sein kann, dass nur bestimmte Datensätze repliziert werden, während im Backup alle Daten gesichert sind.
Synchrone vs. asynchrone Array-Replikation
Bei der synchronen Replikation können Daten auf die zweite Site (IT-Standort) geschrieben werden, sobald sie in den Cache der primären Site gelangen. Beim Empfang sendet die zweite Site eine Bestätigung an den Speicher der primären Site und an den Host, von dem die Änderung stammt. Es ist die Replikationsmethode, die dem gleichzeitigen Schreiben mehrerer Datenkopien so nahe wie möglich kommt.
Die synchrone Replikation ist oft die Domäne der hochwertigsten und teuren Blockspeicher-Arrays.
Die asynchrone Replikation fügt dem Prozess eine Stufe hinzu, indem der Host am Primärstandort beim Schreiben der Daten bestätigt wird. Dann wird der Schreibvorgang an den zweiten Standort gesendet, der das Zurückschreiben an das Array am Primärstandort bestätigt. Die asynchrone Replikation findet sich in einer breiteren Palette von Speicherprodukten, wie zum Beispiel iSCSI-Speicher oder Network Attached Storage (NAS).
Die Replikation über große Entfernungen beginnt unter einer Latenzzeit von etwa einer Millisekunde pro 100 Meilen zu leiden, und die Anbieter empfehlen oft nicht mehr als ein paar hundert Meilen für Hin- und Rückweg anzusetzen.
Aus diesem Grund kann sich die synchrone Replikation stärker auf die Anwendungsleistung auswirken. Sie erfordert eine Bestätigung bevor die nächste Ein-/Ausgabe (E/A, Input/Output, I/O) stattfinden kann, während die asynchrone Replikation lokal bestätigt, so dass die nächste Änderung stattfinden kann, wobei die Bewegung der Daten verzögert wird. Das bedeutet natürlich auch, dass sich die beiden Datensätze über einen längeren Zeitraum unterscheiden werden.
Eine Replikationsstrategie für die reale Welt könnte eine Kombination aus synchroner Replikation - für die kritischsten Elemente einer Anwendung wie Redo-Logs - verwenden, während weniger kritische Daten, die wiederhergestellt werden könnten, über die asynchrone Replikation gehen. Snapshots könnten ebenfalls Teil der Kombination sein, aber das Ganze müsste durch regelmäßige Backups verstärkt werden.
Host-, Hypervisor- und Cloud-Replikation
Hier haben wir uns vor allem mit der synchronen und asynchronen Replikation in Speicher-Arrays befasst.
Es gibt noch andere Formen der Replikation, wie beispielsweise:
- Host-Replikation – zwischen Servern, vielleicht von einzelnen Anwendungen, Datenbanken oder dem gesamten Server.
- Hypervisor-Replikation – Replikation, die auf Hypervisor-Ebene verwaltet wird und aus ihren Elementen, wie unter anderem einzelnen virtuellen Maschinen (VMs), und virtuellem Speicher besteht.
- Cloud-Replikation – Dies kann eine Replikation in die Cloud oder mehrere Clouds als Ziel oder zwischen Clouds sein.
- Geo-Replikation – Hier werden Daten an mehreren entfernten Standorten gespeichert, die möglicherweise sehr weit voneinander entfernt sind. Dies kann aus Gründen das Disaster Recovery (Notfallwiederherstellung) oder zur Verbesserung der Verfügbarkeit geschehen. Die Replikation über solch große Entfernungen ist wahrscheinlich nicht synchron.
