Nutanix NCP-DB cheat sheet

NDB is delivered as a Nutanix-hosted appliance (NDB VM) deployed on AHV or ESXi via Prism; it registers with Prism Element/Prism Central and with a Nutanix Files-capable or NFS share for storage of database artifacts.

Core services on the NDB VM: the NDB server (API/UI, orchestration engine), the built-in PostgreSQL repository database that stores metadata (clusters, DBs, snapshots, SLAs, policies), and the agent (NDB agent) installed on every registered database VM.

The NDB agent runs on each managed database server and executes provisioning, snapshot, clone, and patching operations locally; loss of agent connectivity makes the VM 'unreachable' in NDB even if the VM itself is healthy.

Time machines are the logical container for a database's lifecycle: each provisioned DB has one time machine that records snapshots, log captures, clones, and retention; clone refresh and PITR operate through the source time machine.

Era (NDB version 2.x) terminology: 'database' replaces 'instance', 'time machine' replaces 'snapshot group', and 'database server' replaces 'VM'; older exam items may use either set.

NDB supports multiple database engines: PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, Oracle (single instance and RAC), and MongoDB (replica set); engine-specific profiles (compute, network, software, database parameter) drive provisioning.

Snapshot types: NDB native snapshots are crash-consistent by default; application-consistent snapshots require the database engine to support and enable them (e.g., quiescing via VSS on SQL Server).

NDB components communicate over ports including 22 (SSH), 443 (API/UI), 5432 (repository PostgreSQL), and 2000-2003 range for agent/API traffic; firewall rules must allow the NDB VM to reach database VMs.

NDB can register multiple Nutanix clusters; the 'NDB cluster' selection at provisioning determines which Prism Element hosts the database VM and where its storage containers live.

Prerequisites before deploying the NDB VM: a Nutanix cluster with AHV or ESXi, a network with DHCP or a static IP pool, DNS and NTP reachable, and at least ~4 vCPU / 16 GB RAM / 500 GB+ for the NDB VM (production sizing scales with DB count).

Deployment methods: Prism Central 'Deploy NDB' workflow, or the NDB deployer OVA/qcow image on AHV/ESXi; the deployer prompts for the NDB VM IP, Prism credentials, and storage container.

After the NDB VM boots, run the initial setup wizard: set admin password, register Prism Element/Prism Central, configure the storage container for database data and the NFS share for backups/snapshots.

Register database VMs by installing the NDB agent (via SSH from NDB or a manual RPM/DEB install), then add them as database servers; unregistered VMs cannot be provisioned onto.

Network profiles define VLAN, IP pool, gateway, DNS, and subnet for provisioned DB VMs; without a valid network profile, provisioning fails at the network configuration step.

Software profiles map database engine versions to their installation media; NDB ships default profiles and administrators can upload custom binaries for patching targets.

Compute profiles define vCPU, memory, and disk sizing presets; database parameter profiles (e.g., PostgreSQL shared_buffers) are applied at provision time and can be overridden per database.

SLA policies are created after install: define snapshot frequency, retention count, log capture interval, and whether snapshots are application-consistent; every DB must be attached to an SLA for automated protection.

Validate the install by provisioning a test database end-to-end and confirming snapshot + clone succeed; this exercises agent, network profile, storage, and Prism registration in one pass.

Provisioning flow: choose engine + version (software profile), compute profile, network profile, database parameter profile, SLA, and target NDB cluster; NDB then creates the VM, installs the engine, and registers the time machine.

Provisioning source options: a fresh/empty database, a snapshot of an existing DB (point-in-time clone), or a clone of an existing DB; the source's time machine determines available points.

Cloning is copy-on-write from a snapshot on the same Nutanix cluster; cross-cluster cloning requires the snapshot to be replicated to the target cluster first.

A clone is a full, independent database VM with its own time machine; it can be refreshed from the source, but it does not inherit the source's SLA unless one is explicitly attached.

Clone naming and network: each clone needs a unique name and an IP from the network profile's pool; IP exhaustion is a common provisioning failure.

Provisioning is asynchronous: the operation appears in the NDB task/operation list with per-step status; a failed step (e.g., agent registration) leaves the DB in an error state that must be cleaned up before retry.

Database parameter profiles are engine-specific; an incorrect profile (e.g., PostgreSQL profile applied to MySQL) is rejected at provision time, not at runtime.

Cloning from a snapshot preserves the snapshot's point in time; to clone at a later point, choose a newer snapshot or use PITR (log-based) if log capture is enabled on the source.

Provisioned DBs are registered in Prism as VMs owned by NDB; manual changes to the VM outside NDB (e.g., resizing disks directly in Prism) can desynchronize NDB metadata.

Patching: NDB applies OS and database engine patches via patch profiles; a patch operation snapshots the DB first (if configured), then applies the patch and can roll back on failure.

Engine upgrades (e.g., PostgreSQL 13 to 15) are distinct from patches; upgrades require a compatible software profile and typically a pre-upgrade snapshot for rollback.

Scaling operations: scale compute (vCPU/RAM) by changing the compute profile and applying it; scale storage by adding disks or resizing existing data disks through NDB, not directly in Prism.

