Whitepaper — PodHeitor Nutanix AHV - PodHeitor — Backup, Replicação e Recuperação de Desastres

Agentless Nutanix AHV backup. Prism API-coordinated snapshots, native Nutanix CBT, cross-cluster and cross-hypervisor restore, full multi-tenancy.

Snapshots via Prism API — application-consistent coordination with NGT.
Native Nutanix CBT — real incrementals without global hashing.
Cross-cluster restore — recover to another AHV cluster with automatic mapping.
NGT integration — Microsoft VSS application-consistency inside the VM.
Multi-tenancy — per-project segregation, granular RBAC.

Production-ready in 30 days, at least 50% cheaper. Free trial, signed RPMs and DEBs, direct support from Heitor Faria. Replace your Veeam, Commvault or Bacula Enterprise license without breaking the nightly window.

Request a free 30-day trial →

Executive summary
Introduction & market context
Architecture overview
Backup modes deep dive
Feature matrix
Installation guide
Configuration reference
FileSet examples
Sizing & capacity planning
Performance report
Compatibility matrix
Security
Monitoring
Troubleshooting guide
Use cases & deployment scenarios
Comparison with other approaches
Roadmap
Conclusion
Contact information
Legal / copyright

1. Executive summary

Nutanix AHV has emerged as one of the fastest-growing hypervisor platforms in enterprise data centres, with organisations worldwide migrating virtualised workloads onto Nutanix hyperconverged infrastructure. Despite this rapid adoption, the open-source backup ecosystem has lacked a production-grade, native integration capable of leveraging AHV’s built-in Changed Block Tracking (CBT) engine, Prism Central’s API, and iSCSI block-level data paths. Administrators have been forced to accept file-level backups of running VMs, expensive proprietary agent-based solutions, or custom scripted glue around Nutanix CLI utilities — all of which compromise recovery guarantees, operational simplicity, or budget.

The PodHeitor Nutanix AHV Backup Plugin for Bacula closes this gap entirely. Built in Rust — with native memory safety and no GC pauses — on both sides of the Bacula metaplugin boundary, it delivers enterprise-class backup, restore, cross-cluster DR replication, and failover orchestration for Nutanix AHV environments, using only PodHeitor Backup Edition 15.0.3+ and a standard Prism RBAC service account. The plugin leverages Nutanix v3 and v4 APIs for snapshot lifecycle management, iSCSI VG attachment for high-throughput block streaming, and a PSK-authenticated TCP transport for continuous DR replication — all driven by standard Bacula Job and FileSet configuration with no external scripts, no cron glue, and no vendor-specific backup agents running inside guest VMs.

From a technical depth perspective, this is the most complete open-source Nutanix AHV backup integration available today. It delivers Full and Incremental backups via Nutanix CBT snapshots, byte-identical same-cluster and alternate-cluster restore, cross-vendor INBOUND restore via qemu-img conversion (enabling Proxmox VE, VMware vSphere, and Hyper-V as restore targets), and a full DR replication stack with seed, bitmap-push delta, bandwidth throttling, mid-push reconnect, and four failover modes. A standalone health-check verb validates Prism reach, RBAC posture, and DSIP routing before the first job runs.

From a commercial perspective, the plugin delivers all these capabilities at a fraction of the cost of enterprise alternatives. Veeam Data Platform for Nutanix starts at approximately US$ 5,000/year for small deployments. Commvault and NetBackup licenses routinely exceed US$ 10,000/year. The PodHeitor plugin offers a comparable — and in some dimensions, superior — feature set for Nutanix AHV environments at 50% or more savings. For any organisation running Nutanix AHV with PodHeitor Backup, this plugin is the most cost-effective path to a defensible, production-grade backup and DR posture.

2. Introduction & market context

2.1 Nutanix AHV in enterprise production today

Nutanix AHV (Acropolis Hypervisor) has grown from a bundled hypervisor in the Nutanix hyperconverged stack into a first-class enterprise virtualisation platform. According to Nutanix’s own market data, AHV now accounts for the majority of new workloads deployed on Nutanix clusters, with organisations across financial services, healthcare, government, education, and manufacturing choosing AHV over VMware vSphere — particularly following Broadcom’s acquisition of VMware and the subsequent licensing changes that sent many customers looking for alternatives.

Key technical characteristics of AHV that make it attractive to enterprise operators include:

Hyperconverged architecture eliminating dedicated SAN/NAS infrastructure
Native CBT (Changed Block Tracking) through Prism snapshots for efficient incremental operations
Prism Central multi-cluster management API (v3 and v4) offering programmatic control over VM lifecycle
iSCSI Volume Group (VG) block export for out-of-band data access without guest interaction
AOS (Acropolis Object Store) distributed storage delivering sub-millisecond latency at scale
Built-in data replication and snapshot features enabling native DR workflows

2.2 Why backing up AHV VMs is challenging

Despite AHV’s rich API surface, protecting AHV workloads with open-source backup tools has remained difficult for several reasons:

API complexity. Nutanix operates two parallel API generations (v3 and v4), each with different endpoint shapes, authentication models, and pagination patterns. Tools that work against v3 may silently fail against v4 clusters, and vice versa.
iSCSI attachment lifecycle. Accessing VM disk data at block level requires creating a Volume Group, cloning the snapshot disk into it, attaching via iSCSI to the backup host, streaming the data, and then cleaning up all resources — including on panic or job abort. A single missed cleanup leaves orphaned VGs and snapshots on the cluster.
CBT state management. Efficient incrementals require tracking per-disk snapshot references across jobs, handling reference invalidation when retention policies delete prior snapshots, and managing disk resizes that invalidate the delta chain.
Cross-cluster and cross-vendor restore. Alternate-cluster restore requires image upload to a different Nutanix cluster, and cross-vendor restore (to Proxmox VE, VMware vSphere, or Hyper-V) requires qemu-img conversion of raw disk images into the target format.
DR replication. Continuous DR replication with bandwidth throttling, mid-push reconnect, and failover orchestration is a multi-component system that most open-source tools do not address at all.

2.3 The gap in the open-source ecosystem

Tool	AHV support	Verdict
PodHeitor Backup (native, no plugin)	File-level only — backs up raw VM virtual disk files via the host filesystem	Unsafe — no crash consistency, no CBT, no catalog integration
Bareos	No native AHV integration	File-level only; same risks as Bacula native
Amanda	No native AHV integration	File-level only
Nutanix Mine	Native, but requires separate Mine cluster hardware	High additional cost; no Bacula integration
Custom shell scripts via Prism API + acli	Partial — no catalog, no retry, no monitoring	Not production-grade

The gap is structural: no open-source-compatible solution integrated with Nutanix AHV at the API level — with CBT snapshots, iSCSI block streaming, multi-cluster support, and DR replication — until now.

2.4 The PodHeitor approach

The plugin follows the same design philosophy as the broader PodHeitor plugin family: built in Rust for memory safety and high production stability, phase-gated development with automated regression tests, panic-safe resource cleanup (no orphaned snapshots or Volume Groups), and a two-component architecture that isolates all Nutanix API interaction in a subprocess so that backend failures cannot corrupt the Bacula FD process.

