Skip To Content

Options to prevent data loss and downtime

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.
You can use one or a combination of options. When deciding which to use, take into consideration the following factors:
  • 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 downtimeAcceptable data lossResources requiredGeographic 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 downtimeAcceptable data lossResources requiredGeographic 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 downtimeAcceptable data lossResources requiredGeographic 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.