Once applications have been protected via a policy or a manual action, it is possible to restore then in-place or clone them into a different namespace.
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 an application is accomplished via the Applications page.
One needs to simply click the
While the UI uses the
Export term for backups, no
Import policy is needed to restore from a backup.
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.
Currently, K10 will not restore Kubernetes objects (e.g.,
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.
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.
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
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.
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)
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.
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 RestorePoint 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.
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.