A web GIS provides your organization with a way to create and share geographic information, maps, and applications and the ability to perform geographic analyses. As part of your overall data infrastructure, you want your web GIS deployment to be available to your users as much as possible, with minimal data loss in the event of a disaster. To ensure your deployment is available when users need it, you need to implement a disaster recovery or failover strategy. Options include the following:
- Maintain backups of your web GIS deployment so you can restore it when a disaster occurs.
- Implement a replicated web GIS for disaster recovery.
- Configure a highly available system.
- How much downtime (if any) can your organization tolerate?
- How much data loss (if any) is acceptable?
- How many resources, such as hardware, licensing, and staff, can your organization devote to data loss and downtime prevention?
- Does your organization require deploying in two separate geographic locations? For example, do you need to duplicate your web GIS in two geographically separate data centers so it is available even when a natural disaster occurs in one area?
Restore web GIS backups
If your organization can tolerate some amount of downtime and data loss, you can create backups of your web GIS and restore the backups in the event of a failure or corruption. For example, if one of the machines in your web GIS deployment fails or if someone mistakenly deletes a large number of items from the portal, services from your ArcGIS Server, or data used by your web GIS, you can restore the deployment. The amount of downtime and data loss you incur depends on how frequently you create backups and how much data, items, and services you have in your web GIS; as the amount increases, so does the time to restore.
| Acceptable downtime | Acceptable data loss | Resources required | Geographic redundancy required? | Strategy to use |
|---|---|---|---|---|
Approximately 1 day | Approximately 1 day | Low Requires hardware for single web GIS (1+ machines), media to store backups, development and testing of recovery plan | No | Implement a single web GIS deployment, create backups daily using the webgisdr utility, and maintain the backups in a secure location. |
Approximately 1.5 hours | Approximately 1 hour | Low Requires hardware for single web GIS (1+ machines), media to store backups, development and testing of recovery plan | No | Implement a single web GIS deployment, create backups hourly using the webgisdr utility, maintain backups in a secure location, and actively monitor the deployment. |
For more information, see Web GIS backups.
Maintain a replicated deployment
If your tolerance for downtime is less and you have sufficient machines to use, you can configure a primary web GIS deployment and an identical, isolated standby deployment. Use the webgisdr utility to export from the primary, move the exported file to the isolated standby deployment, and import.
You can set up your primary and standby deployments in the same or different geographic locations. When the primary and standby are in different geographic locations, the time to complete the replication process will likely increase, but you protect your deployment from regional disasters.
| Acceptable downtime | Acceptable data loss | Resources required | Geographic redundancy required? | Strategy to use |
|---|---|---|---|---|
Approximately 1.5 hours | Approximately 1 day | Medium Requires hardware for two web GIS deployments (2+ machines), method and staff to move exports from primary to standby, development and testing of recovery plan | No | Configure both a primary and standby deployment, use the webgisdr utility to replicate the deployment from the primary to the standby once a day, and actively monitor the primary deployment. |
Approximately 1.5 hours | Approximately 1 hour | Medium Requires hardware for two web GIS deployments (2+ machines), method and staff to move exports from primary to standby, development and testing of recovery plan | No | Configure primary and standby deployments, use the webgisdr utility to replicate the deployment from the primary to the standby every hour, and actively monitor the primary deployment. |
Approximately 1.5 to 2 hours | Approximately 1 hour | Medium Requires hardware for two web GIS deployments (2+ machines), method and staff to move exports from primary to remote standby, development and testing of recovery plan | Yes | Configure primary and remote standby deployments, use the webgisdr utility to replicate the deployment from the primary to a remote standby every hour, and actively monitor the deployment. |
For more information, see Disaster recovery and replication.
Configure a highly available web GIS
If your web GIS needs to be available 99.9 percent or more of the time, you cannot tolerate the loss of more than an hour's worth of data, and you can devote a large number of resources, you can implement a highly available web GIS deployment. In this case, you configure connected primary and standby deployments that automatically failover in the event of the failure of any one component.
You can use a highly available web GIS deployment in combination with a replicated deployment if you require geographic redundancy.
| Acceptable downtime | Acceptable data loss | Resources required | Geographic redundancy required? | Strategy to use |
|---|---|---|---|---|
A few minutes | A few minutes | High Requires hardware and licensing for two web GIS deployments (7+ machines) | No | Configure connected primary and standby deployments. |
A few minutes to approximately 1 hour, depending on nature of deployment failure | Approximately 1 hour | High Requires hardware and licensing for two web GIS deployments (14+ machines) | Yes | Configure connected primary and standby deployments and use the webgisdr utility to replicate hourly to an identical primary and standby deployment in another location. |
For more information, see Highly available web GIS.