Disaster Recovery Plan
This page provides details into the DRPlan feature provided by Trilio for Kubernetes (T4K)
Last updated
2.0.X-2.10.X(Deprecated)
This page provides details into the DRPlan feature provided by Trilio for Kubernetes (T4K)
Last updated
Deprecated Documentation
This document is deprecated and no longer supported. For accurate, up-to-date information, please refer to the documentation for the latest version of Trilio.
# Disaster Recovery Plan
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).
DRPlans are created from the resource management page of a particular cluster.
No connection or dependency to the source cluster is needed.
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.
Transforms can be created once and applied to all other applications being restored in the DRPlan.
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.
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.
