Clarified geo-restore behavior in FAQ

Author: dimitri-furman

articles/sql-database/sql-database-business-continuity.md

@@ -82,19 +82,14 @@ simplify the deployment and usage of geo-replication and adds the additional cap
 
 | Recovery method | RTO | RPO |
 | --- | --- | --- | 
-| Geo-restore from geo-replicated backups | 12 h \* | 1 h |
+| Geo-restore from geo-replicated backups | 12 h | 1 h |
 | Auto-failover groups | 1 h | 5 s |
 | Manual database failover | 30 s | 5 s |
 
 > [!NOTE]
 > *Manual database failover* refers to failover of a single database to its geo-replicated secondary using the [unplanned mode](sql-database-active-geo-replication.md#active-geo-replication-terminology-and-capabilities).
 See the table earlier in this article for details of the auto-failover RTO and RPO.
 
-> [!IMPORTANT]
-> \* For [Hyperscale](sql-database-service-tier-hyperscale.md) databases, the time to complete a geo-restore operation is proportional to the size of data in the database. This is in contrast to the [point-in-time restore](sql-database-recovery-using-backups.md) of a Hyperscale database within the same region, where restore time does not depend on database size. For larger Hyperscale databases, geo-restore time may exceed 12-hour RTO.
-> 
-> Geo-restore time for Hyperscale databases will be shorter if the database is restored in an Azure region that is [paired](https://docs.microsoft.com/azure/best-practices-availability-paired-regions) with the region of the source database.
-
 Use auto-failover groups if your application meets any of these criteria:
 
 - Is mission critical.

articles/sql-database/sql-database-service-tier-hyperscale-faq.md

@@ -268,7 +268,7 @@ No. Backups are managed by the storage subsystem, and leverage storage snapshots
 
 ### Can I perform geo-restore with a Hyperscale database
 
-Yes.  Geo-restore is fully supported. Unlike point-in-time restore, geo-restore requires a long running size-of-data operation.
+Yes.  Geo-restore is fully supported. Unlike point-in-time restore, geo-restore requires a size-of-data operation. Data files are copied in parallel, so the duration of this operation depends primarily on the size of the largest file in the database, rather than on total database size. Geo-restore time will be significantly shorter if the database is restored in an Azure region that is [paired](https://docs.microsoft.com/azure/best-practices-availability-paired-regions) with the region of the source database.
 
 ### Can I set up geo-replication with Hyperscale database