Restoring Backups
This page describes the process for restoring backups.
Last updated
4.0.X
This page describes the process for restoring backups.
Last updated
Similar to the backup workflow, Trilio provides intuitive restore workflows that reduce the complexity dramatically for recovering and migrating applications for a Kubernetes based environment.
Backups can be restored by name if within the same cluster or namespace scope of T4K
Restore from via the RestorePoints Tab
Restore from Backup Overview Page
Backups can be restored by location if restoring from a target repository.
Restore from
Regardless of where the Restore operation is initiated, the workflow for the operation is the same, ensuring consistency and simplicity.
For the restore workflow, there are two tabs presented to the user - Basic and Advanced. Basic restores cover general restore properties for the backup - skip resources, patch CRDs etc. whereas Advanced restores cover resource transformation, resource exclusions, and resource hooks.
As part of every restore, users can select different restore flags to define how the restore should happen.
The following flags are provided:
SkipIfAlreadyExists - Specifies whether to skip restoring resources if they are already found in the namespace in which the backup is being restored. This is only applicable for metadata resources and not data resources (PV/PVC).
PatchIfAlreadyExists - Specifies whether to patch the spec section of an already existing resource found in the namespace at the time of restore.
OmitMetadata - Specifies whether to omit metadata labels, annotations of resources while restoring them.
PatchCRD - Specifies whether to patch spec of an already existing CRD
SkipOperatorResources - Specifies whether to omit operator resources at the time of restore (for the use case when an Operator is already present, but the application of that operator needs to be restored)
CleanupOnFailure - Specifies whether to perform cleanup of resources created along with reverting updated resources in case the restore operation fails.
ProtectRestoredApp - Specifies whether to create a backupplan at the destination namespace/cluster to protect the application after it has been restored. With this flag, users can ensure that their application is protected no matter which cluster it runs on.
DisableIgnoreResources - Specifies the behavior of the default list of resources being ignored at the time of restore. If set to true, those resources will not be ignored.
OnlyData - Restores only the data volume components from a backup.
OnlyMetaData - Restores only the metadata components from a backup.
UseOCPNamespaceUIDRange - Openshift specific flag to restore the data with the ocp namespace UID range.
From a resource transform perspective, Trilio provides the ability to transform Helm Charts and transform custom resources. Helm charts can be transformed based on Key:Value pairs whereas custom resources can be transformed by specifying GVKO and Operation (Replace, Move etc.) type.
For both Helm and Custom Transforms - Trilio fetches the metadata and populates it via dropdown menus and tables - to make is easy for the user to manage the granular details of the transforms
Users can choose to exclude resources by specifying the GVK through the Exclude Resources Tab
Upon satisfactorily entering restore workflow information and triggering the restore, the user a presented with a status log for the restore performed.
Once a restore operation is initiated, the restore progress can be tracked via the Monitoring page or from the restore dialog box itself, if kept open
Restoring the Encrypted Backup on same cluster needs Target Browsing enabled. On the restore form, user will get the option to enable the target browsing. Once the target browser is up, user can select the Encryption Secret from the list. After selecting, it will get verified and then user can continue with the restore.
Similarly, the user can specify hooks to inject before and after the restore. The hooks workflow and behavior is the same as the within the backup workflow. By default, the same hooks are loaded for the user to reuse.
While creating , user need to configure the first then create the secret with Encryption key. Similarly, while restoring the encrypted backups, user need to create the secret with Encryption key.
User need to configure the on the cluster where restore operation will be running. After enabling target browsing, user need to select the backup to restore and create the secret with same Encryption Key(which was used at the time of Backup). Refer following video.
