Manage BlueXP backup and recovery execution hook templates for Kubernetes workloads

09/15/2025 Contributors

An execution hook is a custom action that you can configure to run in conjunction with a data protection operation of a managed Kubernetes application. For example, if you have a database app, you can use an execution hook to pause all database transactions before a snapshot, and resume transactions after the snapshot is complete. This ensures application-consistent snapshots. When you create an execution hook template, you can specify the type of hook, the script to run, and any filters that determine which containers the hook applies to. You can then use the template to associate execution hooks with your applications.

By default, NetApp Backup and Recovery automatically freezes and unfreezes filesystems for certain applications such as KubeVirt during data protection operations. You can optionally disable this behavior globally or for specific applications using instructions from the Trident protect documentation:

To disable this behavior for all applications, refer to Protecting data with KubeVirt VMs.
To disable this behavior for a specific application, refer to Define an application.

Required BlueXP role

Organization admin or SnapCenter admin. Learn about BlueXP backup and recovery access roles. Learn about BlueXP access roles for all services.

Types of execution hooks

BlueXP backup and recovery supports the following types of execution hooks, based on when they can be run:

Pre-snapshot
Post-snapshot
Pre-backup
Post-backup
Post-restore

Order of execution

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

Any applicable custom pre-operation execution hooks are run on the appropriate containers. You can create and run as many custom pre-operation hooks as you need, but the order of execution of these hooks before the operation is neither guaranteed nor configurable.
Filesystem freezes occur, if applicable.
The data protection operation is performed.
Frozen filesystems are unfrozen, if applicable.
Any applicable custom post-operation execution hooks are run on the appropriate containers. You can create and run as many custom post-operation hooks as you need, but the order of execution of these hooks after the operation is neither guaranteed nor configurable.

If you create multiple execution hooks of the same type (for example, pre-snapshot), the order of execution of those hooks is not guaranteed. However, the order of execution of hooks of different types is guaranteed. For example, the following is the order of execution of a configuration that has all of the different types of hooks:

Pre-snapshot hooks executed
Post-snapshot hooks executed
Pre-backup hooks executed
Post-backup hooks executed

You should always test your execution hook scripts before enabling them in a production environment. You can use the 'kubectl exec' command to conveniently test the scripts. After you enable the execution hooks in a production environment, test the resulting snapshots and backups to ensure they are consistent. You can do this by cloning the app to a temporary namespace, restoring the snapshot or backup, and then testing the app.

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 apps.

An execution hook must use a script to perform actions. Many execution hooks can reference the same script.
Execution hooks need to be written in the format of 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.

Because execution hooks often reduce or completely disable the functionality of the application they are running against, you should always try to minimize the time your custom execution hooks take to run. If you start a backup or snapshot operation with associated execution hooks but then cancel it, the hooks are still allowed to run if the backup or snapshot operation has already begun. This means that the logic used in a post-backup execution hook cannot assume that the backup was completed.

Execution hook filters

When you add or edit an execution hook for an application, you can add filters to the execution hook to manage which containers the hook will match. 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 will run 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 BlueXP backup and recovery supports for regular expressions in execution hook filters, see Regular Expression 2 (RE2) syntax support.

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.

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.

Steps

In BlueXP, go to Protection > Backup and recovery.
Select the Settings tab.
Expand the Execution hook template section.
Select Create execution hook template.
Enter a name for the execution hook.
Optionally, choose a type of hook. For example, a post-restore hook is run after the restore operation is complete.
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.
Select Create.

The template is created and appears in the list of templates in the Execution hook template section.