In ArcGIS Enterprise on Kubernetes, you can back up your ArcGIS Enterprise organization and subsequently restore it to avoid data loss and downtime. In the event of a failure, you can restore the most recent backup to recover the organization to the point in time when the backup was created. When restoring a backup to a newly deployed organization, the following settings must be identical across the source and target environments:
- Version of the organization
- Fully Qualified Domain Name (FQDN) and Context Path (that is, https://dnsalias.domain.com/context)
- Registry Host and Repo (that is, docker.io and esridocker)
- Kubernetes Namespace (that is, arcgis)
- Kubernetes Cluster Domain (that is, cluster.local)
- Kubernetes Service DNS Suffix (that is, svc.cluster.local)
- FSGroup and Supplemental Group ID (if deployed using a custom value)
Note:
These settings were specified during deployment.
As an administrator, you must provide a persistent volume (PV) to store the backup files. When the organization is backed up, the backup files are stored to this PV. This PV lists the available backups, and you can restore any of the backup files that are stored in that backup store from the same release as the running deployment.
The following support PVs:
- Block storage devices, such as an EBS volume or Azure disk
- File storage, such as Azure files
- Amazon Elastic File System
- A Network File System (NFS) share provisioned in your organization
For the backup store to bind to an existing PV, the access mode must be set to ReadWriteOnce. For dynamically provisioned PVs, set the reclaim policy to Retain to facilitate out-place restores. The hosted backup store type only allows connections from one backup store to the underlying object store.
Backups can be created either manually or automatically through a one-off or a recurring backup schedule using ArcGIS Enterprise Manager.
To determine how often you need to create backups, first identify the amount of data loss your organization can withstand in the event of a failure. For example, if your organization can withstand a day's worth of data loss, you'll need to back up the organization daily.
The amount of time it takes to create or restore a backup as well as the size of a backup depends on a variety of factors, such as the number of items in the organization, the number of web layers, the size of the associated data, and the specifics of where the backups are stored. Testing the restore process will give you an idea of how long the process will generally take and also allow you to practice your disaster recovery plan.
Backup configuration
Before you can create a backup of an organization, you need to define a staging location and register a backup store for the deployment. During the registration of the backup store, you can either bind to an existing PV using label selectors or dynamically provision a new PV using a storage class. The backup store creates a persistent volume claim (PVC) that binds to the PV as part of the registration process. You can also register multiple backup stores using different storage classes or provisioning methods.
You can create a backup using ArcGIS Enterprise Manager. When a backup is created, the following data is backed up:
- Hosted geospatial data
- Organizational items and content
- Server configuration store
- System configuration properties
- Optionally, spatiotemporal feature layer data
In ArcGIS Enterprise on Kubernetes, each backup is time stamped and configured as a full backup of the organization. Data outside of the Kubernetes environment, such as in an enterprise geodatabase or elsewhere in your file system, is not backed up. Back up this data based on the recommendations of your database vendor or your IT department.
It is recommended that you perform routine backups to prevent data loss. You must also create a backup before installing software updates or upgrading to a new release.
Before creating a backup, you must register a staging location and a backup store.
Valid and invalid backups
A valid backup is one that was created successfully and is compatible with your organization's current state.
By default, the Backups page shows all backups, including those that are invalid and cannot be used to restore your organization. To view only valid backups, enable the Show only valid backups toggle button.
A backup may be considered invalid for the following reasons:
- Failed backup—The backup process may have failed due to issues such as insufficient storage.
- Version mismatch—Backups created at a different release cannot be used to restore your organization at its current version.
- Incompatible relational store—If your relational store was migrated to a cloud service, backups created prior to the migration cannot be used to restore your organization after the migration.