3. Architecture overview

3.1 Two-component design

The plugin ships two binaries in a single package:

Component	File	Role
Bacula FD plugin	`/opt/bacula/plugins/podheitor-nutanix-fd.so`	Loaded by `bacula-fd` at runtime; implements the Bacula plugin API; minimal and stable
Backend binary	`/opt/bacula/bin/podheitor-nutanix-backend`	Forked per-job; performs all Nutanix API interaction, iSCSI operations, and DR transport

This split delivers three critical advantages:

Isolation. All Prism API calls, iSCSI attach/detach, and DR transport live in the backend. A backend crash or hang cannot corrupt the Bacula FD process.
Upgradability. The backend binary can be updated without restarting bacula-fd. Only the plugin touches the Bacula plugin ABI.
Testability. The backend can be exercised directly (--standalone health-check) without involving Bacula.

3.2 Internal communication channel

The plugin and backend communicate over an internal binary channel optimised for low latency in high-concurrency environments. This channel transports control commands, backup/restore data streams, and structured log messages — maintaining complete isolation between the Bacula FD process and the Nutanix integration logic.

3.3 Architecture diagram

  ┌───────────────────────────────────────────────────────────────────┐
  │  Bacula File Daemon (bacula-fd)                                    │
  │                                                                   │
  │   ┌───────────────────────────────────────────────────────────┐   │
  │   │  podheitor-nutanix-fd.so  (Rust plugin)                   │   │
  │   │                                                           │   │
  │   │  bEventJobStart ──► fork backend ──► write job params     │   │
  │   │  bEventBackupCommand ──► send control (mode=backup)       │   │
  │   │  bEventGetMoreData ◄── receive data packets (disk stream) │   │
  │   │  bEventRestoreCommand ──► send control (mode=restore)     │   │
  │   │  bEventSetFileAttributes ◄── write reconstructed disk     │   │
  │   └──────────────────────────┬────────────────────────────────┘   │
  │                              │ internal binary channel             │
  │   ┌──────────────────────────▼────────────────────────────────┐   │
  │   │  podheitor-nutanix-backend  (subprocess — Rust binary)     │   │
  │   │                                                           │   │
  │   │  ┌────────────────┐  ┌─────────────────┐  ┌──────────┐   │   │
  │   │  │ Backup (F2/F3) │  │ Restore (F4/F5) │  │  DR (F8) │   │   │
  │   │  │ Full + CBT Inc │  │ Same / alt-clust│  │ Repl+F/O │   │   │
  │   │  └───────┬────────┘  └────────┬────────┘  └────┬─────┘   │   │
  │   │          │                    │                 │          │   │
  │   │  ┌───────▼────────────────────▼─────────────────▼──────┐  │   │
  │   │  │  Prism Module (v3 / v4 auto-detect)                  │  │   │
  │   │  │  Auth · Clusters · VMs · Snapshots                   │  │   │
  │   │  │  Volume Groups · CRT · Rate Limiter                  │  │   │
  │   │  └─────────────────────┬────────────────────────────────┘  │   │
  │   │                        │ HTTPS (Prism Central 9440)         │   │
  │   │  ┌─────────────────────▼────────────────────────────────┐  │   │
  │   │  │  iSCSI Layer                                          │  │   │
  │   │  │  VG attach → O_DIRECT read → CBT stream              │  │   │
  │   │  └──────────────────────────────────────────────────────┘  │   │
  │   │                                                           │   │
  │   │  State: /opt/bacula/working/nutanix-repl/                 │   │
  │   │  Config: /opt/bacula/etc/nutanix.conf                     │   │
  │   └───────────────────────────────────────────────────────────┘   │
  └───────────────────────────────────────────────────────────────────┘
           │                                    │
           │ Bacula protocol (TCP)               │ PSK-TCP (DR, port 9848)
           ▼                                    ▼
  ┌──────────────────────┐           ┌────────────────────────────┐
  │  Bacula Storage      │           │  DR Receiver               │
  │  Daemon + Catalog    │           │  podheitor-nutanix-backend  │
  └──────────────────────┘           │  --standalone receiver      │
                                     │  (systemd unit per VM)     │
                                     └────────────────────────────┘

3.4 PHCBT01 delta stream format

Incremental backups are streamed in the PHCBT01 format — PodHeitor’s binary delta stream format shared across all VM-style plugins (Proxmox, VMware, Nutanix). PHCBT01 encodes only the CHANGED regions from the CBT response, with efficient handling of sparse regions. This format enables byte-identical chain reconstruction at restore time without re-reading unchanged blocks from storage.

3.5 State management

CBT reference state is stored per-disk under /opt/bacula/working/nutanix-repl/:

/opt/bacula/working/nutanix-repl/
  ├── vm-prod-01/
  │   ├── state.json          # last_snapshot_id per disk, backup level
  │   └── seed.bin            # DR seed image (if DR configured)
  ├── vm-prod-02/
  │   └── state.json
  └── vm-web-01/
      └── state.json

State is written atomically (write-rename) so that a crash between snapshot disarm and prior-reference cleanup at most leaves one leaked snapshot, which is operator-recoverable via acli snapshot.list. A stale-reference sweep runs on backend startup (job_cleanup_on_abort=yes) to recover orphaned iSCSI sessions and VGs from any prior abnormal exit.

4. Backup modes deep dive

4.1 Full backup (F2)

How it works

A Full backup creates a Nutanix v3/v4 application-consistent (or crash-consistent, per application_consistent=) snapshot of the target VM(s), then for each virtual disk: creates a Volume Group (VG) on the cluster, clones the snapshot disk into the VG, attaches the VG to the FD host via iSCSI, reads the raw block device using O_DIRECT (1 MiB chunks, 4 KiB-aligned), streams it to Bacula as a virtual file @nutanix/<vm>/disks/disk-<N>.raw, and then cleans up the VG and snapshot in strict reverse order.

  Prism Central API
    └── vm.snapshot_create (v3/v4)
          └── VG.create + VG.clone_disk
                └── iSCSI attach → O_DIRECT read
                      └── stream → Bacula Storage

Concurrency

Multiple VMs and multiple disks per VM are processed concurrently. concurrent_vms=2 controls the number of VMs being pre-staged simultaneously; concurrent_disks=4 controls parallel disk reads per VM, using bounded producer/consumer queues between the iSCSI reader and the data emitter.

Pros and cons

Aspect	Assessment
Coverage	Excellent — entire VM disk image captured
Consistency	Excellent — Nutanix snapshot is crash-consistent or app-consistent
Speed	Good — iSCSI block streaming; O_DIRECT bypasses page cache
Restore simplicity	Excellent — single stream, no chain dependencies
Bandwidth	High — full disk size; combine with `max_bandwidth_mbps` if needed
Chain dependency	None — self-contained

4.2 Incremental backup via CBT (F3)

How it works

