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..
Yes the VDR v1.1 is here :-o)
it is Latest Released
fed-up with lack of response......
after posting a tweet today about VMware VDR, all **** has hit the fan, and the case has now been escalated!
I'll let you know how we get on...
So they escalated it. Now you'll get to hear from a "Senior Engineer" that "it still sucks". If they really can fix your problem...then...why don't they get somebody to fix the friggin' thing for EVERYONE???
Ok - so that is rhetorical. If they could fix it, they would. So the obvious conclusion is that THEY CAN'T FIX THE PROBLEMS WITH VDR.
Had a lot of issues with 1.0.x - 1.0.2 wasn't running at all.
In contrast 1.1 works like charm. Having it running since the official release I have backed up about 30 machines, did several restores (complete, clone, single file) without any problems.
New GUI File Level Restore (FLR) for windows is nice (but slow).
I really hope things stay like this and I finally got a nice backup solution for my system.
Just in case of questions: I did not upgrade the VDR appliance nor reused the destination store. Since the previous version wasn't running I simple did a clean install from scratch.
From my tests VDR 1.1 does seem faster and more responsive, the VDR appliance has changed from Centos to Red Hat Linux (64bit I think!).
But I still have the hanging issue with one VM, it sticks at 73%, and then stops all the other jobs from running.
I managed to fix all the damaged restore points, and integrity check not running, by removing all the *.LCK files from with the datastore, and *.cat indexes. After this I re-ran datarecovery service, and was able to remove/delete (mark for delete) damaged restore points.
But with VDR 1.0, a few VMs still hung. I upgraded to VDR 1.1, and the same issue occured. I've since, moved all the VMs into seperate backup jobs, Brought all the different (16) backup jobs to compliance, and then moved all VMs back into one job. (Upgrade to VDR 1.1 was under VMware SR advice).
But I still have one VM, that faults, and sticks at 73%.
I don't know, why after 7-8 weeks it just stopped, and they all hung, and I had major issues, unless it's the store, thats getting bigger, but we're only small installation at present, 16 VMs, and 30-40GB, out of 100GB de-deuplication store.
The real issue here, we do not have any more cash to spend, after spending on VSphere 4.0 Enterprise + SAN, and we had hoped that VDR would do the job as backup, plus it's integrated as a total solution, rather than addon, Third Party products. We also don't have any cash left to purchase Vizioncore/Veeam.
We much rather the VMware on VMware approach, rather than Veeam or Vizioncore on VMware, if you understand, it keeps it simple for the us.
At least VMware Support are talking to me know, and I'm thankful for that. I'm concerened at the VMware Engineer comments though, and I'll be asking questions about this.
We will see what they find.
Thanks for the info. Please keep us posted. I'm very interested if it still works for you after the first full integrity check starts...
That was always the point where my issues started with the older versions.
LOL.. ... same feelings here too Einstein :-o)
I wish that I can fully trust VDR than having to get 3rd party apps. to do the backup, this is such a shame to VMWare and also unfair since they close / limit the replication API in ESXi
I can't honestly say that. As I've said in some other posts, my "gut feel" says this is the release we have been waiting for but I won't sign off on it untill I've had every aspect working reliably for a month at least.
If your 1.02 install is stable and mission critical. I'd veer away from upgrading just yet. If you've got the luxury of still being in a testing phase like me then go for the upgrade now.
I started a fresh with a new dedupe store rather than trying to bring over my old 1.02 store and I think this is a good idea as I've heard about issues with people upgrading their 1.02 data store.
Hope this helps.
With the help of VMware Support (Many Thanks to VMware), we found a <vm-name>.ctk.vmdk which was corrupted which was causing the backup of the VM to hang at 72/73%, Once this files had been removed, I'm now running VDR 1.1 as sweet as a nut, with no issues.
Backup and Restore are running fine. I have a 100GB local vmdk used as the store, mounted on a local vmfs (mirrored pair of discs) in my server. The VMs in my environment are shared from an iSCSI MSA2324i (SAS disks), 1 LUN per VM. At present we are using software iSCSI to do these operation over dedicated gigabit storage VLAN.
I much prefer the totally integrated solution of VDR, in vCenter for our clients with little VMware knowledge, rather than use third party products.
One happy VMware vSphere 4.0 Enterprise customer.
Sounds promising...2-3 months steady and reliable usage will be the litmus test.
Chief Information Officer
Lexington Memorial Hospital
Lexington, NC 27293