Comment on page
This page describes the process for creating Backups
Trilio aims to simplify the backup creation process by providing intuitive workflows for protecting applications and namespaces. Users can either select a namespace to backup or can select independent applications or objects within a namespace for backup.
From the landing page or the home page screen, users are first presented with a view of all the namespaces that are available in the selected cluster (from the navigation panel) in a honeycomb or list view. Users can select a namespace and then click on the backup button that appears upon selection, to backup that namespace. Once the backup button is clicked, the workflow for creating/selecting a backupPlan is initiated. Trilio lists all the available namespace level Backup Plans that were previously created based on the namespace that the user selected for backup.
Trilio supports capturing multiple namespaces as part of a single backup capture. Trilio has introduced new cluster scoped custom resource definitions (Cluster Backup Plan, Cluster Backup, Cluster Restore). Users can click select any number of namespaces from the namespace view on the management console and then click on 'Create Backup' to create a point-in-time capture of the selected namespaces. The multi-namespace workflows enable users to provide backup configuration at a global level (all selected namespaces) or at an individual namespace level.
Trilio also allows users to capture namespaces based on label values. The advantage of this feature is the ability to dynamically include namespaces that may have been created after the backupPlan was created.
On the Application Level, users can navigate between the 4 views provided in the application discovery panel and select the items present within to build their protection scope or backupPlan. The BackupPlan can be a combination of any number of items from any of the views. For example, 1 helm + 1 label can be a backupPlan or 2 Helm + 2 Operator + 3 Objects can be the backupPlan.
Users can leverage existing backupPlans as part of the new backupPlan they create, which will automatically copy all the backupPlan components into the new BackupPlan along with the other items selected from the different views provided.
Trilio takes out the complexity in building the backupPlan components manually by preloading the specifications for the user based on the selections. For example, selecting an Operator automatically populates the Custom Resources associated with the Operator, the resources for the Operator as well as application resources managed by the Operator. All of this population happens behind the scenes with the user only having to select the Operator item from the application discovery panel. Along with this, Trilio also provides the user the ability to edit the data populated as well as add to it manually.
Auto-populated data for Operator selection
Ability to edit data and customize it further
Similarly, if the the user had chosen items from the labels view, those items would be populated under the Custom tab, and if helm items were chosen as well, those releases would get populated under the Helm Release tab.
Label components in BackupPlan shown under Custom Tab
A backup workflow involves selecting namespaces or applications to protect and then select a matching backupPlan or creating one if no matching backupPlan is found. After a backupPlan is selected, the user can create a backup based on the specifications of the backupPlan.
After the protection scope has been defined by the user either in terms of namespaces or application items from the discovery panel, the user can define the rest of the backupPlan by clicking
Create Backupon the top right and driving through the Backup workflow.
Based on the applications/namespace selected, the workflow first scans the system to check if there are existing Backup Plans available that have the same components that the user has selected from the discovery panel. If matching BackupPlans are found, they are presented to the user in case they would want to reuse it or edit it to save as a new Backup Plan.
After selecting a Backup Plan, the user can provide a name and click 'Save' which will initiate the creation of a Backup after the user provides a name for it.
If no matching BackupPlan is found, the user can choose to create a net-new backupPlan. The user can also edit an existing backupPlan and save that as a new BackupPlan.
Encryption for backups is set at the Backup Plan level by the user providing their own key which is saved as a secret on the Kubernetes cluster. Since Trilio supports encryption at the Backup Plan level with users bringing their own keys, each user is responsible for maintaining their own key. In the event of a user comprimising their key, only the backups using that key would be compromised. As a result, one user compromising their key does not affect another user's backups in any way.
Trilio leverages the LUKS encryption format to protect user data. LUKS is extremely flexible and secure providing a range of cipher suites.
The granular flexibility of setting encryption at the Backup Plan level also helps from a storage cost and capacity perspective. Encryption works against deduplication, and hence having the control to select which applications should be encrypted provides flexibility and lower TCO.
In order to encrypt backups, select the encryption key (that was saved as a secret) from the list of secrets presented in the Backup Plan workflow. Trilio will leverage the secret to encrypt the backups that are based on the Backup Plan.
When restoring an encrypted backup into the same cluster, Trilio will leverage the same key from the Backup Plan to decrypt and restore. However, if the encrypted backup is being restored into a new cluster (DR or Migration use case), then the user will have to provide the encryption key as part of the restore process.
Trilio supports creating immutable backups through immutable backup targets. Trilio works with locking features at the target level to ensure that once a backup has been created, it can only be altered or deleted once the retention period set on the backup through Trilio has expired.
In order to create an immutable backup, the first step is to create an immutable target with Trilio. After that, a Backup Plan referencing the immutable target, a scheduling policy, and a retention policy must be created. Along with that, a maximum value for the incremental backup chain must be provided.
Trilio calculates a new retention policy based on the scheduling policy, retention policy, and maximum length of incremental backups, and then validates it against the default retention policy set on the bucket to ensure Trilio will be able to lifecycle the backups correctly while maintaining SLAs and overall compliance. This calculated new retention policy is then applied to all the backups fr (and subsequent objects) that Trilio stores on the target.