VDR integrity issues, terminated unexpectedly

[wm408]

Hello,

VDR 1.2.1.1616

Vsphere 4.1.0 build: 345043

     For 4 months, VDR has run flawlessly.  Recently I needed to reset permissions on the share that VDR mounts its vmdk in, (the permissions are exactly the same in regards to VDR!!!.  This may not have anything to do with the problem I am having, but it is the only thing I touched, so I blame myself). Since I did this, all I have seen are failed integrity checks on a particular VM's backups.  So I keep marking them for delete.  A day or so goes by, and the failed integrity check comes back with corrupt backups.  One day, all the VMs had failed integrity checks, so I marked those failed snaps for deletion too.

     Based on the time which VDR started back up, (1 second based on timestamp), it looks like a crash.  This keeps happening now.    

     For the past 2 weeks, I can't seem to get VDR to run an integrity check 100%.  Each time now, I get "Task terminated unexpectedly, possibly due to a power failure or system crash".  I removed all Backups until I can get the integrity check to succeed.

      If anyone has recommendations on how to troubleshoot this better than I have done, please let me know.

     If not, what I would like to do is just simply annihilate my entire NFS volume that I am backing up to, ie: delete the vmdk and start over.  But I can't format the volume because its locked by the integrity check not being successful.  And until it is successful, I am sh$# out of luck.

     Thanks for your time.

[RParker]

wm408 wrote:

Hello,

VDR 1.2.1.1616

Vsphere 4.1.0 build: 345043

     For 4 months, VDR has run flawlessly. 

Count your blessings.. I usually have to rebuild-restart at least every 2 months.. sometimes every month..

Best thing to do is redeploy a NEW VDR.  Just detach your target / backup drive from the appliance.  Power it off, delete it.  Redeploy a new one.. attach the target / backup storage.

WATCH carefully, it will prompt to IMPORT your settings / backups.  Make sure you say YES!  Then everything will be fine.

[wm408]

Thanks.  I unmounted the volume.  Went to datastores and deleted it.  I want to just start from scratch here.  Now I can't even power on VDR because its looking for its share that doesn't exist anymore.  Heh.

Going to rebuild a new VDR.

Thanks

[GDillon]

I just ran in to this problem this week after having run VDR 1.2 for about 4 months also.  The integrity check suddenly takes over 24 hours and gets cut off every time by the task window, and about 15 of my backup sets are "damaged" although there was no errors when they were created and the VDR app successfully checked them several times.  I tried replacing the VDR appliance and then attaching the existing backup store to it.   The integrity check still won't complete, so I assume it has crapped in it own bed and we will have to lose all the backup history.  I guess this is why Veeam and Acronis and others don't seem to bother comparing themselves to VDR.  It's not a serious product and doesn't belong in production.

[wm408]

Yeah... pretty much the same thing that happened to me.  I ended up wiping all of my backups and rebuilding the whole NFS volume, adding a new "local disk" to the datastores, and then re-installing VDR.

Definitely a reminder that VDR is not the solution to everything.  I will limp it along though.  I also have another backup running with different software, (symantec).  So VDR 1.2.x will be my backup of backups for now.  I am curious how VDR 2.x runs on vsphere 5.x... hrm.

[GDillon]

AFter looking around we are going with Veeam Backup and Replication, mainly because of the ability to schedule regular tests of you r backup archives where Veeam mounts your VM backup in a private lan and boots it up and run optional application test scripts.  Doesn't even require downtime for your main VM since it all happens in a private network. 

The data corruption problems we had with VDR may have been realted to the fact that we use Netapp NFS storage with deduping turned on.  The VDR backup disk was stored on a deduped volume as a large VMDK file.  between the compression and deduping within VDR and the Netapp deduping, some blocks may have gotten corrupted.  Just a theory.