tampatechman
asked on
Backup SQL Enterprise 2012 to network location
We are having difficulty with the built-in SQL backup directing it to a network location. It only functions properly when the destination is a local disk. We are in a workgroup setup so no active directory. When we tried to use a UNC path and a mapped drive we got permission errors. Do we have any options?
Nick Rhode
Are you able to browse to that share/network location normally? Permission issue usually just refers to not having access to the specific location.
ASKER
we can browse to there properly from a run box. just SQL doesnt like it
This might help you:
http://technet.microsoft.com/en-us/library/ms179313.aspx#NetworkShare
Under "Using Disk Backup Devices"
http://technet.microsoft.com/en-us/library/ms179313.aspx#NetworkShare
Under "Using Disk Backup Devices"
ASKER
our DBA tried that and told us it failed with the following error: cannot open backup device.
ASKER
would SQL respect a MKLink command making a network location a local junction? See http://pingdennis.wordpress.com/2007/10/24/mklink-command-in-windows-server-2008/
You need to grant your SQL Server service account the permission to write on that share. if it is still failing, add that user as local admin on that remote server for debugging purpose
ASKER
The share already has permission for "Everyone"
Did you add the user as local admin ? also can you make sure that the administrator on the sql server machine can connect to the UNC, and also the non admin can connect and create a file.
ASKER
the logged in server user is an administrator. the SQL services are using the system account.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi,
I understand that you're on a workgroup, but your issue perfectly illustrates the advice that SQL should run under a domain account - then things like access to network and shares etc is a lot easier to manage.
Suggestions to try:
Run SQL under a real account rather than local system or some such
Then add that account as rights to the filesystem and share on the target computer
HTH
David
I understand that you're on a workgroup, but your issue perfectly illustrates the advice that SQL should run under a domain account - then things like access to network and shares etc is a lot easier to manage.
Suggestions to try:
Run SQL under a real account rather than local system or some such
Then add that account as rights to the filesystem and share on the target computer
HTH
David