Creating Backups
This page describes the process for creating Backups
Last updated
Was this helpful?
5.0.X
This page describes the process for creating Backups
Last updated
Was this helpful?
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.
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. Before moving forward to create the Encrypted backups, refer the . User need to populate the master encryption secret before backup and restore operation.
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.
