ArcGIS Enterprise Backup Strategy: Is WebGIS DR Still Practical at Scale?

ZentraleTechnik

I'm interested in understanding how other ArcGIS Enterprise administrators are handling backup and disaster recovery in real-world deployments.

Over the years, we've repeatedly encountered challenges with WebGIS DR backups:

• Backup creation can take many hours or even days.
• Large environments can produce backup files approaching or exceeding hundreds of gigabytes.
• Backup jobs occasionally fail or timeout, requiring manual intervention.
• Recovery testing is often time-consuming and operationally complex.
• As environments continue to grow, backup windows become increasingly difficult to maintain.

In our case, WebGIS DR backups can take up to 16 hours for roughly 900 GB of data, making it difficult to perform backups frequently enough to meet recovery objectives.

What makes this particularly challenging is that Esri documentation and support interactions consistently position WebGIS DR as the officially supported backup and recovery mechanism for ArcGIS Enterprise.

At the same time, most organizations are already using mature cloud-native backup capabilities provided by Azure, AWS, GCP, VMware, storage platforms, or other infrastructure-level solutions. These technologies typically offer:

• Faster backup execution
• Incremental backups
• Snapshot-based recovery
• Proven disaster recovery workflows
• Lower operational overhead

This raises an honest question:

What practical advantage does WebGIS DR provide over infrastructure-level backup solutions, especially in larger Enterprise deployments?

Our own disaster recovery exercises have primarily relied on infrastructure backups in combination with documented recovery procedures. While WebGIS DR remains part of the overall strategy, it is increasingly becoming the slowest, most resource-intensive, and least flexible component of the backup process.

Questions for the community

1. Are you still using WebGIS DR as your primary disaster recovery mechanism?
2. Do you combine WebGIS DR with cloud-native backups (Azure Backup, AWS Backup, snapshots, VMware snapshots, etc.)?
3. If so, which solution do you actually trust most in a real disaster recovery scenario?
4. Has anyone moved away entirely from regular WebGIS DR backups and instead relies primarily on infrastructure-level backups?
5. Have you discussed such an approach with Esri Support, and if so, what guidance did you receive?
6. Are there organizations successfully running very large Enterprise environments where WebGIS DR remains practical?

I'm not looking for troubleshooting advice for a specific deployment.

Rather, I'm interested in understanding whether there is a growing gap between the official recommendation to use WebGIS DR and what organizations are actually doing operationally in production.

I'd be very interested to hear how others have approached this challenge.

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.