Overview
For a deeper understanding of Fusion Backup & Restore recipes, refer to our earlier blog post here
The challenge of a one-size-fits-all backup solution in the world of highly customisable deployments:
Complex enterprise solutions like IBM Cloud Paks, watsonx, and IBM Maximo are composed of multiple components that can be installed and configured in various combinations to meet specific customer requirements. While this modularity provides great flexibility, it also introduces significant challenges for data protection.
Each customer environment may differ in terms of which components are installed, how they are configured, and how they evolve over time. As a result, a one-size-fits-all backup strategy is not sufficient for such dynamic and heterogeneous deployments.
Traditionally, every sub-component in these solutions is backed up using a dedicated recipe. However, when new components are added or existing ones are removed, recipe authors must manually modify the backup recipes to reflect those changes.
This approach is:
· Error-prone, especially in large-scale environments
· Time-consuming, requiring constant updates
· Difficult to scale, as it lacks automation and flexibility
In fast-changing environments, maintaining static recipes becomes a bottleneck for reliable and scalable data protection.
Flexible solution using IBM Fusion Backup & Restore recipes:
Instead of trying to provide a single recipe specific to a generalised type of deployment of a specific IBM software stack, we are providing a way for each of the software stack components to define recipe semantics which can be discovered and collated into a single recipe which is customised for the deployment.
Define a base recipe (i.e., parent recipe) to handle the backup of core or foundational components. For each individual sub-component, create separate child recipes. This modular structure ensures that any addition or removal of sub-components does not impact the base recipe, enabling better flexibility and maintainability.
This architecture is referred to as the Dynamic Recipe (Parent-Child) model.
What is a Dynamic Recipe ?
The Dynamic Recipe feature brings a powerful new capability that simplifies the backup and restore process for applications with multiple, variable sub-components.
This is especially valuable for complex solutions like IBM Cloud Paks, watsonx, and similar platforms where the set of deployed components can differ across environments.
With Dynamic Recipes, your backup logic can automatically adapt to changes—if a component is added or removed from the deployment, the recipe is dynamically updated to reflect the current state of the application.
Let’s explore this with an example:
In this example we are going to look at creating a recipe for two components. We want to give each component the ability to execute a task prior to a backup snapshot (pre-snapshot) and immediately following the backup snapshot (post-snapshot). You can imagine that each component has a database engine that needs to put the database into a consistent state (pre-snapshot) and remove it from this state (post-snapshot).
In earlier implementations, the workflows section typically included only the backup and restore workflows. However, with the latest enhancement, additional custom workflows can now be defined and referenced.
apiVersion: spp-data-protection.isf.ibm.com/v1alpha1
kind: Recipe
metadata:
name: parent-recipe
namespace: ibm-spectrum-fusion-ns
spec:
groups:
- name: mysql-volumes
type: volume
includedNamespaces:
- mysql
- name: mysql-resources
type: resource
includedNamespaces:
- mysql
includedResourceTypes:
- deployments
hooks:
- name: mysql-pod-exec
type: exec
namespace: mysql
labelSelector: app=mysql
singlePodOnly: true
timeout: 120
onError: fail
ops:
- name: flush-tables-with-read-lock
command: ["/bin/bash","-c","mysql --user=root --password=$MYSQL_ROOT_PASSWORD -e 'FLUSH TABLES WITH READ LOCK;'"]
container: mysql
timeout: 60
- name: mysql-deployment-check
type: check
namespace: mysql
selectResource: deployment
nameSelector: mysql
timeout: 180
onError: fail
chks:
- name: replicasReady
timeout: 120
onError: fail
condition: "{$.spec.replicas} == {$.status.readyReplicas}"
workflows:
- name: backup
sequence:
- group: mysql-resources
- workflow: pre-hook
- group: mysql-volumes
- name: restore
sequence:
- group: mysql-volumes
- group: mysql-resources
- workflow: post-hook
- name: pre-hook
prority: 1000
sequence:
- hook: mysql-pod-exec/flush-tables-with-read-lock
- name: post-hook
prority: 2000
sequence:
- hook: mysql-deployment-check/replicasReady
In this example, pre-hook and post-hook are custom workflows defined independently and then referenced within the backup and restore sequences. The names of these workflows (e.g., pre-hook, post-hook) can be any arbitrary string, allowing full flexibility to extend and modularize the backup and restore process.
Defining Custom Workflows in Child Recipes:
With the Dynamic Recipe (Parent-Child) model, it's now possible to define custom workflows within child recipes. This allows sub-components to manage their own backup logic independently while still integrating seamlessly into the overall backup process defined in the parent.
Here’s an example of a child recipe:
apiVersion: spp-data-protection.isf.ibm.com/v1alpha1
kind: Recipe
metadata:
name: child-1
namespace: ibm-spectrum-fusion-ns
labels:
dp.isf.ibm.com/parent-recipe: parent-recipe
dp.isf.ibm.com/parent-recipe-namespace: ibm-spectrum-fusion-ns
spec:
groups:
- name: mysql-configmaps
type: resource
includedNamespaces:
- mysql
includedResourceTypes:
- configmaps
hooks:
- name: mysql-pod-exec
type: exec
namespace: mysql
labelSelector: app=mysql
singlePodOnly: true
timeout: 120
onError: fail
ops:
- name: create-temp-file-pre
command: ["/bin/bash", "-c", "echo 'pre-hook' > /tmp/pre-hook.txt "]
container: mysql
timeout: 60
- name: create-temp-file-post
command: ["/bin/bash", "-c", "echo 'post-hook' > /tmp/post-hook.txt "]
container: mysql
timeout: 60
workflows:
- name: pre-hook
prority: 5000
sequence:
- group: mysql-configmaps
- hook: mysql-pod-exec/create-temp-file-pre
- name: post-hook
prority: 1000
sequence:
- hook: mysql-pod-exec/create-temp-file-post
- group: mysql-configmaps
In this example, both pre-hook and post-hook are custom workflows defined directly in the child recipe, each with its own sequence of operations.
Why This Matters
Each sub-component can now define:
- Its own resources to be backed up (via groups)
- Its own hooks or commands to be executed
- Its own workflows that sequence these operations
When the parent workflow is executed, it can discover and invoke additional workflows defined in child recipes. This ensures that:
- Backup logic is modular and reusable
- Sub-components can evolve independently
- The parent recipe doesn't need to be updated every time a sub-component is added or removed
This approach enhances scalability, maintainability, and extensibility of the backup configuration in complex solutions like IBM Cloud Paks.
How to use it
1. Ensure that child recipes correctly reference the parent recipe using labels. i.e.
labels:
dp.isf.ibm.com/parent-recipe: parent-recipe
dp.isf.ibm.com/parent-recipe-namespace: ibm-spectrum-fusion-ns
2. Priority: This field determines the priority of execution.
The priority value can range from -2,147,483,648 to 1,000,000,000.
3. Execution Order:
If a child recipe uses the same workflow as the parent and has a higher priority value, the child recipe will execute first.
If a child recipe shares the same workflow and priority value as its parent, the execution order will be random, but they will run sequentially.
How the child and parent relationship establish:
How does the combined recipe looks like:
Conclusion:
The Dynamic Recipe (Parent-Child) model brings a powerful and flexible approach to managing backup and restore operations in complex, modular applications like IBM Cloud Paks. By decoupling sub-component logic into child recipes and supporting custom workflows, this model reduces manual overhead, improves maintainability, and ensures scalability as your solution evolves.
Whether components are added, removed, or updated, the parent recipe remains stable—while child recipes handle their own backup logic independently. This dynamic architecture is a step forward in simplifying data protection for modern, cloud-native environments.
Note: This feature is supported starting from the Fusion 2.10 release.