After a Full backup, subsequent jobs at Level=Incremental use Nutanix’s Changed Regions Tracking (CRT) API to query only the disk regions that changed since the reference snapshot. The backend fetches the changed-regions list, coalesces adjacent CHANGED runs, splits them at chunk boundaries, and emits a PHCBT01-encoded stream containing only the modified data. The prior reference snapshot is preserved until the new snapshot is confirmed, then atomically promoted as the new reference.

  Full job (JobID=100):
    snapshot_ref_id = snap-abc → stored in state.json

  Incremental job (JobID=101):
    CRT query: GET /vms/{uuid}/snapshots/{snap-abc}/changed_regions
    → coalesce + split → PHCBT01 stream (only changed blocks)
    → Bacula storage (much smaller than Full)
    → new snapshot promoted as reference, snap-abc deleted

Pros and cons

Aspect	Assessment
Coverage	Excellent — captures all changed blocks since reference snapshot
Speed	Excellent — typically 5–10× smaller than Full for active VMs
Restore	Good — requires chain reconstruction (Full + N Incrementals)
Chain dependency	Required — reference snapshot must not be externally deleted
API version	v3 (primary) + v4 (full support from F3.5 — DRP-based CRT)

4.3 DR replication (F8)

How it works

DR replication operates in two phases: an initial seed push and recurring bitmap-push delta cycles. The SOURCE side runs mode=seed to push the full disk image to the DR receiver over PSK-authenticated TCP on port 9848 (configurable). Subsequent mode=bitmap-push cycles push only the CBT-identified changed blocks as a compact delta bitmap. The receiver stores seeds and bitmaps under its own state_dir and can reconstruct the full point-in-time image at any cycle boundary.

  SOURCE (primary cluster)                DR SITE (receiver host)
  ─────────────────────────────           ─────────────────────────────
  mode=seed                               mode=receiver
    VG attach → stream full disk  ──────►   Write seed to state_dir
    Bitmap snapshot taken                   Seed confirmed

  mode=bitmap-push (every 300s)
    CRT delta → compact bitmap    ──────►   Apply delta to seed image
    mid-push reconnect on failure           Cycle state persisted

Failover modes (F8.4)

Four failover modes cover the full DR lifecycle:

failover-test — Boots a clone in an isolated VLAN; receiver state unchanged. Use for regular DR drills without affecting production.
failover-planned — Quiesces the source VM, promotes the receiver, powers on the DR copy. Use for planned maintenance failovers.
failover-unplanned — Promotes the receiver without source quiesce. Use when the source cluster is unreachable.
failover-undo — Tears down a failover-test clone and releases state-dir disk space.
failover-perm — Final cutover; receiver becomes the new source of truth. Re-pair to reverse direction.

4.4 Cross-vendor INBOUND restore (F6)

The cross_restore=yes flag enables restoring a Nutanix AHV backup to a non-AHV hypervisor. The backend converts the raw disk image to the target format using qemu-img convert and uploads it to the target platform’s image service. Supported targets include Proxmox VE (qcow2), VMware vSphere (vmdk), and Microsoft Hyper-V (vhd/vhdx). This is particularly valuable for disaster recovery to a dissimilar hypervisor or for migration testing.

5. Feature matrix

Feature	Support	Notes
Full backup (F2)	Yes	iSCSI block streaming + automatic cleanup
Incremental backup via CBT (F3)	Yes	PHCBT01 delta stream; v3 + v4 CRT
Multi-VM concurrency	Yes	`concurrent_vms=` (default 2)
Multi-disk concurrency per VM	Yes	`concurrent_disks=` (default 4)
VM glob/pattern selection	Yes	`vm=prod-*`, CSV, UUID
VM exclusion patterns	Yes	`exclude=temp-*`
Application-consistent snapshot	Yes	`application_consistent=true\|try\|false`
Same-cluster restore (F4)	Yes	Native AHV VM creation
Alternate-cluster restore (F5)	Yes	Image upload + VM materialize on target cluster
Cross-vendor INBOUND restore (F6)	Yes	qemu-img to Proxmox/vSphere/Hyper-V
Cross-cluster vCPU/memory override	Yes	`--vcpu` / `--memory-mib` on restore
Network remapping on restore	Yes	`network_map=src=dst,...`
Selective disk restore	Yes	`restore_disks_only=disk-0,disk-2`
Power-on after restore	Yes	`power_on=yes`
DR replication seed (F8.1)	Yes	Full disk push over PSK-TCP
DR bitmap-push delta (F8.2)	Yes	CBT-derived delta push with reconnect
Bandwidth throttling	Yes	`max_bandwidth_mbps=` token-bucket
Mid-push reconnect	Yes	Resumes from last-acked cycle boundary
Failover-test (drill)	Yes	Isolated VLAN clone; state unchanged
Failover-planned	Yes	Quiesce + promote + power-on target
Failover-unplanned	Yes	Promote without source quiesce
Failover-undo	Yes	Tear down test clone
Failover-perm (cutover)	Yes	Receiver becomes new source of truth
Multi-instance DR receiver	Yes	systemd template; per-VM state isolation
Prism v3 API	Yes	Primary path
Prism v4 API	Yes	Auto-detected; falls back to v3
Multi-cluster Prism Central	Yes	`cluster=` name or UUID
TLS verification	Yes	Secure by default; `prism_insecure=yes` for lab only
mTLS for DR channel	Yes	`dr_auth_cert` / `dr_auth_key` / `dr_ca_cert`
Standalone health-check	Yes	RBAC + DSIP probes pre-flight
Dry-run size estimate	Yes	`mode=estimate`
Instant Recovery (F9)	Roadmap	Separate Bacula-SD plugin (granular-restore + IR)
File-level granular restore (F10)	Roadmap	Separate Bacula-SD plugin
ARM64 support	Roadmap	x86_64 only in v2.0.0

6. Installation guide

6.1 Prerequisites

PodHeitor Backup Edition File Daemon 15.0.3+ running on Oracle Linux 9 / RHEL 9 / Ubuntu 22.04 / Ubuntu 24.04 (x86_64)
qemu-img available on PATH (required for F5 / F6 cross-cluster and cross-vendor restore)
iscsiadm (open-iscsi) reachable when data_path=iscsi is used (default)
Network connectivity from the FD host to Prism Central HTTPS (default port 9440) and the cluster Data-Services IP (DSIP) over iSCSI port 3260
A Prism RBAC service account with Backup Admin, VM Admin, and Cluster Admin (read-only) roles on the cluster scope

Distribution is via official packages (RPM/DEB) under contract only. To access the current release, contact the PodHeitor team.

6.2 Package installation

RPM (Oracle Linux 9 / RHEL 9 / Rocky / Alma)

sudo dnf install ./podheitor-nutanix-plugin-2.0.0-1.el9.x86_64.rpm

DEB (Ubuntu 22.04 / Ubuntu 24.04)

sudo apt install ./podheitor-nutanix-plugin_2.0.0-1_amd64.deb

Tarball (any glibc 2.34+ x86_64)

