Disaster Recovery Plan

This page provides details into the DRPlan feature provided by Trilio for Kubernetes (T4K)

Overview

Whether you are running one app or multiple apps, every organization needs a strategy to recover from a disaster quickly and restore business operations. Newer-age paradigms like GitOps provide a neat way to deploy/re-deploy applications, however, when you deal with mission critical applications, you require a turnkey solution like Trilio that can be leveraged to redeploy all apps from their last captured running state versus working with the application team to deploy their applications at another site. This problem gets amplified when you deal with applications and services at scale. Once business continuity is restored, GitOps can connect to the DR cluster and sync accordingly.

Furthermore, stateful applications also need data volumes to connect to the metadata configuration, so a solution like T4K that can capture application consistent PIT metadata and data for DR perspective is needed.

With these challenges in mind, T4K provides a DRPlan feature which allows users to restore multiple applications or namespaces as part of a single workflow to restore business operations. This feature is provided as a simple click-driven solution through the management console for constructing the DR plan and executing it within a destination cluster.

Users can now create and execute various DRPlans for different tiers of applications based on criticality from multiple targets or backup locations. The DRPlan is created and saved at the destination cluster - which means that the plan can be executed even when the source cluster is not available. While marketed as a disaster recovery workflow, this same workflow can be used to for application migration and test/dev purposes as well (though these will have their own workflows in the future).

DRPlan Highlights

  1. DRPlans are created from the resource management page of a particular cluster.

  2. No connection or dependency to the source cluster is needed.

  3. First page of the DRPlan focuses on selecting namespaces and apps from various targets, whereas the second page of the DRPlan focuses on massaging the application restores so that they can fit and function well within the target environment.

    1. Transforms can be created once and applied to all other applications being restored in the DRPlan.

  4. The individual backups are restored in parallel at the same time. If any delay is required between the restores etc. that can be achieved by using transforms and adding an 'init' container to the application pod.

  5. Users can monitor the status of the DRPlan from the resource management tab itself and can look at the status of individual restores from the restore overview page.

Creating a new DRPlan
Selecting Apps and Namespace for DRPlan from various targets
Field No.
Field Name
Description

1

Disaster Recovery Plan Name

Enter a meaningful name for your Disaster Recovery Plan. This name will be used to identify and manage the DR plan within the destination cluster.

2

Select Target

Select a target from the dropdown menu. This allows you to browse and select backup plans and backups from various backup plans. The target can be from the same cluster or a different cluster, enabling cross-cluster Disaster Recovery scenarios.

3

Backup plan selection

Select one or more backup plans from the available plans in the selected target. You can select backup plans from multiple targets to create a comprehensive DR plan that restores multiple applications or namespaces as part of a single workflow. In the accordion view, the Instance ID and the instance name where the backup plan is or was present are displayed.

4

Backup selection

After selecting a backup plan, choose a specific backup from that backup plan from which user wants to take a restore as a part of Disaster Recovery. User can select multiple backups from here.

Manipulating data before a restore - Transforms, Exclusions, Hooks
Field No.
Field Name
Description

1

Selected backup plans field

This section displays the selected backup plans grouped by target. All backup plans selected from the same target are displayed together.

2

Backup Name

This field displays the backup name that is automatically selected if multiple backups are available for a backup plan. Users can change the backup by clicking on the 'Change' option to select a different backup from the available backups for that backup plan.

3

Name

Enter a meaningful name for the restore operation for this particular backup. This name will be used to identify and manage the restore within the destination cluster.

4

Restore Namespace

Select the namespace in which you want to restore this particular backup. You can create a new namespace from the dropdown option "+ New Namespace" if needed.

5

Restore Flags

Configure restore flags to define how the restore should happen. Restore flags provide granular control over restore behavior for different scenarios including disaster recovery, cross-cluster migrations, and application updates. For detailed information about each flag, see the Restore Flags Guide.

6

Add Transform Component

Configure transform components to modify Kubernetes resources before restoration. Trilio provides the ability to transform Helm Charts and 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 detailed information, see the Transform Components section.

7

Add Exclude Resources

Configure resources to be excluded from the restore operation. Exclude resources allows you to specify which resources should not be restored using label selectors or GVK selectors. The restore will be performed without the selected resources in this field. For detailed information, see the Resource Selector section.

8

Add Hook

Configure restore hooks to execute custom commands or scripts after the application is restored. TVK allows users to inject hooks similar to how they would apply hooks when performing backups and snapshots. The restore hooks are applied once the application is restored. For detailed information, see the Hooks Configuration section.

9

Cancel / Prev

Cancel - Click to cancel the DR plan creation and return to the previous page. Prev - Click to go back to the previous page (DR plan creation page) to review or modify the selected backup plans and backups.

10

Execute

Click this button to execute the Disaster Recovery Plan. This will initiate the restore operations for all selected backups in parallel. The individual backups are restored simultaneously, and you can monitor the status of the DR plan execution from the resource management tab.

Status logs for multiple restores

After successful creation of Disaster recovery, user is redirected to listing page.

View Execution Status of DRPlans

Last updated

Was this helpful?