Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest
Please, try again later.
A job within Veeam Backup & Replication fails with an error that starts with:
Unable to allocate processing resources.
In the section below is a list of the most common permutations of this error.
Below are different endings to the error "Unable to allocate processing resources." They have been grouped by relative topic and are ordered in no specific way. Click on the error to view the error-specific information.
Note: This is not an exhaustive list. If the error you have observed does not appear below, please collect logs and create a support case.
Some variations of the "Unable to allocate processing resources" error do not have a simple, straightforward solution. Instead, many factors of the environment may need to be considered. In the sections below, Veeam Support has compiled advice based on past cases.
If you would like assistance investigating the error you are facing, please do not hesitate to contact Veeam Support. Our Technical Support Engineers are well-versed in investigating this issue.
An expanded definition of this error would be:
Of the proxies available for the job to use, none were able to be used because they were configured to use a transport mode that was incompatible with the VM that was being backed up.
This error occurs when the proxy that the job is attempting to use is configured to use a specific Transport Mode that is incompatible with the VM that is being backed up.
Identify which proxies the Job was allowed to use, then review each of those proxies to identify which transport mode they were configured to use. Then, review that transport mode's requirements and ensure they are met for the VM that failed to be backed up.
Step 2: Check for Proxies that are Unavailable or Disabled
Having identified which proxies could have been used by the Job, review each proxy and ensure that they are not listed as Unavailable or Disabled.
If any VMware Backup Proxy is listed as Unavailable, identify its related entry under Managed Servers and rescan it. If the entry under Managed Servers fails to rescan, edit it instead and "Next, Next, Finish" through each of the pages of the wizard to force Veeam Backup & Replication to check if services on that remote machine need to be redeployed.
Review the Transport Mode selection to identify if any of those proxies have been configured to only use a specific Transport Mode.
Note: The Transport Mode selector is set to Automatic in most environments to allow the Veeam Backup & Replication software to detect the most appropriate Transport Mode to be used for each VM. The option for "Failover to network mode" is left enabled to ensure that even if Direct storage access or Virtual appliance (HOTADD) fails, the Proxy can still utilize network transport mode as a last resort.
In this scenario, a VMware environment has one or more datastores that are backed by NFS or iSCSI storage. VMware Backup Proxies were created, and were able to contact that backend storage directly via NFS or iSCSI. To ensure that those proxies would always use a connection to the backend storage, the backup admin configured those proxies to use "Direct storage access" and disabled the option to failover to network mode.
In this configuration, if the VMware Backup Proxies cannot reach the backend storage via NFS or iSCSI, the backup jobs will fail with the error "No backup proxy is able to process this VM due to proxy processing mode restrictions." The inability to connect could, for example, be related to a network change or changes to the allowlist on the backend storage. The configuration would need to be reviewed to ensure the requirements for the desired transport mode are met.
An expanded definition of this error would be:
None of the proxies available for the job to use are available because they are either disabled, offline, or have not been updated.
Identify which proxies the job was allowed to use, then review each of those proxies to determine why they are disabled, offline, or outdated.
Step 2: Check for Proxies that are Unavailable or Disabled
Having identified which proxies could have been used by the job, review each proxy and ensure that they are not listed as Unavailable or Disabled.
If any VMware Backup Proxy is listed as Unavailable, identify its related entry under Managed Servers and rescan it. If the entry under Managed Servers fails to rescan, edit it instead and "Next, Next, Finish" through each of the pages of the wizard to force Veeam Backup & Replication to check if services on that remote machine need to be redeployed.
If any VMware Backup Proxy is listed as outdated, select it and then click the "Upgrade Proxy" button in the ribbon menu.
None of the proxies selected as the Source Proxy within the Replication job are available for the job to use because they are offline, outdated, or being processed by another job.
Having identified which proxies could have been used by the job, review each proxy and ensure that they are not listed as Unavailable or Disabled.
If any VMware Backup Proxy is listed as Unavailable, identify its related entry under Managed Servers and rescan it. If the entry under Managed Servers fails to rescan, edit it instead and "Next, Next, Finish" through each of the pages of the wizard to force Veeam Backup & Replication to check if services on that remote machine need to be redeployed.
If any VMware Backup Proxy is listed as outdated, select it and then click the "Upgrade Proxy" button in the ribbon menu.
In this scenario, two sites exist, the main office and the DR site. The Backup Administrator has configured the minimum recommended number of proxies for site-to-site replication — one in each site. The replication jobs have been configured to only use the proxy in the main office as the source proxy and the proxy in the DR site as the target proxy.
With this configuration, if the Veeam Backup Server cannot reach the target proxy, the jobs would fail with "All target backup proxies are offline, outdated or currently being processed." The troubleshooting for this situation would involve identifying why the target proxy can no longer be contacted by the Veeam Backup Server.
None of the proxies selected as the Target Proxy within the Replication job are available for the job to use because they are offline, outdated, or being processed by another job.
Having identified which proxies could have been used by the job, review each proxy and ensure that they are not listed as Unavailable or Disabled.
If any VMware Backup Proxy is listed as Unavailable, identify its related entry under Managed Servers and rescan it. If the entry under Managed Servers fails to rescan, edit it instead and "Next, Next, Finish" through each of the pages of the wizard to force Veeam Backup & Replication to check if services on that remote machine need to be redeployed.
If any VMware Backup Proxy is listed as outdated, select it and then click the "Upgrade Proxy" button in the ribbon menu.
In this scenario, two sites exist, the main office and the DR site. The Backup Administrator has configured the minimum recommended number of proxies for site-to-site replication — one in each site. The replication jobs have been configured to only use the proxy in the main office as the source proxy and the proxy in the DR site as the target proxy.
With this configuration, if the Veeam Backup Server cannot reach the target proxy, the jobs would fail with "All target backup proxies are offline, outdated or currently being processed." The troubleshooting for this situation would involve identifying why the target proxy can no longer be contacted by the Veeam Backup Server.
Within the Backup Infrastructure section, locate the host specified and make sure the components installed on it are up-to-date.
If the Upgrade option is greyed out, open the properties of the host and Next, Next, Finish through the properties wizard to force Veeam Backup & Replication to recheck installed component versions.
If this error persists, collect logs and create a Veeam Support case.
Test-NetConnection -computername <hyper-v host> -port 6163
Rescan the Scale-Out Backup Repository and resolve the underlying issues preventing the extents from being used.
This issue may coincide with Repositories within the Backup Infrastructure > Backup Repositories section being listed in the subcategory "Offline." If those repositories were Direct attached storage type, their associated Windows or Linux server may also be marked as Offline.
This message may be shown when the Veeam Backup Server can no longer contact one or more Scale-Out Backup Repository performance extents or when an extent previously used has been placed in Maintenance mode.
Possible Edge Case: There have been reports that this error may occur when one or more performance extents in a Scale-Out Backup Repository point to the same location or use the same path, a configuration that is explicitly advised against. For example, two Linux-based extent repositories that both point to the folder /backups/ on the same Linux machine.
Review:
Unlike Simple Repositories, Scale-Out Backup Repositories have mechanisms to prevent the backup storage from becoming 100% full. These checks will prevent a job from starting if the software believes that allowing the job to complete would fill the storage.
In environments where jobs are always running and overlapping, the Free Space Estimation system may have issues as it only rechecks actual free space when no jobs are running. For information about how to switch to an alternate Free Space Estimation system, review: KB2282. Please note that this alternate method should only be used in environments where it is needed.
Your feedback has been received and will be reviewed.
Please, try again later.
Please try select less.
This form is only for KB Feedback/Suggestions, if you need help with the software open a support case
Your feedback has been received and will be reviewed.
Please, try again later.