我知道这是一个旧的帖子，但对于它的价值，我发现“最简单”的解决方案是右键单击数据库，并选择“任务”->“导出数据层应用程序”。这个选项可能只是因为服务器托管在Azure上(根据我过去使用Azure的记忆，.bacpac格式在那里非常常见)。

完成此操作后，您可以右键单击本地服务器“Databases”列表，并使用“Import data -tier Application”，使用.bacpac文件将数据获取到本地机器。

不过要记住，输出可能需要很长时间。我的出口花了大约两个小时。不过，导入部分要快得多。

使用SQL Server 2019中的存储过程

CREATE PROCEDURE [dbo].[BackupDB]
@backupPath nchar(200), 
@dbname nchar(50)
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @backupDate as nchar(10) 
    SELECT @backupDate = CONVERT(VARCHAR(10),GETDATE(),112) 
    IF DB_ID(TRIM(@dbname)) IS NOT NULL
    BEGIN
        SET @backupPath = TRIM(@backupPath) + TRIM(@dbname) + '_' + TRIM(@backupDate) + '.BAK'
        BACKUP DATABASE @dbname TO DISK = @backupPath
    END 
END
GO

部分第三方备份程序允许设置文件传输的网络权限。当SQL Server服务在受限帐户下运行且没有足够的网络权限时，它非常有用。尝试使用EMS SQL Backup解决此任务。

在Microsoft SQL Server Management Studio中，您可以右键单击要备份的数据库，然后单击Tasks -> Generate Scripts。

这会弹出一个向导，你可以在其中设置以下内容，以便对数据库进行像样的备份，即使是在远程服务器上:

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

一旦它完成了自己的工作，就会有一个备份脚本摆在你面前。创建一个新的本地(或远程)数据库，并更改脚本中的第一个'USE'语句以使用您的新数据库。将脚本保存在一个安全的地方，然后在新的空数据库上运行它。这将创建一个(几乎)重复的本地数据库，然后可以根据需要进行备份。

如果您拥有远程数据库的完全访问权限，您可以选择在向导的第一个窗口中勾选“脚本所有对象”，然后在下一个窗口中将“脚本数据库”选项更改为True。不过要注意，您需要执行一个完整的搜索并将脚本中的数据库名称替换为一个新的数据库，在这种情况下，您不必在运行脚本之前创建这个数据库。这应该创建一个更准确的副本，但由于权限限制，有时不可用。

我知道这是一个旧的帖子，但对于它的价值，我发现“最简单”的解决方案是右键单击数据库，并选择“任务”->“导出数据层应用程序”。这个选项可能只是因为服务器托管在Azure上(根据我过去使用Azure的记忆，.bacpac格式在那里非常常见)。

完成此操作后，您可以右键单击本地服务器“Databases”列表，并使用“Import data -tier Application”，使用.bacpac文件将数据获取到本地机器。

不过要记住，输出可能需要很长时间。我的出口花了大约两个小时。不过，导入部分要快得多。

AppHarbor团队一直在努力解决这个问题，并使用SQL服务器管理对象和SqlBulkCopy开发了一个临时解决方案。

查看他们的博客文章，或者直接查看代码。

他们只在AppHarbor上进行了测试，但它可能值得一试。