Für Unternehmenssysteme mit Erwartungen, Anforderungen oder Verpflichtungen in Bezug auf die Verfügbarkeit ist ein klar definierter, umsetzbarer und gut getesteter Ansatz zur Sicherung und Notfallwiederherstellung (Disaster Recovery, DR) von entscheidender Bedeutung. Das Entwerfen einer Sicherungsstrategie oder eines Notfallwiederherstellungsansatzes erfordert, dass Organisationen zunächst das Ausmaß und die Abhängigkeiten ihrer Systeme verstehen, bevor sie die Ziele für die Wiederherstellung sorgfältig festlegen, die verfügbaren IT-Ressourcen verstehen und den Wiederherstellungsprozess vom Auslösen einer Sicherung oder einer Wiederherstellung bis hin zur Durchführbarkeit des Personalsupports und der Auswirkungen auf die Benutzer berücksichtigen.
Die Bedeutung oder Rolle von Sicherungen bezieht sich in erster Linie auf die Geschäftskritikalität eines Systems und darauf, welche Workflows es unterstützt und welche Daten welcher Kategorien dort gespeichert werden. Einige Systeme, wie z. B. ein Entwicklungsserver oder ein Server, der von einem kleinen Team verwendet wird, benötigen möglicherweise keine Sicherungsstrategie, während andere Systeme Sicherungs- und Notfallwiederherstellungsansätze in erster Linie verwenden, um die Prozesse zu testen und deren erfolgreiche Anwendung in einem Produktivsystem zu unterstützen.
Dieses Thema bietet einen Überblick über den Sicherungs- und Notfallwiederherstellungsprozess, einschließlich der Auswirkungen auf ArcGIS-Softwarekomponenten und der verfügbaren Optionen zur Unterstützung eines Sicherungs- oder Notfallwiederherstellungsansatzes für verschiedene ArcGIS-Anwendungen.
Der Prozess des Sicherns im Sinne des Anfertigens einer Sicherungskopie eines Systems, eines Datenelements oder einer Hardwarekomponente war für IT-Systeme schon immer wichtig. Während Sicherungen in der Vergangenheit in der Regel auf Speicherebene implementiert wurden, sind mit der Verbreitung von Cloud-Services mehrere neue Optionen in Bezug auf Sicherungen entstanden, vor allem die Notwendigkeit, in der Cloud gehostete Daten und SaaS-Systeme zu sichern, sowie neue Speicherorte und Anbieter, die zum Speichern von Sicherungen auf Datenebene verwendet werden können.
Zu den Überlegungen für Sicherungen gehört eine sorgfältige Definition der folgenden Punkte:
Darüber hinaus ist auch die Methode wichtig, mit der ein System aus einer Sicherung wiederhergestellt wird, sowie die Auswirkungen auf die Benutzer, die damit verbunden sind.
Da in der Vergangenheit nur die kritischsten Business-Systeme oder Geschäftsdaten zuverlässig gesichert wurden, hat sich der Umfang der Sicherungen auf die wichtigsten Systeme, Server oder Datenbanken konzentriert. Da die modernen Speicherkosten deutlich niedriger sind als in der Vergangenheit, hat sich der Umfang der Sicherungen drastisch ausgeweitet, und der Trend geht zu Sicherungen für das gesamte System, anstatt selektiv eine Anwendungskomponente oder Daten eines Typs zu sichern.
Die Methoden, die zum Erstellen von Sicherungen verwendet werden, können sehr unterschiedlich sein und reichen von anwendungsspezifischen Sicherungsformaten wie einer binären Datenbanksicherung zu VM-Images bis hin zu Sicherungen von Konfigurationen oder zu zusammengesetzten Sicherungen, die den Status einer Anwendung mit Daten und dem Anwendungscode selbst kombinieren können. Die Methode, die zum Erstellen von Sicherungen verwendet wird, kann auf die Zeit, die zum Erstellen einer Sicherung benötigt wird, auf die Häufigkeit, mit der sie ausgeführt werden kann, und auf die Art und Weise, in der sie wiederhergestellt wird, einen erheblichen Einfluss haben. Sicherungen können sich auch darin unterscheiden, wie sie erstellt werden und wie gut dabei der Zustand eines aktiven Systems erfasst wird. Für die Sicherungen, die in ArcGIS-Systemen in Betracht gezogen werden sollten, gibt es drei Haupttypen:
Die Häufigkeit, mit der ein System gesichert wird, und die Initiierungszeit, zu der diese Sicherungen erfolgen, sind ebenfalls wichtige Aspekte. Ein zu häufiges Sichern kann zu überhöhten Kosten oder zu vielen Systemunterbrechungen führen, während ein zu seltenes Sichern zu inakzeptablen Datenverlusten zwischen einem Ausfallereignis und der zuletzt durchgeführten Sicherung führen kann. Die meisten Sicherungen sind so konzipiert, dass eine Unterbrechung der Benutzer auf einer bestimmten Ebene vermieden wird. Der Zeitpunkt einer Sicherung kann sich aber darauf auswirken, welche Daten und Workflows in der Sicherung erfasst werden. In der Regel werden Sicherungen in den “Zeiten mit geringer Auslastung” eines Systems (falls vorhanden) erstellt, um die meisten Daten und Informationen des Vortages zu erfassen, und nicht inmitten eines Arbeitstages, an dem die Sicherung möglicherweise nur einen Teil eines längeren Prozesses oder eines größeren Datasets, an dem gerade aktiv gearbeitet wird, erfasst.
Der Grund, warum es einen Sicherungsprozess gibt, mag selbstverständlich erscheinen, z. B. um den Zustand eines Systems wiederherzustellen. Sicherungen werden zusätzlich aber für eine Vielzahl verschiedenster Anwendungsfälle eingesetzt. Einige Sicherungen sind an Upgrades eines Systems gebunden, damit das System wieder in einen bekannten Zustand versetzt werden kann, wenn ein Problem mit dem Upgrade entdeckt wird. Die gleiche Überlegung liegt Sicherungsprozessen zugrunde, die mit einer disruptiven Systemänderung verbunden sind, wie z. B. dem Entfernen eines Servers oder dem Hinzufügen einer neuen Komponente. Einige Sicherungen werden nur für das Worst-Case-Szenario erstellt, damit sie bei einem Notfall für die Wiederherstellung verwendet werden können. Andere werden verwendet, um als Snapshot den Zustand einer Umgebung zu erfassen und eine neue, “niedere” Umgebung als Kopie zu erstellen oder um Inhalte in die andere Richtung von einer niedrigeren Umgebung zu einem höheren System auf Produktionsebene zu befördern.
Notfallwiederherstellung oder DR (Disaster Recovery) ist ein Thema, das oft eng mit einem Sicherungs- und Wiederherstellungsprozess verbunden, aber nicht synonym ist. DR bezieht sich speziell auf die Frage, “was wir tun, um nach einer Katastrophe, also einem Notfall, alles wiederherzustellen”, auf den Prozess, den diese Wiederherstellung erfordern würde, und auf die Definition dessen, was “Katastrophe” und “Wiederherstellung” in einem organisationsspezifischen Kontext bedeuten. Katastrophen im Sinne von Notfällen beziehen sich in der Regel auf erhebliche Ausfälle von IT-Systemen, unabhängig davon, ob sie durch Hardware-, Umgebungs- oder Benutzerkonfigurationsprobleme verursacht werden, und die zu einer erheblichen Unterbrechung der Betriebszeit, Verfügbarkeit oder Funktionalität eines Systems führen.
Einer der ersten Schritte beim Einrichten eines DR-Prozesses ist die Frage, was eine “Katastrophe” darstellt, die einen Notfallwiederherstellungsprozess erfordert. Es ist wichtig, dies sorgfältig zu definieren, denn eine zu empfindliche Definition (z. B. eine fehlgeschlagene Anforderung an ein primäres System) kann zu häufigen DR-Failover-Aktionen führen, aber zu Warten, bis ein Ausfall länger als vier Stunden dauert, könnte dagegen zu tolerant sein und zu umfangreichen Benutzerunterbrechungen führen. Letztendlich erfordert die Definition, “was eine Katastrophe ausmacht”, damit ein System Maßnahmen ergreifen kann, um entweder eine Wiederherstellung oder ein Failover zu initiieren, sowohl eine automatisierte als auch eine von Menschen gesteuerte Entscheidungsfindung und stützt sich auf organisatorische Definitionen von Konzepten wie Verfügbarkeit, Kritikalität und Betriebszeit. Häufige Beispiele für einen DR-“Initiator” als Auslöser wären der Verlust des Zugriffs auf ein Rechenzentrum, Speicherfehler, VM-Hypervisor-Fehler, ein DNS-Ausfall oder ein Problem mit der Netzwerkverbindung und sogar Datenbeschädigung oder ein Ransomware-Angriff auf ein System.
Eine weitere wichtige Definition im DR-Prozess ist das Recovery Point Objective (RPO, Zielsetzung für Wiederherstellungspunkt) und das Recovery Time Objective (RTO, Zielsetzung für Wiederherstellungszeit) der Organisation. RPO entspricht der Menge an Daten, die wir in einem Katastrophenszenario verlieren, und bezieht sich auf die Art der Sicherungen, die erstellt werden, und die Häufigkeit, mit der Daten oder Konfigurationen gesichert werden. Ein RPO von vier Stunden würde bedeuten, dass im schlimmsten Fall vier Stunden an Daten oder Arbeit verloren gehen, wenn ein Ausfall auf DR-Ebene auftritt, und dass es die Organisation toleriert, diese 4 Stunden an Daten oder Eingaben in einem DR-Prozess möglicherweise zu verlieren. Während ein niedriges RPO ein naheliegender Ansatz zu sein scheint, bedeuten in den meisten Systemen die Komplexität der Sicherungen und das Potenzial der Benutzerunterbrechungen, dass ein niedriges RPO zu hohe Kosten für Ressourcen, Speicher oder Auswirkungen auf die Benutzer verursacht.
RTO bedeutet , wie lange es dauert, bis wir wieder verfügbar sind, und bezieht sich auf die Zeit, die benötigt wird, um zur Wiederherstellung nach einem Notfall die Sicherungen auf einem DR-System wiederherzustellen, ein neues System von Grund auf neu zu erstellen oder Ressourcen automatisch bereitzustellen. Das RTO ist oft niedriger als das RPO, da ein Failover-System oder Komponenten eines solchen Systems möglicherweise bereits vorhanden sind und die Möglichkeit, zu diesem System zu wechseln, nur eine DNS- oder Netzwerkänderung erfordert. Das Definieren und Erreichen eines realistischen RPO und RTO sind wichtige Bestandteile beim Entwickeln einer DR-Strategie und beim Einholen der Zustimmung der Projektbeteiligten zu den Auswirkungen auf Kosten und Workflows der Implementierung dieser Strategie.
Ein gängiger Ansatz für die Reaktion auf ein Notfallszenario besteht darin, Datenverkehr an ein Failover-System umzuleiten, das vorhanden ist, um Datenverkehr zu übernehmen, wenn in einem primären System Probleme identifiziert werden oder auftreten. Mit diesem Ansatz sind mehrere wichtige Anforderungen verbunden, die Auswirkungen auf Kosten und Workflows haben:
Ein weiterer DR-Ansatz besteht darin, Sicherungen zu verwenden, um ein System wiederherzustellen, was zu einem längeren RTO führen kann, aber die laufenden Kosten senkt, da nicht ständig ein Failover-System betrieben wird. Dies kann das Erstellen von VM-Sicherungen oder einer Sicherung auf Anwendungsebene und das anschließende Neuerstellen des Systems umfassen, entweder automatisch durch Infrastructure-as-Code und Softwarebereitstellungsautomatisierung oder manuell mit einem erfahrenen Team, bevor die Sicherung wiederhergestellt wird, der Datenverkehr wieder auf das System umgeschaltet wird und die Benutzer die Workloads im System fortsetzen können.
DR-Prozesse können auch umfassendere Auswirkungen haben oder Ansätze verfolgen, die nicht nur für das mit ArcGIS erstellte Unternehmenssystem gelten. Beispielsweise kann für ein gesamtes Rechenzentrum eine DR-Strategie gelten, die die VM-Replikation verwendet, um eine Gruppe bestimmter VMs in einem separaten Rechenzentrum zu verwalten. Wenn in diesem Fall ein Ausfall bei einer Speicher- oder Hypervisor-Komponente festgestellt wird, können alle Benutzer auf den Zugriff auf das sekundäre Rechenzentrum umschalten.
DR-Prozesse müssen auch berücksichtigen, was nach einer Wiederherstellung geschieht. Wenn ein primäres System oder Rechenzentrum vorhanden ist und ein DR-Ereignis zu einem Failover auf ein sekundäres System führt, ist es dann der Standardansatz, nach der Behebung des Ausfalls den Datenverkehr wieder auf das primäre System umzuschalten? Oder wird das Standby-System jetzt zum primären System und das ursprüngliche System als Standby-System eingerichtet, um die nächste DR-Situation zu unterstützen? Beide Szenarien sind wertvoll, und die Definition, was nach der Behebung des Vorfalls geschieht, ist ein wichtiger Bestandteil der DR-Strategie und des DR-Ansatzes.
In ArcGIS-Systemen gibt es mehrere Ansätze zum Initiieren eines Sicherungsprozesses, die in die ArcGIS-Software integriert sind. Sicherungen einzelner Komponenten, bei denen nur der Inhalt und der Zustand einer einzelnen Anwendung gesichert werden, sind für ArcGIS Enterprise-Komponenten verfügbar, zum Beispiel für Portal for ArcGIS, ArcGIS Server und ArcGIS Data Store. Diese komponentenspezifischen Sicherungen sind nicht in erster Linie für DR-Zwecke vorgesehen, sondern dienen der Sicherung und Wiederherstellung an Ort und Stelle. Für DR-Zwecke wird das Werkzeug WebGISDR empfohlen. Für jede Komponente gilt ein anderer Sicherungsansatz, zum Beispiel:
Einige ArcGIS Server-Rollen sind in der Regel zustandslos, d. h. alle relevanten Konfigurationen werden als Portal-Elemente gespeichert und müssen in der Regel nicht gesichert werden. Dazu gehören Notebook Server, Business Analyst Enterprise Server (GeoEnrichment Server) und Raster Analytics Server. Jede dieser Komponenten kann in der Regel auf einem leeren Computer oder einem installierten Image neu erstellt werden, anstatt die spezifische Bereitstellung wiederherzustellen, da der Inhalt in ArcGIS Enterprise gespeichert wird. Darüber hinaus gehen nur Szenarien, in denen benutzerdefinierter Code oder Bibliotheken von Drittanbietern auf dem System bereitgestellt wurden, um einen Python-basierten Workflow oder einen anderen Prozess zu ermöglichen.
Neben der Funktionalität zur komponentenspezifischen Sicherung verfügt ArcGIS Enterprise auch über ein Werkzeug für die Sicherung mehrerer Komponenten mit dem Namen “Web GIS Disaster Recovery” (kurz WebGISDR), mit dem der Zustand mehrerer verschiedener ArcGIS Enterprise-Komponenten gleichzeitig gesichert werden kann.
Das Werkzeug “WebGISDR” wird in der ArcGIS Enterprise-Dokumentation ausführlich beschrieben. Es ist jedoch wichtig zu beachten, dass bei diesem Werkzeug die Konsistenz und der Zustand der Anwendung Vorrang vor der Geschwindigkeit der Sicherung oder der Flexibilität des Prozesses haben. In der Praxis bedeutet dies, dass das Werkzeug versucht, den Zustand des Systems genau zu dem Zeitpunkt zu erfassen, zu dem die Anforderung ausgeführt wurde. Wenn während der Sicherung weitere Inhalte oder Daten veröffentlicht werden, dann sind diese in keiner der Sicherungsdateien enthalten und können nicht auf einem Failover-System wiederhergestellt werden. Dieser Fokus ist gleichbedeutend mit einem Fokus auf RPO anstelle von RTO. Dabei wird die funktionale Vollständigkeit eines Systems über die Schnelligkeit der Wiederherstellung des Systems gestellt (was möglicherweise zu Fehlkonfigurationen oder fehlerhaften Daten führt).
Neben anwendungsspezifischen ArcGIS-Sicherungen gibt es eine Vielzahl anderer Methoden, die von einer Organisation vorgeschlagen oder bevorzugt werden können und die für eine bestimmte Komponente oder einen Infrastrukturanbieter nativ sein können. Diese Methoden können für eine ArcGIS-Sicherung oder einen Notfallwiederherstellungsprozess geeignet sein, sollten jedoch sorgfältig geprüft und abgewogen werden, da ihre Verwendung auch zu Unterbrechungen bei einem System führen kann.
VM-Snapshots sind z. B. ein gängiger Ansatz zum Sichern eines Systems, können jedoch zu komplizierten Herausforderungen führen, wenn die Methode für den Snapshot einen plötzlichen Neustart der Maschine oder nur die Erfassung des Zustands der Daten umfasst, da in Bearbeitung befindliche Operationen oder Konfigurationen möglicherweise nicht oder nur teilweise erfasst werden, was zu einem unerwarteten Zustand mit Datenbeschädigungen führen kann, wenn eine Wiederherstellung erfolgt.
VM-basierte Sicherungsstrategien verschieben manchmal VM-Ressourcen zwischen zwei Datenquellen, um einen Ausfall zu verhindern. In diesen Szenarien müssen Sie sicherstellen, dass die ArcGIS Server- und ArcGIS Pro-Hosts auf eine Datenbank in ihrem eigenen Rechenzentrum zugreifen und keine Anforderungen an das ursprüngliche Rechenzentrum senden, da dies zu Latenzzeiten führt, die sich negativ auf die User Experience auswirken.
Cloud-basierte Werkzeuge für die Sicherung und Notfallwiederherstellung, wie z. B. Microsoft Azure Site Recovery, können mit ArcGIS Enterprise-Systemen kompatibel sein, wenn sie sorgfältig so geplant werden, dass die DNS-Auflösung, die Datenbankkonnektivität und die Clientkonnektivität mit dem System im Falle einer Operation zur Wiederherstellung einer Site erhalten bleiben. Diese Sicherungsansätze arbeiten auf einer relativ niedrigen Ebene des Zugriffs auf virtuelle Maschinen und bieten daher keine Garantien für die Anwendungskonsistenz. Dies bedeutet, dass das Wiederherstellungssystem zwar häufig erfolgreich wiederhergestellt und betrieben wird, in einigen Fällen jedoch Inkonsistenzen auf Anwendungsebene auftreten können, z. B. bei einem laufenden Veröffentlichungsprozess oder einer Bearbeitung eines Feature-Service während des Sicherungsprozesses. Es gibt zwar Möglichkeiten, dies zu planen, wie z. B. das Erstellen von VM-Snapshots außerhalb der Spitzenzeiten, aber im Allgemeinen gilt die Anleitung zum “Planen, Testen und sorgfältigen Abwägen der Auswirkungen” für diese Ansätze mit externen Werkzeugen.
Datenbankanbieter, die relationale Datenbanken erstellen, mit denen ArcGIS arbeitet (entweder als Enterprise-Geodatabase oder als Quelle eines Abfrage-Layers), stellen ihre eigenen datenbankspezifischen Sicherungsoptionen bereit, mit denen in der Regel eine dateibasierte Sicherung der Inhalte und Konfigurationen der Datenbanken erstellt werden kann, um sie bei Bedarf auf einem neuen System wiederherzustellen oder bereitzustellen.
Bei ArcGIS Online als SaaS-Angebot und -System muss aus der Perspektive der Sicherung und Wiederherstellung ein anderer Ansatz verfolgt werden. Im Rahmen der Systemstabilität übernimmt Esri die Sicherungs- und Wiederherstellungsanforderungen für Ausfälle auf Hardware- und Systemebene ohne Benutzereingaben, und das Service Level Agreement für ArcGIS Online spiegelt diese Verpflichtung wider. ArcGIS Online bietet derzeit keine Methode zum Erstellen von organisationsweiten Sicherungen oder Inhaltssicherungen durch Benutzer, und Organisationen müssen eine Strategie für ihre eigenen, zusätzlichen Sicherungen von Inhalten oder Konfigurationen in ArcGIS Online anhand einer Vielzahl von Mustern definieren, wie zum Beispiel:
Beachten Sie, dass Esri Partner auch Sicherungslösungen erstellt haben, die über den ArcGIS Marketplace überprüft oder erworben werden können.
ArcGIS Online hat kürzlich die Funktion “Papierkorb” eingeführt, mit der gelöschte Inhalte für einen Zeitraum von (standardmäßig) 14 Tagen gespeichert werden, bevor sie endgültig gelöscht werden. Inhalte im Papierkorb können mit einem einfachen Workflow in ihrem vorherigen Status am vorherigen Speicherort wiederhergestellt werden. Dies wird dazu beitragen, die Löschung von Inhalten zu verhindern, die mit anderen Inhalten verknüpft sind, aber nicht eindeutig gekennzeichnet sind, dass andere Inhalte auf sie angewiesen sind oder sie selbst auf diese anderen Inhalte angewiesen sind.
Verwenden Sie für grundlegende gehostete Feature-Service-Daten die Funktion Änderungsverfolgung zum Speichern vorheriger Zeileninhalte, während Änderungen vorgenommen werden. Auf diese früheren Versionen kann über die Operation Extract Changes zugegriffen werden.