Veeam v6 - Task Failed Unexpectedly

[davidl]

Hi ,
I have come across quite an annoying issue which is within my Lab environment since upgrading to v6.
Now I know that generally support issues are preferred dealt with by support but because this particular system is within a demo lab and using an NFR licence I do not believe I am eligible so what I would really appreciate as apose to breaking any rules is to request some helpful hints or alternate insight on where to go from here with my problem.
The issue is with one backup in particular ( the largest of the demos) and what seems to be happening is the following;
The backup kicks off as per-normal and seems to start out ok. However the backup never completes, instead it fails on the first or second server within the job with an error that says

Task Failed Unexpectedly
Processing Finished with errors

I do not receive notification of a failure as I do when a job normally fails it just reports the failure within the UI
Based on what the logs where saying the connection from vCenter seemed to be going idle for greater than 7 minutes just before the failure causing Veeam to drop it's connection , hence causing the abrupt failure of the backup job.
Because the system was an upgrade I decided to start things from scratch however now the problem is worse than before because one of the smaller jobs which was happily working before with CBT now wants to do a full backup and is failing . This combined with the timeout and the resource usage being reported by the server made me believe that perhaps my problem was related to a lack of resources.
I then upgraded my Veeam Server to 16 GB of RAM ( from 4… ) and proceeded with some additional testing … same issue
Added a proxy to help and take some IOP load away and put it onto the SAN….. still the same issue
At this point I'm thinking resources are off the table with 16GB and 4 cores available on the backup server and 4 cores and 8GB located on the proxy so back to square one ….
Taking Veeam off the table for a moment I moved to my vSphere environment to ensure that the vCenter Server was not being overloaded during backups and that I had all available patches … VMware tools where up to date .. No old snapshots laying around just general maintenance and quality checking ( which btw revealed one of the symptoms of this issue was that the server failing within the job would keep adding snapshots ! I discovered 4 on one server )
Still having no Luck from a Veeam Perspective I have taken it back to a fresh Install , Fresh SQL instance ,Fresh Database and even a fresh set of backup files but even have the same issue .

I have also Installed KB1442 although I know it wasn't listed to address this issue ( or if my issue is even a know problem) but I felt it was worth a shot
http://www.veeam.com/kb_articles.html/KB1442
Anyway I hope I haven't rambled too much some specifics can be found below, any help you can provide on where to go from here would really be appreciated
Veeam v6 w/ Hotfix 1
VMware ESXi 4.1.0,502767
Although it's not a production system I have had to put off two Veeam v6 demo's off so far because our lab wasn't up to scratch so it would be great to get it working again but I'm starting to run out of ideas
Kindest Regards

David

[Gostev]

This is not a known issue and this has not been reported by anyone else yet, but I will remember to update this topic if something like this pops up in support. Thanks.

[davidl]

Well if Gostev has nothing to suggest I think I'll be rebuilding the server from bare metal tomorrow LOL

It is Unfortunate that it's not on a system with maintenance because imo it's generally the type of "bug" that the developers want to know about

In case I have time or simply get board over the holidays I'll take a virtual snap of the existing server with the issue before I wipe it

Please just let me know if Veeam are interested in a sanitised copy for their own R & D purposes

I work for a Gold partner so it should be relatively easy to provide a copy via local channels

Thankyou very much for your reply and I would still be intrested to know if the issue arises as a known bug and what the fix was if that information does ever become available.

I'll report back to confirm if the total server rebuild has solved my issue

[Gostev]

As per our support policy, you can open support cases even with NFR license, there is just no response time goals or response guarantee (depends on support staff availability).

[davidl]

Hi Gostev,
Thankyou for your reply, yes I know that I am technically entitled to support under NFR but call it not wanting to abuse what is generally considered a gratitude service to partners so close to the holiday period.

A rebuild of the Server from the OS up has resolved the issues I was experiencing and took less than a day to get up and running again so was probably easier than bothering anyone about the problem.

One thing I have come across though is that I have a backup called my "grave yard" which I have not been able to re-import because there is no Veeam backup mettafile associated with the vbk. The backup imports into Veeam using the standard import backup procedure but I can't seem to map a new backup job to the existing Backup Job like I could with the other jobs

Hope you get a break over the new year period

Kindest Regards,

David

[Vitaliy S.]

The backup imports into Veeam using the standard import backup procedure but I can't seem to map a new backup job to the existing Backup Job like I could with the other jobs

Hi David, it's good to hear that you've managed to sort it out, but mapping backup files created by different backup servers is not supported. Is this what you've tried to do?

Happy holidays!

[Gostev]

For restore purposes, you can import backup made by any version. However, the backup mapping is only supported for backups created by v6, so this is expected. Vitaly is talking about additional current limitation of backup mapping (you cannot map backup created by one v6 deployment into another v6 deployment).

Thanks for the update, and happy holidays.

[davidl]

Thankyou for the information about the vbm files and importing the job

What threw me off was that 2 of my jobs had vbm files and one did not , the reasoning being I assume that when I initially upgraded it kept the jobs in place , when I ran the jobs after the upgrade I assume it would have created a v6 mettafile for the 2 backup jobs I did my testing on ( despite failing and having issues ). Which makes perfect sense as I never ran the Grave Yard Job between the time of the upgrade and the re-installation of the server.

Incidentally it's funny you say that mapping from a different server isn't supported as my new Veeam installation would have seen this as a new server for all intents and purposes; formatted drive , Fresh OS , Fresh PC Name , AD SID etc , but I was able to import the 2 v6 Metafiles I had available and it allowed me to map my new backup Jobs to them should it not have allowed this ?

Thankyou for clarifying what I was getting for the third job was the expected behaviour for the import

[Gostev]

Incidentally it's funny you say that mapping from a different server isn't supported as my new Veeam installation would have seen this as a new server for all intents and purposes; formatted drive , Fresh OS , Fresh PC Name , AD SID etc , but I was able to import the 2 v6 Metafiles I had available and it allowed me to map my new backup Jobs to them should it not have allowed this?

Well, technically the mapping will work - the only issue is that the job will still do full backup instead of "re-using" the mapped backup files (which makes the whole process of mapping pointless). Guess you simply did not notice there was a full backup performed.