Redundância de dados do Arquivos do Azure

O Arquivos do Azure sempre armazena várias cópias dos seus dados para que eles fiquem protegidos contra eventos planejados e não planejados, incluindo falhas transitórias de hardware, interrupções de rede ou de energia e desastres naturais. A redundância garante que sua conta de armazenamento atenda às suas metas de disponibilidade e durabilidade mesmo diante de falhas.

Ao decidir qual opção de redundância é melhor para seu cenário, considere os benefícios comparativos entre custos menores e maior disponibilidade. Os fatores que ajudam a determinar qual opção de redundância você deve escolher incluem:

• Como os dados são replicados na região primária.
• Se seus dados são replicados para uma segunda região geograficamente distante da região principal, para proteger contra desastres regionais (redundância geográfica).

Os compartilhamentos de arquivos clássicos do Azure criados com o provedor de recursos Microsoft.Storage são gerenciados por meio de um recurso comum do Azure chamado conta de armazenamento. A conta de armazenamento representa um pool compartilhado de armazenamentos que podem ser usados para implantar compartilhamentos de arquivos. Para saber mais sobre as contas de armazenamento, confira Visão geral da conta de armazenamento.

Ao criar uma conta de armazenamento, você escolhe uma configuração de redundância para a conta de armazenamento que é compartilhada por todos os serviços de armazenamento expostos por essa conta. Portanto, todos os compartilhamentos de arquivos implementados na mesma conta de armazenamento têm a mesma configuração de redundância. Talvez você queira isolar os compartilhamentos de arquivos em contas de armazenamento separadas se eles tiverem requisitos de redundância diferentes.

Redundância na região primária

Os dados em uma conta de armazenamento do Azure são sempre replicados três vezes na região primária. O Arquivos do Azure oferece duas opções de como seus dados são replicados na região primária:

• O LRS (armazenamento com redundância local) replica os dados em suas contas de armazenamento para uma ou mais zonas de disponibilidade localizadas na região primária de sua escolha. O LRS é a opção de replicação menos dispendiosa, mas não é recomendada para aplicativos que exigem alta disponibilidade ou durabilidade.
• O ZRS (armazenamento com redundância de zona) copia seus dados de forma síncrona em três zonas de disponibilidade do Azure na região primária. Para aplicativos que exigem alta disponibilidade, recomendamos o uso do GZRS ( armazenamento com redundância de zona geográfica ), que usa ZRS na região primária e também replica geograficamente seus dados para uma região secundária.

Armazenamento com redundância local

