Restore apps
Astra Control can restore your application from a snapshot or backup. Restoring from an existing snapshot will be faster when restoring the application to the same cluster. You can use the Astra Control UI or Astra Control API to restore apps.
-
Protect your apps first: It is strongly recommended that you take a snapshot or backup of your application before restoring it. This will enable you to clone from the snapshot or backup if the restore is unsuccessful.
-
Check destination volumes: If you restore to a different storage class, ensure that the storage class uses the same persistent volume access mode (for example, ReadWriteMany). The restore operation will fail if the destination persistent volume access mode is different. For example, if your source persistent volume uses the RWX access mode, selecting a destination storage class that is not able to provide RWX, such as Azure Managed Disks, AWS EBS, Google Persistent Disk or
ontap-san
, will cause the restore operation to fail. For more information about persistent volume access modes, refer to the Kubernetes documentation. -
Plan for space needs: When you perform an in-place restore of an application that uses NetApp ONTAP storage, the space used by the restored app can double. After performing an in-place restore, remove any unwanted snapshots from the restored application to free up storage space.
-
(Red Hat OpenShift clusters only) Add policies: When you create a project for hosting an app on an OpenShift cluster, the project (or Kubernetes namespace) is assigned a SecurityContext UID. To enable Astra Control Center to protect your app and move the app to another cluster or project in OpenShift, you need to add policies that enable the app to run as any UID. As an example, the following OpenShift CLI commands grant the appropriate policies to a WordPress app.
oc new-project wordpress
oc adm policy add-scc-to-group anyuid system:serviceaccounts:wordpress
oc adm policy add-scc-to-user privileged -z default -n wordpress
-
Supported storage class drivers: Astra Control supports restoring backups using storage classes backed by the following drivers:
-
ontap-nas
-
ontap-nas-economy
-
ontap-san
-
ontap-san-economy
-
-
(ontap-nas-economy driver only) Backups and restores: Before backing up or restoring an app that uses a storage class backed by the
ontap-nas-economy
driver, verify that the snapshot directory on the ONTAP storage backend is hidden. Failure to hide this directory might lead to loss of access to your application, especially if it is using NFSv3. -
Helm deployed apps: Apps deployed with Helm 3 (or upgraded from Helm 2 to Helm 3) are fully supported. Apps deployed with Helm 2 are not supported.
Performing an in-place restore operation on an app that shares resources with another app can have unintended results. Any resources that are shared between the apps are replaced when an in-place restore is performed on one of the apps. For more information, see this example. |
-
Select Applications and then select the name of an app.
-
From the Options menu in the Actions column, select Restore.
-
Choose the restore type:
-
Restore to original namespaces: Use this procedure to restore the app in-place to the original cluster.
If your app uses a storage class backed by the ontap-nas-economy
driver, you must restore the app using the original storage classes. You cannot specify a different storage class if you are restoring the app to the same namespace.-
Select the snapshot or backup to use to restore the app in-place, which reverts the app to an earlier version of itself.
-
Select Next.
If you restore to a namespace that was previously deleted, a new namespace with the same name is created as part of the restore process. Any users that had rights to manage apps in the previously deleted namespace need to manually restore rights to the newly re-created namespace.
-
-
Restore to new namespaces: Use this procedure to restore the app to another cluster or with different namespaces from the source.
-
Specify the name for the restored app.
-
Choose the destination cluster for the app you intend to restore.
-
Enter a destination namespace for each source namespace associated with the app.
Astra Control creates new destination namespaces as part of this restore option. Destination namespaces that you specify must not be already present on the destination cluster. -
Select Next.
-
Select the snapshot or backup to use to restore the app.
-
Select Next.
-
Choose one of the following:
-
Restore using original storage classes: The application uses the originally associated storage class unless it does not exist on the target cluster. In this case, the default storage class for the cluster will be used.
-
Restore using a different storage class: Select a storage class that exists on the target cluster. All application volumes, regardless of their originally associated storage classes, will be migrated to this different storage class as part of the restore.
-
-
Select Next.
-
-
-
Choose any resources to filter:
-
Restore all resources: Restore all resources associated with the original app.
-
Filter resources: Specify rules to restore a sub-set of the original application resources:
-
Choose to include or exclude resources from the restored application.
-
Select either Add include rule or Add exclude rule and configure the rule to filter the correct resources during application restore. You can edit a rule or remove it and create a rule again until the configuration is correct.
To learn about configuring include and exclude rules, see Filter resources during an application restore.
-
-
-
Select Next.
-
Review details about the restore action carefully, type "restore" (if prompted), and select Restore.
Astra Control restores the app based on the information that you provided. If you restored the app in-place, the content of existing persistent volumes is replaced with the content of persistent volumes from the restored app.
After a data protection operation (clone, backup, or restore) and subsequent persistent volume resize, there is a delay of up to twenty minutes before the new volume size is shown in the web UI. The data protection operation is successful within minutes, and you can use the management software for the storage backend to confirm the change in volume size. |
Any member user with namespace constraints by namespace name/ID or by namespace labels can clone or restore an app to a new namespace on the same cluster or to any other cluster in their organization's account. However, the same user cannot access the cloned or restored app in the new namespace. After a clone or restore operation creates a new namespace, the account admin/owner can edit the member user account and update role constraints for the affected user to grant access to the new namespace. |
Filter resources during an application restore
You can add a filter rule to a restore operation that will specify existing application resources to be included or excluded from the restored application. You can include or exclude resources based on a specified namespace, label, or GVK (GroupVersionKind).
Expand for more about include and exclude scenarios
-
You select an include rule with original namespaces (in-place restore): Existing application resources that you define in the rule will be deleted and replaced by those from the selected snapshot or backup you are using for the restore. Any resources that you do not specify in the include rule will remain unchanged.
-
You select an include rule with new namespaces: Use the rule to select the specific resources you want in the restored application. Any resources that you do not specify in the include rule will not be included in the restored application.
-
You select an exclude rule with original namespaces (in-place restore): The resources you specify to be excluded will not be restored and remain unchanged. Resources that you do not specify to exclude will be restored from the snapshot or backup. All data on persistent volumes will be deleted and recreated if the corresponding StatefulSet is part of the filtered resources.
-
You select an exclude rule with new namespaces: Use the rule to select the specific resources you want to remove from the restored application. Resources that you do not specify to exclude will be restored from the snapshot or backup.
Rules are either include or exclude types. Rules combining resource inclusion and exclusion are not available.
-
After you have chosen to filter resources and selected an include or exclude option in the Restore App wizard, select Add include rule or Add exclude rule.
You cannot exclude any cluster-scoped resources that are automatically included by Astra Control. -
Configure the filter rule:
You must specify at least one namespace, label, or GVK. Ensure that any resources you retain after the filter rules are applied are sufficient to keep the restored application in a healthy state. -
Select a specific namespace for the rule. If you don't make a selection, all namespaces will be used in the filter.
If your application originally contained multiple namespaces and you restore it to new namespaces, all namespaces will be created even if they don't contain resources. -
(Optional) Enter a resource name.
-
(Optional) Label selector: Include a label selector to add to the rule. The label selector is used to filter only those resources matching the selected label.
-
(Optional) Select Use GVK (GroupVersionKind) set to filter resources for additional filtering options.
If you use a GVK filter, you must specify Version and Kind. -
(Optional) Group: From the drop-down list, select the Kubernetes API group.
-
Kind: From the drop-down list, select the object schema for the Kubernetes resource type to use in the filter.
-
Version: Select the Kubernetes API version.
-
-
-
Review the rule that is created based on your entries.
-
Select Add.
You can create as many resource include and exclude rules as you want. The rules appear in the restore application summary before you initiate the operation.
In-place restore complications for an app that shares resources with another app
You can perform an in-place restore operation on an app that shares resources with another app and produce unintended results. Any resources that are shared between the apps are replaced when an in-place restore is performed on one of the apps.
The following is an example scenario that creates an undesirable situation when using NetApp SnapMirror replication for a restore:
-
You define the application
app1
using the namespacens1
. -
You configure a replication relationship for
app1
. -
You define the application
app2
(on the same cluster) using the namespacesns1
andns2
. -
You configure a replication relationship for
app2
. -
You reverse replication for
app2
. This causes theapp1
app on the source cluster to be deactivated.