Scale-out for engines that support it (e.g., SQL Server Always On, Oracle RAC) adds nodes to the database; single-instance engines only support scale-up.

Maintenance windows: SLA/patch schedules can restrict when automated patching and snapshot operations run; manual operations outside the window are still allowed unless policy blocks them.

Rollback after a failed patch uses the pre-patch snapshot; NDB restores the DB to that snapshot and re-registers the time machine at that point.

Changing a database's SLA detaches the old policy and attaches the new one; existing snapshots are retained per the old policy's retention until they age out.

Deleting a database removes the VM and its time machine; snapshots referenced by clones may block deletion until the clones are deleted or refreshed away from that snapshot.

NDB backups are snapshot-based: SLA policies define snapshot frequency and retention; snapshots are stored on the Nutanix cluster and can be replicated to a remote cluster or object store for DR.

Log capture (continuous log shipping) enables PITR: NDB captures database transaction logs at the SLA's log interval, allowing restore to any point between snapshots within the retention window.

PITR requires log capture enabled on the source time machine and a target snapshot as the base; restore replays logs up to the requested timestamp.

Restore types: restore in place (overwrites the existing DB, destructive), restore to a new database (clone from snapshot/PITR point), and restore to a different NDB cluster (requires replicated snapshots).

Snapshot replication to a remote site is configured per SLA or per database; the remote site must have a registered NDB cluster and matching network/storage profiles for restore.

Retention: each SLA defines how many snapshots and how many days of logs to keep; older snapshots are pruned automatically, which also limits the earliest PITR point.

Restoring a SQL Server database uses VSS-consistent snapshots if application consistency is enabled; otherwise the restore is crash-consistent and may require recovery.

Verify backups by cloning from a snapshot and running validation queries; NDB does not automatically prove a snapshot is restorable beyond task success.

Clone refresh replaces a clone's data with a newer snapshot from its source time machine; the clone keeps its name, IP, and network but its data jumps to the chosen point in time.

Refresh requires the clone and source to share the same NDB cluster (or the snapshot to be replicated to the clone's cluster); cross-cluster refresh needs prior replication.

During refresh the clone is briefly unavailable; NDB snapshots the clone before refresh so the previous state can be recovered if the refresh fails.

Snapshot management: list snapshots per time machine, delete individual snapshots (subject to retention and clone dependencies), and tag snapshots for identification.

A snapshot cannot be deleted while a clone is actively based on it; NDB either blocks deletion or requires the clone to be refreshed to a different snapshot first.

Data copy (log copy / snapshot copy) moves snapshots between NDB clusters for DR or test/dev; the destination cluster must be registered and have compatible storage.

Snapshot naming includes the time machine name and timestamp; the 'latest' snapshot is the most recent successful one and is the default source for clones.

Application-consistent snapshots require engine support (VSS on SQL Server, quiesce on Oracle); enabling consistency increases snapshot time and may briefly pause the database.

NDB RBAC roles: Admin (full control), Operator (provision, operate, but not manage users/infrastructure), Developer (use existing DBs, clone, no infra changes), and Read-only/Viewer (view only).

Users and groups are managed in NDB; directory integration (LDAP/AD) allows group-based role assignment so AD groups map to NDB roles.

Role assignment scope: a user can be granted a role globally or scoped to specific projects/clusters; project scoping limits which databases a user can see and operate.

Projects group databases and users; a user's effective permissions are the union of global and project-scoped roles, with the most permissive role winning.

Database credentials: NDB stores engine admin credentials in its repository; users can be granted access to specific databases without seeing the underlying VM credentials.

Network security: NDB requires SSH (22) and API (443) access to database VMs; restrict NDB VM access to trusted networks and use Prism's firewall/flow policies to limit lateral movement.

Audit: NDB logs user actions (provision, clone, delete, patch) in its task/audit history; Prism also logs VM-level operations for correlation.

Encryption: snapshots and backups can be encrypted at rest via Nutanix storage encryption; NDB does not add its own encryption layer on top of the cluster's.

NDB health: the dashboard shows database status (healthy, warning, critical), agent connectivity, and SLA compliance (snapshots taken on schedule).

Alerts are generated for failed snapshots, failed patches, agent disconnection, low storage, and SLA violations; alerts can be forwarded via email or SNMP/Prism alert policies.

Common provisioning failure: agent unreachable - check SSH from NDB VM to the DB VM, firewall, and that the agent service is running.

Common snapshot failure: storage container full or snapshot limit reached on the Nutanix cluster; check Prism storage capacity and snapshot count.

Common clone failure: IP pool exhausted in the network profile, or the source snapshot is not replicated to the target cluster for cross-cluster clones.

PITR failure: log capture disabled or logs pruned beyond the requested timestamp; verify the SLA log retention covers the target time.

Task logs: each NDB operation has a task ID with per-step logs; the NDB server log (/var/log/ndb or via the NDB VM) and agent log on the DB VM are the primary troubleshooting sources.

Prism integration: NDB-registered clusters appear in Prism Central; VM-level alerts (CPU, memory, disk) surface in Prism and can be correlated with NDB database alerts.