我来帮你理清Azure SQL DB Geo-redundant Backup（GRS）的这些疑问，一个个拆解清楚：

这是正常现象——Geo-redundant备份（GRS）并不是一个可直接查看的数据库实例，它本质是把你的数据库备份文件同步存储到配对区域的Azure存储账户中，而非创建一个运行中的副本。

你看到的Replicas列表为空，是因为这个列表只显示**Active Geo-Replication（主动异地复制）**的数据库副本，而GRS属于备份存储层面的冗余，不属于这个范畴。所以你不会在门户里看到配对区域有对应的数据库资源。

不需要提前配置。因为GRS的备份在故障转移/恢复完成前，并不是一个可连接的数据库服务。只有当以下两种情况发生后，才会产生可连接的数据库：

• 微软触发自动故障转移：仅当主区域发生大规模灾难时才会触发，微软会自动将你的数据库从GRS备份恢复到配对区域的新服务器上；
• 你手动发起Geo-Restore（异地恢复）：主动从GRS备份中恢复出一个新的数据库到目标区域。

只有这两种情况完成后，你才能拿到新数据库的连接字符串，再配置到应用中。

• 自动故障转移场景：故障转移完成后，你可以在Azure门户中找到恢复后的数据库（通常在配对区域的新服务器下），进入数据库的「连接字符串」选项卡即可获取；
• 手动Geo-Restore场景：当你在门户/ PowerShell/ CLI中完成恢复操作，创建出目标数据库后，直接进入该新数据库的「连接字符串」页面就能拿到对应的连接信息。

这个选项属于灾难恢复层级的配置，核心价值是保障区域级故障下的数据可恢复性：

• 当主区域完全不可用时，你可以依赖配对区域的GRS备份快速恢复数据库（相对于本地冗余备份，GRS提供了跨区域的数据安全保障）；
• 它和Active Geo-Replication（AGRS）是不同的方案：AGRS是实时同步的数据库副本，有可见实例、可手动快速故障转移，但成本更高；而GRS是备份层面的冗余，成本更低，恢复时间通常为数小时，适合对恢复时间目标（RTO）要求不那么严苛的场景。

另外你提到在创建新数据库时选「使用现有数据-备份」找不到geo-replicated DB，这是因为GRS备份不会以数据库实例的形式展示，你需要在恢复流程中选择「异地恢复」，指定主数据库的订阅和服务器，才能找到对应的GRS备份来恢复。

内容的提问来源于stack exchange，提问作者jrpharis