Check Azure Files failover history before proposing zone redundancy

Source facts

After customer-managed failover of a GRS account during an outage, Microsoft says the account uses LRS in its new primary region. An LRS account produced by that failover cannot convert to ZRS or GZRS. Returning to the original primary through failback does not remove this restriction; Microsoft directs administrators to manual migration to add zone redundancy. That migration copies data into a new account and requires downtime. Microsoft Learn.

Applicability

Azure classic file shares created through Microsoft.Storage, excluding shares created through Microsoft.FileShares. Review this question when recovery history may affect a proposed redundancy change. Check the remaining account, region and protocol requirements separately before approving a destination.

DSE recommendation

Reconstruct the account’s failover history before choosing conversion or a separately approved migration. Ask the recovery owner for the original primary, each subsequent primary and the operations performed between them. Do not use a current LRS setting alone as the eligibility record. If the documented restriction applies, have the storage and application owners plan the new account, data-copy method, downtime and client transition together.

Verification

Compare the proposed route with the retained failover evidence and record why in-place conversion is or is not eligible. For an approved manual migration, define data and application-access checks before the copy begins. Verify the destination’s intended redundancy and the agreed cutover results before considering source-account retirement. Keep retirement outside this eligibility decision; this review does not authorize deleting the original data.

Official references

Microsoft Learn: Change Redundancy Configuration for Azure Files.