Error when SQL path is UNC based

[The_Netguardian]

Having a problem when trying to use Backup exec 10d SP2, to backup an SQL Database referenced via a UNC path. Heres is an example of the setup:
Server1 - Windows Server 2003 Enterprise SP1, SQL 2000 Enterprise SP3, Backup Exec 10d SP2 with SQL Agent
Server2 - Windows Storage Server 2003 R2 SP1, configured as a Database NAS(via a 10Gigabit interconnection between the servers)
The SQL on Server1 has a networked database,that is stored on Server2, connecting via a UNC path I.E. \\Server2\dbshare\database.mdf. This has been setup via Microsofts instructions on using UNC rather than a mapped drive for reliability, and for the fact our company has alot of mapped drives as it is (Citrix environment, which this database is accessed from). The SQL Agent doesn't have any problems with any of the smaller databases that are local directly on Server1, but the UNC path-based database it doesn't like. I set Backup exec to use Debug logs and ran the SGMon and the error that comes up is:
"SQL Agent Database Path Error. The database contains a path with extra backslashes. The database needs to be detached then attached again using a corrected path. See support website."
So I check the support website and come up with nada. I check the forums and see that some users had issues when a local path, I.E. c:\path\\morepath\database.mdf, had extra backslashes. But with this being a UNC path the double backslashes are sorta needed. Does anyone here know if there is a workaround or patch to actually let SQL Agent backup an SQL database that has a UNC path? Because currently moving the database local is not an option due to drive space, and the need for it being in our centralized database NAS. And mapping it to a drive isn't an option due to its need to be used via a Citrix environment. Also this database is live 24 hours and hence the need for a live backup solution.
At this point we have had to use the built-in SQL backup via a Maintenance plan, then backup the backup file to tape via Backup Exec. This isn't our best solution as it takes longer and slows down the server and database usage for a greater time.

Sorry for the length of the post, but this is really frustrating.
Any comments, questions, workarounds, etc. at this point would be more than welcome.

Brent

[Keith_Langmead]

First of all, don't appologise for the length of the post, it's a nice change to see one that actually contains all the relevant information rather than a lot of the ones we see I here!

First thing I can think of, have you checked the actual path of the database within Enterprise Manager to confirm that the location of the database is definitely \\server2, and it hasn't somehow become \\\server2? Just wondering if since I know SQL doesn't object if you have the path as c:\\, eg two slashes instead of one, perhaps the same is true for three slashes instead of two.

The only work around I can think of would be to setup merge replication between that database and a new dummy one used purely for backup. You could then backup the dummy database like normal, and in the event of a DR restore you'd recover all the databases, with the exception that the contents of the \\ referenced one, but I think the database itself should be re-created since that information is in the master.mdf, so you just kick the replication and recover the contents from the dummy database. However you'd more than triple the amount of space required for the database so it probably wouldn't be feasible.

[The_Netguardian]

Thanks for your reply Keith. I checked and the \\server2 is correct, no extra backslashes outside of a normal UNC path.

Your idea is an interesting one, but currently we are accomplishing a similar task by using the SQL to create a backup on the Database NAS, then backing up that SQL backup to tape. We are doubling the amount of space this way though, having both the live database and a backup on the same device, but we are able to get it on tape so it can be stored offsite.

If you have any other ideas, i'm more than happy to hear them.

I am a stickler for servers being kept cleaned up and used for only their required intentions. Hence the need for getting the backup straight to tape, rather than have double the space taken up on the NAS for a live and backup database. And our company is a testing facility, so the least amount of downtime or extra server load for backup is at an utmost importance since some tests run hours and even days for proper results.

Still seeking a resolution.

Brent