Remove unneeded large file share for Geo doc.

Author: wmgries

.openpublishing.redirection.json

@@ -6733,6 +6733,11 @@
       "source_path": "articles/notification-hubs/xamarin-notification-hubs-push-notifications-android-gcm.md",
       "redirect_url": "/dotnet/maui/data-cloud/push-notifications",
       "redirect_document_id": false
+    },
+    {
+      "source_path": "/articles/storage/files/geo-redundant-storage-for-large-file-shares.md",
+      "redirect_url": "/azure/storage/files/files-redundancy",
+      "redirect_document_id": false
     }
   ]
 }

articles/storage/files/TOC.yml

@@ -235,8 +235,6 @@
     href: files-redundancy.md
   - name: Disaster recovery and failover
     href: files-disaster-recovery.md
-  - name: Geo-redundancy for large file shares
-    href: geo-redundant-storage-for-large-file-shares.md
   - name: Change the redundancy configuration
     href: files-change-redundancy-configuration.md
   - name: Initiate storage account failover

articles/storage/files/files-redundancy.md

@@ -127,13 +127,34 @@ Only standard general-purpose v2 storage accounts support GZRS.
 
 To determine if a region supports GZRS, see the [Azure regions list](/azure/reliability/regions-list#azure-regions-list-1). To support GZRS, a region must support availability zones and have a paired region.
 
-### Disaster recovery and failover
+### Snapshot and sync frequency
 
+To ensure Geo and GeoZone redundant file shares are in a consistent state when a failover occurs, a system snapshot is created in the primary region every 15 minutes and is replicated to the secondary region. When a failover occurs to the secondary region, the share state is based on the latest system snapshot in the secondary region. Due to geo-lag or other issues, the latest system snapshot in the secondary region may be older than 15 minutes.
+
+The Last Sync Time (LST) property on the storage account indicates the last time that data from the primary region was written successfully to the secondary region. For Azure Files, the Last Sync Time is based on the latest system snapshot in the secondary region. You can use PowerShell or Azure CLI to [check the Last Sync Time](../common/last-sync-time-get.md#get-the-last-sync-time-property) for a storage account.
+
+It's important to understand the following about the Last Sync Time property:
+
+- The Last Sync Time property on the storage account is based on the service (Files, Blobs, Tables, Queues) in the storage account that's the furthest behind.
+- The Last Sync Time isn't updated if no changes have been made on the storage account.
+- The Last Sync Time calculation can time out if the number of file shares exceeds 100 per storage account. Less than 100 file shares per storage account is recommended.
+
+### Failover considerations
 With GRS or GZRS, the file shares won't be accessible in the secondary region unless a failover occurs. If the primary region becomes unavailable, you can choose to fail over to the secondary region. The failover process updates the DNS entry provided by Azure Files so that the secondary endpoint becomes the new primary endpoint for your storage account. During the failover process, your data is inaccessible. After the failover is complete, you can read and write data to the new primary region. After the failover has completed, the secondary region becomes the primary region, and you can again read and write data. For more information, see [Azure Files disaster recovery and failover](files-disaster-recovery.md).
 
 > [!IMPORTANT]
 > Azure Files doesn't support read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS). If a storage account is configured to use RA-GRS or RA-GZRS, the file shares will be configured and billed as GRS or GZRS.
 
+The following items might impact your ability to fail over to the secondary region:
+
+- Storage account failover is blocked if a system snapshot doesn't exist in the secondary region.
+- Storage account failover is blocked if the storage account contains more than 100,000 file shares. To failover the storage account, open a support request.
+- File handles and leases aren't retained on failover, and clients must unmount and remount the file shares.
+- File share quota might change after failover. The file share quota in the secondary region will be based on the quota that was configured when the system snapshot was taken in the primary region.
+- Copy operations in progress are aborted when a failover occurs. When the failover to the secondary region completes, retry the copy operation.
+
+To failover a storage account, see [initiate an account failover](../common/storage-initiate-account-failover.md).
+
 ### Geo-redundancy for SSD file shares
 
 As previously mentioned, geo-redundancy options (GRS and GZRS) aren't supported for SSD file shares. However, you can achieve geo-redundancy in other ways.