I love the fact that VMware is providing VDR as part of the vSphere package. It's definitely a step in the right direction, albeit I'm still inclined to think this software hasn't been put through the ringer in terms of proper QA. I'm just trying to put out a feeler to see how many others have experienced some of the same issues I'm having.
To start, I'm backing up my VMs via a network share on a standalone Windows 2003 server that has a NAS attached to it.
Some of the issues I've noticed:
1) Backups take an inordinate amount of time. I can understand the first backup, but my VMs don't change very much from day to day. Most of the data being manipulated is located on RDMs are these are backed up using Tivoli, not VDR (I use VDR solely for the OS partitions). Each partition is approximately 25GB, there are 15 VMs and my backup window (10pm - 6pm) isn't sufficient to complete the process.
2) Integrity checks for the backups are taking a crazy amount of time and will usually stop due to my window being closed (see point #1)
3) I'm getting inconsistent "failures" for certain VMs (the report will simply state that a VM failed to backup, not much else). It also varies per night and not always the same VMs (not exactly sure if this is related to #1 where the window is closing while VDR is executing)
4) I had the most difficult time setting up the remote share from the VDR appliance in vSphere. The username and password would never be accepted (even though if I tried the same share with the same user/pass on a Windows machine, it would work fine). I finally narrowed down the problem to the simple fact that the VDR appliance can't handle passwords that have special characters in them (this password had an "@" and a ","). Looking at the console while attempting to mount the share would spit out a CIFS error -22. Changing the password to include only numbers and letters was sufficient to work around this issue.
5) Snapshots not being created for no apparent reason and thus failing the VDR process. I'm fully able to do a manual snapshot with or without the memory state, so I'm not sure why VDR can't do it. This issue is very intermittent. I had it often when I first setup VDR, but now it only happens every so often (without any type of consistency).
I think that's all I can think about for now..
Another issue I seem to have somewhat regularly is that, when trying to run a job, nothing happens. I mean nothing at all; no snapshots get created or anything. Of course, rebooting the VDR VM usually fixes this... usually.
I've had a SR open for well over a month. VDR worked (as far as I know) OK for a couple of weeks, then started throwing errors, and now it just sits there acting stupid. I've sent over a gig of logs to support and spent hours playing "Try this and see what happens".
I heard back from support a week or so ago. There's a patch coming for VDR to resolve these problems.
They couldn't say when it was coming, other than "soon". But rumor has it there's a big patch coming for ESX4, so maybe it'll be in there.
I've moved on. PHDvirtual's esXpress and its dedup feature is doing the job (and is much more flexible about where the backups live).
We have this exact problem as well. It works well for a few weeks and then falls over. It then takes days to recatalog/integrity check but never finishes.
We cannot let the integrity check run indefinitely so we have to start again with a clean repository.
Has anyone tried swapping between CIFS shares and directly-attached (i.e., VMDK) shares as destinations? Today I am getting yet another error message; I'm trying to run an integrity check on my destination and it's failing with error -2241 (Destination index invalid/damaged.)
I have had a SR open for 2 weeks now. The tech said they are aware of the many issues and a release will be coming out late Dec. He also mentioned there would be a service pack upgrade coming for ESX4 as well in that same time frame.
If you have not deployed VDR my advice is DO NOT USE IN A PRODUCTION ENVIROMENT
My first issue was that the integrity check was taking days to run despite the fact we had only made 3 days of backup. I posted the solution to that in another thread. As soon as I got that resolved a new problem started right away, the back-ups jobs were running when they were not supposed to in the middle of the day. I had a VMware tech look at and he didn't have a solution other than to wait it out as a Integrity check was going on at the same time. So after waiting several more days the 5 VM's are now stuck at various points in their back-up. I can't stop them and the Snapshots are now growing, they have been stuck for 7 days. I have had the same tech working on all these issues and I have been in contact with him everyday and honestly it doesn't seem like he has a lot of answers.
Also whenever I reboot the VDR server it doesn't remount the VDR datastore. I also just saw a thread where VDR deleted someones VMDK files, it is a known bug
VDR should have been released as 'Experimental'
At this point VMware should recall this product
I have already posted (several times) about:
- NO ONE SHOULD USE THIS IN PRODUCTION
- THE VDR PRODUCT IS FAULTY AND SHOULD BE RECALLED
- VMWARE SHOULD TAKE ACCOUNTABILITY AND WARN CLIENTS THAT THIS IS NOT A RELIABLE PRODUCT (YET)
So, I completely agree with you. After a couple of SRs, I had to give up. I don't get paid to troubleshoot "experimental" software. We paid good money for the VMWare product...it is a shame they ARE NOT LISTENING to their customers.
Has anyone heard anything from VMware regarding the possibility of fixes for these issues (or a 1.0.3 release)? I find that I have to either reboot my VDR VM every day or, at least, restart /etc/init.d/datarecovery in order for the VDR vClient plug-in to actually be able to connect to the VM.
I suggest, you STOP using VDR as a primary backup solution for production systems. There are enough problems in the forums to indicate the product has serious flaws and is highly unreliable.
STOP USING IT unless you are "testing VDR" as non-primary backup solution. If you are "testing VDR", then let me say "Thanks" - because I can't spend the time it takes to beta test it and deal with the headaches of it not working.
We have just implemented vSphere 4.0, and very happy that VMware had incoporated a backup product VMware Data Recovery. The implementation was installed 8 weeks ago, VDR has been running perfect with no issues, until the weekend. The backups just hang, integrity and recatalog no longer work, it states the store is locked and we need to remove damaged restores, but no restores are marked as damaged, we have error -2240.
We raised an SR today, and the VMware Support Repesentitive told me VDR was SHIT! (his words), and we should use another third party product e.g. Veeam or Vizioncore vRanger. He told me Support Engineers view VDR as experimental, but management view it as production.
I'll be trying to speak to my Sales/Account Manager tomorrow to try and get a handle on this, because we have no money to purchase Vizioncore/Veeam product, and don't won't to use third party addons, when we've paid-up for Enterprise, and we cannot use the backup application.
Comments, anyone know how I can cure the -2240 error?
Well it looks like we'll be speaking to VMware tomorrow, and finding out what's the situation, and trying to get some money out of them, for a third patry product to backup up our environment!!!
Go Go Go Einstein !
Let us know the outcome, as a vSphere Essentials Plus user, there is USD $ 2000 price difference with the lowest vSphere Essentials license which is for HA and VDR features.
Around the 20th of November VDR 1.1 will be released.
This release will fix a lot of problems and increase
performance drastically on certain operations.
I will send you another mail with the direct link once it
I managed to get going again, by stopping datarecovery service, removing *.lck files in the store, and restarting datarecovery. Now I need to workout why one VM backup stops at 73%
Well, seems like this and ESX4 U1 and View4 won't get released today (PST), but things have been further postponed: