VDR problems / anyone actually USING VDR successfully?

[AndyShinn]

I have been trying since vSphere and VDR came out to get some successful backups and rehearsal restores. I am just trying to get backups to be stable for more than a week at least..

I have reinstalled the appliance and plugin to the latest version (build 4.0.0-176771-R1.0G68) and appliance version reporting 1.0.1.362.

The errors I am receiving in the tasks view after letting VDR run overnight are:

- (vm name) incomplete"

- Trouble writing to destination volume, error -102 ( I/O error)

My backup storage is on CIFS. I cannot attach a VMDK, mainly for the reason that I don't want to use my SAN as backup storage! I setup a separate server with over 4TB space specifically designed as storage. If it WILL make a difference I guess I can mount the CIFS on the ESX host which VDR resides and create a VMDK on it. I don't see how this is any different than VDR using the CIFS share directly though...

Things I have checked:

- The CIFS share is working fine. I have an OS level backup software on some physical machines using it fine for over a month without disconnections

- There is plenty of space on the share (2 shares, 1 has over 600GB free space, the other over 3TB free space...)

- I can manually snapshot the VMs in question just fine and the LUNs over iSCSI have plenty of free space to accommodate the duplicated VM + some more...

- I have tried using the VDR appliance as-is and also upgraded the VDR appliance CentOS to latest 5.3 and kernel using instructions found on the boards here. No difference.

- The VDR appliance can ping the VC server and all the ESX hosts just fine and resolves the hostname of each fine.

Any ideas? Is anyone actually successfully using VDR for over a month without issue?

[dustinn3]

Funny everything was running great on mine for a couple of weeks till this weekend and I started getting the same exact errors. Last night I rebooted my host and the VDR appliance and then none of the snapshots would delete because VDR wasn't releasing them. Called tech support and we had to shutdown VDR, delete all the drives but the first one, and I had to manually create a new snapshot and delete all snapshots to get rid of them on each VM.

Hopefully it works tonight.

[RParker]

I have reinstalled the appliance and plugin to the latest version (build 4.0.0-176771-R1.0G68)

I have a list of stuff VDR does and does NOT do.

I see the same things as you, right now I have an outstanding issue, for OVER 120 hours now VDR is stuck at42% (currently) trying to recatalog / reclaim. It's an endless loop. If I restart it, it picks right up where it left off...

The problem is I can't perform backups while its doing this, and for almost 5 straight days it's been hammering the drive (5-8 Mbs) doing whatever its doing.. I am letting it run to see what it will do..

That's just the start of the problems and besides what you are seeing...

BTW officially you can't run multiple VDR's, unofficially multiple VDR's seems the best solution, using different backup target drives of course.

[AndyShinn]

Multiple VDR would make sense to alleviate some of the stress. It only makes sense as, you can run multiple VCB, why take a step backwards?

I don't think I am even getting to the point of your issue yet. But hopefully if we keep providing information on failures, Vmware will notice and actually test these cases instead of just releasing an update in hopes that it fixes issues.

It is quite obvious at this point that VDR had very little or no real world / lab testing at all...

[RParker]

actually test these cases instead of just releasing an update in hopes that it fixes issues.

Wow you are the first person that sees my point of view (or at least said anything about it). That's how I feel. This was SUPPOSED to be a seasoned product, that's why VM Ware bought it.. I really fail to see how it got even THIS far if you ask me...

It is quite obvious at this point that VDR had very little or no real world / lab testing at all...

Exactly what I was thinking. And to top it all off, where is the 'community' of users to test it BEFORE they decide its ready? I am guessing we are the beta testers.. but it should be READY when we get it, we shouldn't be testing bugs and finding these types of issues. As you said, 'no real world testing'.

[ian4563]

No, it won't matter if you put the dedupe store on the SAN, you will still have the same problems (iv'e been running mine on FC SAN from the start). I can't even get vDR to attempt to run jobs anymore. A week is about as long as I can get it to run without problems before I have to just wipe the dedupe store and start fresh.

[whitesj]

Mine was working fine for a few days and then it started getting hung on backing up a few VMs, seems the only way to stop it was to just restart the VDR server, but it seems to hang on the same machine everytime, not sure why since it hadn't been hanging on it before and nothing has changed on that virtual machine (no data at all)

