cancel
Showing results for 
Search instead for 
Did you mean: 

V-79-57344-851 The path for this database is invalid because it contains ex

Solihull_Helpde
Level 2
Hi All,

I have recently upgrade from BE9.1 to BE11d on Windows 2000SP4. When backing up my SQL servers (i have 2 SQL2K servers) i am receiving the error "The path for this database is invalid because it contains extra backslash characters". I have checked the relevant databases and I can find no extra backslashes. If i exclude one of the failing databases from the job it then decides to fail on another database instead.

Any ideas?

Matt
19 REPLIES 19

Shraddha_Dhaval
Level 6
Hi,


Please try to recreate selection list. Under what account the remote agent service is running? It should run under Local system a/c.

Please check the database properties in Enterprise manager and see if there are any double slash?


Thanks.

Solihull_Helpde
Level 2
Hi,

Thanks for the reply. The agent is running under the local system account and none of my databases have double slashes in them. Do you have nay other ideas?

Many thanks,

John_Rounds
Level 4
I have this same problem now too. It doesn't even tell me what database it's having trouble with!!
Just saw the error this AM.. will look into it and update if I come up w/ anything.

Jeff_Zankofsky
Level 5
Employee
Unfortunately, you will have to check the properties of all of them in the Enterprise Admin to see which one has the "\\"

Here's an article that tells you how to fix it. Look under the Workaround section: http://seer.entsupport.symantec.com/docs/284887.htm

Solihull_Helpde
Level 2
Hi Jeff,

As stated in my original post I have checked all my databases and none of them contain double slashes. In fact If I exclude one of the failing db's from the backup then the error moves to another db that was fine until then.

I am rapidly loosing patience with this product.

Regards

Jeff_Zankofsky
Level 5
Employee
Matt,

That is very strange. Cant say I've seen this before without there being an extra \ in the path. If you do a "select * from sysfiles" in the query analyzer on that DB, what is returned? Does it happen on system db's or just user db's?

If you job is set to use AOFO, try turning that off as a test to see if VSS may be causing a problem.

Alec_Waters
Level 2
I am having the exact same problem. The database in question is a named instance of MSDE that is used with SharePoint Team Services. The server and instance are called:

HYPNOS\SHAREPOINT

The error I get is:

Backup- http://hypnos\Team DB 1 (HYPNOS\SHAREPOINT\STS_hypnos_1) V-79-57344-34110 - AOFO: Initialization failure on: "HYPNOS". Advanced Open File Option used: Microsoft Volume Shadow Copy Service (VSS).
Snapshot provider error (0xE0000353): The path for this database is invalid because it contains extra backslash characters. You must remove the extra backslash characters before the database can be backed up.

I've been through the sysfiles tables of all the databases on this instance, and none of them have double slashes in them.

alec

Solihull_Helpde
Level 2
Hi Jeff,

Thanks for the reply. The select statement returns the paths with single slashes and I am not using any open file agent so am at a loss to explain this...

Regards,

Matt

Dennis_Thornton
Level 6
I saw the same error when I ran the eval version of 11d . It occurred with our WSUS MSDE. It didn't appear to be a problem as this database isn't critical and we don't run full SQL.

If we were, I'd use the built in backup ability of SQL to backup to disk and then use BE to put it to tape (assuming time windows allowed).

Dennis_Thornton
Level 6
I forgot to mention - the eval had the SQL option. Our licensed version doesn't have this option and I'm doing a full backup of the same server without an error.

Larry_Schunk
Not applicable
I have this same problem with both MSDE databases and MSEE (SQL 2005) created by and used for Windows Server Update Services. I also have Veritas Support that I pay for but they told me it was a Microsoft problem. Microsoft says it is a Veritasproblem. Veritas says it will only leave my case open for 24 hours from now. I guess I am in trouble. If anyone solves this I would sure appreciate knowing about it!

Jeff_Zankofsky
Level 5
Employee
I know that you guys have already checked the db itself.. just curious, what is returned when you run the following query on the Master db?

select * from sysaltfiles

Trevor_Harding
Not applicable
Same issue for me too. Not happy. Other than this I've been quite impressed with 11d.

I'm not even sure what databases it's having a problem with, it doesn't say in the job logs.

I've even tried setting up a completely new job from scratch, same result. We went from 10 (not 10d) to 11d, trying to backup 2 x SQL 2k servers (one of which works fine, the other has this problem)

Will watch this thread with interest....

perry_baker
Level 6
Employee Accredited
The post from Jeff Zankofsky in which he suggests running "select * from sysaltfiles" on the master DB is a good suggestion.

We have seen occasions when the filename path has a double backslash (\\).

It may not initially be visible, it may be necessary to copy the path and paste it to e text file for review. But the query should be run and the path's reviewed.

Berri_Albright
Level 2
Just f.y.i. - Veritas fixed this exact issue with a hot fix in version 10 of Backup Exec.

See http://support.veritas.com/docs/284887.

Are the Symantec guys going to come out with a hotfix for 11d like they did for 10?

I searched on all available hotfixes for 11d and there is not one available for this issue yet.

Has anybody heard about a hotfix for this issue on 11d for this error?

Jeff_Zankofsky
Level 5
Employee
Hi Berri,

This document describes the problem, and how to fix the "\\" in the SQL path. It is not a Symantec fix.

The hotfixes listed in this doc are what is causing the jobs to fail with invalid path error. Prior to these hotfixes being released, the job would succeed regardless of the path. This caused potential restore issues. Symantec developed a fix that verified the path, causing a failure if a bad path was found. This fix is in 11d as well. The only way to get a successful backup is to find the invalid path and fix it. There are two places to check this. In the Master database sysaltfiles table and in the sysfiles table on the db itself. If the path comes back okay in both locations, you may need to contact Symantec Support to make them aware of this issue.

Thanks,
Jeff

Berri_Albright
Level 2
Hi Jeff,

just fyi if you go futher down in the tech note there are 3 different permanent hotfixes that could/can be applied to the 10x version of BE.

I double checked.

perry_baker
Level 6
Employee Accredited
The Hotfix does NOT make it possible to backup databases with the double backslash configuration.

The Hotfix causes Backup Exec to "fail" the backup job...just as is stated in the technote:
Document ID: 284887
http://support.veritas.com/docs/284887
Backup Exec 10.x Microsoft SQL backups that have VSS for Advanced Open File Option (AOFO) enabled may not protect a database file due to an invalid path stored within SQL.

Here is the exact text:
Note: These hotfixes will cause the backup job to fail if it runs into an invalid SQL database path. The workaround below will still need to be performed in order to correct this issue.

Until the path configuration is changed in the manner Jeff Zankofsky suggested the backups will continue to fail...just as the Hotfixes and BE 11 are designed to function.

Mark_Cummings
Level 2
I have to admit I have seen this error and it drove me nuts.
In selecting the database for backup there is no double backslash.

If I remove the database the backup was fine. add it back and failure "double backslash".

I did however find the cause.

Using Enterprise Manager (for SQL) I found the database and log path had a double backslash in the path.
Take note of the database path, log path and database owner.
Just detach the database and reattach it removing the double backslash in the path and your backup will work.

MarkMessage was edited by:
Mark Cummings