Back up and restore

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:

• 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 stored in the system data stores:

• Hosted geospatial data
• Organizational items and content
• Server configuration store
• System configuration properties

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 do the following:

• Register a staging location.
• Register a backup store.

Register a staging location and a backup store

Each component in an organization is initially backed up separately during the backup process. Since the size of the staged files and folders may be large, you must first configure a staging location and ensure that there is enough storage space for them. The staging location uses a PV to temporarily store each backup before they are moved to the backup store.

Because the staging location is used for temporary data, you must use a storage class with dynamically provisioned PVs.

Note:

If the original organization where the backup was created is no longer accessible, there are specific steps you'll need to follow to register a backup store and retrieve your existing backups. For more information, see Restore a backup when the original organization is not accessible.

To register a staging location and a backup store, complete the following steps:

1. Sign in to ArcGIS Enterprise Manager as an administrator of your organization.
2. Click the Backups button.
3. On the backups page, click Register a backup store.
4. Provide the following information for the staging location:
   • Size (GiB)—The size of the PV for the staging location. The minimum size is 16 GiB. The size should be large enough to contain each store's backup.
   • Storage class name—The storage class name.
5. Select the type of backup store being registered.
   • Amazon S3
   • Azure Blob
   • Google Cloud Storage
   • System managed storage
   1. If using Amazon S3, provide the following information:
      • Backup store name—The name of the backup store. The name can only contain lowercase letters, numbers, and hyphens, and must not begin or end with a hyphen.
      • Bucket name—The name of the bucket created in Amazon S3 to store backups.
      • Region—The region where the bucket was created.
      • Authentication type—Choose either Access key or IAM role.
      • If using access key as the authentication type, provide the following information:
        • Access key—Paste or type the access key for the IAM user.
        • Secret key—Paste or type the secret key for the IAM user.
   2. If using Azure Blob, provide the following information:
      • Backup store name—The name of the backup store. The name can only contain lowercase letters, numbers, and hyphens, and must not begin or end with a hyphen
      • Container name—The name of the container created in Azure to store backups.
      • Storage account—The name of the parent storage account the container exists under.
      • Authentication type—Choose either Storage account key or Managed identity.
      • If using storage account key as the authentication type, provide the following information:
        • Account key—Paste or type the primary or secondary account key for the associated storage account.
   3. If using Google Cloud Storage, provide the following information:
      • Backup store name—The name of the backup store. The name can only contain lowercase letters, numbers, and hyphens, and must not begin or end with a hyphen.
      • Bucket name—The name of the bucket created in Google Cloud Storage to store backups.
      • Access key—Paste or type the access key for the service account.
      • Secret key—Paste or type the secret key for the service account.

      Note:

      While a multi-region bucket increases the availability and redundancy of storage, it may introduce performance degradation and unpredictable latency when creating or restoring backups. See Google Cloud documentation for differences between regional, dual-region, and multi-region Cloud Storage and location considerations.

   4. If using system managed storage, provide the following information:
      • Volume type—Choose Static when the PVC should bind to an existing PV. Choose Dynamic when a new PV should be provisioned through the specified storage class.
      • Backup store name—Defines the name of the backup store. It must match the name of the previously registered backup store. The name can only contain lowercase letters, numbers, and hyphens and must not begin or end with a hyphen.
      • Size (GiB)—Defines the size of the PV for the backup store. The minimum size is 32 GiB and the value should match the size of the existing PV when using static binding. If the value is higher than the size of the existing PV, the PVC will not bind with the PV.
      • Storage class name—The storage class must match the storage class of the existing PV.
      • Label selector—Required for static provisioning, and the label or labels must match those of the existing PV.
6. Click Register.

Note:

When binding to an existing PV that has no storage class defined, leave the storage class name blank. If a default storage class is configured in the cluster, the DefaultStorageClass admission controller adds the default storage class and prevents the PVC from binding. In this case, administrators should either add a storage class specification to the PV or remove the default storage class configuration.

Consider the size of the backup store if your storage provider does not allow the expansion of PVs. If this is the case, evaluate the amount of data your organization will hold as well as the number of backups you'll create. If the original backup store runs out of storage space, delete the old backups or register a new backup store.

If your storage provider does support expansion of PVs, you can modify the configuration of the volume. Whether PVs can be resized is determined by the allowVolumeExpansion setting for the storage class. It must be set to true. Review the documentation specific to your environment for more information.

Next, you'll create a backup.