Enable SQL Server to backup on remote machines/drives

Use the UNC path when specifying the destination-- the SQL Agent doesn't have a concept of "mapped" "drives".

Also, SQL Agent typically runs as "Local Service" or "Local System" and, as such, doesn't have rights to remote shares on other computers.

You have a couple of choices:

• Run SQL Agent as a role account in the domain. Grant that account permission to write to the directory / share where you'd like the backups stored.

• Run SQL Agent as "Network Service". It will authenticate to the sharing server with the domain computer account of the machine the service is running on. Grant that account permission to write to the directory / share where you'd like the backup stored.

• If you don't have a domain, create an account with the same username and password on both the machine hosting SQL Agent and the machine hosting the backup files. Change SQL Agent to run as this "role" account, and grant that account permission to write to the directory / share where you'd like the backup stored. (The "poor man's domain"...)

I totally agree with both answers about UNC path.

I would also like to add that even with mapped drives you have a simple workaround. You can execute a backup to any of normal drives of your server. And then you can add

xp_cmdshell 'XCOPY [source] [destination] \flags'

SQL command to the job or SQL script you run.

With xp_cmdshell you can do even more - for example run an external archive command line tool, like 7z to compress the file before you will copy it to the mapped drive (when remote connection is too slow...)

P.S.: Forgot to mention that xp_cmdshell can be enabled and disabled by using the Surface Area Configuration tool and by executing sp_configure (and by default it is disabled)

If SQL Server doesn't run under a domain account, you can map a network drive for sqlserver account(not your account) as per described in this stackoverflow answer

First you need to enable xp_cmdshell

-- allow changes to advanced options 
EXEC sp_configure 'show advanced options', 1
GO
-- Update currently configured values for advanced options.
RECONFIGURE
GO
-- To enable xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 1
GO
-- Update currently configured values for advanced options.
RECONFIGURE
GO

Then you you can map a drive using:

EXEC xp_cmdshell 'NET USE Z: \\Srv\Path password1 /USER:Domain\UserName'

Finally you can backup to that mapped drive:

BACKUP DATABASE myDB TO DISK = 'z:\file.bak'

Your agent needs access to the network shares. They don't need to be mapped beforehand.

You do it like this:

BACKUP DATABASE myDB TO DISK = '\\machine\share\dir\file.bak'

I believe that if the user that owns the job is a sql sysadmin, it runs under the agent, otherwise it runs as the non-sysadmin user.

Keep in mind here that SQL Server is very intolerant of network delays. If they occur, and they tend to, the backup will fail. I do not recommend this practice at all for production environments.

Better to back up locally and then copy.

The most easy way is to create a .vhd drive on a network share through disk management and assign a drive letter to it. SQL can access this drive without any modification.

Just add a diskpart.exe script to scheduler on boot in order to auto attach on restart.

example select vdisk file="\{ip address/server}{networkshare}{filenamep.vhd}" attach vdisk // remembers the last drive letter assigned to.