Author name: Managecast Technologies

Introduction When using CDP and attempting to complete the initial sync for a virtual machine, the initial sync may complete with the following error: The initial sync process for CDP is when it copies all of the data for a virtual machine from the client side to the target side, creating a working replica of the VM as an initial “restore point”.  This restore point is basically a working VM replica on the target size that can be used in a failover situation to boot the VM.  Once the initial sync has completed, the status for that VM should then go to “syncing”, which means CDP is now synchronizing incremental changes in the VM. The Issue Sometimes after the initial sync completes, the VM synchronization process may go into a failed state with the following error: The most common issue with this is a backup or replication job that has taken place during the CDP initial sync process that took a snapshot of the VM.  During the CDP initial sync process, no snapshots of the VM can exist or be taken from any source, this includes any Veeam or VMware tasks that take snapshots or any pre-existing snapshot of the VM. Per Veeam’s documentation: https://helpcenter.veeam.com/docs/backup/vsphere/cdp_requirements.html?ver=120 “VMs that you plan to protect must not have snapshots at the moment the CDP policy starts for the first time.” If a snapshot is taken while the CDP initial sync is taking place, CDP doesn’t just fail (even though it’s not going to work anyway), CDP continues to try to complete the process, but now it’s in a perpetual behind state because of the snapshot and the sync process runs much slower.  Then each time the backups with snapshots runs again and again, which has a cumulative slowness effect on CDP, so it just gets slower and slower to a crawl, then when it finally copies everything at the end, it is so far behind it can never catch up, so it then has a perpetual disk traffic not clean. Solution Verify no snapshots exist when the VM’s initial sync process is taking place and confirm that no other jobs or policies will run that may create a snapshot of that VM.  If a VM was replicated and is now in a failed state, that replica must be deleted from the “Replicas” section before attempting to start the CDP sync again. Conclusion As part of the initial sync process, CDP attempts to make a replica of the VM on the target side, which is basically a one-to-one copy of the existing VM.  When a snapshot is taken on the source side, the VM’s disk is placed in a read-only state and a delta file is created to record all of the changes.  This changes the disk’s state, thus the I/O flow that CDP is monitoring is disrupted, and CDP cannot continue to accurately track and replicate the changes since the I/O flow has now changed.  Furthermore, the target replica doesn’t detect these changes immediately, resulting in a mismatch between the source and destination size.  Veeam now tries to restart the process but ends up in basically a failed loop state.

The “Job aborted due to server termination” error in Veeam occurs when the backup job is unexpectedly interrupted due to the backup server shutting down or restarting. This can be caused by scheduled system updates, maintenance tasks, or resource constraints that force the server to reboot during an active backup operation.  Suggested Solution  To prevent this issue, review and adjust scheduled tasks and updates that may cause the server to restart during backup jobs:  By proactively managing scheduled tasks, updates, and system settings, you can prevent unexpected server terminations and ensure uninterrupted Veeam backup operations.   For more information, please contact our support team at support@managecast.com. 

Veeam’s malware detection feature scans backups for potential threats before they are restored or used in production. Once a scan completes, the metadata should be published to the Veeam Guest Catalog Service, which stores backup indexing and security scan results.  When this process fails, users may see the “Failed to publish malware detection metadata to the catalog” warning in their job logs.  This warning may occur due to:  Steps to Resolve the Issue  Restart the Veeam Guest Catalog Service  Simply restarting this service may help resolve the issue.  To restart it:  Check File Permissions on the Catalog Folder  Ensure that the Veeam Backup Service account has full control over:  C:\ProgramData\Veeam\Backup\Catalog  C:\Program Files\Veeam\Backup and Replication\Catalog  While this issue is not severe, it can still be a concern for administrators who prioritize security and rely on Veeam’s malware scanning. If the issue persists, please contact our support team at support@managecast.com for further investigation. 

When working with Veeam Backup & Replication, ensuring seamless backups is a critical part of IT infrastructure management. However, you might occasionally encounter errors that disrupt the process, such as:  Failed to index guest file system. Veeam Guest Agent is not started. Failed to prepare guest for hot backup. Details: Failed to connect to guest agent. Errors: ‘Cannot connect to the admin share. Host: [Target Machine]. Account: [Account Name]. Win32 error:The network path was not found. Code: 53  Or you may encounter errors such as:  Failed to inventory guest system: Veeam Guest Agent is not started. Failed to index guest file system. Failed to prepare guest for hot backup. Details: Failed to connect to guest agent. Errors: ‘Cannot connect to the admin share. Host: [Target Machine]. Account: [Account Name]. Win32 error:Access is denied. Code: 5  These errors can be daunting, especially if you’re unsure where to begin troubleshooting. It usually indicates issues related to network connectivity and/or permissions. By understanding the underlying causes and following structured troubleshooting steps, you can quickly identify and resolve the problem.  Error Codes Breakdown  Win32 Error Code 53: “The network path was not found.”  This error indicates that the Veeam server is unable to reach the specified host over the network. Common causes include:  Win32 Error Code 5: “Access is denied.”  This error occurs when the account used for authentication lacks the necessary permissions to access the admin share or perform guest processing tasks.  Troubleshooting Steps  1. Verify Network Connectivity Confirm that the host is reachable: 2. Verify Admin Share Accessibility Confirm that the admin share is enabled and accessible using Command Prompt: 3. Check Credentials and Permissions Verify that the account used for the job has the necessary permissions: 4. DNS and Hosts File Confirm that the Veeam server can resolve the hostname to the correct IP address: 5. Test Backup Job with Another Account If all else fails, test the backup job using a different account: By following these steps, you should be able to identify and resolve the “Failed to index guest file system” error. If you encounter persistent issues or need additional assistance, don’t hesitate to contact our support team at support@managecast.com. We are ready to help ensure your backup operations run smoothly and effectively!