Backup Exec Dedupe Folder Sometimes Useful, When It is Around

Backup Exec De-duplication Storage folders are interesting. They use postgreSQL to manage usernames and passwords for access to the contents of the folder from within BE.

The service in Windows is generally managed by BE, but can sometimes get stopped and not stay running. If this is not running the jobs fail. When the jobs fail, the software reports physical media issues.

Windows can see the physical media and reports no problems.  This issue is not physical media.  It is logical media and should be reported as such.  BE cannot access its logical volume to process the backup jobs.

When the service gets started, things may work.  If you forgot the password used by the BE, During the setup of the feature, which is not a windows logon, but stored in postgreSQL forget it.  Will need to reset the password, but if you do not know the old password, you will need to recreate a new dedupe target for backup jobs.

Doing this and restarting the services will get you rolling again, but the errors logged by BE are super misleading.  They could list the disk issue as a logical disk issue because the problem is with the logical BE volume, not the physical media where the backups are actually being written.  The Dedupe folder in BE is not physical, it is a logical folder placing items on the volume chosen to hold the backup.  And since the problem isnt really with the device in BE, but with the service managing credentials for the device, the error should attempt to point that out

Since BE already uses SQL Express for some job management and reporting, why not create a table there for the user IDs or use a Windows account to manage this.  Would simplify the process for correcting the issue.  I spent the better portion of a week trying to chase this down… found it late Saturday night while waiting for Daylight Savings Time to expire.  Great way to spend a Saturday, but it does wonders when you cannot sleep.

I am hopeful that someone from Symantec can comment on why this is configured this way and explain what they might do to correct the rather misleading error messages logged when backup jobs fail because of this.  I would love to discuss it.