About the deployment approach
NetBackup Snapshot Manager uses a micro-services model of installation. When you load and run the Docker image, NetBackup Snapshot Manager installs each service as an individual container in the same Docker network. All containers securely communicate with each other using RabbitMQ.
Two key services are RabbitMQ and PostgreSQL. RabbitMQ is NetBackup Snapshot Manager's message broker, and PostgreSQL stores information on all the assets NetBackup Snapshot Manager discovers.
The following figure shows NetBackup Snapshot Manager's micro-services model.
NetBackup Snapshot Manager solution can be deployed on Virtual Machine, VM based extension and Kubernetes Service Cluster environments.
The following figures show the different deployment model diagrams:
VM based deployment:
VM based extension deployment
Kubernetes based NetBackup Snapshot Manager extension deployment
For more information, refer to Cohesity Cloud Scale Technology Manual Deployment Guide for Kubernetes Clusters.
These deployment approaches have the following advantages:
NetBackup Snapshot Manager has minimal installation requirements.
Deployment requires only a few commands.
With NetBackup 11.1, as part of the parallel stream backup mechanism for Cloud Virtual Machines (VMs), a new job hierarchy has been introduced.
When parallel read is enabled during Cloud VM backups, multiple stream images are created as part of the Cloud VM snapshot operation:
One child image (stream) is generated for each VM disk.
Stream 1 serves as a synthesized/consolidated image, combining data from all other child streams.
Once all child streams complete successfully, the backup for Stream 1 (the anchor image) proceeds.
The Stream 1 job acts as the anchor (or grandparent) image job, serving as the top-level controller for the entire backup hierarchy.
Job hierarchy process
When a backup job starts for a virtual machine (VM):
The primary job (anchor/grandparent image job) initiates and performs pre-processing tasks.
After pre-processing, the Storage Lifecycle Policy (SLP) triggers individual data transfer jobs - one per VM disk.
All jobs initiated by the SLP are part of the same grandparent hierarchy.
Any future retry jobs initiated by the SLP also fall under the same hierarchy, maintaining structural consistency.
For example, for a VM containing three virtual disks, the job hierarchy appears as follows:
10 - Backup From Snapshot ----------Top job in hierarchy (Anchor image job/Parent Job) (Parent stream Stream No = 1)
17 - Backup from Snapshot - Data transfer job for Stream 1 - This is synthesized job, which synthesizes all the child stream data.
13 - Backup from Snapshot ---------- Export Snapshot Job for Disk 1 ( Child stream backup stream = 2 )
. 14 - Backup from Snapshot ---------- Data transfer Job for Disk 1
12 - Backup from Snapshot ---------- Export Snapshot Job for Disk 2 ( Child stream backup stream = 3 )
. 15 - Backup from Snapshot ---------- Data transfer Job for Disk 2
11 - Backup from Snapshot ---------- Export Snapshot Job for Disk 3 ( Child stream backup stream = 4 )
. 16 - Backup from Snapshot ---------- Data transfer Job for Disk 3