SQL中的备份非常慢

Question

在将我们的应用程序移植到Azure之前，我目前正在研究SQL数据库备份策略。目前，我们正在使用Server维护任务，每15分钟运行一次本地数据库的备份，保留1小时(从而保留4个本地副本)。我们还运行了24小时备份，并将其推入亚马逊S3。

在Azure中，到目前为止，我已经尝试使用以下to对主数据库进行备份(到另一个sql服务器实例)：

CREATE DATABASE targetserver.backupName AS COPY OF sourceserver.sourceName

源数据库的大小约为3GB，每月扩展5%至10%。我遇到的问题是复制过程非常缓慢！我30分钟前就开始复制了，现在还在运行！这意味着在Azure中采用15分钟的备份计划似乎是站不住脚的。

因此，我想知道我是否可以与其他用户进行一些限定：

1. 3GB备份需要超过30分钟(并计数)才能复制到另一个服务器实例，这是正常的吗？
2. 是否应该将备份保存在与源服务器相同的服务器上？我非常紧张，因为在Azure门户上点击几下就可以消除许多关键数据！我知道这是一个“黑天鹅”事件，但我只是觉得在一个服务器实例中运行所有东西并不容易。
3. 是否有更快的方法备份SQL数据库？我已经看过红门了，但是做每日次增量备份似乎很昂贵。

任何有关这方面的想法都将不胜感激！

我应该补充说，我很高兴重新考虑我的备份策略，完全是为了更友好的Azure。关键是减少管理员错误，例如，由于一条笨拙的语句(备份间隔越短)和一个24小时的备份被推入不同的存储方法(例如blob容器)而丢弃大量重要数据。

更新？。

在等待1小时后，我取消了初始备份请求，并重新启动。第二次备份在5分钟内完成。我现在回到Red，看看他们托管的备份解决方案。

Answer 1

运行复制数据库所需的时间不仅取决于数据的大小，还取决于数据上运行的事务数，因此在您的情况下，此选项可能不成立。现在您已经拥有了备份DB，您可以通过备份备份来测试这一点，并查看需要多长时间。

另一个选项是导出.bacpac文件并将其存储在blob存储中。这里有一些库，但我手头没有参考资料。这也将是一个更便宜的选择。我很肯定这就是红门在他们服务的掩护下所做的。