YAML examples for Trilio Custom Resource Definitions
TrilioVaultManager
TrilioVaultManager CRD, owned by Trilio Operator for Upstream/Non-Operator Lifecycle Manager (OLM) based environments, manages the lifecycle of Trilio for Kubernetes Application.
The following snippet provides an example on how to use the TrilioVaultManager CRD.
The version number provided below is only for illustrative purposes. Please refer to the Compatibility Matrix to find the latest version to use.
In the above CRD restoreNamespaces is optional.
Application scope of Namespaced, will enable additonal namespaces that can be restored into. Application scope of clustered will restrict restores to those specific namespaces only.
Provide Resource Limits for Trilio Pods
apiVersion:triliovault.trilio.io/v1kind:TrilioVaultManagermetadata:labels:triliovault:k8sname:tvkspec:trilioVaultAppVersion:2.5.0applicationScope:Cluster# T4K components configuration, currently supports control-plane, web, exporter, web-backend, ingress-controller, admission-webhook.# User can configure resources for all componentes and can configure service type and host for the ingress-controllercomponentConfiguration:web-backend:resources:requests:memory:"400Mi"cpu:"200m"limits:memory:"2584Mi"cpu:"1000m"ingress-controller:service:type:LoadBalancerhost:"trilio.co.in"
Backup Target
The Backup Target CRD specifies the backup storage media. Trilio supports either AWS S3 compatible object storage or NFS. A user can configure multiple backup targets and choose the target when an Application CR is created by providing target name and the name of the namespace where it resides. The target credentials can be saved as a secret and refer to the target CR for better security reasons. All backups that are created for that Application will be saved on the backup target specified in Application CR spec. Once a backup target is chosen for an Application, it cannot be changed.
Example 1 - S3 Target: AWS
Sample YAML file for AWS based S3 bucket and credentialSecret
Additional values for the nfsOptions field can be found here
Example 6 - S3 Based Event Target Example
Any backup target can be designated as an event target. An event target is used to share state information between clusters with the shared event target. Two or more clusters can share the same event target.
Sample YAML file for S3-based event target is given below
Trilio provides a Policy Custom Resource Definition through which scheduling, retention, and cleanup policies can be created.
Scheduling Policy
A scheduling policy can be created to automate the capture of applications within a Kubernetes system on a periodic basis. T4K enables users to create a scheduling policy with multiple cron strings defined within it. Each Cron string creates an associated cron job within the Kubernetes system and as a result daily, weekly, yearly, etc. policies can be created independently of each other within the same policy CR.
The retention policy enables users to define the number of backups to retain and the cadence to delete backups as per compliance requirements. The retention policy CR provides a simple YAML specification to define the number of backups to retain in terms of days, weeks, months, years, latest etc.
Retention Polices are referenced within a BackupPlan and can be added to any of the example YAML files provided below
By default, Trilio does not delete failed backup job backup images or backup CRs. Users must manually delete failed backups. However, Trilio provides a cleanup policy to clean up failed backups. This policy only cleans up the backup files on the target associated with the failed backup job, not the backup CR itself. Users must use the kubectl command to delete any failed backup CRs from the cluster. If the spec.default is true and the policy is created in the T4K installed namespace, the policy applies to the entire cluster. If the spec.default is false, then the policy applies to the namespace where the policy was created. UI automatically sets the spec.default to false. A cron job that runs every 30 mins and deletes failed backups data based on the value specified by spec.cleanupConfig.backupdays. The policy does not delete any volume snapshots left behind by the failed backup jobs. Since backup CRs have an ownerRef on the volume snapshots, they will be automatically deleted when the failed backup CRs are deleted
An example cleanup policy that cleans up failed backups after five days is provided below.
Trilio provides the ability to create immutable backups at the application level. Once the backup is taken and stored on an immutable target, it can not be altered (overwritten/deleted) until the retention period set through T4K is up.
Immutable Target
To create immutable backups, user needs to create an immutable target as shown in the sample below. The immutable targets work only on object storage targets.
kind:TargetapiVersion:triliovault.trilio.io/v1metadata:name:sample-immutable-targetspec:type:ObjectStorevendor:AWSobjectStoreCredentials:# immutable targets works only on object store targetsregion:us-east-1bucketName:trilio-browser-testcredentialSecret:name:sample-secretnamespace:TARGET_NAMESPACEobjectLockingEnabled:truethresholdCapacity:5Gi
Retention Policy for immutable backup
After immutable target, user needs to create a retention policy. This sets up the retention period for the backup. Refer the sample Example - Retention Policy.
Immutable Backup
After immutable target and retention policy are set, user needs to create a backup. Once the backup is taken and stored on an immutable target, it can not be altered (overwritten/deleted) until the retention period set through T4K is up. Refer the BackupPlan and Backup samples below.
Hooks enable injecting commands into pods/containers before and after a backup via pre/post commands. Hooks enable taking application consistent backups and extending backup workflows.
Note: Hook should be created in the same namespace as that of BackupPlan referencing it resides.
The BackupPlan CRD specifies the backup job. The specification includes the backup schedule, backup target and the resources to backup. Trilio supports three types of resources to backup and an BackupPlan CR may include combination of these resources.
This BackupPlan CR defines a set of resources to backup. Resources can be defined in the form of Helm release, Operators or just bare k8s api resources.
In this release, Trilio supports backup of the following:
Helm releases
Operator-based application instances
Label-based selection of resources
Namespaces
Type: Custom Label - Example 1
The following sample BackupPlan CR specifies a Label-based selection of resources. In this example any resource has a label app with valuegcp-compute-persistent-disk-csi-driver will be backed up.
The following sample BackupPlan CR that specifies Helm release based resources to backup. Trilio automatically discovers the resources that belong to the release and backups the helm chart as whole. The release that this example backups is mysql-releasename.
Another type of resource that Trilio supports is an Operator-based applications and the following YAML snippet describes the BackupPlan CR that includes the operator based application.
OLM or Openshift Operators can also be protected by providing the subscription name and namespace in operator resources.
Example 5a. backups CockroachDB operator subscription named cockroachdb-certified along with its custom resource named crdb-tls-example of the kind CrdbCluster
Example 5b. backups Openshift Pipelines operator subscription named openshift-pipelines-operator-rh along with its custom resources apply-manifests and update-deployment of the kind Task , and build-and-deploy of kind Pipeline
User can provide specific resource which needs to be included or excluded while doing backup. Resources can be specified either by GVKO or by the Kind directly.
apiVersion:triliovault.trilio.io/v1kind:BackupPlanmetadata:name:sample-applicationspec:encryption:encryptionSecret:name:sample-secretnamespace:BACKUPPLAN_NAMESPACEbackupConfig:target:name:sample-targetretentionPolicy:name:sample-retention-policybackupPlanComponents:helmReleases: - mysql
Backup
The Backup CRD takes a backup of the resources specified in the BackupPlan spec. It takes either a Full backup or an Incremental Backup. The first backup of the Application will always be a Full backup, even if the user specifies their backup type as Incremental.
Note: BackupPlan and Backup CR should be created in the same namespace.
The incremental backup includes all the YAML files and delta changes to PV data. Incremental backups are not complete by themselves and rely on all the previous incremental backups and the full backup.
The scheduleType the field is to specify if the backup should follow the backup schedule provided in the backupPlan or if it should be a one-time backup only.
Example 3 - ClusterBackup
Sample Backup YAML for ClusterBackup. This CR is used to back up multiple namespaces and should be used with ClusterBackupPlan. It takes either a Full backup or an Incremental Backup. The first backup will always be a Full backup, even if the user specifies their backup type as Incremental.
User can only cancel in-progress backup and canceling completed or available backups will be blocked.
Restore
The Restore CRD specifies the backup that resources need to be restored from. Resources can be restored to the same namespace or a different namespace. If a backup target with existing backups are created to a different cluster, those backups can be restored to the cluster. A migration or disaster recovery use case can be implemented using this functionality.
Example 1 - Restore from a specific backup
Sample YAML file to restore from a specific backup. The backup is identified by name sample-backup.
Trilio provides the capability to Skip the restoration of objects if they already exist in the namespace. This is achieved by using the skipIfAlreadyExists field within the Restore custom resource
Select the resources for restoration using the resourceSelector field. This allows the user to restore only the specified resources, rather than the entire backup.
ClusterRestore enables users to restore the last successful ClusterBackup based on a ClusterBackupPlan. It is used to restore multiple namespaces protected by the ClusterBackup. The ClusterBackup is identified by name sample-clusterbackup. It also provides a flag to cleanup in case of a failure.