Ready to give up on Veeam

[marty9876]

I don't know how many more of these blow outs I can take form Veeam. I've been using Veeam since 5.x and I'm on my third complete blow out where I basically need to scrap the entire DR environment (replicas/backup files) and start over.

Anyone having long term success with Veeam?

Latest mess: Veeam Cloud Connect provider has a weeks worth of issues on their end with the result being I need to delete all my data from the backup copy job. Great DR plan there... And, my replication target (my own gear) goes snap shot stupid and basically gets all the parent/child snaps messed up to the point Veeam, VMware nor myself can make sense of it.

[CarlVon]

Yes we have had long term success with Veeam. For many years (version 5 I think). Most stable backup product I ever used.

However, as of V8 I would say there are some issues. Not a big deal, but then I contacted support for the first time since Veeam 5. Horrible. We have some good size infrastructure using Veeam and we are scared now. I would rather they just work the issue, but they are kind of indifferent too us -- with so many customers I'm not sure if they care about us. Been almost a month. Last diagnoses was needs more ram (10G RAM at the time), increased to 20G still same issue (running out of RAM on copy pools). From my standpoint, I would love someone to work my problem a bit, one guy went on a webex and said, hey this needs to go to development after watching 10G ram get sucked up in 3 seconds on copy pools only, then nothing, then limit your restore points (5), then, did you limit your restore points?, then Increase your RAM. Now, they are going to see if it could 'be anything else'. It's odd because we have 3 systems a 3 separate companies doing the same thing with copy pools.

I think they have asked me 2-3 times now if I reduced the pool restore points, that tells me know one is concentrating on us.

[m_zolkin]

I don't know how many more of these blow outs I can take form Veeam. I've been using Veeam since 5.x and I'm on my third complete blow out where I basically need to scrap the entire DR environment (replicas/backup files) and start over.

Anyone having long term success with Veeam?

Latest mess: Veeam Cloud Connect provider has a weeks worth of issues on their end with the result being I need to delete all my data from the backup copy job. Great DR plan there... And, my replication target (my own gear) goes snap shot stupid and basically gets all the parent/child snaps messed up to the point Veeam, VMware nor myself can make sense of it.

Hello Marty,

It's Mike Zolkin from the Veeam Customer Support.
I took a look at the tickets you had with us in 2015 (there were 3 so far). You had one ticket closed, where the suggested solution did help you (00735034). There are two ongoing tickets also (00846055, 00846885). Both of them seem to be a VMware related, but one of my senior guys will take a closer look at them today/tomorrow.

Really sad to hear that you had some poor experience with our support team. I reviewed you ticket history, you were one of our valued customers since 2010. We'll do our best to return your faith in us.

Could you also send me a PM sharing some more details regarding a Cloud Connect issue.

[marty9876]

That's just it, the really bad blow outs are always (almost) VMware issues. I get the difference between Veeam and VMware but in all honesty your product is making the VMware calls and it VMware won't clean up after themselves then Veeam needs to put the brakes on in some context. The "All Veeam does is make calls to VMware" is a support line cope out. If I pointed the finger at other vendors I'd be out of a job.

iland went to the dumps last week, still not working this week. Data is all hosed up, can't remap the jobs or anything. Get Keyset can't restore from file (job errors out right away, that's after spending 1/2 the day not being able to connect to their environment at all). Their recommendation is to dump all the data and start over. Wish I could but the WAN cache on their end is full (again, this is like the 5th time I've had that issue) so yet again another job not working. I tried iland in Veeam 5.x days, was a unreliable solution and I guess some things don't change.

I haven't opened up many tickets with Veeam, honestly the time and effort it takes to drive to a conclusion when it's just pointing the finger at VMware is not worth it.

[m_zolkin]

Yes we have had long term success with Veeam. For many years (version 5 I think). Most stable backup product I ever used.

However, as of V8 I would say there are some issues. Not a big deal, but then I contacted support for the first time since Veeam 5. Horrible. We have some good size infrastructure using Veeam and we are scared now. I would rather they just work the issue, but they are kind of indifferent too us -- with so many customers I'm not sure if they care about us. Been almost a month. Last diagnoses was needs more ram (10G RAM at the time), increased to 20G still same issue (running out of RAM on copy pools). From my standpoint, I would love someone to work my problem a bit, one guy went on a webex and said, hey this needs to go to development after watching 10G ram get sucked up in 3 seconds on copy pools only, then nothing, then limit your restore points (5), then, did you limit your restore points?, then Increase your RAM. Now, they are going to see if it could 'be anything else'. It's odd because we have 3 systems a 3 separate companies doing the same thing with copy pools.

I think they have asked me 2-3 times now if I reduced the pool restore points, that tells me know one is concentrating on us.

Good day, Dan,

I assume you were talking about 00822720. If so, our Tier 2 Support Manager took this one under his personal control. I will check with him the current state and involve our dev team if needed.
We will get it sorted out soon.

Mike

[Gostev]

your product is making the VMware calls and if VMware won't clean up after themselves then Veeam needs to put the brakes on in some context

Unfortunately, it is not possible in most cases. I don't know what is causing this specific issue, but for example as far as snapshot management goes, VMware specifically isolates ISVs from any and all possibilities to control or interfere with the process. We are literally isolated to two calls around snapshot management (Create and Remove), other than that it is one huge black box for us.

As much as we can possibly do in some cases, is to fix the collateral damage (one example is Snapshot Hunter feature in v8), but we cannot possibly prevent potential damage from that "black box".

Note - I am not trying to find any excuses, just addressing this specific statement from R&D perspective and from pure facts standpoint.

[m_zolkin]

That's just it, the really bad blow outs are always (almost) VMware issues. I get the difference between Veeam and VMware but in all honesty your product is making the VMware calls and it VMware won't clean up after themselves then Veeam needs to put the brakes on in some context. The "All Veeam does is make calls to VMware" is a support line cope out. If I pointed the finger at other vendors I'd be out of a job.

Marty, if we find an issue is caused by VMware or any other 3rd party vendor, we usually submit a ticket with them on behalf of our joint customer to make sure we are not playing "ping pong". We help customer to describe an issue to a 3rd party support representative and then we are with customer until it's resolved or explained.

The same applies for your ticket, If you feel the suggested KB is not related to the issue - we can work together with VMware to check what they say.