Dedupe Folder - Undiscovered

[dgrove12]

Did you anyone figure out the issue with the dedupe folder being in an undiscovered state?  I'm not using iSCSI, so it's not related to that.  No errors in the event log.  Rebooted... restarted services... re-added with a new path/volume... still nothing.  What's the secret here?

[AmolB]

Hello 

Refer to the below articles.

http://www.symantec.com/docs/TECH127821

http://www.symantec.com/docs/TECH135492

Also upgrade to BE2010 R2 if you are using BE2010

[dgrove12]

I'm on R2 x64 now.  I will take a look at the articles you posted.  Thanks.

[AmolB]

Also make sure all 5 updates have been installed for R2

[dgrove12]

I have no updates for R2 currently installed but when I goto LiveUpdate, only one is displayed.  Do these 5 updates need to be manually downloaded and installed?

[AmolB]

After installing the 1st update again run live update it will show the next 4 updates.

[dgrove12]

Ugh... I have to udpate the agents after this.  Not cool.  Thanks for your suggestions.

[AmolB]

Well you need to push out updates to the agents, it won't ask for reboot.

[dgrove12]

Bonus.  Thanks again.

[dgrove12 · Accepted solution]

Turned out to be a password character issue.  Resolved.  My only other question is regarding full vs. differential backups.  We currently do one full and 4 diffs per week.  When you throw deduplication in the mix, doesn't the need for diffs go out the window?  If it's deduplicating the data client-side, it's only going to send those changed blocks anyway... right?  Trying to get my brain around this...  thoughts?

[teiva-boy]

Keep it as is with your normal rotation.  

Yes deduplication muddies the water a bit, but keep in mind there is a dedupe database, to catalog all the segments that get scanned to see if there is any new unique data to backup or skip over.  If you did FULL's all the time, the dedupe database would grow abnormally faster than designed.  

The Dedupe database in Symantec's eye will grow at a rate of 6-7% per TB of deduped data, this I figure is based on a normal FULL and typical incr/diff policy.  It could grow to 10% if you did FULL's all day every day.

[AmolB]

If it's deduplicating the data client-side, it's only going to send those changed blocks anyway... right?

The first backup job of the resource will  backup all the files but once you run

subsequent backup of the same resource only the changed data will be backed up.