Free Nutanix NCP-BC-7.5 Practice Exam with Questions & Answers | Set: 3

Self-Service Restore (SSR) is a Nutanix feature that allows end-users to recover individual files by mounting a recovery point as a local drive within the guest VM. NearSync replication provides high-frequency protection with Recovery Point Objectives (RPOs) as low as 1 minute using Lightweight Snapshots (LWS). However, there is a technical distinction in how these high-frequency points are handled for end-user recovery.

In a NearSync configuration, the system generates dozens of LWS throughout an hour. While these are available for full VM disaster recovery, Nutanix limits the " granularity " available for Self-Service Restore to manage metadata overhead and guest agent performance. By default, SSR in a NearSync environment typically supports recovery point intervals of 1 hour. This means that while an administrator can restore the entire VM to a state from 5 minutes ago, an end-user using the SSR browser inside the VM will see recovery points at 1-hour increments (the " consolidated " points). This design balances the need for high-frequency disaster protection with the operational efficiency of file-level recovery. If a user needs a file from a point between the hourly intervals, an administrator may need to perform a full VM clone or an " Out-of-place " restore to provide access to those more granular lightweight recovery points.

Network segmentation in a Nutanix cluster allows for the physical or logical isolation of different types of traffic (management, storage, and backplane). When applied to Disaster Recovery, it allows an administrator to dedicate a specific network interface (typically ntnx0) and a dedicated subnet for replication traffic, ensuring it does not contend with VM or management traffic for bandwidth.

However, Disaster Recovery is a site-to-site operation that requires a symmetric network configuration. If an administrator enables segmentation on the primary cluster, the Cerebro service at that site will now attempt to originate and receive all replication traffic on the newly defined segmented IP addresses. If the recovery cluster is still in its original " brownfield " state without segmentation, it will be looking for traffic on its management IP addresses (on eth0). This creates a mismatch where the two sites are effectively " speaking different languages " or looking for each other on the wrong networks. Nutanix does not automatically propagate segmentation settings between clusters because each site may have different physical network topologies or VLAN requirements. Therefore, the administrator must manually enable and configure network segmentation on the recovery cluster to match the primary. Only when both sites have consistent segmented interfaces and the routing/firewall rules are updated to allow communication between these new subnets will the replication link be restored and functional.

The Nutanix Cloud Gateway serves as a critical bridge between on-premises Nutanix clusters and the Nutanix Cloud Availability Zone (AZ). Its primary role is to provide a secure, encrypted tunnel for replicating recovery points and managing disaster recovery orchestration metadata. When utilizing standard IPSec for this traffic, the system architecture imposes certain throughput limitations based on the processing capabilities of the gateway instance. For a single Nutanix Cloud Gateway, the maximum supported bandwidth for IPSec-encrypted traffic is 1 Gbps.

This 1 Gbps limit is an important consideration for BCDR planning, as it defines the maximum " Snapshot-on-wire " throughput available for a given protection policy. If an organization has a high data change rate (churn) that exceeds 1 Gbps of sustained replication traffic, the Recovery Point Objective (RPO) may be at risk of lag. While the physical network link might be 10 Gbps or higher, the encryption overhead of the IPSec protocol within the gateway VM is the limiting factor. To achieve higher aggregate throughput, administrators would need to deploy multiple gateways or consider high-performance direct connectivity options if available. Understanding this 1 Gbps threshold ensures that administrators can accurately size their replication windows and manage expectations for initial seed transfers and ongoing delta synchronization to the cloud AZ.

NearSync replication is a Nutanix technology that provides RPOs as low as 1 minute by using " Lightweight Snapshots " (LWS). However, NearSync has specific operational requirements to maintain its aggressive schedule . If the system detects that it cannot maintain the 15-minute RPO using lightweight snapshots, it will automatically " downshift " to a standard Asynchronous (hourly) replication mode to ensure that protection is not lost entirely.

One of the most common triggers for this temporary transition is the addition of a new virtual machine to the category associated with the Protection Policy. When a new VM is added, the Nutanix cluster must perform a " full initial sync " (also known as a seed replication) to transfer all the VM ' s data to the remote site. Because a full seed replication involves transferring much more data than a standard delta update, it often exceeds the time window and processing capabilities of the NearSync LWS engine. To handle this large data transfer safely, the system switches to the Async (hourly) schedule, which uses more robust but slower snapshot mechanisms. Once the initial sync of the new VM is complete and the clusters are in a " consistent " state, the system will automatically attempt to " upshift " back to the NearSync schedule to restore the 15-minute RPO. This behavior ensures that the system handles growth and changes in the environment while maintaining the highest possible level of protection without administrative intervention.

Migrating from legacy Protection Domains to modern Prism Central Protection Policies is a recommended practice for scaling DR management. However, large environments must account for architectural limits during this transition. A Nutanix cluster has specific maximum thresholds for the number of entities (VMs) that can be contained within a single Protection Domain, and similar limits exist for the initial " handoff " to Prism Central.

If a single legacy Protection Domain contains more than 500 VMs, attempting to migrate it as a single unit can lead to timeouts, metadata synchronization failures, and potential gaps in protection. To ensure that all VMs remain consistently protected during the migration, the first step is to " split " the existing large Protection Domain into multiple smaller, more manageable ones. For example, an administrator might split a 600-VM domain into three 200-VM domains. This reduction in " entity density " allows the Nutanix Cerebro and Prism Central services to process the migration tasks more efficiently without hitting resource contention or task timeout limits. Once the VMs are organized into these smaller groups, they can be systematically unlinked from the legacy domains and added to the new PC-based Protection Policies. This phased and controlled approach minimizes risk and ensures that a valid recovery point always exists for every VM throughout the entire migration lifecycle.