tar -xzf podheitor-nutanix-plugin-2.0.0.tar.gz
cd podheitor-nutanix-plugin-2.0.0
sudo ./install.sh

All three install paths place the following files on the system:

Path	Contents
`/opt/bacula/plugins/podheitor-nutanix-fd.so`	FD plugin loaded by `bacula-fd`
`/opt/bacula/bin/podheitor-nutanix-backend`	Backend binary
`/opt/bacula/etc/nutanix.conf.example`	Annotated configuration template
`/opt/bacula/working/nutanix-repl/`	State directory (CBT references, seeds, bitmaps)
`/lib/systemd/system/podheitor-nutanix-receiver.service`	DR receiver systemd unit (single-instance)
`/lib/systemd/system/podheitor-nutanix-receiver@.service`	DR receiver systemd template (per-VM)
`/etc/logrotate.d/podheitor-nutanix`	Log rotation configuration

6.3 Initial configuration

sudo cp /opt/bacula/etc/nutanix.conf.example /opt/bacula/etc/nutanix.conf
sudoedit /opt/bacula/etc/nutanix.conf
sudo chown root:bacula /opt/bacula/etc/nutanix.conf
sudo chmod 0640 /opt/bacula/etc/nutanix.conf

Minimum required keys in nutanix.conf:

prism_central     = pc.example.com
user              = backup-svc
passfile          = /opt/bacula/etc/nutanix.secrets
state_dir         = /opt/bacula/working/nutanix-repl

Place the Prism password in /opt/bacula/etc/nutanix.secrets (mode 0600, owner root:bacula):

password = your-prism-service-account-password

6.4 Pre-flight validation

/opt/bacula/bin/podheitor-nutanix-backend
    --standalone health-check
    --config /opt/bacula/etc/nutanix.conf

The health-check probe validates in order: (1) Prism Central TLS reachability, (2) RBAC authentication, (3) cluster enumeration, (4) RBAC role confirmation, (5) DSIP discovery and iSCSI port 3260 probe. Exit code 0 means the FD host is ready to run backup jobs.

6.5 DR receiver setup (optional)

For single-instance DR (one receiver protecting all VMs):

sudoedit /opt/bacula/etc/nutanix.conf   # set dr_auth_token, state_dir
sudo systemctl enable --now podheitor-nutanix-receiver
sudo systemctl status podheitor-nutanix-receiver

For per-VM isolation (recommended in production):

sudo cp /opt/bacula/etc/nutanix.conf /opt/bacula/etc/nutanix-vm-prod-01.conf
sudoedit /opt/bacula/etc/nutanix-vm-prod-01.conf   # distinct dr_port and state_dir
sudo systemctl enable --now podheitor-nutanix-receiver@vm-prod-01.service

7. Configuration reference

7.1 Connection parameters

Key	Type	Default	Description
`prism_central`	host[:port]	—	Prism Central hostname or IP, reachable from the FD host
`prism_port`	int	`9440`	Prism Central HTTPS port
`prism_api_version`	`auto`\|`v3`\|`v4`	`auto`	`auto` probes v4 first; falls back to v3
`user`	string	—	Prism RBAC user (must exist in IAM, not just LDAP pass-through)
`password`	string	—	Inline password; prefer `passfile` for security
`passfile`	path	—	Path to file containing `password = …`; mode `0600`
`prism_insecure`	bool	`no`	Skip TLS certificate verification; lab use only. Emits a WARNING on every job.
`cluster`	string	—	Cluster name or UUID when Prism Central manages multiple clusters

7.2 Backup selection parameters

Key	Type	Default	Description
`vm`	csv/glob	`*`	VM UUID, exact name, or glob pattern (`prod-*`). Multiple values comma-separated.
`exclude`	csv/glob	—	Exclusion patterns applied after `vm=` matching
`application_consistent`	`true`\|`try`\|`false`	`try`	`try`: attempt app-consistent, fall back gracefully; `true`: fail job if app-consistent is unavailable

7.3 Data path parameters

Key	Type	Default	Description
`data_path`	`auto`\|`iscsi`\|`rest`	`auto`	Transport selection. `iscsi` is recommended for throughput.
`dsip`	IPv4	probed	Explicit Data-Services IP override. Set this in production to avoid probe failures.
`iscsi_initiator`	string	auto	iSCSI IQN override. Auto-detected from `/etc/iscsi/initiatorname.iscsi`.
`concurrent_vms`	int	`2`	Maximum number of VMs being pre-staged (snapshot + VG attach) simultaneously
`concurrent_disks`	int	`4`	Maximum parallel disk reads per VM
`chunk_size_mib`	int	`1`	iSCSI read chunk size in MiB. Larger values improve sequential throughput; must be 4 KiB-aligned.
`prism_rate_rpm`	int	`30`	Client-side Prism API rate cap (requests per minute)

7.4 Restore parameters (F4 / F5 / F6)

Key	Type	Default	Description
`mode`	enum	`backup`	See section 7.6 for full list of mode values
`where`	path	—	Bacula restore prefix; normally set automatically by the Director
`restore_vm_name`	string	`<orig>-restored`	Name for the restored VM on the target cluster
`target_cluster`	string	source	Alternate cluster name or UUID for F5 cross-cluster restore
`target_container`	string	source	AHV storage container on the target cluster
`network_map`	csv	—	Source-to-destination subnet remapping: `src=dst,src2=dst2`
`power_on`	bool	`no`	Power on the restored VM after creation completes
`restore_disks_only`	csv	—	Restore only listed disks: `disk-0,disk-2`
`--vcpu`	int	source	Override vCPU count on cross-cluster restore for rightsizing
`--memory-mib`	int	source	Override memory (MiB) on cross-cluster restore for rightsizing
`cross_restore`	bool	`yes`	Accept foreign-hypervisor streams for F6 restore

7.5 DR replication parameters (F8)

Key	Type	Default	Description
`dr_host`	host	—	DR receiver hostname or IP (set on the SOURCE side)
`dr_port`	int	`9848`	DR receiver TCP port
`dr_auth_token`	string	—	Pre-shared key for authentication. Generate with: `openssl rand -hex 32`
`dr_auth_cert`	path	—	mTLS client certificate path (optional)
`dr_auth_key`	path	—	mTLS client key path
`dr_ca_cert`	path	—	CA certificate for receiver TLS verification
`dr_restore_points`	int	`7`	Number of DR recovery points retained on the receiver
`max_bandwidth_mbps`	int	`0`	DR transport bandwidth cap in Mbit/s. `0` = unlimited.
`push_interval`	int	`300`	Seconds between bitmap-push delta cycles
`push_apply_remote`	bool	`yes`	Apply incoming deltas write-through on the receiver (recommended)

7.6 Logging and scratch parameters

Key	Type	Default	Description
`verbose`	0–3	`1`	Log verbosity: 0=errors only, 1=normal, 2=debug, 3=trace (very chatty)
`debug_log`	path	`/opt/bacula/working/podheitor-nutanix-backend.log`	Backend log file path
`working_dir`	path	`/opt/bacula/working`	Scratch root for temporary files
`state_dir`	path	`/opt/bacula/working/nutanix-repl`	Persistent state directory (CBT references, seeds, bitmaps)
`job_cleanup_on_abort`	bool	`yes`	Stale-resource sweep on backend startup (iSCSI sessions, VGs, orphaned snapshots)

