Restoring Applications

Once applications have been protected via a policy or a manual action, it is possible to restore them in-place or clone them into a different namespace.

Note

Restore can take a few minutes as this depends on the amount of data captured by the restore point. The restore time is usually dependent on the speed of the underlying storage infrastructure as times are dominated by how long it takes to rehydrate captured data followed by recreating the application containers.

Restoring Existing Applications

Restoring an application is accomplished via the Applications page. One needs to simply click the Restore icon.

Note

While the UI uses the Export term for backups, no Import policy is needed to restore from a backup. Import policies are only needed when you want to restore the application into a different cluster.

At that point, one has the option to pick a restore point, a grouped collection of data artifacts belonging to the application, to restore from. As seen above, this view distinguishes manually generated restore points from automated policy-generated ones.

It also distinguishes between snapshots and backups. When both are present, as seen above, a layered box is shown to indicate more than one kind of restore point is present for the same data. If you want to restore a version of the application stack, clicking on the layered restore point will present the below option to select between the local snapshot and exported backup.

Selecting a restore point will bring up a side-panel containing more details on the restore point for you to preview, if needed, before you initiate an application restore.

Warning

Currently, K10 will not restore Kubernetes objects (e.g., ConfigMaps or Secrets) that already exist (it will always replace volumes if part of the restore point). This behavior will change in an upcoming release to always overwrite namespaced resources but only create global/non-namespaced resources if they don't exist and to not overwrite them if they already exist.

Once you click Restore Application, the system will automatically recreate the entire application stack into the selected namespace. This not only includes the data associated with the original application but also the versioned container images.

Note

Restored PersistentVolumes may not have the annotations specified in the original PersistentVolume.

After the restore completes, you will be able to go back to your application and verify that the state was restored to what existed at the time the restore point was obtained.

Restoring Deleted Applications

The process of restoring a deleted application is nearly identical to the above process. The only difference is that, by default, removed applications are not shown on the Applications page. To discover them, you simply need to filter and select Removed.

Once the filter is in effect, you will see applications that K10 has previously protected but no longer exist. These can now be restored using the normal restore workflow.

Limitations

• Changing the name of a PersistentVolumeClaim resource (PVC) on restore via transform is not supported.

• Currently, K10 only supports Allowed Topologies consisting of a single zone. If more that one zone is provided, K10 will choose the first one.

• Changing the size of a PersistentVolumeClaim resource (PVC) on restore via transform is not supported.

• A resource's owner references will not be preserved if a transform changes the name of the resource to an auto-generated name (generatedName).

Restore Filtering

By default, a restore will bring back all artifacts and data captured during the backup process. However, there are times where only a subset of these artifacts are required and, to support that use case, the restore workflow supports two distinct filtering options.

• Artifact Filtering: Full-control over what artifacts and data to restore

• Data-Only Restore: Data-only restore (usually for a running application)

Artifact Filtering

As seen in the above diagram, it is possible to selectively bring back restore point artifacts (including volume snapshots). This is useful for scenarios such as single PVC restore or rolling back configuration updates. By default, all artifacts are selected for restore.

Note

To preserve owner references, both the resource and its owners must be included by the filters.

Data-Only Restore

As seen in the above sections, it is also possible to select a Data-Only Restore. While, at the surface level, this is similar to just selecting all volume snapshots and no Kubernetes specs, there are a number of safety guardrails for successful data-only restores. The important differences to be aware of include:

• The Kubernetes workloads (Deployments, StatefulSets, etc.) captured in the restore point must exist in the namespace the application is being restored in

• The running Kubernetes workloads must have the same number of replicas as captured in the restore point

• The Kubernetes workloads must also have same volumes as were gathered in the restore point (number of volumes, names of the volumes)

These guardrails are in place as data-only restore is frequently used to bring older versions of data into a newer version of application code. In those scenarios, these checks are essential to ensure that a successful restore can be completed.

Note

Data-Only Restore follows delete and restore from backup approach for the PVCs to maintain data integrity.

Resource Transformation

By default, K10 restores Kubernetes resources as they exist in the restore point. However, there are times when the restore target does not match the environment of the backup. For these situations, K10 allows Kubernetes resource artifacts to be transformed on restore.

For example, if a restore point was create in one cloud provider and you wish to restore into a cluster in a different cloud provider, you may need a transformation that edits the container image URLs in some of your resources, or one that changes storage class settings.

A complete specification of how transforms can be used can be found here.

Transforms can be added when restoring an application from the desired restore-point. Enabling Apply transforms to restored resources and clicking the Add New Transformation button will open a form for creating new transforms.

On the form, name your transformation, select which resources you want the transformation to be be applied to, and then create one or more operations.

Each operation will have its own panel allowing customization and testing of the selected operation.

Operations can be tested against resources present in the restore point to verify the operations result in the desired resource transformation. The ability to apply transformations will provide any needed flexibility with advanced migration and restore workflows.

Changing Availability Zone via Storage Class Transformation

It is possible to transform a PVC to use a different StorageClass. Using this method, you can change the availability zone in which to restore. The following example provides more detail.

In order to change the Availability Zone, create a duplicate storage class with an additional Allowed Topologies section. More documentation on allowed topologies is available here. An example of such a StorageClass is as follows:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    kubernetes.io/cluster-service: "true"
  name: ssd-us-west1-a
parameters:
  type: pd-ssd
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowedTopologies:
- matchLabelExpressions:
  - key: failure-domain.beta.kubernetes.io/zone
    values:
    - us-west1-a

When creating a new transform operation, select persistentvolumeclaims as the Resource, provide the PVC name the needs to be transformed and then select New Operation.

Replace must be selected as the type of transform operation with the path specified as /spec/storageClassName and the name of the new storage class provided as the value.

It is recommended that the Test Operation feature be used to verify that the transform operations are working correctly.

Following a successful test verification, select Add Operation and then Create Transform.

Verify that the transforms are represented on the restore page.

The subsequent restore operation will apply this transformation and uses the new StorageClass to only provision storage in the specified availability zone.

Changing Storage Types via Storage Class Transformation

The storage class transformation method illustrated above can also be used to change the storage types for both GCE Persistent Disks, AWS EBS Volumes, and Azure Disks.

For GCE Persistent Disks, storage classes with the following storage types are supported: pd-ssd, pd-standard.

For AWS EBS Volumes, storage classes with the following storage types are supported: standard, io1, gp2, sc1, st1.

For Azure Disks, storage classes with the following storage account types are supported: Standard_LRS, Premium_LRS, StandardSSD_LRS, UltraSSD_LRS.

Cloning Applications

By default, K10 restores applications into the original namespace the restore point was created from. However, as the above image shows, the target namespace can be changed and new namespaces can be created at this point. In particular, this functionality can be used to extract only a few files or subset of the originally gathered data with requiring a complete rollback of the primary application. Other use cases include debugging and test/dev purposes or for cloning.

Using an Alternate Location Profile

An exported restore point can be selected to restore an application from a location outside the cluster. By default, it is assumed that the restore point exists at the location it was originally exported to. However, the "Alternate Location Profile" option can be used to select a different location profile to restore from. This can be useful if, for example, restore points have been copied or moved to a different location.