Nutanix Disaster Recovery (formerly Leap) utilizes a " policy-driven " approach where virtual machines are protected based on assigned " Categories " rather than individual VM names. This allows for automated protection: any VM tagged with a specific category (e.g., App:Web) is automatically picked up by the associated Protection Policy. When existing VMs are replicating fine but new ones are not, and there are no network or storage errors, the root cause is almost always an administrative oversight during provisioning.

If the separate team that deployed the VMs followed a checklist that didn ' t include category assignment, those VMs exist as " unprotected entities " in the eyes of Prism Central. The Protection Policy will ignore them because they do not match the entity selection criteria defined in the policy ' s configuration. To resolve this, the administrator must simply apply the correct category to the new VMs. Once tagged, the Cerebro service will identify the new members during its next scan and initiate the initial full seed replication to the recovery site. This scenario highlights the critical need for cross-team coordination and the use of automated deployment tools (like Nutanix Self-Service or Calm) to ensure that security and BCDR requirements are applied consistently during the VM lifecycle.

Preserving IP addresses during a failover is a common requirement for applications with hardcoded IP references or complex inter-service dependencies. In a standard multi-site DR setup, the source and destination sites reside on different Layer 3 subnets, meaning a VM would naturally require a new IP address to be routable at the recovery site. To achieve " IP Preservation, " the underlying network infrastructure must support Layer 2 (L2) stretching.

L2 stretching (often implemented via VXLAN or specialized VPN tunnels like Nutanix Flow Virtual Networking) allows a single logical subnet to span multiple physical locations. When a VM fails over to a cluster on a stretched subnet, it effectively stays on the same network broadcast domain. As a result, its IP address, default gateway, and subnet mask remain valid and unchanged. If the subnets are not stretched, the administrator must rely on the Recovery Plan ' s " IP Mapping " feature to assign a new, valid IP at the destination—which does not " preserve " the original address. While preserving IPs simplifies application recovery, it requires more complex network engineering to ensure that traffic is correctly routed to the active site during a disaster, highlighting the trade-off between application simplicity and infrastructure complexity in BCDR design.

Transitioning from legacy Protection Domains (which are cluster-centric) to modern Prism Central-based Protection Policies (which are management-plane centric) is a common task during Nutanix environment upgrades. This migration involves a " handoff " where the responsibility for snapshots and replication shifts from the local Cerebro service on the cluster to the global orchestration provided by Prism Central.

The primary risk during this migration is the creation of a " protection gap. " If an administrator deletes the legacy snapshots immediately after assigning a new policy, and that new policy has not yet successfully completed its first replication cycle, the virtual machine is effectively unprotected. If a disaster occurs at that exact moment, there would be no valid recovery points at the destination site to restore from. Nutanix best practice dictates that legacy artifacts must be preserved until the new system is verified as operational. Once the first recovery point for the VM appears in the Prism Central " Recovery Points " tab, it confirms that the new Protection Policy has successfully captured the VM ' s state and replicated it to the recovery AZ. At this stage, the legacy snapshots in the Protection Domain become redundant and can be safely deleted to reclaim storage space without compromising the organization ' s ability to meet its Recovery Point Objective (RPO) and Recovery Time Objective (RTO).

An In-place Restore (Revert) is the fastest way to roll back a VM because it overwrites the current vDisks with the data from the snapshot. However, this operation has strict requirements regarding the consistency of the VM ' s hardware configuration. The most common technical blocker for an in-place revert is a change in the disk topology between the time the snapshot was taken and the time of the restore.

If the administrator added a new 50GB data disk (Option D) after taking the snapshot, the VM ' s current configuration now includes a vDisk that does not exist in the snapshot ' s metadata. Nutanix AOS cannot " revert " a disk that has no point-in-time reference in the recovery point. In this situation, the " In-place Restore " button is typically disabled or will throw an error, forcing the administrator to use the " Clone " (Out-of-place) option. Cloning creates a new VM based exactly on the snapshot ' s metadata, effectively ignoring the newly added disk. While changing memory (Option B) or NGT versions (Option A) might affect performance or guest features, they do not usually prevent the storage-level revert operation. Being forced into a " Clone " restore increases the RTO slightly, as the administrator must then delete the corrupted VM and ensure the new clone has the correct network settings.

Troubleshooting replication failures requires analyzing the relationship between snapshot creation and data transfer. In this scenario, the failure occurs during the snapshot creation phase rather than during the transfer of data across the wire. While network spikes and I/O timeouts are noted (Option D), these are often symptoms rather than the root cause when the specific failure point is the snapshot itself .

If multiple replication jobs or protection policies are scheduled to run at the exact same time, the cluster may experience " snapshot contention " or metadata locks. When schedules overlap significantly, the overhead on the Controller VMs (CVMs) can lead to the observed I/O timeout errors in the guest OS as the system struggles to quiesce applications and freeze the filesystem multiple times in quick succession. This is particularly common in environments with high data change rates where the previous replication cycle has not finished before the next one begins. Since storage is sufficient (Option B) and the clusters are compatible (Option E), the most logical cause is schedule misconfiguration. To resolve this, the administrator should stagger the start times of protection policies or combine multiple VMs into a single, unified policy to ensure that the Nutanix snapshot engine can process the requests sequentially without causing the resource exhaustion that leads to job failure.