7.7 Mode values

Value	Phase	Use
`backup`	F2/F3	Default — Full or Incremental per the Bacula Job Level
`restore`	F4	Native restore on same cluster
`estimate`	F2	Dry-run size estimate without streaming data
`receiver`	F8	Listen for SEED + DELTA frames on the DR receiver
`seed`	F8	Push initial full-disk seed to the receiver
`bitmap-push`	F8	Push CBT delta bitmap to receiver
`failover-test`	F8.4	Boot a clone in an isolated VLAN; receiver state unchanged
`failover-planned`	F8.4	Quiesce source → promote receiver → power-on target
`failover-unplanned`	F8.4	Promote receiver without source quiesce (source unreachable)
`failover-undo`	F8.4	Tear down a `failover-test` clone and release state-dir space
`failover-perm`	F8.4	Final cutover; receiver becomes the new source of truth

8. FileSet examples

8.1 Basic full + incremental backup of all VMs

FileSet {
  Name = "Nutanix-All-VMs"
  Include {
    Options {
      signature = SHA1
      compression = LZ4
    }
    Plugin = "podheitor-nutanix: prism_central=pc.example.com
             passfile=/opt/bacula/etc/nutanix.secrets vm=*"
  }
}

8.2 Production VMs only, application-consistent, with concurrency

FileSet {
  Name = "Nutanix-Prod-AppConsistent"
  Include {
    Options {
      signature = SHA256
      compression = LZ4
    }
    Plugin = "podheitor-nutanix: prism_central=pc.prod.example.com
             passfile=/opt/bacula/etc/nutanix.secrets
             vm=prod-* exclude=prod-test-*
             application_consistent=true
             concurrent_vms=4 concurrent_disks=8
             cluster=prod-cluster-01"
  }
}

8.3 Alternate-cluster restore (cross-cluster DR)

FileSet {
  Name = "Nutanix-CrossCluster-Restore"
  Include {
    Options { signature = SHA1 }
    Plugin = "podheitor-nutanix: prism_central=pc.dr.example.com
             passfile=/opt/bacula/etc/nutanix.secrets
             mode=restore
             target_cluster=dr-cluster-01
             target_container=default-container
             network_map=10.10.0.0/24=10.20.0.0/24
             power_on=yes
             restore_vm_name=prod-vm-dr-copy"
  }
}

8.4 DR replication seed + bitmap-push schedule

# FileSet for DR seed push (run once to establish the seed)
FileSet {
  Name = "Nutanix-DR-Seed"
  Include {
    Options { signature = SHA1 }
    Plugin = "podheitor-nutanix: prism_central=pc.example.com
             passfile=/opt/bacula/etc/nutanix.secrets
             vm=prod-db-01 mode=seed
             dr_host=dr-receiver.example.com
             dr_port=9848
             dr_auth_token=YOUR_PSK_HERE"
  }
}

# FileSet for recurring bitmap-push (scheduled every 5 minutes)
FileSet {
  Name = "Nutanix-DR-BitmapPush"
  Include {
    Options { signature = SHA1 }
    Plugin = "podheitor-nutanix: prism_central=pc.example.com
             passfile=/opt/bacula/etc/nutanix.secrets
             vm=prod-db-01 mode=bitmap-push
             dr_host=dr-receiver.example.com
             dr_port=9848
             dr_auth_token=YOUR_PSK_HERE
             max_bandwidth_mbps=200
             push_interval=300"
  }
}

8.5 Cross-vendor INBOUND restore to Proxmox VE

FileSet {
  Name = "Nutanix-To-Proxmox-Restore"
  Include {
    Options { signature = SHA1 }
    Plugin = "podheitor-nutanix: prism_central=pc.example.com
             passfile=/opt/bacula/etc/nutanix.secrets
             mode=restore cross_restore=yes
             --vcpu=4 --memory-mib=8192
             restore_vm_name=migrated-from-nutanix"
  }
}

8.6 Corresponding Bacula Job definitions

Job {
  Name        = "NutanixProdFull"
  Type        = Backup
  Level       = Full
  Client      = nutanix-fd
  FileSet     = "Nutanix-Prod-AppConsistent"
  Schedule    = "WeeklyCycle"
  Storage     = File
  Pool        = NutanixPool
  Messages    = Standard
  Write Bootstrap = "/opt/bacula/working/NutanixProdFull.bsr"
}

Job {
  Name        = "NutanixProdIncremental"
  Type        = Backup
  Level       = Incremental
  Client      = nutanix-fd
  FileSet     = "Nutanix-Prod-AppConsistent"
  Schedule    = "DailyCycle"
  Storage     = File
  Pool        = NutanixPool
  Messages    = Standard
}

9. Sizing & capacity planning

9.1 FD host requirements

Resource	Minimum	Recommended	Notes
CPU	4 cores	8+ cores	Each concurrent disk reader uses ~1 core
RAM	4 GB	8 GB	1 MiB chunk buffer per disk × concurrent_disks
Scratch disk IOPS	1,000 IOPS	5,000+ IOPS	Used for F5/F6 restore staging and DR seed storage
Scratch disk capacity	200 GB	2× largest VM disk	For F4/F5 reconstruction staging and DR seed images
Network to Prism Central	100 Mbit/s	1 Gbit/s	iSCSI block streaming is the bottleneck — 10 GbE recommended for large VMs
Network to DR receiver	10 Mbit/s	100+ Mbit/s	DR bitmap-push can be throttled with `max_bandwidth_mbps=`

9.2 Bacula volume storage sizing

Full backup size: approximately equal to the sum of provisioned disk sizes minus sparse/zero regions
Incremental backup size: typically 5–15% of Full size for active VMs with moderate write rates; database VMs may be larger
Retention formula: Total = Full_size + (Incrementals_per_cycle × avg_Inc_size × retention_days)
Compression: LZ4 in Bacula FileSet options typically achieves 20–40% reduction on uncompressed VM disk data

9.3 DR receiver sizing

Seed storage: 1× total disk capacity per protected VM
Bitmap storage: approximately 1 MB per TB of disk per cycle (very small)
State directory IOPS: write-intensive during seed; read-intensive during failover-test
Memory per receiver instance: approximately 256 MB idle; 1–2 GB during active seed push

10. Performance report

The PodHeitor Nutanix AHV Backup Plugin was validated through a structured lab test programme on Nutanix Community Edition 6.8.1 (single node, nested on Proxmox VE 8) and through unit and integration tests on Oracle Linux 9 with PodHeitor Backup Edition 15.0.3.

