Estrategia de Respaldo de ArcGIS Enterprise: ¿Sigue siendo práctico WebGIS DR a gran escala?

ZentraleTechnik

Estoy interesado en entender cómo otros administradores de ArcGIS Enterprise están manejando el respaldo y la recuperación ante desastres en implementaciones reales.

A lo largo de los años, hemos encontrado repetidamente desafíos con los respaldos de WebGIS DR:

• La creación del respaldo puede tomar muchas horas o incluso días.
• Los entornos grandes pueden producir archivos de respaldo que se acercan o superan cientos de gigabytes.
• Los trabajos de respaldo ocasionalmente fallan o se agotan, requiriendo intervención manual.
• Las pruebas de recuperación suelen ser lentas y operativamente complejas.
• A medida que los entornos continúan creciendo, las ventanas de respaldo se vuelven cada vez más difíciles de mantener.

En nuestro caso, los respaldos de WebGIS DR pueden tomar hasta 16 horas para aproximadamente 900 GB de datos, lo que dificulta realizar respaldos con la frecuencia suficiente para cumplir con los objetivos de recuperación.

Lo que hace esto particularmente desafiante es que la documentación y las interacciones con soporte de Esri consistentemente posicionan WebGIS DR como el mecanismo oficialmente soportado para respaldo y recuperación de ArcGIS Enterprise.

Al mismo tiempo, la mayoría de las organizaciones ya están utilizando capacidades maduras de respaldo nativas en la nube proporcionadas por Azure, AWS, GCP, VMware, plataformas de almacenamiento u otras soluciones a nivel de infraestructura. Estas tecnologías típicamente ofrecen:

• Ejecución más rápida del respaldo
• Respaldos incrementales
• Recuperación basada en snapshots
• Flujos de trabajo probados para recuperación ante desastres
• Menor carga operativa

Esto plantea una pregunta honesta:

¿Qué ventaja práctica ofrece WebGIS DR sobre las soluciones de respaldo a nivel de infraestructura, especialmente en implementaciones Enterprise más grandes?

Nuestros propios ejercicios de recuperación ante desastres se han basado principalmente en respaldos a nivel de infraestructura combinados con procedimientos documentados de recuperación. Aunque WebGIS DR sigue siendo parte de la estrategia general, cada vez se está convirtiendo en el componente más lento, que consume más recursos y menos flexible del proceso de respaldo.

Preguntas para la comunidad

1. ¿Siguen usando WebGIS DR como su mecanismo principal de recuperación ante desastres?
2. ¿Combinan WebGIS DR con respaldos nativos en la nube (Azure Backup, AWS Backup, snapshots, VMware snapshots, etc.)?
3. Si es así, ¿en qué solución confían más realmente en un escenario real de recuperación ante desastres?
4. ¿Alguien ha dejado completamente los respaldos regulares de WebGIS DR y confía principalmente en respaldos a nivel de infraestructura?
5. ¿Han discutido este enfoque con Soporte Esri y, si es así, qué orientación recibieron?
6. ¿Existen organizaciones que ejecutan exitosamente entornos Enterprise muy grandes donde WebGIS DR sigue siendo práctico?

No estoy buscando consejos para solucionar problemas en una implementación específica.

Más bien, estoy interesado en entender si existe una brecha creciente entre la recomendación oficial de usar WebGIS DR y lo que las organizaciones están haciendo realmente operativamente en producción.

Me interesaría mucho saber cómo otros han abordado este desafío.

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.