考虑到成本和硬件故障时的维护速度/简单性，将 SQL 数据文件保存在与 SQL Server 实例分开的 NAS 服务器上是否有意义？我们的应用程序存储来自许多设备的大量测量值（时间序列），因此数据量相对较大，无法保存在相对较小的 SAS 服务器磁盘上（每月约 200GB）。
尽管通过以太网访问文件的风险更大（即使只有数据库服务器和 NAS 在同一交换机上），但将数据文件完全分离似乎就像由于耦合度较低，在出现硬件问题时可以简化事情一样——数据库服务器可以简单得多（我可以快速迁移简单的映像，它甚至可以与所有简单应用程序的应用程序服务器捆绑在一起），并且修复 NAS 故障也应该主要涉及切换磁盘，或者在发生故障时切换到副本。
是否存在一些更好的（具有成本效益且应用速度更快的）方法来管理故障情况下的快速迁移，而无需分离数据文件，或者这个想法是否没有那么成问题？
答案1
这取决于你正在处理的软件，但是......
通常（从历史上看）您不会希望将数据库存储在 NAS 上，因为这意味着使用网络文件系统（如NFS或CIFS等）...这可能会导致各种数据完整性和性能问题。虽然仍然iSCSI不是文件系统，但它仍然意味着（如您所说）通过网络而不是 SAS 连接运行。这可能意味着性能和可靠性的巨大差异。
对于使用 NFS 的 MySQL
http://dev.mysql.com/doc/refman/5.7/en/innodb-init-startup-configuration.html
如果您的数据需要可靠性，请不要将 InnoDB 配置为使用 NFS 卷上的数据文件或日志文件。潜在的问题因操作系统和 NFS 版本而异，包括缺乏对冲突写入的保护以及对最大文件大小的限制等问题。
这只是一个例子...谷歌还可以提供更多。
我建议您详细研究特定的数据库软件，以确定将其数据存储在 NAS 上是否是推荐且合适的配置。如果您有 NAS 供应商，他们可能也会提供一些意见（据我所知，NetApp 有）。
至于你最后一个问题，我不明白。标准数据库复制还不够吗？你能重新表述一下这个问题吗？