Skip to main content
Question

Backup copy issues: VM not found : Intellisnap backups

  • July 2, 2026
  • 7 replies
  • 35 views

Forum|alt.badge.img+4

We have Intellisnap backups configured and all VMs are configured in 1 backup job; unfortunately as we are currently using NBD mode, I noticed some backup copy jobs got delayed for days and now showing error “VM not found” for certain VMs.  although I can go back to the snapshot job; do a mount snapshot.  Like 1 specific VM holding the whole Snapshot in storage and causing issues 

 

If I were to select do not copy these specific corrupt restore points to backup storage and trigger a backup copy will it just do like a differential or will I have to do a new full Intellisnap backup and dont copy the historical restore points; we have weekly retention for storage snapshot and yearly retention for weekly full  

7 replies

Bronco
Vaulter
Forum|alt.badge.img+3
  • Vaulter
  • July 2, 2026

We have Intellisnap backups configured and all VMs are configured in 1 backup job; unfortunately as we are currently using NBD mode, I noticed some backup copy jobs got delayed for days and now showing error “VM not found” for certain VMs.  although I can go back to the snapshot job; do a mount snapshot.  Like 1 specific VM holding the whole Snapshot in storage and causing issues 

 

If I were to select do not copy these specific corrupt restore points to backup storage and trigger a backup copy will it just do like a differential or will I have to do a new full Intellisnap backup and dont copy the historical restore points; we have weekly retention for storage snapshot and yearly retention for weekly full  

Hello ​@Rajeev Mehta,

 

In this Commvault IntelliSnap scenario, all VMs are protected within a single IntelliSnap backup job, but delayed backup copy operations using NBD mode have resulted in some VMs reporting "VM not found" errors during backup copy. Although snapshots for the affected VMs can still be mounted, these problematic restore points are preventing successful backup copy completion and delaying snapshot cleanup. Marking the affected restore points as "Do Not Copy" is a valid method to skip corrupted or unavailable jobs and prevent repeated backup copy failures. However, if a full IntelliSnap snapshot is skipped, the backup copy chain is broken, meaning subsequent incremental or differential backup copies cannot continue because they lack a valid baseline. To restore normal backup copy operations, a new full IntelliSnap backup must be performed, followed immediately by a backup copy to establish a new backup copy chain. After the new baseline is created, incremental or differential backup copies will function normally. While skipped restore points will not be copied to backup copy storage, they will remain on the storage array until removed according to the snapshot retention policy. Once the new backup copy chain is verified, old or corrupted snapshots can be safely aged out or deleted.

 

Regards,

Siddharth Gandhi


Forum|alt.badge.img+4
  • Author
  • Apprentice
  • July 2, 2026

okay so do I have to identify all the vms which are failing with this error; put them on one sub client and take a full backup; shall I test a restore for a vm for a single volume 


Bronco
Vaulter
Forum|alt.badge.img+3
  • Vaulter
  • July 2, 2026

okay so do I have to identify all the vms which are failing with this error; put them on one sub client and take a full backup; shall I test a restore for a vm for a single volume 

You do not need to move the failing VMs to a new subclient unless you want to isolate them for troubleshooting; you can keep them in the existing subclient, mark the problematic jobs as Do Not Backup Copy, and run a new Full IntelliSnap backup to re-establish the backup copy chain. If a few VMs continue to cause issues, separating them into a new subclient can help with isolation, but it is optional rather than required. After the new full backup and successful backup copy, it is a good practice to test a restore of a VM or even a single volume to confirm data integrity and recoverability. The recommended sequence is to mark failed or corrupt jobs as Do Not Backup Copy, run a new Full IntelliSnap backup, trigger backup copy, and then perform a restore test to verify that the environment is healthy. In larger environments, isolating problematic VMs can reduce risk and simplify troubleshooting, but regardless of the approach, backup and backup copy jobs should be monitored closely for errors.


Forum|alt.badge.img+4
  • Author
  • Apprentice
  • July 2, 2026

so an intellisnap backup (incremental) when it has not copied across; is it not like a full backup? say if I try and restore something from a storage snapshot and not from the media library (like the whole VM) it wont have to depend on the whole chain? 


Bronco
Vaulter
Forum|alt.badge.img+3
  • Vaulter
  • July 2, 2026

so an intellisnap backup (incremental) when it has not copied across; is it not like a full backup? say if I try and restore something from a storage snapshot and not from the media library (like the whole VM) it wont have to depend on the whole chain? 

An IntelliSnap incremental backup is not the same as a full backup because it captures only the data that has changed since the previous backup, and backup copies stored on media require a complete backup chain consisting of the full backup and all subsequent incrementals to support a successful restore. However, restoring directly from a storage snapshot is different, as each hardware snapshot is a self-contained point-in-time copy on the storage array and does not rely on the backup copy chain. As long as the storage snapshot exists and is healthy, you can restore a VM or volume directly from it regardless of the status of the backup copy. In contrast, restores from the backup copy (media library) depend on an intact backup chain, and missing or skipped full or incremental jobs can cause restore failures. Therefore, storage snapshot restores are independent of backup copy health, while backup copy restores require a complete and valid backup chain.


Forum|alt.badge.img+4
  • Author
  • Apprentice
  • July 3, 2026

Sure thanks the other question I have is relating to backup copy configuration; because we use HSX and the webportal (I was more used to Commcell) for job configuration and we are using NBD; if there is a single job and the snapmount esxhost is a specific ESX host; during backup copies is Commvault only going to use this specific snaphost esx host or is it Intelligent enough to use other esx hosts in the environment for backup copies; there is non option to add a secondry or group of esx host as snapshot mounts.  HSX uses  NBD (SAN mode will happen once we have cables and switches) ; so I am wondering if only one esx host is used for backup copies (to mount the snapshot and copied )


Bronco
Vaulter
Forum|alt.badge.img+3
  • Vaulter
  • July 3, 2026

Sure thanks the other question I have is relating to backup copy configuration; because we use HSX and the webportal (I was more used to Commcell) for job configuration and we are using NBD; if there is a single job and the snapmount esxhost is a specific ESX host; during backup copies is Commvault only going to use this specific snaphost esx host or is it Intelligent enough to use other esx hosts in the environment for backup copies; there is non option to add a secondry or group of esx host as snapshot mounts.  HSX uses  NBD (SAN mode will happen once we have cables and switches) ; so I am wondering if only one esx host is used for backup copies (to mount the snapshot and copied )

When using Commvault IntelliSnap with HSX and NBD transport mode, the ESX host used to mount storage snapshots during backup copy operations is determined by the Snap Mount ESX Host configured for the subclient or backup copy job. Commvault always uses the specified ESX host for snapshot mounting and does not automatically select an alternate host if the configured one is unavailable or under heavy load. The Command Center also does not provide an option to configure a pool or group of ESX hosts for automatic selection or failover. While multi-node backup copy allows backup copy workloads to be distributed across multiple access nodes/ proxies for improved performance, it does not affect snapshot mount host selection, which remains tied to the configured ESX host. In NBD transport mode, data is transferred over the network from the mounted snapshot on the designated ESX host to the access node, making reliable network connectivity between these components essential for successful backup copy operations. If a different ESX host is required for snapshot mounting, the Snap Mount ESX Host configuration must be updated manually, as there is no built-in mechanism for automatic host failover or load balancing.