迁移到新数据中心。数据中心将使用 SRM 复制进行虚拟机备份，并使用 NetApp Snap Manager 进行 SQL 备份。我们目前正在使用完整/tlog 本机备份。新标准与当前标准相比如何？我可以安全地停止本机备份吗？
答案1
NetApp SnapManager 优点：
- 无论数据库有多大，完整备份都只需要一秒钟甚至更短的时间。
- 完整备份不会减慢 SQL Server 的速度，因为没有数据通过 SAN 连接传输。
- 磁带备份驱动器可以直接连接到 SAN，从而实现快速的快照备份。
- 您可以将快照安装到开发或 QA 服务器上进行测试，以尽量减少生产速度下降（如果配置正确）
NetApp SnapManager的缺点：
- 快照仍在 SAN 上。如果您的 SAN 控制器坏了，您就完蛋了，而且 SAN 控制器确实会坏。
- 如果您需要频繁地从生产数据刷新 dev/QA SQL Server，并且该服务器未使用相同的 NetApp SAN，您仍然必须将数据转移到另一个 SAN。您可以这样做，但这比使用传统日志传送稍微复杂一些。
本地优点：
- 它完全在 DBA 的控制之下。他不会担心 SAN 是否没有足够的空间来存储快照。（您可以通过与 SAN 管理员沟通来缓解这种情况，我并不是说要浪漫地沟通，尽管我认为这也行得通。）
- 如果您需要将日志传送到多台服务器以用于报告目的，并且其他服务器不在 NetApp SAN 上（例如它们使用本地存储或 Fusion-IO），则日志传送更易于管理。
- 免费并与 SQL Server 集成。
本机缺点：
- 速度非常非常慢的完整备份会对生产查询造成影响。
答案2
我们使用 NetApp 的快照管理器进行 SQL 备份。这是一种快速备份，但我时不时会遇到问题。有时我会遇到繁忙的 lun 快照。一旦它得到一个繁忙的 lun，它就会开始创建越来越多的繁忙 lun 快照，并最终填满快照空间，导致所有备份失败。摆脱它们的唯一方法是销毁繁忙的 lun，然后删除这些 lun 的快照，然后所有内容都会再次开始正确备份。我还没有成功阻止创建繁忙的 lun。当然，我还没有联系供应商，我只是在问题发生时处理它。
答案3
我与他们合作已经有一段时间了，但我发现 Netapp Snap Manager for SQL 工具在关键时刻（即在恢复期间）存在不足。您无法了解或追查恢复过程，而且恢复经常失败。如果有机会，我不会再使用 Netapp Snap 进行备份。