VMware Cloud Community
jarsenea
Contributor
Contributor

Anyone else having these VDR issues?

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..

Tags (1)
0 Kudos
252 Replies
Stevester
Contributor
Contributor

I read what you said, and once again, less not totally count out an open source solution. There is no contract with GhettoVCB and yet its used and very popular I might add.

0 Kudos
KBuchanan
Enthusiast
Enthusiast

Fully agree with you.

Open source an community supported software has its place within a business IT infrastructure. I would be careful that someone not confuse free open source as always a viable solution.

Anyway...I am still running VDR and I am hoping that VMware is able to fix the problems reported in the community postings...but it is our responsibility to report the problems as an SR case so that they get an officially recorded statement of the problem. Until VMware releases a version that is reliable in my environment, I will continue to test and work with their tech support. The VDR features are incredibly outstanding...I just need to see it work consistently and reliably well in my environment.

0 Kudos
Stevester
Contributor
Contributor

Let's all just give VDR a chance. You have to crawl before you can walk. Its gonna take time before it gets polished and consistent. I am sure the VMWare engineers are well aware of what needs to be done. We just need to give them a chance and be patient.

Take care everyone!!!!!

Stevester

0 Kudos
KBuchanan
Enthusiast
Enthusiast

Absolutely!

Believe it or not, I got a call last week from the VMware Product Mgr for VDR. He is actively reading the community threads, and I believe the VDR product will ROCK - in the next major release. Most of the problems come from people using poor quality storage destinations - although, I have had numerous problems on high end FC destinations.

Anyway - I think it is important to test VDR and report problems as an SR case. Don't complain about VDR in the forums, unless you are opening an SR. Opening a SR will ultimately be beneficial to everyone because it helps them to better understand how VDR is being used in the various different configurations.

I'm just as quick to point out my frustrations with VDR b/c I think there some serious problems under the hood...which I why I have several open SR cases now.

I think that when another major release of VDR is available, it will be more reliable. I just hope that it doesn't lose too much credibility before then.

0 Kudos
Mirko_Huth
Enthusiast
Enthusiast

Not only the product lost it's credibility vmware also did in my opinion. VDR is not a beta product. That's why customers can expect it to work as is.

I'm really disappointed that VMware is not feeling responsible and is moving it's quality control to the customers site!

It's not ready yet and VMware product mgmt seemed to ignore the developement progress just to lauch it together with vSphere.

And blaming the customers Hardware is not the right way to handle insufficient testing done by vmware.

By the way, has anyone seen an increase of iSCSI performance by factor 10 in v4phere as promised? I doubt...

Just my opinion...

0 Kudos
KBuchanan
Enthusiast
Enthusiast

I don't recall seeing any promise to increase iSCSI performance, but the performance doesn't appear any different in 4.0 vs 3.5.

