VM Migration best practices

[DennisT]

I've been doing some maintenance on my vsphere servers and this has been creating havoc with my backups. I'm wondering what is the best procedure to prevent this from happening.

Here's what happened:
Migrated all VMs to another host, then some back with many now on a different host (doing a manual load balance).
Start the backup job wizard.
Click on Recalculate on the VM page. All show proper sizes. Tried adding a couple VMs just to be sure, however when I add one nothing happens. I take this to mean since the VM is already on the list it is skipped when an attempt is made to add it again.
Application aware processing is not checked and neither is enable guest file system indexing.
Backup runs. Some systems back up, some get a Error: Failed to call RPC function 'FcIsExists': The user name or password is incorrect. I get a notification email of the failures (though the # of failed backups doesn't match the job instance history).

So what should I be doing? Should I just delete and readd the VM from all associated backup jobs when the VM is migrated regardless?

[PetrM]

Hello,

I don't think I can give you an advice unless I clearly understand the reason of RPC error. It would be best to contact our support team, upload debug logs and ask them to explain what went wrong and why, after that we'll be able to work out an action plan to prevent this problem in future. Please share a support case ID over here so that we can keep an eye on it.

I also have an off topic question: why you don't use application-aware image processing? It's a proper way to produce transactionally consistent backups.

Thanks!

[DennisT]

I did contact support about 3 weeks ago. I finally gave up and R&R'd every VM from the job and that fixed it. I then had to do more migrations and the problem is back, thus why I started this thread.

I quit using application-aware as I was getting the RPC errors. That appears to be the only place in a job that needs passwords. It appears that didn't help. Right now I need to be able to make backups and other than one day this week I haven't been able to. I closed the case as it wasn't going anywhere.

[rennerstefan]

Hi Dennis,

I'd really recommend to open that ticket again as support should have a look at your issue.
RPC errors are almost impossible to solve over the forum in most cases.
If you have issues with support you can always use the official escalation process detailed here: https://www.veeam.com/kb2320

If both, app aware processing as well as indexing are disabled I'd look at the destionation side of things.
What is the repo your are writing to? A NAS?

Thanks

[DennisT]

It seems the best procedure I can come up with is if a VM is migrated in Vcenter delete it from the backup and then re add it in every job it is in.
"Recalculate" and "Test Now" are misleading as they will be successful yet the backup will fail.
Incrementals will email they were successful yet when looking at the log I see "[VM] is no longer processed by this job. Make sure this change is intentional." I disagree with this. The email should show a status of Warning, not Success. This alone shakes my confidence in the software.

My synthetic and full backups occur over the weekend, so I won't know if they're successful until next Monday.

As to the support case - I'm busy. Slow responses, failure to answer questions, and incomplete/weak try this try that is a signal to me that getting a solution is going to take a long time. If I can come up with a workaround then that is my solution.

[PetrM]

Hi Dennis,

Not sure that it should be Warning, what if you stopped to process a VM intentionally? In this case, you'll be getting yellow reports despite there are no issues and everything works as expected. I would anyway recommend to continue working with our support team to find out what causes RPC errors now and when you enabled AAIP. Also, it make sense to analyze why does job show the message: "[VM] is no longer processed by this job", I wouldn't expect to see this message as long as VM MoRef ID (a unique ID inside vCenter for every object) remains the same after migration.

Please keep in mind that you have an option to escalate the case according to Stefan's instruction if you feel that the analysis moves into the wrong direction.

Thanks!