Create Sql Server Backup on Local Machine

Question

I am using SQL Server Management Studio running on my local machine.

I can log on to a remote box (database engine) and use the Studio to create a database backup w

Answer 1

STEP 1 : From sql-server 2008 connect to remote server

STEP 2 : Right Click server database

STEP 3 : Select Export Option

STEP 4 : Follow Instructions, Import to local server database and Backup from Local database

Answer 2

You can't - the remote machine has no information about your local machine's setup and cannot see the drives on it. You'd have to setup a shared folder on your local machine, and make sure the remote machine has access to it (which will mean both the SQL Server Agent and SQL Server services on the remote machine will need access to it via domain accounts).

Answer 3

See this MSDN article, for the section on backing up to a network share, e.g.:

BACKUP DATABASE YourDatabase
   TO DISK = '\\SomeMachine\Backups\YourDatabase.Bak';

Backing Up to a File on a Network
Share For SQL Server to access a remote disk file, the SQL Server service account must have access to the network share. This includes having the permissions needed for backup operations to write to the network share and for restore operations to read from it. The availability of network drives and permissions depends on the context is which SQL Server service is running:

• To back up to a network drive when SQL Server is running in a domain user account, the shared drive must be mapped as a network drive in the session where SQL Server is running. If you start Sqlservr.exe from command line, SQL Server sees any network drives you have mapped in your login session.
  
• When you run Sqlservr.exe as a service, SQL Server runs in a separate session that has no relation to your login session. The session in which a service runs can have its own mapped drives, although it usually does not.
  
• You can connect with the network service account by using the computer account instead of a domain user. To enable backups from specific computers to a shared drive, grant access to the computer accounts. As long as the Sqlservr.exe process that is writing the backup has access, it is irrelevant whether the user sending the BACKUP command has access.

Answer 4

If the remote machine is on the same network as your machine, see AdaTheDev's answer.

Otherwise you'll have to RDP or FTP into the remote machine and transfer the backup manually. I recommend 7-zip'ing it by the way.

Answer 5

In Microsoft SQL Server Management Studio you can right-click on the database you wish to backup and click Tasks -> Generate Scripts.

This pops open a wizard where you can set the following in order to perform a decent backup of your database, even on a remote server:

Select the database you wish to backup and hit next, In the options it presents to you: In 2010: under the Table/View Options, change 'Script Data' and 'Script Indexes' to True and hit next, In 2012: under 'General', change 'Types of data to script' from 'Schema only' to 'Schema and data' In 2014: the option to script the data is now "hidden" in step "Set Scripting Options", you have to click the "Advanced" and set "Types of data to script" to "Schema and data" value In the next four windows, hit 'select all' and then next, Choose to script to a new query window Once it's done its thing, you'll have a backup script ready in front of you. Create a new local (or remote) database, and change the first 'USE' statement in the script to use your new database. Save the script in a safe place, and go ahead and run it against your new empty database. This should create you a (nearly) duplicate local database you can then backup as you like.

If you have full access to the remote database, you can choose to check 'script all objects' in the wizard's first window and then change the 'Script Database' option to True on the next window. Watch out though, you'll need to perform a full search & replace of the database name in the script to a new database which in this case you won't have to create before running the script. This should create a more accurate duplicate but is sometimes not available due to permissions restrictions.