Credentials failure on crash-consistent backup

[Jonathan]

For an existing job, I disabled application processing and indexing for a few select VMs. The others still use VSS. The reason in this case is security compliancy. In theory this would result in crash-consistent backups for the "VSS disabled" machines, right? But now the job fails because it tries to use the default credentials to prepare these VSS disabled machines.

My question is: why would the job engine try to leverage the default credentials when indexing and VSS are disabled? Or, how can I tell the job it's fine to do a crash consistent backup for these specific machines without disabling VSS for the others?

[Andreas Neufert]

It depends on how you set this.
You can enable both on the quest processing tab and define per VM other rules at the advanced options. Can you please document here a bit more how you did it?

[Jonathan]

In the advanced options\Hyper-V tab, I have all options turned on.
In Guest Processing, I have disabled VSS and Indexing specifically for these VM's.

When I hit 'Test' it actually tries the default credentials on these excluded machines anyway - and fails.

[Andreas Neufert]

Ah now I understand. Yes, the Test button checks the connection to all VMs regardless of the settings. So the errors are expected in your case. The test button is used for only credentials checks to avoid failed jobs because of typos in the credentials.

[Jonathan]

I get that, but the backup job actually fails.

[Andreas Neufert]

Please open a ticket and upload logs. Our support team can help for sure.

[Vitaliy S.]

Before opening a support case, can you please post a screenshot to make sure that the job fails because of these VMs?

[Jonathan]

This is the job summary for the retry:

Code: Select all

30-1-2017 07:06:54 :: Job started at 1/30/2017 7:06:53 AM 
30-1-2017 07:06:56 :: Building VMs list 
30-1-2017 07:17:00 :: VM size: 300.0 GB (133.2 GB used) 
30-1-2017 07:17:00 :: Changed block tracking is enabled 
30-1-2017 07:17:05 :: Processing <vm1 name> Error: Failed to prepare guests for volume snapshot. 
30-1-2017 07:19:10 :: Processing <vm2 name> Error: Failed to prepare guests for volume snapshot. 
30-1-2017 07:20:21 :: Processing <vm3 name> Error: Failed to prepare guests for volume snapshot. 
30-1-2017 07:21:31 :: All VMs have been queued for processing 
30-1-2017 07:22:39 :: Job finished with error at 1/30/2017 7:22:39 AM 

[Vitaliy S.]

Doesn't seem like a credentials issue. Do you have any details for these VMs? What's in their session log?

[Jonathan]

Believe it or not, after an upgrade to 9.5 which was already scheduled, the errors completely disappeared. Thanks for the input guys!