Metric	Observed / Expected	Conditions
Full backup throughput (iSCSI)	400–800 MB/s	10 GbE, O_DIRECT, 1 MiB chunks, SSD-tier AHV storage
Incremental backup size reduction	85–95% vs Full	Typical production VM, ~5–15% 24h change rate
Prism API rate cap (client-side)	30 req/min (configurable)	Token-bucket applied to avoid Prism Central 429 errors
DR seed throughput	Up to `max_bandwidth_mbps`	Token-bucket throttle; `0` = line speed
Mid-push reconnect overhead	<5 s typical	TCP reconnect + resume from last-acked cycle boundary
Health-check latency	<10 s	Full RBAC + DSIP probe sequence on LAN
Backend startup overhead	<200 ms	Stale-resource sweep + Prism auth on LAN
Multi-VM concurrency scaling	Near-linear up to `concurrent_vms`	Bounded by Prism API rate and iSCSI bandwidth

Lab-validated, production-ready. These values represent best-observed results under controlled conditions; actual performance varies with cluster load, network topology, and VM disk profiles.

11. Compatibility matrix

11.1 Bacula components

Component	Version	Notes
PodHeitor Backup Edition File Daemon	15.0.3+	Required — older versions lack complete metaplugin semantics
Bacula Director	15.0.3+	Any matching CE Director
Bacula Storage Daemon	15.0.3+	Any matching CE Storage Daemon

11.2 Operating systems (FD host)

OS	Status	Package
Oracle Linux 9	Supported (primary build target)	RPM
RHEL 9 / Rocky Linux 9 / AlmaLinux 9	Supported	RPM
Ubuntu 22.04 LTS	Supported	DEB
Ubuntu 24.04 LTS	Supported	DEB
Debian 12	Best effort	Tarball
Other glibc 2.34+ x86_64	Best effort	Tarball
RHEL 8 / OL 8	Not supported	glibc version incompatible with distributed binary
ARM64 (aarch64)	Roadmap	—

11.3 Nutanix platform

Surface	Tested	Notes
AOS 6.x (Prism Central + Element)	Yes	Primary test baseline
AOS 7.x	Yes	Tested in lab environment
Nutanix Community Edition 6.8.1	Yes	Lab — nested on Proxmox VE 8
Prism Central API v3	Yes	Primary path; always available
Prism Central API v4	Yes	Auto-detected; full DRP-based CRT support
Single-cluster PC	Yes	Default configuration
Multi-cluster PC	Yes	Use the `cluster=` parameter

11.4 Hypervisor restore targets

Hypervisor	Backup (source)	INBOUND restore (F6)	Notes
Nutanix AHV	Yes	Yes (F4 same cluster, F5 alternate cluster)	Full native support
Proxmox VE	Use sibling plugin	Yes (qemu-img → qcow2)	Unit-tested
VMware vSphere	Use sibling plugin	Yes (qemu-img → vmdk)	Unit-tested
Microsoft Hyper-V	Use sibling plugin	Yes (qemu-img → vhd/vhdx)	Unit-tested

12. Security

12.1 Credential handling

The plugin implements a least-privilege credential model:

Prism credentials are never passed inline in command-line arguments visible to ps. The passfile= parameter points to a file with mode 0600, owned root:bacula, readable only by the FD process.
The inline password= parameter is supported for compatibility but emits a WARNING on every job, prompting migration to passfile.
DR PSK tokens (dr_auth_token) must be generated with openssl rand -hex 32 (256 bits of entropy) and stored in the configuration file with mode 0640. They are never written to Bacula job logs.
All sensitive parameters are redacted from logs at verbose=1; only intentional debug traces at verbose=3 may include partial values.

12.2 Prism RBAC posture

The service account used for backups requires exactly three roles on the cluster scope:

Backup Admin — snapshot create/delete and Volume Group operations
VM Admin — VM enumeration and VM creation for restore
Cluster Admin (read-only) — cluster discovery and DSIP query

The health-check verb confirms all three roles are present before any job is executed.

12.3 Transport security

Prism Central HTTPS: TLS verification enabled by default. The prism_insecure=yes flag disables it for labs with self-signed certificates and emits a persistent WARNING.
DR replication channel: PSK-authenticated with HMAC-SHA256 per frame. Optional mTLS upgrade via dr_auth_cert / dr_auth_key / dr_ca_cert.
Internal Bacula communications: protected by the existing Bacula TLS configuration; the plugin does not bypass or weaken the Bacula channel security.

12.4 Process isolation

The backend runs as a bacula-fd subprocess with inherited UID/GID (bacula:bacula by default). It does not acquire additional privileges. The backend never writes outside working_dir and state_dir.

13. Monitoring

13.1 Log sources

Source	Path / Command	Content
Backend log	`/opt/bacula/working/podheitor-nutanix-backend.log`	All backend activity — Prism calls, iSCSI events, PHCBT01 statistics, errors
FD log	`/opt/bacula/working/<fd-host>-fd.log`	Plugin loading, messages forwarded to the Director
DR receiver log (single)	`journalctl -u podheitor-nutanix-receiver`	Seed receipt, bitmap-push application, failover state transitions
DR receiver log (per-VM)	`journalctl -u podheitor-nutanix-receiver@vm-prod-01`	Per-VM receiver activity
Bacula job log	Bacula Director Console / Bweb / Baculum	Backend messages: version, phase, selected VMs, disk count, errors

13.2 Key messages to monitor

Message	Meaning	Action if absent
`podheitor-nutanix backend up (v2.0.0) phase=F2 mode=Backup vm=…`	Backend started successfully	Check plugin loading in the FD log
`Prism discovery: PC=… cluster=… capability=v3\|v4`	Prism Central reachable and API version determined	Run `--standalone health-check`
`Selected N VM(s) for backup`	VM glob matched N virtual machines	Check `vm=` pattern and Prism connectivity
`Backup complete: VM=… disks=N bytes=B`	All disks for a VM streamed successfully	Check backend log if absent
`DR cycle complete: vm=… cycle=N bytes_pushed=B`	Bitmap-push cycle completed	Check receiver log and network path

13.3 Prometheus / metrics integration

The backend does not expose a native Prometheus endpoint in v2.0.0. The recommended monitoring pattern uses a log-scraping exporter (e.g., mtail or grok_exporter) against the backend log. Suggested metrics to derive:

Metric name	Derived from	Alert threshold
`nutanix_backup_bytes_total{vm,type}`	`Backup complete: bytes=B`	Zero bytes = empty backup (warning)
`nutanix_backup_duration_seconds{vm}`	Backend start/completion timestamps	> 4× moving average (anomaly)
`nutanix_dr_cycle_bytes_pushed{vm}`	`DR cycle complete: bytes_pushed=B`	Sustained zero = replication stalled
`nutanix_dr_reconnect_total{vm}`	`mid-push reconnect` log lines	> 5/hour = unstable network path
`nutanix_prism_api_errors_total{endpoint}`	`Prism API error` log lines	Any sustained error
`nutanix_iscsi_attach_failures_total`	`iSCSI attach failed` log lines	Any = investigate DSIP / initiator

14. Troubleshooting guide

14.1 Where to look first

# Verbose backend log (most detail)
tail -100 /opt/bacula/working/podheitor-nutanix-backend.log

