Skip to main content
NetApp Backup and Recovery

Manage Kubernetes execution hook templates in NetApp Backup and Recovery

Contributors netapp-mwallis
PDFs

Create execution hook templates to run custom scripts before or after protection operations for managed Kubernetes applications.

Note

NetApp Backup and Recovery freezes and unfreezes filesystems for applications like KubeVirt during data protection. You can disable this behavior globally or for specific applications using the Trident Protect documentation:

Required NetApp Console role

Backup and Recovery super admin, Backup and Recovery backup admin, or Backup and Recovery restore admin. Learn about NetApp Backup and Recovery access roles. Learn about NetApp Console access roles for all services.

Types of execution hooks

NetApp Backup and Recovery supports the following types of execution hooks based on when they run:

  • Pre-snapshot

  • Post-snapshot

  • Pre-backup

  • Post-backup

  • Post-restore

Order of execution

When a data protection operation runs, execution hook events take place in the following order:

  1. Any applicable custom pre-operation execution hooks are run on the appropriate containers. You can create multiple custom pre-operation hooks, but their execution order is not guaranteed or configurable.

  2. Filesystem freezes occur, if applicable.

  3. The data protection operation is performed.

  4. Frozen filesystems are unfrozen, if applicable.

  5. NetApp Backup and Recovery runs any applicable custom post-operation execution hooks on the appropriate containers. You can create multiple custom post-operation hooks, but their execution order is not guaranteed or configurable.

If you create multiple hooks of the same type, their execution order is not guaranteed. Hooks of different types always run in the specified order. For example, hooks run in this order when a configuration includes all supported hook types:

  1. Pre-snapshot hooks run

  2. Post-snapshot hooks run

  3. Pre-backup hooks run

  4. Post-backup hooks run

Note Test execution hook scripts before enabling them in production. Use 'kubectl exec' to test scripts, then verify snapshots and backups by cloning the app to a temporary namespace and restoring.
Note If a pre-snapshot execution hook adds, changes, or removes Kubernetes resources, those changes are included in the snapshot or backup and in any subsequent restore operation.

Important notes about custom execution hooks

Consider the following when planning execution hooks for your applications.

  • An execution hook must use a script to perform actions. Many execution hooks can reference the same script.

  • Execution hooks must be executable shell scripts.

  • Script size is limited to 96KB.

  • Execution hook settings and any matching criteria are used to determine which hooks are applicable to a snapshot, backup, or restore operation.

Note Execution hooks can reduce or disable application functionality. Make your custom hooks run as quickly as possible. If you cancel a backup or snapshot operation that has associated execution hooks, those hooks still run if the operation has already begun. A post-backup execution hook's logic cannot assume that the backup completed.

Execution hook filters

When you add or edit an execution hook for an application, you can add filters to the execution hook to control which containers the hook matches. Filters are useful for applications that use the same container image on all containers, but might use each image for a different purpose (such as Elasticsearch). Filters allow you to create scenarios where execution hooks run on some but not necessarily all identical containers. If you create multiple filters for a single execution hook, they are combined with a logical AND operator. You can have up to 10 active filters per execution hook.

Each filter you add to an execution hook uses a regular expression to match containers in your cluster. When a hook matches a container, the hook runs its associated script on that container. Regular expressions for filters use the Regular Expression 2 (RE2) syntax, which does not support creating a filter that excludes containers from the list of matches. For information on the syntax that NetApp Backup and Recovery supports for regular expressions in execution hook filters, see Regular Expression 2 (RE2) syntax support.

Note If you add a namespace filter to an execution hook that runs after a restore or clone operation and the restore or clone source and destination are in different namespaces, the namespace filter is only applied to the destination namespace.

Execution hook examples

Visit the NetApp Verda GitHub project to download real execution hooks for popular apps such as Apache Cassandra and Elasticsearch. You can also see examples and get ideas for structuring your own custom execution hooks.

Note The scripts in the Verda GitHub repository are provided as-is and are not officially supported by NetApp. Only the execution hooks framework within Trident Protect and Backup and Recovery is officially supported by NetApp.

Create an execution hook template

You can create a custom execution hook template that you can use to perform actions before or after a data protection operation on an application.

Note Templates that you create here are only usable when protecting Kubernetes workloads.
Steps

  1. In the Console, go to Protection > Backup and recovery.

  2. Select the Settings tab.

  3. Expand the Execution hook template section.

  4. Select Create execution hook template.

  5. Enter a name for the execution hook.

  6. Optionally, choose a type of hook. For example, a post-restore hook is run after the restore operation is complete.

  7. In the Script text box, enter the executable shell script that you want to run as part of the execution hook template. Optionally, you can select Upload script to upload a script file instead.

  8. Select Create.

    After you create the template, it appears in the list of templates in the Execution hook template section.