Database Corruption Nightmare
-
I'll admit when I am wrong. Veeam warned everyone about this in March
http://www.veeam.com/blog/vmware-vsphere-6-support-coming-soon.html
-
@IRJ said:
Serious issues were caused by using a combination of Veeam and VMware 6.
Serious issues were caused by using VMware. That Veeam was used is a red herring. It's VMware itself that was the problem.
Yes, in this situation Veeam's use exposed the existing issue. But Veeam is not at all what is causing it. It's only incidentally related. Any backup software for VMware or even just normal admin functions would have and will cause the same issues.
-
@IRJ said:
IMO both vendors are at fault. Someone at Veeam had to do some testing before they approved compatibility with VmWare 6. At this point who's fault it is doesn't really matter. Serious issues were caused by using a combination of Veeam and VMware 6.
I'll agree that Veeam has fault if they listed VMware 6 as a certified platform, but as mentioned this is totally a VMware problem, as most likely you'll have the same corruption problem if you just kick off a manual snapshot.
Assuming you, @IRJ, don't use Veeam, there's not reason for you to be mad/upset at them.
-
It's a tough position for Veeam, they have to make the products that their customers demand. They can't just not release products for VMware, they'd be out of business. They are caught making a great backup product for a hypervisor that they don't control. Think of all the vendors making software for Windows, if Windows has a flaw they are stuck with the stability of the platform that they are built on.
-
@scottalanmiller said:
It's a tough position for Veeam, they have to make the products that their customers demand. They can't just not release products for VMware, they'd be out of business. They are caught making a great backup product for a hypervisor that they don't control. Think of all the vendors making software for Windows, if Windows has a flaw they are stuck with the stability of the platform that they are built on.
I agree. I love being able to restore an entire VM in less than 15 minutes. I thought Veeam was the greatest thing since sliced bread.
-
I agree they have to make products for the platforms they exist on, but I agree with @IRJ I can't believe they did any real testing and didn't find this problem before they 'Certified' their software to run on it.
If they didn't ever list that they support VMware 6, then nevermind because they didn't tell customers they were ready for VMware 6 - AKA stay on VMWare 5.5 etc until they do.
-
@IRJ said:
I agree. I love being able to restore an entire VM in less than 15 minutes. I thought Veeam was the greatest thing since sliced bread.
It is! But it needs a reliable platform to work with. It works with HyperV too... which is free!
-
I heard about a problem with VMware related to the CBD (Change Based Tracking)...I did a quick google and found the relevant info...
The problem lies not with Veeam in this instance, but a bug in VMware's VDDK... see:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2090639My Google Search: https://www.google.com/search?q=VMWare+CBT+Bug&gws_rd=ssl
1st link goes to the Veeam Forums, second one goes to the KB article I linked above, and the 5th ones goes to Symantec.
-
@Dashrender said:
I agree they have to make products for the platforms they exist on, but I agree with @IRJ I can't believe they did any real testing and didn't find this problem before they 'Certified' their software to run on it.
Why? Here are some reasons:
- Obviously VMware and Veeam did test and this wasn't happening. Are you blaming Veeam for not testing but ignoring the testing that VMware obviously did? Clearly there was testing, it's silly to think that there was not.
- Many vendors, not just these, tested without finding these problems.
- We've already seen that VMware 6 is stable with the right patch, so none of the above even matters. VMware 6 isn't the issue but a specific patch level(s) of it.
- Veeam didn't fail, why would they not certify? That's silly. Veeam should not refuse to release products because their customers chose an unstable platform.
I think that any blaming of Veeam here is wrong. You are basically attacking Veeam for existing. Giving them literally no "out". Their product was flawless. That their customers might choose a platform that isn't working or a patch level that isn't working - what do you expect from Veeam? You are giving them no means of not having been wrong. You'd hate them just as much or more had they dropped VMware completely. Imagine if they did that, the discussion we would be having here about how could they abandon VMware users would be even worse.
This line is completely unfair and unreasonable to all the vendors caught by the situation.
-
Again, think of ANY company that makes software that runs on a third party system. They are always at the mercy of that product and of the customers who decide that that platform is what they are going to deploy and how they are going to deploy it.
Veeam, in this case, worked perfectly. Why would they not certify? Veeam works flawlessly with VMware 6, right? If you don't have VMware working, Veeam still works, right? The backups are still good? It's only VMware having an issue here. Even at the failure level, Veeam isn't involved.
-
Really it depends @scottalanmiller, If the version of VMware 6 wasn't the RTM, but instead a patched level, then sure I'll give you that Veeam shouldn't suffer any blame what so ever.
I'll agree that it's nearly insane to think that VMware and Veeam didn't do any testing, I'm sure they did.
The question from me is, Is the effected version of VMware 6 an effected version because of a patch they released or an RTM problem?
-
@Dashrender said:
The question from me is, Is the effected version of VMware 6 an effected version because of a patch they released or an RTM problem?
Isn't every version patched at some level? There isn't just one version.