As for VDR...we should treat this as a 1.0 product (well, I suppose that won't be too hard) and we should test it and report the problems to VMware. And for now, don't rely on it as a backup solution unless we see (collectively) that it is working for the masses.

VDR promises to be awesome - we just need to give it every opportunity.

0 Kudos
ruddg
Enthusiast
Enthusiast

Have to agree here. vDR is not even a beta quality product... unbelievably poor.

I am seeing this same problem on a CIFS share. Tried 1.0.0 and 1.0.1. Looks like I'll have to nuke the whole thing... don't have time to waste on SRs for crud like this!

0 Kudos
Stevester
Contributor
Contributor

Wow!!!!!!!!!!!!!! VDR is that bad huh. Well i guess i will have to wait and continue to use the GhettoVCB.sh script. In particular, I have a 120 GB physical machine which i am eventually going to convert to a 120GB VM. I would really NOT like to continue performing full backups of that machine every night via ghettoVCB.sh. I need a data deduplication system and we are entitled to VDR. Guess i will have to wait,lol!!!!!!!!!!!!!!!!!

Stevester

0 Kudos
TAMW
Enthusiast
Enthusiast

Afwezig,

Zoals de meeste van jullie weten ben ik op dit moment vrij, ik ben weer aanwezig op maandag 7 september. Voor dringende zaken kunt u bij Erik de Wit (tel: 0318-559153) of Jan-Willem van den Hoek (tel: 0318-559150)terecht.

Met vriendelijke groet,

Gertjan Pruim

0 Kudos
Stevester
Contributor
Contributor

Can this be converted to English, i cant understand. LOL!!!!!!!!!!!!!!!

0 Kudos
KBuchanan
Enthusiast
Enthusiast

Well - for me, it is OFFICIAL. I am not going to run the VDR until I hear that it is running without any problems. After much effort, I am throwing the towel in the ring. Maybe the next release will be more impressive - and actually work reliably. Even though I have heard VMware say they have customers running it without problems - I JUST DON'T BELIEVE IT.

But - to anyone that is interested, here is a script that is set to run as a cron job on each of the ESX hosts in farm. I have to balance the times that they run - but, at least they running SUCCESSFULLY. I only have 6 ESX servers, so the overhead with managing when each host begins their backup is NOTHING compared to the overhead of trying to get VDR to work.

It isn't elegant - there isn't any notification if there is a failure - BUT HEY...NEITHER DOES VDR!

This is as simple as it can get. I have seen other elaborate backup scripts...but (for me) they are overkill. I have this set to save 3 copies - but you can modify it (just read through the code). The only thing you shoud really have to change, is the backup path. I am using my VDR datastore (/vmfs/volumes/ESXDataRecStore)...just change this to your backup destination path.

Good luck to everyone! We'll meet again when the next version of VDR is released!

This is the script below:

  1. This script will enumerate the guests running on this

  2. host, snap it, clone it, and remove the snaps

  3. This script will also keep 3 versions of the backups

for VMXFILE in $(/usr/bin/vmware-cmd -l)

do

FLDRNAME=`dirname $VMXFILE`;

VMXCFG=`basename $VMXFILE`;

GUESTNAME=`basename $VMXFILE .vmx`

BKUPDIR=/vmfs/volumes/ESXDataRecStore/$GUESTNAME

http:// -d $BKUPDIR.1 || ( mkdir $BKUPDIR.1 && touch $BKUPDIR.1/emptydir.txt; )

http:// -d $BKUPDIR.2 || ( mkdir $BKUPDIR.2 && touch $BKUPDIR.2/emptydir.txt; )

http:// -d $BKUPDIR.3 || ( mkdir $BKUPDIR.3 && touch $BKUPDIR.2/emptydir.txt; )

rm -f $BKUPDIR.3/*

mv $BKUPDIR.2/* $BKUPDIR.3/

mv $BKUPDIR.1/* $BKUPDIR.2/

cp $VMXFILE $BKUPDIR.1

/usr/bin/vmware-cmd $VMXFILE createsnapshot BackupSnap BackupSnap 1 0;

for VMDKFILE in $(find $FLDRNAME -type f -name "$GUESTNAME.vmdk")

do

VMDKFILENAME=`basename $VMDKFILE`

/usr/sbin/vmkfstools -i $VMDKFILE -d thin $BKUPDIR.1/$VMDKFILENAME

done

for VMDKFILE in $(find $FLDRNAME -type f -name "$GUESTNAME"_"?.vmdk")

do

VMDKFILENAME=`basename $VMDKFILE`

/usr/sbin/vmkfstools -i $VMDKFILE -d thin $BKUPDIR.1/$VMDKFILENAME

done

/usr/bin/vmware-cmd $VMXFILE removesnapshots

done

0 Kudos
XavierE
Enthusiast
Enthusiast

I give up with VDR as well. I have been testing well enough and I've been losing time.

I will keep using the script I wrote in the meantime, it's simple, nothing complex and has been working fine for me.

The script is attached if anyone'd like to use it. Here are some notes:

  • The script should run on the VCB proxy server.

  • There's a part to fill out variables to suit it to your environment

  • It sends notifications when it's done and attaches the log.

  • It also notifies about general failure backups.

0 Kudos
Stevester
Contributor
Contributor

Does anyone know if an open source data deduplication or freeware solution has been developed or is in the making.

Just curious

Stevester

0 Kudos
FBlanchet
Contributor
Contributor

Take a look at Windows Storage Server 2008 (WSS), witch is an embedded version of windows 2008, that you will use ase an ISCSI target, it runs data dedup. I have the ISO, named "en_windows_storage_server_2008_embedded_basic_standard_enterprise_workgroup_dvd_x64_x15-49574.iso" contact me by email if you want it...

0 Kudos
XavierE
Enthusiast
Enthusiast

0 Kudos
Stevester
Contributor
Contributor

I saw this and I assume this is only a virtual appliance that does file level deduplication. Can it do deduplication on VM snapshots as VDR does?

Stevester

0 Kudos
Stevester
Contributor
Contributor

Can this do deduplication at the VM snapshot level as VDR does?

0 Kudos
06blade
Enthusiast
Enthusiast

the only way I've managed to resolve the snapshot issues are to create another storage destination.

It works for a while.....before screwing up again.

0 Kudos
Elgreco
Contributor
Contributor

The same error here...destioation volume error 2241

vdr is still full of bugs and i wonder why they put it in the production ...

0 Kudos
morciod
Contributor
Contributor

This message is for Adisarro.

Are you running vdr from remote site across the wan to a datacenter network share? we are testing vdr against local vm's and have not had many issues. deploying to remote site and sending data back across the wan cannot be tested in our environment yet. have you any experiences?

Debbie
0 Kudos