O LRS (armazenamento com redundância local) replica os dados em suas contas de armazenamento para uma ou mais zonas de disponibilidade do Azure localizadas na região primária de sua escolha. Embora você não possa escolher sua zona de disponibilidade preferida, o Azure pode mover ou expandir contas LRS entre as zonas para melhorar o balanceamento de carga. O LRS oferece pelo menos 99,999999999% (11 9's) de durabilidade dos objetos ao longo de um determinado ano. Para mais informações, veja Quais são as zonas de disponibilidade do Azure.

O LRS é a opção de redundância de menor custo e oferece a menor durabilidade em comparação com outras opções. O LRS protege seus dados contra falhas de unidade e rack do servidor. No entanto, se ocorrer um desastre como incêndio ou inundação dentro do data center, todas as réplicas de uma conta de armazenamento usando LRS poderão ser perdidas ou irrecuperáveis. Para atenuar esse risco, recomendamos o uso de ZRS, GRS ou GZRS.

Uma solicitação de gravação para uma conta de armazenamento que está usando LRS ocorre de forma síncrona. A operação de gravação retorna com êxito somente depois que os dados são gravados em todas as três réplicas.

O diagrama a seguir mostra como os dados são replicados em um único data center com o LRS:

O LRS é uma boa opção para os seguintes cenários:

• Se seu aplicativo armazena dados que podem ser facilmente reconstruídos em caso de perda de dados.
• Se seu aplicativo estiver restrito à replicação de dados somente dentro de um país ou região devido a requisitos de governança de dados. Em alguns casos, as regiões emparelhadas nas quais os dados são replicados geograficamente podem estar em outro país ou região. Para obter mais informações, consulte pares de regiões do Azure e regiões não emparelhadas.

O LRS tem suporte em todas as regiões do Azure para compartilhamentos de arquivos HDD (padrão). Para obter uma lista de regiões que dão suporte ao LRS para compartilhamentos de arquivos SSD (premium), consulte o suporte de LRS para compartilhamentos de arquivos SSD.

Armazenamento com redundância de zona

O ZRS (armazenamento com redundância de zona) replica os dados em suas contas de armazenamento para três ou mais zonas de disponibilidade do Azure localizadas na região primária de sua escolha. Cada zona de disponibilidade é um local físico separado com energia, resfriamento e rede independentes. O ZRS oferece durabilidade para recursos de armazenamento de, pelo menos, 99,9999999999% (doze noves) ao ano. Para mais informações, veja Quais são as zonas de disponibilidade do Azure.

Com o ZRS, seus dados ainda podem ser acessados por operações de leitura e de gravação, mesmo em caso de não disponibilidade de uma zona. Se uma zona ficar indisponível, o Azure realiza atualizações de rede, como reponto de DNS. Essas atualizações podem afetar sua aplicação se você acessar os dados antes da conclusão das atualizações. Ao criar aplicativos para ZRS, siga práticas para manipulação de falha transitórias, incluindo a implementação de políticas de novas tentativas com retirada exponencial.

Uma solicitação de gravação para uma conta de armazenamento que está usando o ZRS ocorre de forma síncrona. A operação de gravação retorna com êxito somente depois que os dados são gravados em todas as réplicas nas três zonas de disponibilidade.

Uma vantagem de usar as cargas de trabalho do ZRS para o Arquivos do Azure é que, se uma zona ficar indisponível, não será necessário remontar os compartilhamentos de arquivos do Azure dos clientes conectados. Recomendamos usar ZRS na região primária em cenários que exigem alta disponibilidade. Também recomendamos o ZRS para restringir a replicação de dados a um determinado país ou região para atender aos requisitos de governança de dados.

O diagrama a seguir mostra como os dados são replicados entre as zonas de disponibilidade na região primária com o ZRS:

O ZRS fornece desempenho excelente, baixa latência e resiliência para seus dados se eles ficarem temporariamente indisponíveis. No entanto, o ZRS, por si só, pode não proteger seus dados contra um desastre regional em que várias zonas são permanentemente afetadas. Para proteção contra desastres regionais, recomendamos o uso do GZRS.

Suporte do ZRS por região

O ZRS tem suporte para compartilhamentos de arquivos SSD e HDD. Para ver quais regiões dão suporte ao ZRS para cada camada de mídia, consulte os seguintes recursos:

• Compartilhamentos de arquivos HDD: consulte a coluna de suporte da zona de disponibilidade na lista de regiões do Azure.
• Compartilhamentos de arquivos SSD: consulte o suporte do ZRS para compartilhamentos de arquivos SSD.

Redundância em uma região secundária

Para aplicativos que exigem alta durabilidade para compartilhamentos de arquivos SMB, você pode escolher o armazenamento com redundância geográfica para copiar os dados da sua conta de armazenamento para uma região secundária que esteja a centenas de quilômetros de distância da região primária. Se sua conta de armazenamento for copiada para uma região secundária, seus dados serão duráveis mesmo no caso de uma interrupção regional completa ou um desastre no qual a região principal não possa ser recuperada.

Quando você cria uma conta de armazenamento, pode selecionar a região primária para a conta. A região secundária emparelhada é determinada com base na região primária e não pode ser alterada. Para obter mais informações sobre regiões compatíveis com o Azure, consulte a lista de regiões do Azure.

O Arquivos do Azure fornece duas opções para copiar seus dados para uma região secundária. As opções de armazenamento geo-redundante estão disponíveis apenas para compartilhamentos de arquivos SMB em HDD.

• Armazenamento geo-redundante (GRS) replica seus dados usando LRS na região primária e depois os copia assíncronamente para uma região secundária. Veja Armazenamento geo-redundante.
• O armazenamento redundante por zona geográfica (GZRS) replica seus dados usando o ZRS na região primária e depois os copia assíncronamente para uma região secundária. Veja Armazenamento redundante de zona geográfica.

Armazenamento com redundância geográfica

GRS oferece durabilidade de pelo menos 99,99999999999999% (16 9's) ao longo de um determinado ano.

Uma operação de gravação primeiro é confirmada para o local primário e replicados usando o LRS. A atualização, em seguida, é replicada assincronamente para a região secundária. Quando dados são gravados para o local secundário, ela também é replicada dentro desse local usando o LRS.

O diagrama a seguir mostra como seus dados são replicados com o GRS:

Armazenamento com redundância de zona geográfica

O armazenamento com redundância de zona geográfica (GZRS) combina a alta disponibilidade fornecida pela redundância entre zonas de disponibilidade com a proteção contra interrupções regionais fornecidas pela replicação geográfica. Os dados em uma conta de armazenamento GZRS são copiados entre três zonas de disponibilidade do Azure na região primária e também são replicados para uma região geográfica secundária para proteção contra desastres regionais. Recomendamos o uso do GZRS para aplicativos que exigem o máximo de consistência, durabilidade e disponibilidade, excelente desempenho e resiliência para recuperação de desastres.

Com uma conta de armazenamento GZRS, você pode continuar lendo e gravando dados se uma zona de disponibilidade ficar indisponível ou não puder ser recuperada. Além disso, seus dados também serão duráveis no caso de uma interrupção regional completa ou um desastre no qual a região primária não possa ser recuperada. O GZRS foi projetado para oferecer durabilidade de pelo menos 99,99999999999999% (16 9's) em um determinado ano.

O diagrama a seguir mostra como seus dados são replicados com o GZRS:

Para determinar se uma região dá suporte ao GZRS, consulte a lista de regiões do Azure. Para dar suporte ao GZRS, uma região precisa oferecer suporte a zonas de disponibilidade e ter uma região emparelhada.

Frequência de sincronização e instantâneo georredundante

Para garantir que os compartilhamentos de arquivos com redundância geográfica e com redundância entre zonas geográficas estejam em um estado consistente quando ocorre um failover, a região primária cria um instantâneo do sistema a cada 15 minutos e o replica para a região secundária. Quando um failover ocorrer na região secundária, o estado de compartilhamento será baseado no instantâneo do sistema mais recente na região secundária. Devido ao atraso geográfico ou a outros problemas, o último instantâneo do sistema na região secundária pode ter mais de 15 minutos.

A propriedade Horário da Última Sincronização (LST) na conta de armazenamento indica a última vez em que os dados da região primária foram gravados com êxito na região secundária. Para o Arquivos do Azure, o Horário da Última Sincronização se baseia no instantâneo do sistema mais recente na região secundária. Você pode usar o PowerShell ou a CLI do Azure para verificar o Horário da Última Sincronização de uma conta de armazenamento.

É importante reconhecer o seguinte sobre a propriedade Horário da Última Sincronização:

• A propriedade Horário da Última Sincronização na conta de armazenamento baseia-se no serviço (Arquivos, Blobs, Tabelas, Filas) na conta de armazenamento que está mais distante.
• O Horário da Última Sincronização não será atualizado se nenhuma alteração tiver sido feita na conta de armazenamento.
• O cálculo do Horário da Última Sincronização pode expirar se o número de compartilhamentos de arquivos exceder 100 por conta de armazenamento. Recomenda-se menos de 100 compartilhamentos de arquivos por conta de armazenamento.

Considerações de failover para armazenamento georredundante

Com o GRS ou o GZRS, os compartilhamentos de arquivos não poderão ser acessados na região secundária, a menos que ocorra um failover. Se a região primária ficar indisponível, você poderá optar por fazer failover para a região secundária. O processo de failover atualiza a entrada do DNS fornecida pelos Arquivos do Azure para que o ponto de extremidade secundário se torne o novo ponto de extremidade primário para sua conta de armazenamento. Durante o processo de failover, seus dados são inacessíveis. Após a conclusão do failover, você pode fazer a leitura e gravar dados na nova região primária. Após a conclusão do failover, a região secundária se tornará a região primária e você poderá ler e gravar os dados novamente. Para obter mais informações, confira Recuperação de desastre e failover dos Arquivos do Azure.

Os itens a seguir podem afetar sua capacidade de fazer failover para a região secundária:

• O failover da conta de armazenamento será bloqueado se um instantâneo do sistema não existir na região secundária.
• O failover da conta de armazenamento será bloqueado se ela contiver mais de 100 mil compartilhamentos de arquivos. Para fazer failover da conta de armazenamento, abra uma solicitação de suporte.
• Os identificadores de arquivos e as concessões não são retidas no failover e os clientes devem desmontar e remontar os compartilhamentos de arquivos.
• A cota de compartilhamento de arquivos pode ser alterada depois do failover. A cota de compartilhamento de arquivos na região secundária será baseada na cota configurada quando o instantâneo do sistema foi tirado na região primária.
• As operações de cópia em andamento serão anuladas quando ocorrer um failover. Quando o failover da região secundária for concluído, repita a operação de cópia.

Para fazer failover de uma conta de armazenamento, confira iniciar failover de conta.

Redundância geográfica para compartilhamentos de arquivos SSD

Como mencionado anteriormente, as opções de redundância geográfica (GRS e GZRS) não têm suporte para compartilhamentos de arquivos SSD. No entanto, você pode obter redundância geográfica de outras maneiras.

Para cenários da Sincronização de Arquivos do Azure, você pode sincronizar entre o seu compartilhamento de arquivos do Azure (seu ponto de extremidade de nuvem), um servidor de arquivos do Windows local e um compartilhamento de arquivos montado em execução em uma máquina virtual em outra região do Azure (seu ponto de extremidade de servidor para fins de recuperação de desastre). Você deve desabilitar a camada de nuvem para garantir que todos os dados estejam presentes localmente e provisionar uma quantidade suficiente de armazenamento na VM do Azure para manter todo o conjunto de dados. Para garantir que as alterações sejam replicadas rapidamente na região secundária, os arquivos só devem ser acessados e modificados no ponto de extremidade do servidor e não no Azure.

Você também pode criar seu próprio script para copiar dados para uma conta de armazenamento em uma região secundária usando ferramentas como a AzCopy (use a versão 10.4 ou posterior para preservar as ACLs e carimbos de data/hora).

Resumo das opções de redundância

As tabelas nas seções a seguir resumem as opções de redundância disponíveis para o Arquivos do Azure.

Parâmetros de durabilidade e disponibilidade do Arquivos do Azure

A tabela a seguir descreve os principais parâmetros para cada opção de redundância:

Para obter mais informações, consulte o SLA para contas de armazenamento.

Durabilidade e disponibilidade do Arquivos do Azure por cenário de interrupção

A tabela a seguir indica se seus dados são duráveis e estão disponíveis em um determinado cenário, dependendo do tipo de redundância em vigor para sua conta de armazenamento. O Arquivos do Azure não tem suporte para acesso de leitura à região secundária se a região primária ficar indisponível, a menos que ocorra um failover.

¹ O failover da conta é necessário para restaurar a disponibilidade de gravação se a região primária ficar indisponível.

Para obter informações sobre os preços de cada opção de redundância, confira Preços do Arquivos do Azure.

Suportabilidade de região com base em diferentes modelos de cobrança

Você pode verificar a capacidade de suporte da região para vários modelos de cobrança usando os comandos a seguir.

# Login
Connect-AzAccount
# (Optional but recommended if you have multiple subs)
# Set-AzContext -Subscription $subscriptionID

$subscriptionID = "your-subscription-id-number"

# Get token (output is now SecureString by default, see https://learn.microsoft.com/powershell/module/az.accounts/get-azaccesstoken)
$secureToken = (Get-AzAccessToken).Token  # SecureString now

# Convert SecureString -> plaintext (Az 14 migration pattern)
$ssPtr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($secureToken)
try {
    $plainToken = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($ssPtr)
}
finally {
    [System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($ssPtr)
}

# Call List SKUs
$uri = "https://management.azure.com/subscriptions/$subscriptionID/providers/Microsoft.Storage/skus?api-version=2025-08-01"
$headers = @{ Authorization = "Bearer $plainToken" }

$result = Invoke-RestMethod -Method Get -Uri $uri -Headers $headers

$filteredResult = $result | `
    Select-Object -ExpandProperty value | `
    Where-Object {
        $_.resourceType -eq "storageAccounts" -and
        # Filter based on your needs. FileStorage account kind includes Pv2 and Pv1 file share, where StorageV2 kind includes PayGO file shares.
        $_.kind -in @("FileStorage", "StorageV2") -and
        # Filter based on your needs. "Standard_" for PayGO file share, "StandardV2_" for Pv2 file share, "Premium_" for Pv1 file shares.
        # $_.name.StartsWith("StandardV2_") -and
        # Change region based on your need to see if the region is currently supported (all lowercase, no space in between).
        # $_.locations -eq "italynorth" -and
        $_.name -notin @("Standard_RAGRS", "Standard_RAGZRS")
    }

if ($filteredResult.Count -eq 0) {
    Write-Output "No results found."
} else {
    $filteredResult | `
        Select-Object `
            -Property `
                @{
                    Name = "sku";
                    Expression = { $_.name }
                }, `
                kind, `
                @{
                    Name = "mediaTier";
                    Expression = {
                        if ($_.tier -eq "Premium") {
                            "SSD"
                        } elseif ($_.tier -eq "Standard") {
                            "HDD"
                        } else {
                            "Unknown"
                        }
                    }
                }, `
                @{
                    Name = "billingModel";
                    Expression = {
                        if ($_.name.StartsWith("StandardV2_") -or
                            $_.name.StartsWith("PremiumV2_")
                        ) {
                            "ProvisionedV2"
                        } elseif ($_.name.StartsWith("Premium_")) {
                            "ProvisionedV1"
                        } else {
                            "PayAsYouGo"
                        }
                    }
                }, `
                @{
                    Name = "location";
                    Expression = { $_.locations | Select-Object -First 1 }
                } | ft sku, kind, mediaTier, billingModel, location
}

# Login to Azure account
az login

# Track down the subscription ID in GUID format and set subscription ID
subscriptionID="your-subscription-id-number"

# Get Token
token=$(az account get-access-token --query accessToken --output tsv)

# Invoke SRP list SKU API, and get the returned SKU list
result=$(az rest --method get --uri "https://management.azure.com/subscriptions/$subscriptionID/providers/Microsoft.Storage/skus?api-version=2025-08-01" --headers "Authorization=Bearer $token")

# Filter the SKU list to get the required information, customization required here to get the best result.
filteredResult=$(echo $result | jq '.value[] | select(.resourceType == "storageAccounts" and (.kind == "FileStorage" or .kind == "StorageV2") and (.name | test("^(?!Standard_RAGRS|Standard_RAGZRS)")))' )

if [ -z "$filteredResult" ]; then
    echo "No results found."
else
    # Print the table header
    printf "%-30s %-15s %-10s %-20s %-15s\n" "SKU" "Kind" "MediaTier" "BillingModel" "Location"
    # Print the filtered results
    echo $filteredResult | jq -r '. | "\(.name)\t\(.kind)\t\(.tier | if . == "Premium" then "SSD" elif . == "Standard" then "HDD" else "Unknown" end)\t\(.name | if test("^StandardV2_|^PremiumV2_") then "ProvisionedV2" elif test("^Premium_") then "ProvisionedV1" else "PayAsYouGo" end)\t\(.locations)"' | while IFS=$'\t' read -r sku kind mediaTier billingModel location; do
        printf "%-30s %-15s %-10s %-20s %-15s\n" "$sku" "$kind" "$mediaTier" "$billingModel" "$location"
    done
fi

Confira também

• Alterar a configuração de redundância para Arquivos do Azure
• Uso da redundância geográfica para criar aplicativos altamente disponíveis