ArcGIS Enterprise Backup-Strategie: Ist WebGIS DR bei großem Maßstab noch praktikabel?

ZentraleTechnik

Ich möchte verstehen, wie andere ArcGIS Enterprise-Administratoren Backup und Disaster Recovery in realen Einsätzen handhaben.

Im Laufe der Jahre sind wir wiederholt auf Herausforderungen mit WebGIS DR-Backups gestoßen:

• Die Erstellung von Backups kann viele Stunden oder sogar Tage dauern.
• Große Umgebungen können Backup-Dateien erzeugen, die hunderte Gigabyte erreichen oder überschreiten.
• Backup-Jobs schlagen gelegentlich fehl oder laufen zeitlich ab, was manuelles Eingreifen erfordert.
• Recovery-Tests sind oft zeitaufwendig und betrieblich komplex.
• Da die Umgebungen weiter wachsen, werden Backup-Fenster zunehmend schwerer einzuhalten.

In unserem Fall können WebGIS DR-Backups bis zu 16 Stunden für etwa 900 GB Daten dauern, was es schwierig macht, Backups häufig genug durchzuführen, um Wiederherstellungsziele zu erfüllen.

Was dies besonders herausfordernd macht, ist, dass Esri-Dokumentation und Support-Interaktionen WebGIS DR konsequent als offiziell unterstützten Backup- und Wiederherstellungsmechanismus für ArcGIS Enterprise positionieren.

Gleichzeitig nutzen die meisten Organisationen bereits ausgereifte cloud-native Backup-Funktionen, die von Azure, AWS, GCP, VMware, Speicherplattformen oder anderen Infrastruktur-Lösungen bereitgestellt werden. Diese Technologien bieten typischerweise:

• Schnellere Backup-Ausführung
• Inkrementelle Backups
• Snapshot-basierte Wiederherstellung
• Bewährte Disaster-Recovery-Workflows
• Geringeren betrieblichen Aufwand

Dies wirft eine ehrliche Frage auf:

Welchen praktischen Vorteil bietet WebGIS DR gegenüber Infrastruktur-Backup-Lösungen, insbesondere bei größeren Enterprise-Einsätzen?

Unsere eigenen Disaster-Recovery-Übungen haben sich hauptsächlich auf Infrastruktur-Backups in Kombination mit dokumentierten Wiederherstellungsverfahren gestützt. Während WebGIS DR weiterhin Teil der Gesamtstrategie ist, wird es zunehmend zur langsamsten, ressourcenintensivsten und am wenigsten flexiblen Komponente des Backup-Prozesses.

Fragen an die Community

1. Verwenden Sie WebGIS DR noch als primären Mechanismus für Disaster Recovery?
2. Kombinieren Sie WebGIS DR mit cloud-nativen Backups (Azure Backup, AWS Backup, Snapshots, VMware-Snapshots usw.)?
3. Wenn ja, welcher Lösung vertrauen Sie in einem echten Disaster-Recovery-Szenario am meisten?
4. Hat jemand vollständig von regelmäßigen WebGIS DR-Backups Abstand genommen und verlässt sich stattdessen hauptsächlich auf Infrastruktur-Backups?
5. Haben Sie einen solchen Ansatz mit dem Esri Support besprochen und wenn ja, welche Empfehlungen haben Sie erhalten?
6. Gibt es Organisationen, die sehr große Enterprise-Umgebungen erfolgreich betreiben, in denen WebGIS DR weiterhin praktikabel ist?

Ich suche keinen Troubleshooting-Rat für eine spezifische Implementierung.

Vielmehr interessiert mich zu verstehen, ob es eine wachsende Kluft zwischen der offiziellen Empfehlung zur Nutzung von WebGIS DR und dem tatsächlichen operativen Vorgehen der Organisationen in der Produktion gibt.

Ich wäre sehr daran interessiert zu hören, wie andere diese Herausforderung angegangen sind.

ryanuthoff

We're pretty much in the same situation as your described, so I'll try and answer your questions.

1. No, we stopped using WebGISDR.
2. We just use AWS snapshots. Not only does AWS take just minutes to backup (compared to hours for WebGISDR), it only takes minutes to restore (again, compared to hours for WebGISDR).
3. I trust AWS's backups more than the WebGISDR. We had a scenario where we needed to do a WebGISDR backup and restore to an isolated test environment to troubleshoot an issue. The restore of the WebGISDR failed due to a known Esri bug (which was eventually fixed by Esri). If this would have been a real-world DR situation, we could have lost everything due to the inability to restore from a backup. It was an incredibly dangerous bug for organizations that solely relied on WebGISDR.
4. As the answers above indicate, we moved to AWS backups.
5. I indirectly discussed this approach with Esri when we encountered the WebGISDR bug. The only guidance was to wait for the bug fix to be released.
6. I can't answer that one since we don't really use WebGISDR.

As I mentioned above, WebGISDR can still be useful for non-DR scenarios, such as doing a restore to an isolated test environment to troubleshoot an issue. Or perhaps machine migrations as well. But for just doing general backups, doing it at the AWS level is much more simpler, reliable, and faster.