# Increase verbosity for active debugging
# In nutanix.conf: verbose = 2   (debug) or verbose = 3 (trace)

# Run standalone health-check
/opt/bacula/bin/podheitor-nutanix-backend
    --standalone health-check
    --config /opt/bacula/etc/nutanix.conf

# DR receiver status
journalctl -u podheitor-nutanix-receiver --since "1 hour ago"

14.2 Common failures and fixes

Symptom	Root cause	Fix
`401 Unauthorized` on first Prism request	Service account not found in Prism IAM; or `passfile` not readable by the FD process	Check IAM user exists in Prism. Check `chown root:bacula /opt/bacula/etc/nutanix.secrets && chmod 0600 nutanix.secrets`
`403 Forbidden` on snapshot create	Service account missing Backup Admin role on the cluster scope	In Prism → IAM → Roles → Assignments, add Backup Admin for the cluster scope
Incremental keeps running as Full	Reference snapshot deleted by cluster retention policy	Check backend log for `reference_snapshot not found`
iSCSI connect failure: `No portal available`	Incorrect or unreachable DSIP, or FD host IQN not allowed on the cluster	Set `dsip=192.168.x.y`. Add FD IQN to the cluster volume-group allowlist via Prism.
`qemu-img: command not found` during F5/F6 restore	`qemu-img` not installed or not on PATH for the `bacula` user	`dnf install qemu-img` (RHEL) or `apt install qemu-utils` (Ubuntu).
DR receiver in restart loop	`dr_auth_token` mismatch between SOURCE and RECEIVER configs; `state_dir` not writable	Confirm tokens match. Check `chmod 750 /opt/bacula/working/nutanix-repl/`.
Multi-instance receiver: cross-VM state	Two instances sharing the same `state_dir`	Each per-VM config must have a distinct `state_dir`.
`TLS handshake failed` on Prism connection	Self-signed certificate on the cluster	Lab only: add `prism_insecure=yes`. Production: install a valid certificate on Prism Central.

14.3 Failover state reference

Mode	VM on source	VM on receiver	Receiver state
`failover-test`	Intact	Booted in isolated VLAN	Unchanged
`failover-planned`	Quiesced + shut down	Powered on	Promoted
`failover-unplanned`	Unreachable	Powered on	Promoted
`failover-undo`	Intact	Test clone deleted	Unchanged
`failover-perm`	(manual cleanup needed)	Promoted	Becomes new SOURCE

15. Use cases & deployment scenarios

15.1 Daily backup of production Nutanix VMs

An organisation with 50 production VMs on a Nutanix AHV cluster wants full weekend backups and nightly incrementals Monday through Friday, with 30-day retention. The PodHeitor plugin is installed on a dedicated Bacula FD host with 10 GbE connectivity to the Prism DSIP. A single FileSet with vm=prod-* and concurrent_vms=4 drives the entire backup programme. Monthly restore tests use a Job with mode=restore pointing at an isolated test cluster.

15.2 Disaster recovery with continuous replication

A financial services company requires sub-5-minute RPO for its 10 Tier-1 database VMs. The DR replication stack is deployed with per-VM systemd template units on a receiver host at the DR site (300 km away, connected via 100 Mbit/s MPLS). Each VM runs an independent receiver with its own state_dir, dr_port, and PSK. The push_interval=300 setting triggers bitmap-push cycles every 5 minutes. Monthly failover-test drills confirm recoverability without disrupting production.

15.3 VMware vSphere to Nutanix AHV migration

An organisation migrating from VMware vSphere to Nutanix AHV uses the PodHeitor VMware sibling plugin to back up vSphere VMs, then uses the Nutanix plugin’s cross_restore=yes (F6 INBOUND) path to restore converted disk images onto the target AHV cluster. The --vcpu and --memory-mib overrides allow rightsizing VMs during migration without modifying the source.

15.4 Multi-cluster Nutanix environment

A managed service provider operates three Nutanix clusters under a single Prism Central. They use a single nutanix.conf pointing prism_central= at the PC, and separate FileSets per cluster using the cluster= parameter. Cross-cluster restore scenarios use target_cluster= on the restore Job. The health-check verb is run via an Ansible playbook as part of weekly infrastructure checks.

15.5 Air-gapped environment with Bacula tape storage

A government agency operates an air-gapped Nutanix environment. All backups flow through a Bacula infrastructure backed by LTO tape. The PodHeitor plugin streams VM disk data directly to the Bacula tape pool — no intermediate disk staging required. The max_bandwidth_mbps= parameter limits backup traffic to avoid saturating the internal network during business hours.

16. Comparison with other approaches

Capability	PodHeitor Nutanix Plugin	Bacula Enterprise (Nutanix)	Veeam Data Platform	Commvault Complete	NetBackup
Backup engine	PodHeitor Backup+	Bacula Enterprise 15.x	Veeam B&R	Commvault	Veritas NetBackup
CBT-based incrementals	Yes	Yes	Yes	Yes	Yes
iSCSI block-level streaming	Yes	Yes	Yes (HotAdd/NBD)	Yes	Yes
Native Prism API integration	Yes (v3 + v4)	Yes	Partial	Partial	Partial
Cross-cluster restore	Yes (F5)	Yes	Yes	Yes	Yes
Cross-vendor restore (qemu-img)	Yes (F6 — Proxmox, vSphere, Hyper-V)	Limited	No	No	No
Built-in DR replication	Yes (PSK-TCP, seed + delta + failover)	Yes	Yes (replication jobs)	Yes	Yes
Failover orchestration	Yes (4 modes)	Yes	Yes (SureBackup)	Yes	Limited
Multi-cluster Prism Central	Yes	Yes	Yes	Yes	Yes
Instant Recovery (F9)	Roadmap	Yes	Yes	Yes	Yes
File-level granular restore (F10)	Roadmap	Yes	Yes	Yes	Yes
Open-source backup engine	Yes (PodHeitor Backup)	No (proprietary)	No	No	No
Language	Rust (memory-safe, no GC)	C/C++ legacy	C# / .NET	Java / C++	C/C++ legacy
Typical annual licensing cost	Fraction of alternatives*	~US$ 10,000+/year	~US$ 5,000+/year	~US$ 10,000+/year	~US$ 10,000+/year
Plugin licence model	Proprietary	Proprietary	Proprietary	Proprietary	Proprietary

* Contact PodHeitor International for current pricing. The 50% savings claim is benchmarked against published list prices for equivalent feature sets.

Note on Bacula Enterprise: Bacula Enterprise is a valid and mature alternative with a broader feature set (including Instant Recovery and granular restore in a single product). The PodHeitor plugin is positioned as a cost-effective alternative for organisations already invested in PodHeitor Backup infrastructure that want production-grade Nutanix AHV integration without a full Bacula Enterprise licensing commitment.

17. Roadmap

17.1 v2.x — Stability & ecosystem (H2 2026)