-John

[VMSpotlight]

VDR does seem to be a little bit fiddly to get working.

For an entry level product I'd have expected it to be easier to set up!

______________________________________________________________________________________________________________________

Community Rep for PHD Virtual Technologies Inc

esXpress radically alters the notion of how to protect data in virtual infrastructures in one simple way: we use the virtual infrastructure to back itself up!

______________________________________________________________________________________________________________________

[RParker]

expected it to be easier to set up!

And use...... IT also lacks many features that would make it easier to work with as well.

Community Rep for PHD Virtual Technologies Inc

Nothing like a little competition to make you look good huh?

[RParker]

No, it won't matter if you put the dedupe store on the SAN

There is a flaw in that logic however. What is the point of backups? To preserve states of machines so you can restore if a problem arises. So if a VM has a problem, what is the most likely cause? SAN connectivity, Volume corruption.

So if you put backups on the SAME SAN where your VM's reside, and that SAN Volume has problems, the backup will ALSO become inaccessible. So that's counter intutitive to why you backup in the first place, the idea is to backup to a device that's NOT sharing the same storage as what you are trying to backup. It's like doing a Windows backup on the C: drive, if Windows crashes.. how are you going to access the C: drive to restore the data?

[Jim_Nickel]

Just thought I would update this thread and see if anyone else is actually having success with VDR - I am now using the 1.0.2 version.

I have two clients with similar setups. iSCSI SAN's and backing up to a separate Windows FIleshare. Windows shares were about 1.3 TB for one and 1.5 TB for the other. I moved one of them to use the StarWind iSCSI target and tried smaller 250 GB disks attached directly to the VDR appliance - didn't seem to make any difference.

I have had all kinds of problems which make the backups essentially useless.

Problems like:

error -107 - trouble writing to destination volume (out of application memory)

Integrity check that takes 2-3 days to get to 56% over a 1 GB link - backup speed was ok

Failed to create snapshot, error -1

Failed to create snapshot, error -3902

This product just does not seem to be ready for production use.

Please tell me if I am crazy and just setting this up wrong or if others are also having difficulties?

Thanks,

Jim

[AndyShinn]

I eventually scrapped VDR. On the outside it looks great and the features it advertises are amazing. However, it just does not work. It is unstable, the interface is lacking information and current status, and it feels like a very beta product.

I went back to consolidated backup on vSphere. Not really what I wanted. But the backups work week after week without me having to restart or fix some problem. The downside is it's slow and uses a ton of space (a full VMDK backed up takes a lot of space and has to transfer the entire image over the proxy each time).

I'll probably look back into VDR in another 6 - 12 months.

[Jim_Nickel]

Thank you for letting me know. I was starting to doubt myself.

I recommended VDR to my clients because I trusted VMware and the features looked fantastic!

If it worked, then I would be extremely happy.

Not that it could use a few things - It would be nice to have more control over scheduling. Even more important would be the ability to run a script prior to the backup and after the snapshot has been completed for quiescing databases, exchange etc.

Jim

[stltech]

I have installed VDR and all that has changed is a change from DHCP to a static address and the removal and upgrade of vmware tools by following the below link followed by a vm hardware upgrade from 4 to 7. The backup destination is a slice of a datastore on a SCSI Nexsan SASboy SAN

The first backup was set up to run a backup of a Windows 2003 Standard file server which ran absolutely fine.

The next job scheduled to run the next day came up with the following error

Failed to create snapshot for server X error -3941(Create Snapshot Failed)

I rebooted the Data Recovery appliance and tried it again and it was fine

I am leaving it until tomrorow to see if it will run without issue tomorrow

[athlon_crazy]

Ahh maybe I be the first who really like VDR and I'm using v1.0.2

My lab setup + customer production so far working very well but maybe it's down to my small environment which currently have less than 50x VMs.

• Lab = backup to .vmdk (local ESX)

• Production = backup to second VDR .vmdk (RDM on another SAN Box - Netapp)

vcbMC-1.0.6 Beta

vcbMC-1.0.7 Lite