Verify Job failing after dedupe

[B77]

Hi, 

I have two Hyper-V VMs that seem to be backing up to dedupe successfully and then duplicating to tape.  I've scheduled the Verify on the dedupe job to run the following day.  This works fine for all my jobs bar 2.

They both are verifying a lot more data than has been backed up.. One show's error E000810D (V-79-57344-33037- Error- Mount failed.) the other shows E00084D4 (Unexpected end of backup set encountered on dedupe disk:5)

There's obviously something off-key with the backup so my plan was to somehow clear the historical backups and start afresh.  Question is though, how would I clear this backup from the dedupe drive.

Cheers

[CraigV]

Hi,

The TN below is for BE 2010 so ignore the 2nd recommendation (new selection list), but try the first:

http://www.symantec.com/business/support/index?page=content&id=TECH168885

Thanks!

[B77]

Hi Craig,

One server doesn't have GRT option and the other doesn't have it enabled for Hyper-V

The problems occur when it's verifying the dedupe job.  The duplicate to tape works fine.

Cheers

[VJware]

What type of dedupe is being used ? Is it client-side or media-side ...If former, change it to media-side dedupe & observe the results of the verify job..

[B77]

I was using client-side.  I've since removed the dedupe to backup directly to tape, which works fine.  I'll backup again to dedupe once I've got a couple of decent backups and test your theory.  Cheers.

[teiva-boy]

You shouldn't be verifying the Dedupe based backup, just the tape one.

[B77]

I spoke with Symantec directly regarding the verify and their recommendation was to verify it but schedule for later so it doesn't interfere with the backup window.

[B77]

Now I've had this error start with another job that was fine up until last night's backup.

[teiva-boy]

Talk to support, they give that schpeel.

Take a field engineer into a room and have them spill the beans, they'll tell you what I stated.  You do not verify a dedupe backup for many reasons related to performance, reliability, etc.  

Now a new feature in BE2010 onwards allows a verify job to be part of a policy to be scheduled AFTER the backup job.  But even still it's not necessary.

When a verify happens, it now has to rehydrate each file out of the dedupe store, killing performance of the BE server.  Just to ensure the data has the right checksum.  However, since the data is deduplicated, it's not the original file to begin with.  

When you write to tape, the data is already hydrated and in its original format.  Thus a verify is pretty straight forward, and is recommended here.

I go by the rule of what is the real-world and works in practice.  Symantec goes by what is safe to cover themselves.  Ask any product manager or field SE, they'll tell you the documentation is misleading or too conservative.

[B77]

Thanks teiva-boy for taking the time to reply.

I had originally set the dedupe verify during the day and as the server does nothing but run backups, the performance isn't a major issue.  And like you say, the backup/verify  direct to tape works fine.

So to confirm.  To use the dedupe, I'll run the backup to dedupe, disable verify, duplicate to tape and verify that?

Cheers

[B77 · Accepted solution]

Update: This seems to have come right by itself after the weekend's full backup.  Must have been something it wasn't liking within the differential.  It has since run without any issues.