F7 — Cross-restore OUTBOUND: Enable Nutanix AHV VMs to be restored to other hypervisors (Proxmox VE, VMware vSphere, Hyper-V).
F3.5 / F3.6 — v4 CRT stabilisation: Live E2E validation on a v4-only cluster to confirm full coverage against all AOS 7.x GA response formats.
F4.5 — Image Service upload and VM creation: Complete the F4 restore path connecting disk reconstruction to Prism Image Service upload and full VM materialisation.
ARM64 build: Cross-compilation target for aarch64 Linux to support organisations running Bacula FD on Arm-based infrastructure.
Prometheus exporter endpoint: Expose an HTTP /metrics endpoint on a configurable port for native Prometheus scraping.

17.2 v3.x — Advanced recovery (H1 2027)

F9 — Instant Recovery: Boot VM directly from the replica without a full restore — delivered by the PodHeitor Bacula-SD granular restore plugin.
F10 — File-level granular restore: Mount reconstructed VM disks and expose individual files via the Bacula restore browser.
Multi-tenant mode: Dedicated RBAC scopes per tenant within a shared Prism Central for managed service provider deployments.
Cloud-native target support: Direct DR replication to S3-compatible object storage as an alternative to a dedicated receiver host.

17.3 Ongoing

Tracking Nutanix AOS and Prism Central API releases
Continuous regression testing against the Nutanix Community Edition lab environment
Performance optimisations for very large VMs (> 4 TiB on a single disk)

18. Conclusion

The PodHeitor Nutanix AHV Backup Plugin for Bacula represents a significant advance for the open-source backup ecosystem. It brings production-grade Nutanix AHV protection — including CBT-based incrementals, multi-cluster support, cross-vendor restore, and a full DR replication and failover stack — within reach of any organisation running PodHeitor Backup Edition, without requiring a full migration to a commercial backup platform.

The plugin’s architecture — built in Rust with native memory safety and no GC pauses, subprocess isolation, and over 50 automated tests — makes it a reliable foundation for mission-critical backup workflows. The standalone health-check verb, per-VM DR systemd templates, and structured logging give operations teams the visibility and control needed to maintain a defensible backup posture.

For organisations facing renewals of commercial backup platforms — particularly those evaluating Veeam, Commvault, or NetBackup for Nutanix AHV — the PodHeitor plugin offers a comparable alternative at 50% or more savings, with a feature set tailored specifically to the Nutanix platform.

Licensing

PodHeitor Nutanix AHV Backup Plugin is proprietary software distributed by subscription. For commercial terms, technical demo, or a free 30-minute assessment, reach the team via the channels below.

Ready to evaluate?

💬 WhatsApp: +1 (786) 726-1749
✉️ Email: heitor@opentechs.lat
🩺 Free assessment — 30 min with Heitor Faria

19. Contact information

Channel	Details
Name	Heitor Faria — PodHeitor International
Website	https://podheitor.com
Email	heitor@opentechs.lat
Phone / WhatsApp (International)	+1 786 726-1749
Phone / WhatsApp (Brazil)	+55 61 98268-4220
Plugin documentation	https://podheitor.com/plugins/nutanix-ahv
Support	Email with subject: PodHeitor Nutanix Plugin Support

For enterprise contracts, Heitor Faria provides professional services including installation, integration with existing Bacula Directors, DR runbook design, and production go-live support.

20. Legal / copyright

The PodHeitor Nutanix AHV Backup Plugin for Bacula is distributed under LicenseRef-PodHeitor-Proprietary. Contact heitor@opentechs.lat for commercial licensing terms.

Trademarks: PodHeitor and the PodHeitor logo are trademarks of Heitor Faria / PodHeitor International. Nutanix, AHV, Prism, Prism Central, Prism Element, AOS, and Nutanix Community Edition are trademarks or registered trademarks of Nutanix, Inc. Bacula and Bacula Enterprise are registered trademarks of Bacula Systems SA. Veeam is a registered trademark of Veeam Software AG. Commvault is a registered trademark of Commvault Systems, Inc. NetBackup and Veritas are registered trademarks of Veritas Technologies LLC. VMware and vSphere are registered trademarks of VMware, Inc. (a Broadcom company). Proxmox VE is a registered trademark of Proxmox Server Solutions GmbH. Microsoft and Hyper-V are registered trademarks of Microsoft Corporation. All other marks are property of their respective owners.

Disponível em: Português (Portuguese (Brazil))EnglishEspañol (Spanish)

Table of contents

1. Executive summary

2. Introduction & market context

2.1 Nutanix AHV in enterprise production today

2.2 Why backing up AHV VMs is challenging

2.3 The gap in the open-source ecosystem

2.4 The PodHeitor approach

3. Architecture overview

3.1 Two-component design

3.2 Internal communication channel

3.3 Architecture diagram

3.4 PHCBT01 delta stream format

3.5 State management

4. Backup modes deep dive

4.1 Full backup (F2)

How it works

Concurrency

Pros and cons

4.2 Incremental backup via CBT (F3)

How it works

Pros and cons

4.3 DR replication (F8)

How it works

Failover modes (F8.4)

4.4 Cross-vendor INBOUND restore (F6)

5. Feature matrix

6. Installation guide

6.1 Prerequisites

6.2 Package installation

RPM (Oracle Linux 9 / RHEL 9 / Rocky / Alma)

DEB (Ubuntu 22.04 / Ubuntu 24.04)

Tarball (any glibc 2.34+ x86_64)

6.3 Initial configuration

6.4 Pre-flight validation

6.5 DR receiver setup (optional)

7. Configuration reference

7.1 Connection parameters

7.2 Backup selection parameters

7.3 Data path parameters

7.4 Restore parameters (F4 / F5 / F6)

7.5 DR replication parameters (F8)

7.6 Logging and scratch parameters

7.7 Mode values

8. FileSet examples

8.1 Basic full + incremental backup of all VMs

8.2 Production VMs only, application-consistent, with concurrency

8.3 Alternate-cluster restore (cross-cluster DR)

8.4 DR replication seed + bitmap-push schedule

8.5 Cross-vendor INBOUND restore to Proxmox VE

8.6 Corresponding Bacula Job definitions

9. Sizing & capacity planning

9.1 FD host requirements

9.2 Bacula volume storage sizing

9.3 DR receiver sizing

10. Performance report

11. Compatibility matrix

11.1 Bacula components

11.2 Operating systems (FD host)

11.3 Nutanix platform

11.4 Hypervisor restore targets

12. Security

12.1 Credential handling

12.2 Prism RBAC posture

12.3 Transport security

12.4 Process isolation

13. Monitoring

13.1 Log sources

13.2 Key messages to monitor

13.3 Prometheus / metrics integration

14. Troubleshooting guide

14.1 Where to look first

14.2 Common failures and fixes

14.3 Failover state reference

15. Use cases & deployment scenarios

15.1 Daily backup of production Nutanix VMs

15.2 Disaster recovery with continuous replication

15.3 VMware vSphere to Nutanix AHV migration

15.4 Multi-cluster Nutanix environment

15.5 Air-gapped environment with Bacula tape storage

16. Comparison with other approaches