Arquivos Do Azure

Contents
Documentação dos Arquivos do Azure

Visão geral
O que são os Arquivos do Azure?
Inícios rápidos
Criar/usar compartilhamentos de arquivos – Windows
Criar compartilhamentos de arquivos - Portal
Criar compartilhamentos de arquivos - PowerShell
Criar compartilhamentos de arquivos - CLI
Criar compartilhamentos de arquivos - Gerenciador de Armazenamento
Tutoriais
Estender servidores de arquivos do Windows com a Sincronização de Arquivos do
Azure
Conceitos
Planejando uma implantação de Arquivos do Azure
Planejando uma implantação da Sincronização de Arquivos do Azure
Considerações de rede para acesso direto
Sobre a camada de nuvem
Impedir exclusões acidentais de dados
Sobre contas de armazenamento
Instantâneos de compartilhamento de arquivos do Azure
Redundância de dados
Recuperação de desastre e failover
Escalabilidade e metas de desempenho
Autenticação e autorização baseadas em identidade
Criptografia do Armazenamento do Azure em repouso
Chaves gerenciadas pelo cliente com o Azure Key Vault
Configurar preferência de roteamento de rede
Ofertas de conformidade
Desenvolvimento
Gerenciar simultaneidade
Autenticação de chave compartilhada
SAS (Assinaturas de Acesso Compartilhado)
Monitorar e solucionar problemas
Monitorar, diagnosticar e solucionar problemas
Métricas no Azure Monitor
Migrar para novas métricas
Métricas da análise de armazenamento (clássico)
Perguntas frequentes
Guias de instruções
Criar
Criar um compartilhamento de arquivos
Habilitar compartilhamentos de arquivos grandes
Criar um compartilhamento de arquivo premium
Implantar
Implantar os Arquivos do Azure
Implantar a Sincronização de Arquivos do Azure
Definir configurações de proxy e firewall da Sincronização de Arquivos
FCI do SQL Server com compartilhamentos de arquivos Premium
Montar
Usar Arquivos do Azure com o Windows
Usar o Arquivos do Azure com o Linux
Usar Arquivos do Azure com o macOS
Rede
Configurar pontos de extremidade de rede de Arquivos do Azure
Como configurar o encaminhamento de DNS para Arquivos do Azure
Configurar uma VPN site a site
Configurar a VPN ponto a site no Windows
Configurar a VPN ponto a site no Linux
Gerenciar
Registrar um servidor com a Sincronização de Arquivos do Azure
Adicionar um ponto de extremidade do Servidor de Sincronização de Arquivos do
Azure
Habilitar exclusão reversível
Gerenciar o armazenamento nas nuvens independentes do Azure
Gerenciar redundância de dados
Alterar a forma como os dados são replicados
Criar aplicativos altamente disponíveis
Gerenciar recuperação de desastre
Verificar a propriedade Horário da Última Sincronização
Iniciar failover da conta
Monitoramento
Monitorar a Sincronização de Arquivos do Azure
Migrar
Migrar para compartilhamentos de Arquivos do Azure
Direcionar a uma implantação híbrida
Migrar dados em massa para Sincronização de Arquivos do Azure com o Azure
Data Box
Migrar do Linux para um servidor de arquivos híbrido com a Sincronização de
Arquivos do Azure
Migrar de um NAS local para um servidor de arquivos híbrido com a
Sincronização de Arquivos do Azure
Do StorSimple
Guia de migração do StorSimple 8100 e 8600
Guia de migração do StorSimple 1200
Desenvolver
Configurar cadeias de conexão
.NET
Java
C++
Python
Seguro
Gerenciar chaves de criptografia para a conta de armazenamento
Verificar o modelo de chave de criptografia para a conta
Configurar chaves de criptografia gerenciadas pelo cliente
Portal
PowerShell
CLI do Azure
Configurar firewalls e redes virtuais
Requer transferência segura
Habilitar autenticação e autorização do AD
Habilitar autenticação e autorização do Microsoft Azure AD DS
Habilitar TLS seguro para cliente de Armazenamento do Microsoft Azure
Transferência
Introdução – AzCopy
Usar com Arquivos
Configurar, otimizar, solucionar problemas – AzCopy
Solucionar problemas
Solucionar Problemas dos Arquivos do Azure no Windows
Solucionar Problemas dos Arquivos do Azure no Linux
Solucionar problemas de desempenho dos Arquivos do Azure
Solucionar problemas da Sincronização de Arquivos do Azure
Solucionar problemas de exclusão de Arquivos do Azure
Referência
Azure PowerShell (Storage)
Azure PowerShell (StorageSync)
CLI do Azure
.NET
Arquivos (versão 11.x)
Movimentação de dados
Provedor de recursos de armazenamento
Java
Arquivos (versão 8.x)
JavaScript (versão 10.x)
Python (versão 2.x)
REST
Blobs, Filas, Tabelas e Arquivos
Importar/Exportar
C++
Ruby
PHP
iOS
Android
Modelo do Resource Manager
Exemplos
Recursos
Atualizações do Azure
Notas de versão da Sincronização de Arquivos do Azure
Fórum do Armazenamento do Azure
Armazenamento do Azure no Stack Overflow
Preços do Armazenamento do Azure
Calculadora de preços do Azure
vídeos
Pacotes NuGet (.NET)
Microsoft.Azure.Storage.Common (versão 11.x)
Azure.Storage.Common (versão 12.x – versão prévia)
Microsoft.Azure.Storage.File (versão 11.x)
Azure.Storage.File (versão 12.x – versão prévia)
Azure Configuration Manager
Biblioteca de Movimentação de Dados do Armazenamento do Microsoft Azure
Biblioteca do provedor de recursos de armazenamento
Código-fonte
.NET
Biblioteca de clientes do Armazenamento do Azure
Versão 12.x (versão prévia)
Versão 11.x e anteriores
Biblioteca da Movimentação de Dados
Biblioteca do provedor de recursos de armazenamento
Java
Biblioteca de clientes do Armazenamento do Azure versão 12.x (versão prévia)
Biblioteca de clientes do Armazenamento do Azure versão 8.x e anteriores
Node.js
Biblioteca de clientes do Armazenamento do Azure versão 10.x
Python
Biblioteca de clientes do Armazenamento do Azure versão 2.1
O que são os Arquivos do Azure?
15/04/2020 • 8 minutes to read • Edit Online
Os Arquivos do Azure oferecem compartilhamentos de arquivos totalmente gerenciados na nuvem,

acessíveis por meio do protocolo SMB (Server Message Block) padrão no setor. Os compartilhamentos de
arquivos do Azure podem ser montados de maneira simultânea por implantações locais ou na nuvem do
Windows, do Linux e do MacOS. Além disso, os compartilhamentos de arquivos do Azure podem ser
armazenados em cache nos Windows Servers com a Sincronização de Arquivos do Azure para acesso rápido
perto de onde os dados estão sendo usados.
vídeos
IN T RO DUÇ Ã O À SIN C RO N IZ A Ç Ã O DE A RQ UIVO S DO A RQ UIVO S DO A Z URE C O M SIN C RO N IZ A Ç Ã O ( IGN IT E
A Z URE 2019)
Veja alguns vídeos sobre os casos de uso comuns dos Arquivos do Azure:
Substitua o servidor de arquivos por um Compartilhamento de Arquivo do Azure sem servidor
Introdução a contêineres de perfil FSLogix nos Arquivos do Azure na Área de Trabalho Virtual do
Windows usando a autenticação do AD
Por que o serviço Arquivos do Azure é útil

Os compartilhamentos de arquivos do Azure podem ser usados para:
Substituir ou complementar os ser vidores de arquivos locais :
Os Arquivos do Azure podem ser usados para substituir completamente ou complementar os
servidores de arquivos tradicionais no local ou dispositivos NAS. Sistemas operacionais conhecidos,
como o Linux, Windows e macOS podem montar diretamente compartilhamentos de arquivos do
Azure em qualquer lugar do mundo. Os compartilhamentos de arquivos do Azure também podem ser
replicados com a Sincronização de Arquivos do Azure para Windows Servers, no local ou na nuvem,
para armazenamento dos dados em cache distribuído e com desempenho onde estão sendo usados.
Com o recente lançamento da Autenticação do AD para os Arquivos do Azure, os compartilhamentos
de arquivo do Azure podem continuar trabalhando com o AD hospedado localmente para o controle
de acesso.
Aplicativos de "Deslocamento e comparação" :
O serviço Arquivos do Azure facilita "comparar e deslocar" aplicativos para a nuvem que espera que o
compartilhamento de arquivos armazene o aplicativo de arquivo ou os dados do usuário. O serviço
Arquivos do Azure permite o cenário “clássico” de comparar e deslocar, em que o aplicativo e os dados
são movidos para o Azure, e o cenário “híbrido”, em que os dados do aplicativo são movidos para o
serviço Arquivos do Azure e o aplicativo continua a ser executado no local.
Simplificar o desenvolvimento na nuvem :
Os Arquivos do Azure também podem ser usados de várias maneiras para simplificar novos projetos
de desenvolvimento na nuvem. Por exemplo:
Configurações de aplicativo compar tilhado :
Um padrão comum para aplicativos distribuídos é fazer com que os arquivos de configuração
fiquem em um local centralizado, onde possam ser acessados de diversas instâncias de
aplicativos. As instâncias do aplicativo podem carregar sua configuração por meio da API REST
de Arquivo e os usuários podem acessá-las conforme necessário com a montagem local do
compartilhamento SMB.
Compar tilhamento de diagnóstico :
Um compartilhamento de arquivos do Azure é um local conveniente para aplicativos de nuvem
gravarem seus logs, métricas e despejos de memória. Os logs podem ser gravados pelas
instâncias do aplicativo por meio da API REST de Arquivo e os desenvolvedores podem acessá-
los ao montar o compartilhamento de arquivos em seu computador local. Isso permite maior
flexibilidade, já que os desenvolvedores podem adotar o desenvolvimento em nuvem sem a
necessidade de abandonar as ferramentas existentes que conhecemos e amamos.
Desenv/Teste/Depuração :
Quando desenvolvedores ou administradores estão trabalhando em máquinas virtuais na
nuvem, eles frequentemente precisam de um conjunto de ferramentas ou utilitários. Copiar tais
ferramentas e utilitários em cada VM pode ser uma atividade demorada. Ao montar um
compartilhamento de arquivos do Azure localmente nas máquinas virtuais, o desenvolvedor e
o administrador podem acessar rapidamente suas ferramentas e utilitários sem precisar copiá-
las.
Principais benefícios
Acesso compar tilhado . Os compartilhamentos de arquivos do Azure suportam o protocolo SMB
padrão, ou seja, você pode substituir perfeitamente seus compartilhamentos de arquivos locais pelos
compartilhamentos de arquivos do Azure sem se preocupar com a compatibilidade dos aplicativos. Poder
compartilhar um sistema de arquivos em vários computadores, aplicativos e instâncias é uma vantagem
significativa com os Arquivos do Azure para aplicativos que precisam de compartilhamento.
Totalmente gerenciado . Os compartilhamentos de arquivos do Azure podem ser criados sem a
necessidade de gerenciar um sistema operacional ou hardware. Isso significa que você não precisa lidar
com a correção do sistema operacional do servidor com atualizações críticas de segurança ou com a
substituição de discos rígidos com defeito.
Scripts e ferramentas . Os cmdlets do PowerShell e a CLI do Azure podem ser usados para criar, montar
e gerenciar compartilhamentos dos Arquivos do Azure como parte da administração dos aplicativos do
Azure. Você pode criar e gerenciar compartilhamentos de Arquivos do Azure usando o Portal do Azure e
o Gerenciador de Armazenamento do Azure.
Resiliência . O serviço Arquivos do Azure foi criado do zero para estar sempre disponível. Substituir os
compartilhamentos de arquivos locais pelos Arquivos do Azure significa que não é preciso estar ativado
para lidar com interrupções locais de energia ou problemas de rede.
Programação familiar . Os aplicativos executados no Azure podem acessar dados no compartilhamento
por meio de APIs de E/S do sistema de arquivos. Os desenvolvedores podem, portanto, utilizar seus
códigos e habilidades existentes para migrar aplicativos existentes. Além das APIs de E/S do sistema, você
pode usar as Bibliotecas do Cliente de Armazenamento do Azure ou a API de REST do Armazenamento do
Azure.
Próximas etapas
Criar um compartilhamento de arquivos do Azure
Conexão e montagem no Windows
Conexão e montagem no Linux
Conexão e montagem no MacOS
Início Rápido: Criar e gerenciar compartilhamento do
Armazenamento de Arquivos do Azure com
máquinas de virtuais do Windows
O artigo demonstra as etapas básicas para criar e usar um compartilhamento do Arquivos do Azure. Neste início
rápido, a ênfase é como configurar rapidamente um compartilhamento do Arquivos do Azure para que você possa
experimentar o funcionamento do serviço. Se precisar de instruções mais detalhadas para criar e usar
compartilhamentos de arquivo do Azure em seu próprio ambiente, consulte Usar um compartilhamento de
arquivos do Azure com o Windows.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
Entrar no Azure
Entre no portal do Azure.
Prepare o seu ambiente

Neste início rápido, você configura os seguintes itens:
Uma conta de armazenamento e um compartilhamento de arquivo do Azure
Uma VM do Windows Server 2016 Datacenter
Criar uma conta de armazenamento
Antes de poder trabalhar com um compartilhamento de arquivo do Azure, você precisa criar uma conta de
armazenamento do Azure. Uma conta de armazenamento v2 de uso geral fornece acesso a todos os serviços do
Armazenamento do Azure: blobs, arquivos, filas e tabelas. O guia de início rápido cria uma conta de
armazenamento de uso geral v2, mas as etapas para criar qualquer tipo de conta de armazenamento são
semelhantes. Uma conta de armazenamento pode conter uma quantidade ilimitada de compartilhamentos. Um
compartilhamento pode conter uma quantidade ilimitada de arquivos, até os limites de capacidade da conta de
armazenamento.
Para criar uma conta de armazenamento de uso geral v2 no portal do Azure, siga estas etapas:
1. No menu do portal do Azure, selecione Todos os ser viços . Na lista de recursos, digite Contas de
armazenamento . Quando você começa a digitar, a lista é filtrada com base em sua entrada. Selecione
Contas de Armazenamento .
2. Na janela Contas de Armazenamento que aparece, escolha Adicionar .
3. Selecione a assinatura na qual você deseja criar a conta de armazenamento.
4. No campo Grupo de recursos , selecione Criar novo . Insira um nome para seu novo grupo de recursos,
conforme mostrado na imagem a seguir.
5. Em seguida, insira um nome para sua conta de armazenamento. O nome escolhido deve ser exclusivo no
Azure. O nome também deve ter entre 3 e 24 caracteres e pode incluir apenas números e letras minúsculas.
6. Selecione um local para sua conta de armazenamento ou use o local padrão.
7. Deixe esses campos definidos como seus valores padrão:
CAMPO VA LO R
Modelo de implantação Gerenciador de Recursos
Desempenho Standard
Tipo de conta StorageV2 (uso geral v2)
Replicação Armazenamento com redundância geográfica com acesso

de leitura (RA-GRS)
Camada de acesso Dinâmica
8. Se você planeja usar o Azure Data Lake Storage, escolha a guia Avançado e, em seguida, defina
Namespace hierárquico como Habilitado .
9. Selecione Revisar + Criar para examinar as configurações da conta de armazenamento e criar a conta.
10. Selecione Criar .
Para obter mais informações sobre tipos de contas de armazenamento e outras configurações da conta de
armazenamento, confira Visão geral da conta de armazenamento do Azure. Para saber mais sobre grupos de
recursos, confira Visão geral do Azure Resource Manager.
Em seguida, crie um compartilhamento de arquivos.
1. Quando a implantação da conta de armazenamento do Azure for concluída, selecione Ir para o recurso .
2. Selecione Arquivos no painel da conta de armazenamento.
3. Selecione Compar tilhamento de Arquivo .
4. Nomeie o novo compartilhamento de arquivo qsfileshare > digite "1" para a Cota > selecione Criar . A cota
pode ter um máximo de 5 TiB, mas você só precisa de 1 GiB para este início rápido.
5. Crie um novo arquivo txt chamado qsTestFile no computador local.
6. Selecione o novo compartilhamento de arquivo e, no local do compartilhamento de arquivo, selecione
Carregar .
7. Navegue até o local onde você criou o arquivo .txt > selecione qsTestFile.txt > selecione Carregar .
Até agora, você criou uma conta de armazenamento do Azure e um compartilhamento de arquivo contendo um
arquivo no Azure. Em seguida, você criará a VM do Azure com o Windows Server 2016 Datacenter para
representar o servidor local neste início rápido.
Implantar uma máquina virtual
1. Em seguida, expanda o menu no lado esquerdo do portal e escolha Criar um recurso no canto superior
esquerdo do portal do Azure.
2. Na caixa de pesquisa acima da lista de recursos do Azure Marketplace , procure e selecione Windows
Ser ver 2016 Datacenter , em seguida, escolha Criar .
3. Na guia Básico , em Detalhes do projeto , selecione o grupo de recursos que você criou para este início
rápido.
4. Em Detalhes da instância , nomeie a VM qsVM.
5. Deixe as configurações padrão para Região , Opções de disponibilidade , Imagem e Tamanho .
6. Em Conta de administrador , adicione VMadmin como Nome de usuário e insira uma Senha para a VM.
7. Em Regras de por ta de entrada , escolha Permitir por tas selecionadas e, em seguida, selecione RDP
(3389) e HTTP na lista suspensa.
8. Selecione Examinar + criar .
9. Selecione Criar . A criação de uma nova VM levará alguns minutos para ser concluída.
10. Após a conclusão da implantação da VM, selecione Ir para o recurso .
Nesta altura, você já criou uma nova máquina virtual e anexou um disco de dados. Agora, você precisa se conectar
à VM.
Conectar-se à sua VM
1. Selecione Conectar na página de propriedades da máquina virtual.
2. Na página Conectar-se à máquina vir tual , mantenha as opções padrão para se conectar por endereço
IP no número da por ta 3389 e selecione Baixar arquivo RDP .
3. Abra o arquivo RDP baixado e selecione Conectar quando solicitado.
4. Na janela Segurança do Windows , selecione Mais opções e Usar uma conta diferente . Digite o nome
de usuário como localhost\nome de usuário,em que <nome de usuário> é o nome do usuário
administrador da VM que você criou para a máquina virtual. Insira a senha que você criou para a máquina
virtual e selecione OK .
5. Você pode receber um aviso do certificado durante o processo de logon. Selecione Sim ou Continuar para
criar a conexão.
Mapeie o compartilhamento de arquivo do Azure para uma unidade do

Windows
1. No portal do Azure, navegue até o compartilhamento de arquivo qsfileshare e selecione Conectar .
2. Copie o conteúdo da segunda caixa e cole-o no Bloco de notas .
3. Na VM, abra Explorador de Arquivos e selecione Este PC na janela. Esta seleção alterará os menus
disponíveis na faixa de opções. No menu Computador , selecione Mapear unidade de rede .
4. Selecione a letra da unidade e digite o caminho UNC. Se você seguiu as sugestões de nomenclatura deste
início rápido, copie \qsstorageacct.file.core.windows.net\qsfileshare do Bloco de notas .
Verifique se as duas caixas de seleção estão marcadas.
5. Selecione Concluir .
6. Na caixa de diálogo Segurança do Windows :
No Bloco de notas, copie o nome da conta de armazenamento iniciada por AZURE\ e cole-o na caixa
de diálogo Segurança do Windows como o nome de usuário. Se você seguiu as sugestões de
nomenclatura neste início rápido, copie AZURE\qsstorageacct.
No Bloco de notas, copie a chave da conta de armazenamento e cole-a na caixa de diálogo
Segurança do Windows como a senha.
Criar um instantâneo de compartilhamento

Agora que mapeou a unidade, você pode criar um instantâneo.
1. No portal, navegue até o compartilhamento de arquivo e selecione Criar instantâneo .
2. Na VM, abra qstestfile.txt e digite "Este arquivo foi modificado" > salve e feche o arquivo.
3. Crie outro instantâneo.
Procurar um instantâneo de compartilhamento

1. Em seu compartilhamento de arquivo, selecione Exibir instantâneos .
2. No painel Instantâneos de compar tilhamento de arquivo , selecione o primeiro instantâneo da lista.
3. No painel do instantâneo, selecione qsTestFile.txt.
Restaurar de um instantâneo
1. Na folha de instantâneo do compartilhamento de arquivo, clique com o botão direito do mouse em
qsTestFile e selecione o botão Restaurar .
2. Selecione Substituir arquivo original .
3. Na VM, abra o arquivo. A versão não modificada foi restaurada.
Excluir um instantâneo de compartilhamento

1. Em seu compartilhamento de arquivo, selecione Exibir instantâneos .
2. No painel Instantâneos de compar tilhamento de arquivo , selecione o último instantâneo da lista e
clique em Excluir .
Usar um instantâneo de compartilhamento no Windows
Assim como acontece com instantâneos locais do VSS, você pode exibir os instantâneos de seu compartilhamento
de arquivo do Azure montado usando a guia Versões Anteriores.
1. No Explorador de Arquivos, localize o compartilhamento montado.
2. Selecione qsTestFile.txt e > clique com o botão direito do mouse e selecione Propriedades no menu.
3. Selecione Versões Anteriores para ver a lista de instantâneos de compartilhamento para esse diretório.
4. Selecione Abrir para abrir o instantâneo.
Restaurar de uma versão anterior
1. Selecione Restaurar . Esta ação copia o conteúdo de todo o diretório recursivamente para o local original no
momento da criação do instantâneo.
Observação: se o arquivo não tiver sido alterado, você não verá uma versão anterior desse arquivo porque
esse arquivo é da mesma versão que o instantâneo. Isso é consistente com a maneira como isso funciona
em um servidor de arquivos do Windows.
Limpar os recursos
Após a conclusão, exclua o grupo de recursos. A exclusão do grupo de recursos exclui a conta de armazenamento, o
compartilhamento de arquivos do Azure e outros recursos implantados dentro do grupo de recursos.
1. No menu esquerdo, selecione Grupo de recursos .
2. Clique com o botão direito do mouse em grupo de recursos e selecione Excluir grupo de recursos . Uma
janela é aberta e exibe um aviso sobre os recursos que serão excluídos com o grupo de recursos.
3. Insira o nome do grupo de recursos e selecione Excluir .
Próximas etapas
Usar um compartilhamento de arquivos do Azure com o Windows
Início Rápido: criar e gerenciar compartilhamentos de
arquivos do Azure com o portal do Azure
Arquivos do Azure é o sistema de arquivos de nuvem fácil de usar da Microsoft. Os compartilhamentos de

arquivos do Azure podem ser montados no Windows, no Linux e no macOS. Este guia percorre os fundamentos de
trabalhar com compartilhamentos de arquivos do Azure usando o Portal do Azure.

Uma conta de armazenamento é um pool compartilhado de armazenamento no qual você pode implantar um
compartilhamento de arquivos do Azure ou outros recursos de armazenamento como blobs ou filas. Uma conta de
armazenamento pode conter uma quantidade ilimitada de compartilhamentos. Um compartilhamento pode conter
uma quantidade ilimitada de arquivos, até os limites de capacidade da conta de armazenamento.
Para criar uma conta de armazenamento:
1. No menu esquerdo, selecione + para criar um recurso.
2. Na caixa de pesquisa, insira conta de armazenamento , selecione Conta de armazenamento - blob,
arquivo, tabela, fila e selecione Criar .
3. Em Nome , insira mystorageacct, seguido por alguns números aleatórios até aparecer a marca de seleção
verde indicando que é um nome exclusivo. Um nome de conta de armazenamento deve conter apenas letras
minúsculas e ser globalmente exclusivo. Anote o nome da sua conta de armazenamento. Você o usará mais
tarde.
4. Em Modelo de implantação , deixe o valor padrão de Gerenciador de Recursos . Para saber mais sobre
as diferenças entre o Azure Resource Manager e o modelo de implantação clássica, consulte Entender os
modelos de implantação e o estado de seus recursos.
5. Em Tipo de conta , selecione StorageV2 . Para saber mais sobre os diferentes tipos de contas de
armazenamento, consulte Noções básicas de contas de armazenamento do Azure.
6. Em Desempenho , mantenha o valor padrão de Armazenamento padrão . Os arquivos do Azure
atualmente oferecem suporte apenas ao armazenamento padrão. Mesmo que você selecione o
Armazenamento Premium do Azure, o compartilhamento de arquivos será armazenado no armazenamento
padrão.
7. Em Replicação , selecione Armazenamento com redundância local (LRS) .
8. Em Transferência segura necessária , é recomendável sempre selecionar Habilitado . Para saber mais
sobre essa opção, consulte Noções básicas sobre criptografia em trânsito.
9. Em Assinatura , selecione a assinatura que foi usada para criar a conta de armazenamento. Se você tiver
apenas uma assinatura, ela deverá ser a padrão.
10. Em Grupo de recursos , selecione Criar novo . Para o nome, insira myResourceGroup.
11. Em Localização , selecione Leste dos EUA .
12. Em Redes vir tuais , deixe a opção padrão como Desabilitado .
13. Selecione Fixar no painel para tornar o armazenamento de conta mais fácil de ser encontrado.
14. Ao terminar, selecione Criar para iniciar a implantação.

Para criar um compartilhamento de arquivos do Azure:
1. Selecione a conta de armazenamento no seu painel.
2. Na página da conta de armazenamento, na seção Ser viços , selecione Arquivos .
3. No menu na parte superior da página Arquivo de ser viço , clique em Compar tilhamento de arquivo . O
menu suspenso da página Novo compar tilhamento de arquivos .
4. Em Nome , digite myshare.
5. Clique em OK para criar o compartilhamento de arquivos do Azure.
Os nomes de compartilhamento precisam ter somente letras em minúsculas, números e hifens, mas não podem
começar com um hífen. Para obter detalhes completos sobre como nomear arquivos e compartilhamentos de
arquivos, confira Nomenclatura e referência de compartilhamentos, diretórios, arquivos e metadados.
Usar o compartilhamento de arquivos do Azure

Os Arquivos do Azure fornecem dois métodos para trabalhar com arquivos e pastas dentro do seu
compartilhamento de arquivos do Azure: o padrão do setor protocolo SMB (Server Message Block) e o protocolo
REST de arquivo.
Para montar um compartilhamento de arquivos com SMB, consulte o documento abaixo com base em seu sistema
operacional:
Windows
Linux
macOS
Usando um compartilhamento de arquivo do Azure no portal do Azure
Todas as solicitações feitas por meio do Portal do Azure são feitas com a API REST do arquivo, permitindo a você
criar, modificar e excluir arquivos e diretórios nos clientes sem acesso ao SMB. É possível trabalhar diretamente
com o protocolo REST de Arquivo (ou seja, criar manualmente chamadas REST HTTP por conta própria), mas a
maneira mais comum (além de usar o portal do Azure) de usar o protocolo REST de Arquivo é usar o módulo do
Azure PowerShell, a CLI do Azure ou um SDK do Armazenamento do Azure, que fornecem um bom wrapper do
protocolo REST de Arquivo na linguagem de scripts/programação de sua escolha.
Acreditamos que a maioria dos usuários dos Arquivos do Azure desejará trabalhar com o compartilhamento de
arquivo do Azure em vez do protocolo SMB, pois isso permite usar os aplicativos e as ferramentas existentes que
eles esperam poder usar, mas há vários motivos que mostram como é vantajoso usar a API REST de Arquivo em
vez do SMB, como:
Você precisa fazer uma alteração rápida ao seu compartilhamento de arquivo do Azure em trânsito, como um
laptop sem acesso ao SMB, tablet ou dispositivo móvel.
Você precisa executar um script ou aplicativo de um cliente que não consegue montar um compartilhamento de
SMB, como clientes locais que não têm a porta 445 desbloqueada.
Você está aproveitando as vantagens dos recursos sem servidor, como o Azure Functions.
Os exemplos a seguir mostram como usar o portal do Azure para manipular o compartilhamento de arquivos do
Azure com o protocolo REST de arquivo.
Agora que você criou um compartilhamento de arquivos do Azure, pode montar o compartilhamento de arquivos
com SMB no Windows, no Linux ou no macOS. Como alternativa, você pode trabalhar com o compartilhamento de
arquivos do Azure com o Portal do Azure.
Criar um diretório
Para criar um novo diretório chamado myDirectory na raiz do seu compartilhamento de arquivos do Azure:
1. Na página Ser viço de arquivos , selecione o compartilhamento de arquivos myshare . A página do
compartilhamento de arquivos é aberta.
2. No menu na parte superior da página, selecione + Adicionar diretório . Menu suspenso da página Novo
diretório .
3. Digite myDirectory e clique em OK .
Carregar um arquivo
Para demonstrar o upload de um arquivo, primeiro crie ou selecione um arquivo a ser carregado. Você pode fazer
isso por qualquer meio que desejar. Depois de selecionar o arquivo que você deseja carregar:
1. Clique no diretório myDirector y . O painel myDirector y é aberto.
2. No menu na parte superior, clique em Carregar . O painel Carregar arquivos é aberto.
3. Clique no ícone de pasta para abrir uma janela e procurar seus arquivos locais.
4. Selecione um arquivo e clique em Abrir .
5. Na página Carregar arquivos , verifique o nome do arquivo e clique em Carregar .
6. Quando terminar, o arquivo deverá aparecer na lista da página myDirector y .
Baixar um arquivo
Você pode baixar uma cópia do arquivo carregado clicando com o botão direito do mouse no arquivo. Depois de
clicar no botão de download, a experiência exata dependerá do sistema operacional e do navegador que você está
usando.
Limpar os recursos
Após a conclusão, exclua o grupo de recursos. A exclusão do grupo de recursos exclui a conta de armazenamento,
o compartilhamento de arquivos do Azure e outros recursos implantados dentro do grupo de recursos.
Próximas etapas
O que Arquivos do Azure?
Início Rápido: criar e gerenciar um
compartilhamento de arquivos do Azure com o
Azure PowerShell
Este guia oferece orientações básicas sobre como trabalhar com compartilhamentos de arquivos do Azure usando
o PowerShell. Os compartilhamentos de arquivos do Azure são iguais a outros compartilhamentos de arquivos,
mas são armazenados na nuvem e compatíveis com a plataforma do Azure. Os compartilhamentos de Arquivos
do Azure oferecem suporte ao protocolo SMB padrão do setor e habilitar o compartilhamento de arquivos entre
vários computadores, aplicativos e instâncias.
Usar o Azure Cloud Shell

O Azure hospeda o Azure Cloud Shell, um ambiente de shell interativo que pode ser usado por meio do
navegador. É possível usar o bash ou o PowerShell com o Cloud Shell para trabalhar com os serviços do Azure. É
possível usar os comandos pré-instalados do Cloud Shell para executar o código neste artigo sem precisar instalar
nada no seu ambiente local.
Para iniciar o Azure Cloud Shell:
OPÇ ÃO EXEM P LO / L IN K
Selecione Experimente no canto superior direito de um

bloco de código. Selecionar Experimente não copia
automaticamente o código para o Cloud Shell.
Acesse https://shell.azure.com ou selecione o botão Iniciar o

Cloud Shell para abri-lo no navegador.
Selecione o botão Cloud Shell na barra de menus no canto

superior direito do portal do Azure.
Para executar o código neste artigo no Azure Cloud Shell:

1. Inicie o Cloud Shell.
2. Clique no botão Copiar no bloco de código para copiá-lo.
3. Cole o código na sessão do Cloud Shell ao pressionar Ctrl +Shift +V no Windows e no Linux ou
Cmd +Shift +V no macOS.
4. Pressione Enter para executar o código.
Se você quiser instalar e usar o PowerShell localmente, este guia exigirá o módulo do Azure PowerShell versão Az
0.7 ou posterior. Para descobrir qual versão do módulo do Azure PowerShell está em execução, execute
Get-Module -ListAvailable Az . Se você precisa atualizar, consulte Instalar o módulo do Azure PowerShell. Se você
estiver executando o PowerShell localmente, também precisará executar o Login-AzAccount para fazer logon na
conta do Azure.
Criar um grupo de recursos
Um grupo de recursos é um contêiner lógico no qual os recursos do Azure são implantados e gerenciados. Se
você ainda não tem um grupo de recursos do Azure, crie um novo com o cmdlet New-AzResourceGroup.
O seguinte exemplo cria um grupo de recursos chamado myResourceGroup na região Oeste dos EUA 2:
$resourceGroupName = "myResourceGroup"
$region = "westus2"
New-AzResourceGroup `
-Name $resourceGroupName `
-Location $region | Out-Null

Uma conta de armazenamento é um pool compartilhado de armazenamento que você pode usar para implantar
compartilhamentos de arquivo do Azure. Uma conta de armazenamento pode conter um número ilimitado de
compartilhamentos, e um compartilhamento pode conter um número ilimitado de arquivos, até os limites de
capacidade da conta de armazenamento. Este exemplo cria uma versão de uso geral 2 (conta de armazenamento
GPv2), que pode armazenar compartilhamentos de arquivo do Azure padrão ou outros recursos de
armazenamento, como blobs ou filas, na mídia de rotação da HD (unidade de disco rígido). Os Arquivos do Azure
também dão suporte a SSDs (unidades de disco de estado sólido) Premium; os compartilhamentos de arquivo
premium do Azure podem ser criados em contas de armazenamento FileStorage.
Este exemplo cria uma conta de armazenamento usando o cmdlet New-AzStorageAccount. A conta de
armazenamento é denominada mystorageaccount<número aleatório> e uma referência a essa conta de
armazenamento é armazenada na variável $storageAcct . Os nomes de conta de armazenamento devem ser
exclusivo e, portanto, use Get-Random para acrescentar um número ao nome e torná-lo exclusivo.
$storageAccountName = "mystorageacct$(Get-Random)"
$storageAcct = New-AzStorageAccount `
-ResourceGroupName $resourceGroupName `
-Name $storageAccountName `
-Location $region `
-Kind StorageV2 `
-SkuName Standard_ZRS `
-EnableLargeFileShare
NOTE
Compartilhamentos maiores que 5 TiB (até o máximo de 100 TiB por compartilhamento) só estão disponíveis em contas de
armazenamento LRS (com redundância local) e ZRS (com redundância de zona). Para criar uma conta de armazenamento
GRS (com redundância geográfica) ou GZRS (com redundância de zona geográfica), remova o parâmetro
-EnableLargeFileShare .

Agora você pode criar seu primeiro compartilhamento de arquivos do Azure. Você pode criar um
compartilhamento de arquivo usando o cmdlet New-AzRmStorageShare. Esse exemplo cria um
compartilhamento chamado myshare .
$shareName = "myshare"
New-AzRmStorageShare `
-StorageAccount $storageAcct `
-Name $shareName `
-QuotaGiB 1024 | Out-Null
Os nomes dos compartilhamentos precisam ter todos letras minúsculas, números e hifens, mas não podem
começar com um hífen. Para obter detalhes completos sobre como nomear arquivos e compartilhamentos de

REST de arquivo.
Para montar um compartilhamento de arquivos com SMB, consulte o documento abaixo com base em seu
sistema operacional:
Windows
Linux
macOS
Usar um compartilhamento de arquivos do Azure com o protocolo REST de arquivo
É possível trabalhar com o protocolo REST de arquivo (ou seja, modelar manualmente as chamadas REST HTTP
por conta própria), mas a maneira mais comum de usar o protocolo REST de arquivo é usar o módulo do Azure
PowerShell, a CLI do Azure ou um SDK do Armazenamento do Azure, que fornecem um bom wrapper do
protocolo REST de arquivo na linguagem de script/programação de sua escolha.
Na maioria dos casos, você usará o compartilhamento de arquivos do Azure em vez do protocolo SMB, pois isso
permite usar os aplicativos e as ferramentas existentes que você espera poder usar, mas há várias razões por que
é vantajoso usar a API REST de arquivo em vez de SMB, a saber:
Você está buscando seu compartilhamento de arquivos no Cloud Shell do PowerShell (o que não pode montar
os compartilhamentos de arquivos via SMB).
Você está criando um serviço de valor agregado que interagirá com muitos compartilhamentos de arquivos do
Azure, como realizar backup ou verificações antivírus.
Os exemplos a seguir mostram como usar o módulo do Azure PowerShell para manipular o compartilhamento de
arquivos do Azure com o protocolo REST de arquivo. O parâmetro -Context é usado para recuperar a chave de
conta de armazenamento para executar as ações indicadas no compartilhamento de arquivo. Para recuperar a
chave de conta de armazenamento, é necessário ter a função RBAC de Owner na conta de armazenamento.
Criar diretório
Para criar um novo diretório chamado myDirectory na raiz do seu compartilhamento de arquivos do Azure, use o
cmdlet New-AzStorageDirectory.
New-AzStorageDirectory `
-Context $storageAcct.Context `
-ShareName $shareName `
-Path "myDirectory"
Carregar um arquivo
Para demonstrar como carregar um arquivo usando o cmdlet Set-AzStorageFileContent, primeiro precisamos criar
um arquivo dentro da unidade temporária do Cloud Shell do PowerShell para upload.
Este exemplo coloca a data e a hora atuais em um novo arquivo na unidade temporária e o carrega no
compartilhamento de arquivos.
# this expression will put the current date and time into a new file on your scratch drive
cd "~/CloudDrive/"
Get-Date | Out-File -FilePath "SampleUpload.txt" -Force
# this expression will upload that newly created file to your Azure file share
Set-AzStorageFileContent `
-Source "SampleUpload.txt" `
-Path "myDirectory\SampleUpload.txt"
Se você estiver executando o PowerShell localmente, substitua ~/CloudDrive/ por um caminho existente em seu
computador.
Depois de carregar o arquivo, você pode usar o cmdlet Get-AzStorageFile para verificar se o arquivo foi carregado
no compartilhamento de arquivos do Azure.
Get-AzStorageFile `
-Path "myDirectory\"
Baixar um arquivo
Você pode usar o cmdlet Get-AzStorageFileContent para baixar uma cópia do arquivo que você acabou de
carregar na unidade temporária do Cloud Shell.
# Delete an existing file by the same name as SampleDownload.txt, if it exists because you've run this example
before.
Remove-Item `
-Path "SampleDownload.txt" `
-Force `
-ErrorAction SilentlyContinue
Get-AzStorageFileContent `
-Path "myDirectory\SampleUpload.txt" `
-Destination "SampleDownload.txt"
Depois de baixar o arquivo, você pode usar o Get-ChildItem para ver se o arquivo foi baixado na unidade
temporária do Cloud Shell do PowerShell.
Get-ChildItem | Where-Object { $_.Name -eq "SampleDownload.txt" }
Copiar arquivos
Uma tarefa comum é copiar arquivos de um compartilhamento de arquivo para outro. Para demonstrar essa
funcionalidade, você pode criar um novo compartilhamento e copiar o arquivo recém-carregado para esse novo
compartilhamento usando o cmdlet Start-AzStorageFileCopy.
$otherShareName = "myshare2"
New-AzRmStorageShare `
-StorageAccount $storageAcct `
-Name $otherShareName `
-QuotaGiB 1024 | Out-Null
New-AzStorageDirectory `
-ShareName $otherShareName `
-Path "myDirectory2"
Start-AzStorageFileCopy `
-SrcShareName $shareName `
-SrcFilePath "myDirectory\SampleUpload.txt" `
-DestShareName $otherShareName `
-DestFilePath "myDirectory2\SampleCopy.txt" `
-DestContext $storageAcct.Context
Agora, se você listar os arquivos no novo compartilhamento, deverá ver o arquivo copiado.
Get-AzStorageFile `
-ShareName $otherShareName `
-Path "myDirectory2"
Embora o cmdlet Start-AzStorageFileCopy seja conveniente para movimentações de arquivo ad hoc entre
compartilhamentos de arquivo do Azure, para migrações e movimentações de dados maiores, recomendamos
robocopy no Windows e rsync no macOS e Linux. robocopy e rsync usam o SMB para executar
movimentações de dados em vez da API FileREST.
Criar e gerenciar instantâneos de compartilhamento

Outra tarefa útil que você pode fazer com um compartilhamento de arquivos do Azure é criar instantâneos de
compartilhamento. Um instantâneo preserva um ponto no tempo para um compartilhamento de arquivos do
Azure. Os instantâneos de compartilhamento são semelhantes às tecnologias de sistema operacional que você
talvez já conheça, como:
VSS (Serviço de Cópias de Sombra de Volume) para sistemas de arquivos Windows, como NTFS e ReFS.
Instantâneos do LVM (Gerenciador de Volumes Lógicos) para sistemas Linux.
Instantâneos do APFS (Sistema de arquivos da Apple) para macOS.
Você pode criar um instantâneo de compartilhamento para um compartilhamento usando o método Snapshot no
objeto do PowerShell para um compartilhamento de arquivo, que é recuperado com o cmdlet Get-
AzStorageShare.
$share = Get-AzStorageShare -Context $storageAcct.Context -Name $shareName

$snapshot = $share.Snapshot()
Procurar instantâneos de compartilhamento

Você pode procurar o conteúdo do instantâneo de compartilhamento passando a referência do instantâneo (
$snapshot ) para o parâmetro -Share do cmdlet Get-AzStorageFile .
Get-AzStorageFile -Share $snapshot

Listar instantâneos de compartilhamento
Você pode ver a lista de instantâneos tirados para seu compartilhamento com o comando a seguir.
Get-AzStorageShare `
-Context $storageAcct.Context | `
Where-Object { $_.Name -eq $shareName -and $_.IsSnapshot -eq $true }
Restaurar de um instantâneo de compartilhamento

Você pode restaurar um arquivo usando o comando Start-AzStorageFileCopy usado anteriormente. Para fins
deste início rápido, iremos primeiro excluir nosso arquivo SampleUpload.txt carregado anteriormente para que
possa ser restaurado do instantâneo.
# Delete SampleUpload.txt
Remove-AzStorageFile `
-Path "myDirectory\SampleUpload.txt"
# Restore SampleUpload.txt from the share snapshot

Start-AzStorageFileCopy `
-SrcShare $snapshot `
-SrcFilePath "myDirectory\SampleUpload.txt" `
-DestContext $storageAcct.Context `
-DestShareName $shareName `
-DestFilePath "myDirectory\SampleUpload.txt"

Você pode excluir um instantâneo de compartilhamento usando o cmdlet Remove-AzStorageShare, com a variável
que contém a referência $snapshot para o parâmetro -Share .
Remove-AzStorageShare `
-Share $snapshot `
-Confirm:$false `
-Force
Limpar os recursos
Quando tiver concluído, você poderá usar o cmdlet Remove-AzResourceGroup para remover o grupo de recursos
e todos os recursos relacionados.
Remove-AzResourceGroup -Name myResourceGroup
Como alternativa, você pode remover recursos individualmente:

Para remover os compartilhamentos de arquivos do Azure que criamos para este início rápido.
Get-AzRmStorageShare -StorageAccount $storageAcct | Remove-AzRmStorageShare -Force
NOTE
Você deve excluir todos os instantâneos de compartilhamento para os compartilhamentos de arquivo do Azure
criados antes de excluir o compartilhamento de arquivo do Azure.
Para remover a própria conta de armazenamento (isso removerá implicitamente os compartilhamentos de
arquivos do Azure que criamos, bem como qualquer outro recurso de armazenamento criado, como um
contêiner do Armazenamento de Blobs do Azure).
Remove-AzStorageAccount `
-ResourceGroupName $storageAcct.ResourceGroupName `
-Name $storageAcct.StorageAccountName
Próximas etapas
Início Rápido: Criar e gerenciar compartilhamentos
de arquivos do Azure usando a CLI do Azure
Este guia percorre os fundamentos de trabalhar com compartilhamentos de arquivos do Azure usando a CLI do
Azure. Os compartilhamentos de arquivos do Azure são iguais a outros compartilhamentos de arquivos, mas são
armazenados na nuvem e compatíveis com a plataforma do Azure. Os compartilhamentos de Arquivos do Azure
oferecem suporte ao protocolo SMB padrão do setor e habilitar o compartilhamento de arquivos entre vários
computadores, aplicativos e instâncias.
Usar o Azure Cloud Shell

O Azure hospeda o Azure Cloud Shell, um ambiente de shell interativo que pode ser usado por meio do
navegador. É possível usar o bash ou o PowerShell com o Cloud Shell para trabalhar com os serviços do Azure. É
possível usar os comandos pré-instalados do Cloud Shell para executar o código neste artigo sem precisar
instalar nada no seu ambiente local.
Para iniciar o Azure Cloud Shell:
OPÇ ÃO EXEM P LO / L IN K
Selecione Experimente no canto superior direito de um

bloco de código. Selecionar Experimente não copia
automaticamente o código para o Cloud Shell.
Acesse https://shell.azure.com ou selecione o botão Iniciar o

Cloud Shell para abri-lo no navegador.
Selecione o botão Cloud Shell na barra de menus no canto

superior direito do portal do Azure.
Para executar o código neste artigo no Azure Cloud Shell:

1. Inicie o Cloud Shell.
2. Clique no botão Copiar no bloco de código para copiá-lo.
3. Cole o código na sessão do Cloud Shell ao pressionar Ctrl +Shift +V no Windows e no Linux ou
Cmd +Shift +V no macOS.
4. Pressione Enter para executar o código.
Se você decidir instala e usar a CLI do Azure localmente, para as etapas neste artigo, você deve estar executando a
versão 2.0.4 ou posterior da CLI do Azure. Execute az --version para saber qual é a versão da sua CLI do Azure.
Se você precisa instalar ou atualizar, consulte Instalar a CLI 2.0 do Azure.
Por padrão, os comandos da CLI do Azure são em JavaScript Object Notation (JSON). JSON é a forma padrão de
enviar e receber mensagens a partir de APIs REST. Para facilitar o trabalho com as respostas em JSON, alguns dos
exemplos neste artigo usam o parâmetro query nos comandos da CLI do Azure. Esse parâmetro utiliza a
linguagem de consulta JMESPath para a análise do JSON. Você pode aprender mais sobre como usar os
resultados dos comandos da CLI do Azure seguindo a linguagem de consulta JMESPath, consulte o Tutorial de
JMESPath.

Um grupo de recursos é um contêiner lógico no qual os recursos do Azure são implantados e gerenciados. Se
você ainda não tiver um grupo de recursos do Azure, pode usar o comando az group create para criar um.
O seguinte exemplo cria um grupo de recursos chamado myResourceGroup na localização Oeste dos EUA 2:
export resourceGroupName="myResourceGroup"
region="westus2"
az group create \
--name $resourceGroupName \
--location $region \
--output none

Uma conta de armazenamento é um pool compartilhado de armazenamento no qual você pode implantar o
compartilhamento de arquivos do Azure ou outros recursos de armazenamento, como blobs ou filas. Uma conta
de armazenamento pode conter uma quantidade ilimitada de compartilhamentos de arquivos. Um
compartilhamento pode conter uma quantidade ilimitada de arquivos, até os limites de capacidade da conta de
armazenamento.
O exemplo a seguir cria uma conta de armazenamento usando o comando az storage account create. Os nomes
de conta de armazenamento devem ser exclusivo e, portanto, use $RANDOM para acrescentar um número ao nome
e torná-lo exclusivo.
export storageAccountName="mystorageacct$RANDOM"
az storage account create \

--resource-group $resourceGroupName \
--name $storageAccountName \
--kind StorageV2 \
--sku Standard_LRS \
--enable-large-file-share \
--output none
NOTE
Compartilhamentos maiores que 5 TiB (até o máximo de 100 TiB por compartilhamento) só estão disponíveis em contas de
armazenamento LRS (com redundância local) e ZRS (com redundância de zona). Para criar uma conta de armazenamento
GRS (com redundância geográfica) ou GZRS (com redundância de zona geográfica), remova o parâmetro
--enable-large-file-share .
Obter a chave da conta de armazenamento

As chaves de conta de armazenamento controlam o acesso aos recursos em uma conta de armazenamento. As
chaves são criadas automaticamente quando você cria uma conta de armazenamento. Você pode obter as chaves
da conta de armazenamento usando o comando az storage account keys list:
export storageAccountKey=$(az storage account keys list \
--account-name $storageAccountName \
--query "[0].value" | tr -d '"')

Agora você pode criar seu primeiro compartilhamento de arquivos do Azure. Criar compartilhamentos de
arquivos usando o comando az storage share create. Este exemplo cria um compartilhamento de arquivos do
Azure chamado myshare:
shareName="myshare"
az storage share create \

--account-key $storageAccountKey \
--name $shareName \
--quota 1024 \
--output none
Os nomes de compartilhamento podem conter somente letras em minúsculas, números e hifens (mas não podem
começar com um hífen). Para obter detalhes completos sobre como nomear arquivos e compartilhamentos de

REST de arquivo.
Para montar um compartilhamento de arquivos com SMB, consulte o documento abaixo com base em seu
sistema operacional:
Linux
macOS
Windows
Usar um compartilhamento de arquivos do Azure com o protocolo REST de arquivo
É possível trabalhar diretamente com o protocolo REST de Arquivo (criar manualmente chamadas REST HTTP por
conta própria), mas a maneira mais comum para usar o protocolo REST de Arquivo é usar a CLI do Azure, o
módulo do Azure PowerShell ou um SDK do Armazenamento do Microsoft Azure, que fornecem um bom
wrapper do protocolo REST de Arquivo na linguagem de scripts/programação de sua escolha.
Acreditamos que a maioria dos usos dos arquivos do Azure será com o compartilhamento em vez do protocolo
SMB, pois isso permite usar os aplicativos e as ferramentas existentes que se espera poder usar, mas há vários
motivos que mostram como é vantajoso usar a API REST de arquivo em vez de SMB, a saber:
Você está buscando seu compartilhamento de arquivo no Azure Bash Cloud Shell (que não pode montar os
compartilhamentos de arquivos via SMB).
Você está criando um serviço de valor agregado que interagirá com muitos compartilhamentos de arquivos
do Azure, como realizar backup ou verificações antivírus.
Os exemplos a seguir mostram como usar a CLI do Azure para manipular o compartilhamento de arquivos do
Azure com o protocolo REST de Arquivo.
Criar um diretório
Para criar um novo diretório chamado myDirectory na raiz do seu compartilhamento de arquivos do Azure, use o
comando az storage directory create :
az storage directory create \

--share-name $shareName \
--name "myDirectory" \
--output none
Carregar um arquivo
Para demonstrar como carregar um arquivo usando o comando az storage file upload , primeiro crie um
arquivo para carregar a unidade temporária do Cloud Shell. No exemplo a seguir, crie e carregue o arquivo:
cd ~/clouddrive/
date > SampleUpload.txt
az storage file upload \

--source "SampleUpload.txt" \
--path "myDirectory/SampleUpload.txt"
Se você estiver executando a CLI do Azure localmente, substitua ~/clouddrive por um caminho existente em seu
computador.
Depois de carregar o arquivo, você pode usar o comando az storage file list para verificar se o arquivo foi
carregado no compartilhamento de arquivos do Azure:
az storage file list \

--path "myDirectory" \
--output table
Baixar um arquivo
Você pode usar o comando az storage file download para baixar uma cópia do arquivo que você carregou na
unidade temporária do Cloud Shell:
# Delete an existing file by the same name as SampleDownload.txt, if it exists, because you've run this
example before
rm -f SampleDownload.txt
az storage file download \

--path "myDirectory/SampleUpload.txt" \
--dest "SampleDownload.txt" \
--output none
Copiar arquivos
Uma tarefa comum é copiar arquivos de um compartilhamento de arquivo para outro. Para demonstrar essa
funcionalidade, crie um novo compartilhamento. Copie o arquivo que você carregou neste novo
compartilhamento usando o comando az storage file copy:
otherShareName="myshare2"

--name $otherShareName \
--quota 1024 \
--output none
az storage directory create \

--share-name $otherShareName \
--name "myDirectory2" \
--output none
az storage file copy start \

--source-share $shareName \
--source-path "myDirectory/SampleUpload.txt" \
--destination-share $otherShareName \
--destination-path "myDirectory2/SampleCopy.txt"
Agora, se você listar os arquivos no novo compartilhamento, deverá ver o arquivo copiado:

--share-name $otherShareName \
--path "myDirectory2" \
--output table
Embora o comando az storage file copy start seja conveniente para movimentações de arquivo entre
compartilhamentos de arquivo do Azure, para migrações e grandes movimentações de dados, recomendamos o
rsync no macOS e Linux e robocopy no Windows. rsync e robocopy usam o SMB para executar
movimentações de dados em vez da API FileREST.
Criar e gerenciar instantâneos de compartilhamento

Outra tarefa útil que você pode fazer com um compartilhamento de arquivos do Azure é criar instantâneos de
compartilhamento. Um instantâneo preserva um ponto no tempo para uma cópia de um compartilhamento de
arquivos do Azure. Os instantâneos de compartilhamento são semelhantes a algumas tecnologias de sistema
operacional que você talvez já conheça, como:
Instantâneos do LVM (Gerenciador de Volumes Lógicos) para sistemas Linux.
Instantâneos do APFS (Sistema de arquivos da Apple) para macOS.
VSS (Serviço de Cópias de Sombra de Volume) para sistemas de arquivos Windows, como NTFS e ReFS.
Você pode criar um instantâneo de compartilhamento usando o comando az storage share snapshot :
snapshot=$(az storage share snapshot \
--name $shareName \
--query "snapshot" | tr -d '"')
Procurar conteúdo do instantâneo de compartilhamento

Você pode procurar o conteúdo de um instantâneo de compartilhamento passando o carimbo de data/hora do
instantâneo de compartilhamento capturado na variável $snapshot para o comando az storage file list :

--snapshot $snapshot \
--output table

Para ver a lista de instantâneos tirados para seu compartilhamento use o comando a seguir:
az storage share list \

--include-snapshot \
--query "[? name== '$shareName' && snapshot!=null].snapshot" \
--output tsv
Restaurar de um instantâneo de compartilhamento

Você pode restaurar um arquivo usando o comando az storage file copy start usado anteriormente. Primeiro,
exclua o arquivo SampleUpload.txt que você carregou, para que você possa restaurá-lo a partir do instantâneo:
# Delete SampleUpload.txt
az storage file delete \
--path "myDirectory/SampleUpload.txt" \
--output none
# Build the source URI for a snapshot restore

URI=$(az storage account show \
--query "primaryEndpoints.file" | tr -d '"')
URI=$URI$shareName"/myDirectory/SampleUpload.txt?sharesnapshot="$snapshot
# Restore SampleUpload.txt from the share snapshot

az storage file copy start \
--source-uri $URI \
--destination-share $shareName \
--destination-path "myDirectory/SampleUpload.txt"

Você pode excluir um instantâneo de compartilhamento usando o comando az storage share delete . Use a
variável que contém a referência $SNAPSHOT ao parâmetro --snapshot :
az storage share delete \

--name $shareName \
--snapshot $snapshot \
--output none
Limpar os recursos
Quando concluir, você poderá usar o comando az group delete para remover o grupo de recursos e todos os
recursos relacionados:
az group delete --name $resourceGroupName
Alternativamente, você pode remover os recursos individualmente.

Para remover os compartilhamentos de arquivos do Azure que você criou com este artigo:
az storage share list \

--query "[].name" \
--output tsv | \
xargs -L1 bash -ec '\
az storage share delete \
--account-name "$storageAccountName" \
--account-key "$storageAccountKey" \
--name $0 \
--delete-snapshots include \
--output none'
Para remover a própria conta de armazenamento. (Isso remove de forma implícita os compartilhamentos
de arquivo do Azure que você criou e quaisquer outros recursos que tenham sido criados, como o
contêiner de armazenamento de Blobs do Azure.)
az storage account delete \

--yes
Próximas etapas
Início Rápido: criar e gerenciar compartilhamentos de
arquivos do Gerenciador de Armazenamento do
Azure
Este guia percorre os fundamentos de trabalhar com compartilhamentos de arquivos do Azure com o Gerenciador
de Armazenamento do Azure. Os compartilhamentos de arquivos do Azure são iguais a outros compartilhamentos
de arquivos, mas são armazenados na nuvem e compatíveis com a plataforma do Azure. Os compartilhamentos de
Arquivos do Azure oferecem suporte ao protocolo SMB padrão do setor e habilitar o compartilhamento de
arquivos entre vários computadores, aplicativos e instâncias.
O Gerenciador de Armazenamento do Azure é uma ferramenta popular de cliente disponível para Windows,
macOS e Linux. Você pode usar o Gerenciador de Armazenamento para gerenciar compartilhamentos de arquivo e
outros recursos de armazenamento.
Prerequisites
Este guia de início rápido requer que o Gerenciador de Armazenamento esteja instalado. Para baixá-lo e instalá-lo,
vá até Gerenciador de Armazenamento do Azure.

Você não pode usar o Gerenciador de Armazenamento para criar novos recursos. Para esta demonstração, crie a
conta de armazenamento no Portal do Azure.
Uma conta de armazenamento é um pool compartilhado de armazenamento no qual você pode implantar um
compartilhamento de arquivos do Azure ou outros recursos de armazenamento como blobs ou filas. Uma conta de
armazenamento pode conter uma quantidade ilimitada de compartilhamentos. Um compartilhamento pode conter
uma quantidade ilimitada de arquivos, até os limites de capacidade da conta de armazenamento.
Para criar uma conta de armazenamento:
1. No menu esquerdo, selecione + para criar um recurso.
2. Na caixa de pesquisa, insira conta de armazenamento , selecione Conta de armazenamento - blob,
arquivo, tabela, fila e selecione Criar .
3. Em Nome , insira mystorageacct, seguido por alguns números aleatórios até aparecer a marca de seleção
verde indicando que é um nome exclusivo. Um nome de conta de armazenamento deve conter apenas letras
minúsculas e ser globalmente exclusivo. Anote o nome da sua conta de armazenamento. Você o usará mais
tarde.
4. Em Modelo de implantação , deixe o valor padrão de Gerenciador de Recursos . Para saber mais sobre
as diferenças entre o Azure Resource Manager e o modelo de implantação clássica, consulte Entender os
modelos de implantação e o estado de seus recursos.
5. Em Tipo de conta , selecione StorageV2 . Para saber mais sobre os diferentes tipos de contas de
armazenamento, consulte Noções básicas de contas de armazenamento do Azure.
6. Em Desempenho , mantenha o valor padrão de Armazenamento padrão . Os arquivos do Azure
atualmente oferecem suporte apenas ao armazenamento padrão. Mesmo que você selecione o
Armazenamento Premium do Azure, o compartilhamento de arquivos será armazenado no armazenamento
padrão.
7. Em Replicação , selecione Armazenamento com redundância local (LRS) .
8. Em Transferência segura necessária , é recomendável sempre selecionar Habilitado . Para saber mais
sobre essa opção, consulte Noções básicas sobre criptografia em trânsito.
9. Em Assinatura , selecione a assinatura que foi usada para criar a conta de armazenamento. Se você tiver
apenas uma assinatura, ela deverá ser a padrão.
10. Em Grupo de recursos , selecione Criar novo . Para o nome, insira myResourceGroup.
11. Em Localização , selecione Leste dos EUA .
12. Em Redes vir tuais , deixe a opção padrão como Desabilitado .
13. Selecione Fixar no painel para tornar o armazenamento de conta mais fácil de ser encontrado.
14. Ao terminar, selecione Criar para iniciar a implantação.
Conecte o Gerenciador de Armazenamento aos recursos do Azure

Quando você iniciar o Gerenciador de Armazenamento pela primeira vez, a janela Gerenciador de
Armazenamento do Microsoft Azure - Conectar será exibida. O Gerenciador de Armazenamento fornece
várias maneiras de se conectar às contas de armazenamento:
Entre usando a sua conta do Azure : Você pode entrar usando as credenciais do usuário para a sua
organização ou a sua conta da Microsoft.
Conecte-se a uma conta de armazenamento específica usando uma cadeia de conexão ou um
token SAS : Uma cadeia de conexão é uma cadeia de caracteres especial que contém um nome de conta de
armazenamento e a chave da conta de armazenamento/token SAS. Com o token, o Gerenciador de
Armazenamento acessa diretamente a conta de armazenamento (ao invés de simplesmente ver todas as contas
de armazenamento em uma conta do Azure). Para saber mais sobre cadeias de conexão, confira Configurar
cadeia de conexão do Armazenamento do Azure.
Conectar-se a uma conta de armazenamento específico usando um nome de conta de
armazenamento e uma chave : use o nome e a chave da conta de armazenamento para se conectar ao
armazenamento do Azure.
Para os fins deste início rápido, entre com sua conta do Azure. Selecione Adicionar uma Conta do Azure e, em
seguida, selecione Entrar . Siga os prompts para entrar na sua conta do Azure.
Para criar seu primeiro compartilhamento de arquivos do Azure na conta de armazenamento
storageacct<random number> :
1. Expanda a conta de armazenamento que você criou.

2. Clique duas vezes em Compar tilhamentos de Arquivos e selecione Criar Compar tilhamento de
Arquivos .
3. Para o compartilhamento de arquivos, insira myshare e pressione Enter.

Os nomes de compartilhamento podem conter somente letras em minúsculas, números e hifens (mas não podem
começar com um hífen). Para obter detalhes completos sobre como nomear arquivos e compartilhamentos de
Após o compartilhamento de arquivos ter sido criado, uma guia para o seu compartilhamento de arquivos é
exibida no painel à direita.

Agora que você criou um compartilhamento de arquivos do Azure, pode montar o compartilhamento de arquivos
com SMB no Windows, no Linux ou no macOS. Como alternativa, você pode trabalhar com o compartilhamento de
arquivos do Azure usando o Gerenciador de Armazenamento do Azure. A vantagem de usar o Gerenciador de
Armazenamento do Azure em vez de montar o compartilhamento de arquivos usando SMB é que todas as
solicitações feitas por meio do Gerenciador de Armazenamento do Azure são realizadas com o uso da API REST de
arquivo. Você pode usar a API REST para criar, modificar e excluir arquivos e diretórios em clientes que não
possuam acesso ao SMB.
Criar um diretório
A adição de um diretório fornece uma estrutura hierárquica para gerenciar o compartilhamento de arquivos. Você
pode criar vários níveis no seu diretório. No entanto, você deve garantir a existência de todos os diretórios pai
antes de criar subdiretórios. Por exemplo, para o caminho myDirectory/mySubDirectory, você deve primeiro criar o
diretório myDirectory. Em seguida, você deve criar o subdiretório mySubDirectory.
1. Na guia para o compartilhamento de arquivos, no menu superior, selecione o botão Nova pasta . O painel
Criar novo diretório é exibido.
2. Para o nome do diretório, insira myDirectory, e selecione OK .

O diretório myDirectory será listado na guia para o compartilhamento de arquivos myshare.
Carregar um arquivo
Você pode carregar um arquivo do computador local para o novo diretório em seu compartilhamento de arquivos.
Você pode carregar uma pasta inteira ou um único arquivo.
1. No menu superior, selecione Carregar . Essa operação dá a opção de carregar um arquivo ou uma pasta.
2. Selecione Carregar arquivo e selecione um arquivo do computador local a ser carregado.
3. Em Carregar em um diretório , insira myDirectory e selecione Carregar .
Quando terminar, o arquivo é exibido em uma lista no painel myDirectory.
Baixar um arquivo
Para baixar uma cópia de um arquivo do seu compartilhamento de arquios, clique com o botão direito no arquivo
e, em seguida, selecione Baixar . Escolha onde deseja colocar o arquivo em seu computador local e selecione
Salvar .
O andamento do download é exibido no painel Atividades na parte inferior da janela.
Limpar os recursos
Você não pode usar o Gerenciador de Armazenamento para remover recursos. Para limpar com este guia de início
rápido, você pode usar o portal do Azure.
Próximas etapas
Tutorial: Estender servidores de arquivos do Windows
com a Sincronização de Arquivos do Azure
Este artigo demonstra as etapas básicas para estender a capacidade de armazenamento de um Windows Server
usando a Sincronização de Arquivos do Azure. Embora o tutorial apresente o Windows Server como uma VM
(máquina virtual) do Azure, você normalmente fará esse processo para os servidores locais. Encontre instruções
sobre como implantar a Sincronização de Arquivos do Azure em seu próprio ambiente no artigo Implantar a
Sincronização de Arquivos do Azure.
Implantar o Serviço de Sincronização de Armazenamento
Preparar Servidores Windows para uso com Sincronização de arquivos do Azure
Instalar o agente de Sincronização de Arquivo do Azure
Registrar o Windows Server no Serviço de Sincronização de Armazenamento
Criar um grupo de sincronização e um ponto de extremidade de nuvem
Criar um ponto de extremidade do servidor
Entrar no Azure
Prepare o seu ambiente

Para este tutorial, você precisará fazer o seguinte antes de implantar a Sincronização de Arquivos do Azure:
Criar uma conta de armazenamento do Microsoft Azure e um compartilhamento de arquivo
Configurar uma VM do Windows Server 2016 Datacenter
Preparar a VM do Windows Server para a Sincronização de Arquivos do Azure
Criar uma pasta e um arquivo .txt
No computador local, crie uma nova pasta chamada FilesToSync e adicione um arquivo de texto chamado
mytestdoc.txt. Você carregará esse arquivo no compartilhamento de arquivo mais adiante neste tutorial.
Para criar uma conta de armazenamento de uso geral v2 no portal do Azure, siga estas etapas:
1. No menu do portal do Azure, selecione Todos os ser viços . Na lista de recursos, digite Contas de
armazenamento . Quando você começa a digitar, a lista é filtrada com base em sua entrada. Selecione
Contas de Armazenamento .
7. Deixe esses campos definidos como seus valores padrão:
CAMPO VA LO R
Desempenho Standard
Replicação Armazenamento com redundância geográfica com acesso

de leitura (RA-GRS)
8. Se você planeja usar o Azure Data Lake Storage, escolha a guia Avançado e, em seguida, defina
Namespace hierárquico como Habilitado .
Para obter mais informações sobre tipos de contas de armazenamento e outras configurações da conta de
armazenamento, confira Visão geral da conta de armazenamento do Azure. Para saber mais sobre grupos de
recursos, confira Visão geral do Azure Resource Manager.
Depois de implantar uma conta de armazenamento do Azure, você criará um compartilhamento de arquivo.
1. No portal do Azure, selecione Ir para o recurso .
2. Selecione Arquivos no painel da conta de armazenamento.
3. Selecione + Compar tilhamento de Arquivo .
4. Nomeie o novo compartilhamento de arquivo afsfileshare. Insira "1" para a Cota e, em seguida, selecione
Criar . A cota pode ter um máximo de 5 TiB, mas você só precisa de 1 GB para este tutorial.
5. Selecione o novo compartilhamento de arquivo. Na localização do compartilhamento de arquivo, selecione

Carregar .
6. Procure a pasta FilesToSync em que você criou o arquivo .txt, selecione mytestdoc.txt e Carregar .
Nesta altura, você já criou uma conta de armazenamento e um compartilhamento de arquivo contendo um
arquivo. Em seguida, você implantará uma VM do Azure com o Windows Server 2016 Datacenter para representar
o servidor local neste tutorial.
Implantar uma VM e anexar um disco de dados
1. Acesse o portal do Azure e expanda o menu à esquerda. Escolha Criar um recurso no canto superior
esquerdo.
2. Na caixa de pesquisa acima da lista de recursos do Azure Marketplace , pesquise Windows Ser ver 2016
Datacenter e selecione-o nos resultados. Escolha Criar .
3. Acesse a guia Informações Básicas . Em Detalhes do projeto , selecione o grupo de recursos criado para
este tutorial.
4. Em Detalhes da instância , forneça um nome de VM. Por exemplo, use myVM.

5. Não altere as configurações padrão para Região , Opções de disponibilidade , Imagem e Tamanho .
6. Em Conta de administrador , forneça um Nome de usuário e uma Senha para a VM.
7. Em Regras de por ta de entrada , escolha Permitir por tas selecionadas e, em seguida, selecione RDP
(3389) e HTTP no menu suspenso.
8. Antes de criar a VM, você precisará criar um disco de dados.
a. Selecione Avançar :Discos .
b. Na guia Discos , em Opções de disco , mantenha os padrões.
c. Em DISCOS DE DADOS , selecione Criar e anexar um novo disco .
d. Use as configurações padrão, exceto Tamanho (GiB) , que poderá ser alterado para 1 GB para este
tutorial.
e. Selecione OK .
9. Selecione Examinar + criar .
Selecione o ícone Notificações para inspecionar o Progresso da implantação . A criação de uma VM
poderá levar alguns minutos para ser concluída.
11. Após a conclusão da implantação da VM, selecione Ir para o recurso .
Nesta altura, você já criou uma nova máquina virtual e anexou um disco de dados. Em seguida, você se conectará à
VM.
Conectar-se à sua VM
1. No portal do Azure, selecione Conectar na página de propriedades da máquina virtual.
2. Na página Conectar-se à máquina vir tual , mantenha as opções padrão para se conectar pelo endereço
IP na porta 3389. Selecione Baixar Arquivo RDP .
3. Abra o arquivo RDP baixado e selecione Conectar quando solicitado.
4. Na janela Segurança do Windows , selecione Mais opções e Usar uma conta diferente . Digite o nome
de usuário como localhost\nome de usuário, insira a senha criada para a máquina virtual e, em seguida,
selecione OK .
5. Você pode receber um aviso de certificado durante o processo de entrada. Selecione Sim ou Continuar
para criar a conexão.
Preparar o Windows Server
Para o servidor Windows Server 2016 Datacenter, desabilite a opção Configuração de Segurança Aprimorada do
Internet Explorer. Essa etapa é necessária apenas para o registro inicial do servidor. Você pode habilitá-la
novamente depois que o servidor foi registrado.
Na VM do Windows Server 2016 Datacenter, o Gerenciador do Servidor será aberto automaticamente. Se o
Gerenciador do Servidor não abrir por padrão, pesquise-o no menu Iniciar.
1. Em Gerenciador do Ser vidor , selecione Ser vidor Local .
2. No painel Propriedades , selecione o link de Configuração de Segurança Aprimorada do IE .
3. Na caixa de diálogo Configuração de Segurança Reforçada do Internet Explorer , selecione

Desativado para Administradores e Usuários .
Agora, você pode adicionar o disco de dados à VM.

Adicionar o disco de dados
1. Enquanto estiver na VM do Windows Ser ver 2016 Datacenter , selecione Ser viços de arquivos e
armazenamento > Volumes > Discos .
2. Clique com o botão direito do mouse no disco de 1 GB chamado Disco Vir tual Msft e selecione Novo
volume .
3. Conclua o assistente. Use as configurações padrão e anote a letra da unidade atribuída.
5. Selecione Fechar .
Nesta altura, você já colocou o disco online e criou um volume. Abra o Explorador de Arquivos na VM do
Windows Server para confirmar a presença do disco de dados recém-adicionado.
6. No Explorador de Arquivos na VM, expanda Este computador e abra a nova unidade. É a unidade F: neste
exemplo.
7. Clique com botão direito do mouse e selecione Nova > Pasta . Nomeie a pasta FilesToSync.
8. Abra a pasta FilesToSync .
9. Clique com botão direito do mouse e selecione Novo > Documento de Texto . Nomeie o arquivo de texto
MyTestFile.
10. Feche o Explorador de Arquivos e o Gerenciador do Ser vidor .

Baixar o módulo do Azure PowerShell
Em seguida, na VM do Windows Server 2016 Datacenter, instale o módulo do Azure PowerShell no servidor.
1. Na VM, abra uma janela do PowerShell com privilégios elevados.
2. Execute o comando a seguir:
Install-Module -Name Az
NOTE
Caso você tenha uma versão do NuGet que seja mais antiga do que 2.8.5.201, você deverá baixar e instalar a última
versão do NuGet.
Por padrão, a galeria do PowerShell não está configurada como um repositório confiável para o
PowerShellGet. Na primeira vez que usar a PSGallery, você verá o seguinte prompt:
Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its
InstallationPolicy value by running the Set-PSRepository cmdlet.
Are you sure you want to install the modules from 'PSGallery'?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"):
3. Responda Sim ou Sim para Todos para continuar com a instalação.

O módulo Az é um módulo de rollup para os cmdlets do Azure PowerShell. A instalação dele baixa todos os
módulos disponíveis do Azure Resource Manager e disponibiliza seus cmdlets para uso.
Nesta altura, você já configurou seu ambiente para o tutorial. Você está pronto para implantar o Serviço de
Sincronização de Armazenamento.
Implantar o serviço
Para implantar a Sincronização de Arquivos do Azure, primeiro coloque um recurso do Ser viço de
Sincronização de Armazenamento em um grupo de recursos da assinatura selecionada. O Serviço de
Sincronização de Armazenamento herda as permissões de acesso da assinatura e do grupo de recursos.
1. No portal do Azure, selecione Criar um recurso e, em seguida, pesquise Sincronização de Arquivos do
Azure .
2. Nos resultados da pesquisa, selecione Sincronização de Arquivos do Azure .
3. Selecione Criar para abrir a guia Implantar Sincronização de Armazenamento .
No novo painel que será aberta, insira as seguintes informações:
VA LO R DESC RIÇ Ã O
Nome Um nome exclusivo (por assinatura) para o Serviço de

Use afssyncservice02 para este tutorial.
Assinatura A assinatura do Azure usada para este tutorial.
Grupo de recursos O grupo de recursos que contém o Serviço de

Use afsresgroup101918 para este tutorial.
Localidade Leste dos EUA
4. Quando terminar, selecione Criar para implantar o Ser viço de Sincronização de Armazenamento .
5. Selecione a guia Notificações > Ir para o recurso .
Instalar o agente
O agente de Sincronização de arquivos do Azure é um pacote baixável que permite que o Windows Server seja
sincronizado com um compartilhamento de arquivos do Azure.
1. Na VM do Windows Ser ver 2016 Datacenter , abra o Internet Explorer .
2. Vá para o Centro de Download da Microsoft. Role a tela para baixo até a seção Agente de Sincronização
de Arquivos do Azure e selecione Baixar .
3. Marque a caixa de seleção StorageSyncAgent_V3_WS2016.EXE e selecione Avançar .
4. Selecione Permitir uma vez > Executar > Abrir .

5. Se você ainda não fez isso, feche a janela do PowerShell.
6. Aceite os padrões do Assistente de Instalação do Agente de Sincronização de Armazenamento .
7. Selecione Instalar .
8. Selecione Concluir .
Você implantou o Serviço de Sincronização do Azure e instalou o agente na VM do Windows Server 2016
Datacenter. Agora você precisa registrar a VM no Serviço de Sincronização de Armazenamento.
Registrar o Windows Server

O registro do Windows Server em um Serviço de Sincronização de Armazenamento estabelece uma relação de
confiança entre o servidor (ou o cluster) e o Serviço de Sincronização de Armazenamento. Um servidor só pode ser
registrado em um único Serviço de Sincronização de Armazenamento. Ele pode ser sincronizado com outros
servidores e compartilhamentos de arquivos do Azure associados a esse Serviço de Sincronização de
Armazenamento.
A interface do usuário do Registro do Servidor deverá ser aberta automaticamente após a instalação do agente de
Sincronização de Arquivos do Azure. Caso contrário, abra-a manualmente na localização do arquivo:
C:\Program Files\Azure\StorageSyncAgent\ServerRegistration.exe.
1. Quando a interface do usuário do Registro do Servidor for aberta na VM, selecione OK .

2. Selecione Entrar para começar.
3. Entre com suas credenciais de conta do Azure e selecione Entrar .
4. Forneça as seguintes informações:
Valor Descrição
Assinatura do Azure A assinatura que contém o Serviço de Sincronização de

Armazenamento para este tutorial.
Grupo de recursos O grupo de recursos que contém o Serviço de
Sincronização de Armazenamento. Use afsresgroup101918
para este tutorial.
Ser viço de Sincronização de Armazenamento O nome do Serviço de Sincronização de Armazenamento.

Use afssyncservice02 para este tutorial.
5. Selecione Registrar para concluir o registro do servidor.

6. Como parte do processo de registro, você deverá entrar novamente. Entre e selecione Avançar .
7. Selecione OK .
Criar um Grupo de Sincronização

Um grupo de sincronização define a topologia de sincronização para um conjunto de arquivos. Um grupo de
sincronização precisa conter um ponto de extremidade da nuvem, que representa um compartilhamento de
arquivo do Azure. Um grupo de sincronização também precisa conter um ou mais pontos de extremidade de
servidor. Um ponto de extremidade do servidor representa um caminho em um servidor registrado. Para criar um
grupo de sincronização:
1. No portal do Azure, selecione + Grupo de sincronização no Serviço de Sincronização de
Armazenamento. Use afssyncservice02 para este tutorial.
2. Insira as seguintes informações para criar um grupo de sincronização com um ponto de extremidade da
nuvem:
VA LO R DESC RIÇ Ã O
Nome do grupo de sincronização Esse nome deve ser exclusivo dentro do Serviço de
Sincronização de Armazenamento, mas pode ser qualquer
nome lógico para você. Use afssyncgroup para este
tutorial.
Assinatura A assinatura onde você implantou o Serviço de

Sincronização de Armazenamento para este tutorial.
Conta de armazenamento Escolha Selecionar conta de armazenamento . No

painel exibido, selecione a conta de armazenamento que
contém o compartilhamento de arquivo do Azure criado.
Use afsstoracct101918 para este tutorial.
Compar tilhamento de arquivos do Azure O nome do compartilhamento de arquivo do Azure criado.

Use afsfileshare para este tutorial.
Se você selecionar o grupo de sincronização, verá que possui agora um ponto de extremidade de nuvem .
Adicionar um ponto de extremidade do servidor

Um ponto de extremidade de servidor representa uma localização específica em um servidor registrado. Por
exemplo, uma pasta em um volume do servidor. Para adicionar um ponto de extremidade de servidor:
1. Selecione o grupo de sincronização recém-criado e, em seguida, Adicionar ponto de extremidade de
ser vidor .
2. No painel Adicionar ponto de extremidade de ser vidor , insira as seguintes informações para criar um
ponto de extremidade de servidor:
Valor Descrição
Ser vidor registrado O nome do servidor criado. Use afsvm101918 para este
tutorial.
Caminho O caminho do Windows Server para a unidade criada. Use

f:\filestosync neste tutorial.
Disposição em camadas de nuvem Deixe desabilitada para este tutorial.
Espaço Livre do Volume Deixe em branco para este tutorial.
Os arquivos agora estão sincronizados entre o compartilhamento de arquivos do Azure e o Windows Server.
Limpar os recursos
Próximas etapas
Neste tutorial, você aprendeu as etapas básicas para estender a capacidade de armazenamento de um Windows
Server usando a Sincronização de Arquivos do Azure. Para obter uma visão mais completa do planejamento de
uma implantação da Sincronização de Arquivos do Azure, confira:
Planejar a implantação da Sincronização de Arquivos do Azure
Os arquivos do Azure podem ser implantados de duas maneiras principais: montando diretamente os
compartilhamentos de arquivos do Azure sem servidor ou armazenando em cache os compartilhamentos de
arquivos do Azure no local usando sincronização de arquivos do Azure. A opção de implantação escolhida altera
as coisas que você precisa considerar ao planejar sua implantação.
Montagem direta de um compar tilhamento de arquivos do Azure : como os arquivos do Azure
fornecem acesso SMB, você pode montar compartilhamentos de arquivos do Azure localmente ou na
nuvem usando o cliente SMB padrão disponível no Windows, no MacOS e no Linux. Como os
compartilhamentos de arquivos do Azure são sem servidor, a implantação para cenários de produção não
requer o gerenciamento de um servidor de arquivos ou dispositivo NAS. Isso significa que você não
precisa aplicar patches de software nem trocar discos físicos.
Armazenar em cache o compar tilhamento de arquivos do Azure local com o sincronização de
arquivos do Azure : sincronização de arquivos do Azure permite centralizar os compartilhamentos de
arquivos da sua organização em arquivos do Azure, mantendo, ao mesmo tempo, a flexibilidade, o
desempenho e a compatibilidade de um servidor de arquivos local. Sincronização de Arquivos do Azure
transforma um Windows Server local (ou de nuvem) em um cache rápido do seu compartilhamento de
arquivos do Azure.
Este artigo aborda principalmente as considerações de implantação para implantar um compartilhamento de
arquivos do Azure para ser montado diretamente por um cliente local ou em nuvem. Para planejar uma
implantação de Sincronização de Arquivos do Azure, consulte planejando uma implantação de sincronização de
arquivos do Azure.
Conceitos de gerenciamento
Os compartilhamentos de arquivos do Azure são implantados em contas de armazenamento, que são objetos de
nível superior que representam um pool de armazenamento compartilhado. Esse pool de armazenamento pode
ser usado para implantar vários compartilhamentos de arquivos, bem como outros recursos de armazenamento,
como contêineres de BLOB, filas ou tabelas. Todos os recursos de armazenamento implantados em uma conta de
armazenamento compartilham os limites que se aplicam a essa conta de armazenamento. Para ver os limites
atuais de uma conta de armazenamento, consulte metas de desempenho e escalabilidade de arquivos do Azure.
Há dois tipos principais de contas de armazenamento que serão usadas para implantações de arquivos do Azure:
Contas de armazenamento de uso geral versão 2 (GPv2) : as contas de armazenamento do GPv2
permitem que você implante compartilhamentos de arquivos do Azure em hardware padrão/baseado em
disco rígido (baseado em HDD). Além de armazenar compartilhamentos de arquivos do Azure, as contas de
armazenamento GPv2 podem armazenar outros recursos de armazenamento, como contêineres de BLOB,
filas ou tabelas.
Contas de armazenamento de armazenamento em FileStorage: as contas de armazenamento de
armazenamento de arquivo permitem que você implante compartilhamentos de arquivos do Azure em
hardware Premium/de estado sólido baseado em disco (SSD). Contas de armazenamento de arquivo só
podem ser usadas para armazenar compartilhamentos de arquivos do Azure; nenhum outro recurso de
armazenamento (contêineres de BLOB, filas, tabelas, etc.) pode ser implantado em uma conta de
armazenamento de File.
Há vários outros tipos de conta de armazenamento que podem ser incluídos no portal do Azure, no PowerShell
ou na CLI. Dois tipos de conta de armazenamento, contas de armazenamento BlockBlobStorage e BlobStorage,
não podem conter compartilhamentos de arquivos do Azure. Os outros dois tipos de conta de armazenamento
que você pode ver são GPv1 (uso geral versão 1) e contas de armazenamento clássicas, ambos podem conter
compartilhamentos de arquivos do Azure. Embora as contas de armazenamento GPv1 e clássico possam conter
compartilhamentos de arquivos do Azure, a maioria dos novos recursos dos arquivos do Azure está disponível
apenas nas contas de armazenamento GPv2 e FileStorage. Portanto, recomendamos que você use apenas contas
de armazenamento GPv2 e FileStorage para novas implantações e atualize as contas de armazenamento GPv1 e
clássico se elas já existirem em seu ambiente.
Ao implantar compartilhamentos de arquivos do Azure em contas de armazenamento, recomendamos:
Implantar somente compartilhamentos de arquivos do Azure em contas de armazenamento com outros
compartilhamentos de arquivos do Azure. Embora as contas de armazenamento GPv2 permitam que
você tenha contas de armazenamento de finalidade mista, como os recursos de armazenamento como
compartilhamentos de arquivos do Azure e contêineres de blob compartilham os limites da conta de
armazenamento, misturar recursos em conjunto pode dificultar a solução de problemas de desempenho
posteriormente.
Prestar atenção às limitações de IOPS de uma conta de armazenamento ao implantar compartilhamentos
de arquivos do Azure. O ideal é que você mapeie os compartilhamentos de arquivos 1:1 com contas de
armazenamento. no entanto, isso nem sempre pode ser possível devido a vários limites e restrições, tanto
da sua organização quanto do Azure. Quando não for possível ter apenas um compartilhamento de
arquivos implantado em uma conta de armazenamento, considere quais compartilhamentos serão
altamente ativos e quais compartilhamentos serão menos ativas para garantir que os compartilhamentos
de arquivos mais interessantes não sejam colocados na mesma conta de armazenamento.
Implante somente contas GPv2 e FileStorage e atualize GPv1 e contas de armazenamento clássico quando
encontrá-las em seu ambiente.
Identidade
Para acessar um compartilhamento de arquivos do Azure, o usuário do compartilhamento de arquivos deve ser
autenticado e ter autorização para acessar o compartilhamento. Isso é feito com base na identidade do usuário
que está acessando o compartilhamento de arquivos. Os arquivos do Azure integram-se com três provedores de
identidade principais:
Active Director y Domain Ser vices local (AD DS ou AD DS local) (visualização): as contas de
armazenamento do Azure podem ser ingressadas no domínio para um Active Directory Domain Services de
Propriedade do cliente, assim como um servidor de arquivos do Windows Server ou um dispositivo nas.
Você pode implantar um controlador de domínio local, em uma VM do Azure ou até mesmo como uma VM
em outro provedor de nuvem; Os arquivos do Azure são independentes em que o controlador de domínio
está hospedado. Quando uma conta de armazenamento está ingressada no domínio, o usuário final pode
montar um compartilhamento de arquivos com a conta de usuário com a qual ele entrou em seu PC. A
autenticação baseada em AD usa o protocolo de autenticação Kerberos.
Azure Active Director y Domain Ser vices (azure AD DS) : o Azure AD DS fornece um controlador de
domínio gerenciado pela Microsoft que pode ser usado para recursos do Azure. Domínio ingressando em sua
conta de armazenamento no Azure AD DS fornece benefícios semelhantes ao ingresso no domínio para um
Active Directory de Propriedade do cliente. Essa opção de implantação é mais útil para cenários de elevação e
deslocamento de aplicativos que exigem permissões baseadas no AD. Como o Azure AD DS fornece
autenticação baseada em AD, essa opção também usa o protocolo de autenticação Kerberos.
Chave de conta de armazenamento do Azure : compartilhamentos de arquivos do Azure também
podem ser montados com uma chave de conta de armazenamento do Azure. Para montar um
compartilhamento de arquivos dessa forma, o nome da conta de armazenamento é usado como o nome de
usuário e a chave da conta de armazenamento é usada como uma senha. Usar a chave de conta de
armazenamento para montar o compartilhamento de arquivos do Azure é efetivamente uma operação de
administrador, pois o compartilhamento de arquivos montado terá permissões completas para todos os
arquivos e pastas no compartilhamento, mesmo que eles tenham ACLs. Ao usar a chave da conta de
armazenamento para montar por SMB, o protocolo de autenticação NTLMv2 é usado.
Para os clientes que migram de servidores de arquivos locais ou para criar novos compartilhamentos de
arquivos em arquivos do Azure destinados a se comportarem como servidores de arquivos do Windows ou
dispositivos NAS, o domínio que ingressa em sua conta de armazenamento para Active Director y de
Propriedade do cliente é a opção recomendada. Para saber mais sobre o ingresso no domínio de sua conta de
armazenamento para um Active Directory de Propriedade do cliente, consulte visão geral dos arquivos do Azure
Active Directory.
Se você pretende usar a chave de conta de armazenamento para acessar os compartilhamentos de arquivos do
Azure, recomendamos o uso de pontos de extremidade de serviço, conforme descrito na seção rede .
Rede
Os compartilhamentos de arquivos do Azure são acessíveis de qualquer lugar pelo ponto de extremidade
público da conta de armazenamento. Isso significa que as solicitações autenticadas, como solicitações
autorizadas pela identidade de logon de um usuário, podem se originar de forma segura de dentro ou fora do
Azure. Em muitos ambientes de clientes, uma montagem inicial do compartilhamento de arquivos do Azure em
sua estação de trabalho local falhará, embora as montagens de VMs do Azure tenham êxito. O motivo disso é
que muitas organizações e provedores de serviços de Internet (ISPs) bloqueiam a porta que o SMB usa para se
comunicar, porta 445. Para ver o resumo de ISPs que permitem ou proíbem o acesso a partir da porta 445, vá
para TechNet.
Para desbloquear o acesso ao compartilhamento de arquivos do Azure, você tem duas opções principais:
Desbloqueie a porta 445 da rede local da sua organização. Os compartilhamentos de arquivos do Azure
só podem ser acessados externamente por meio do ponto de extremidade público usando protocolos
seguros da Internet, como SMB 3,0 e a API filerest. Essa é a maneira mais fácil de acessar o
compartilhamento de arquivos do Azure do local, já que ele não requer configuração avançada de rede
além de alterar as regras de porta de saída de sua organização. no entanto, recomendamos que você
remova as versões herdadas e preteridas do protocolo SMB, ou seja, SMB 1,0. Para saber como fazer isso,
consulte protegendo o Windows/Windows Server e protegendo o Linux.
Acesse compartilhamentos de arquivos do Azure por meio de uma conexão de ExpressRoute ou VPN.
Quando você acessa o compartilhamento de arquivos do Azure por meio de um túnel de rede, é possível
montar o compartilhamento de arquivos do Azure como um compartilhamento de arquivos local, pois o
tráfego SMB não atravessa o limite organizacional.
Embora, de uma perspectiva técnica, seja consideravelmente mais fácil montar os compartilhamentos de
arquivos do Azure por meio do ponto de extremidade público, esperamos que a maioria dos clientes opte por
montar seus compartilhamentos de arquivos do Azure por meio de uma conexão de ExpressRoute ou VPN. Para
fazer isso, será necessário configurar o seguinte para o seu ambiente:
O túnel de rede usando o ExpressRoute, site a site ou VPN ponto a site : o túnel para uma rede
virtual permite acessar compartilhamentos de arquivos do Azure do local, mesmo se a porta 445 estiver
bloqueada.
Pontos de extremidade privados : pontos de extremidade privados dão à sua conta de armazenamento
um endereço IP dedicado de dentro do espaço de endereço da rede virtual. Isso habilita o túnel de rede sem a
necessidade de abrir redes locais até todos os intervalos de endereços IP pertencentes aos clusters de
Encaminhamento de DNS : configure seu DNS local para resolver o nome da sua conta de armazenamento
(ou seja storageaccount.file.core.windows.net , para as regiões de nuvem pública) para resolver o endereço
IP dos seus pontos de extremidade privados.
Para planejar a rede associada à implantação de um compartilhamento de arquivos do Azure, consulte
considerações de rede de arquivos do Azure.
Criptografia
Os arquivos do Azure dão suporte a dois tipos diferentes de criptografia: criptografia em trânsito, relacionada à
criptografia usada ao montar/acessar o compartilhamento de arquivos do Azure e criptografia em repouso, que
se relaciona com o modo como os dados são criptografados quando armazenados em disco.
Criptografia em trânsito
Por padrão, todas as contas de armazenamento do Azure têm criptografia em trânsito habilitada. Isso significa
que quando você montar um compartilhamento de arquivo via SMB ou acessá-lo por meio do protocolo
FileREST (por exemplo, por meio do portal do Azure, do PowerShell/CLI ou de SDKs do Azure), os Arquivos do
Azure só permitirão a conexão se for feita com o SMB 3.0 e com criptografia ou HTTPS. Os clientes que não são
compatíveis com SMB 3.0 ou os clientes que são compatíveis com SMB 3.0, mas não com a criptografia SMB,
não poderão montar o compartilhamento de arquivo do Azure se a criptografia em trânsito estiver habilitada.
Para obter mais informações sobre quais sistemas operacionais são compatíveis com o SMB 3.0 com
criptografia, consulte nossa documentação detalhada para Windows, macOS e Linux. Todas as versões atuais do
PowerShell, da CLI e dos SDKs são compatíveis com HTTPS.
Você pode desabilitar a criptografia em trânsito para uma conta de armazenamento do Azure. Quando a
criptografia estiver desabilitada, os arquivos do Azure também permitirão SMB 2,1, SMB 3,0 sem criptografia e
chamadas de API filerest não criptografadas via HTTP. O principal motivo para desabilitar a criptografia em
trânsito é dar suporte a um aplicativo herdado que deve ser executado em um sistema operacional mais antigo,
como o Windows Server 2008 R2 ou a distribuição mais antiga do Linux. Os Arquivos do Azure só permitem
conexões SMB 2.1 na mesma região do Azure que o compartilhamento de arquivo do Azure. Um cliente SMB 2.1
fora da região do Azure do compartilhamento de arquivo do Azure, como local ou em uma região diferente do
Azure, não será capaz de acessar o compartilhamento de arquivo.
É altamente recomendável garantir que a criptografia de dados em trânsito esteja habilitada.
Para obter mais informações sobre criptografia em trânsito, consulte Exigir transferência segura no
Criptografia em repouso
Todos os dados armazenados nos arquivos do Azure são criptografados em repouso usando a SSE (criptografia
do serviço de armazenamento) do Azure. A criptografia do serviço de armazenamento funciona de forma
semelhante ao BitLocker no Windows: os dados são criptografados abaixo do nível do sistema de arquivos.
Como os dados são criptografados abaixo do sistema de arquivos do compartilhamento de arquivos do Azure,
pois eles são codificados no disco, você não precisa ter acesso à chave subjacente no cliente para ler ou gravar
Por padrão, os dados armazenados nos arquivos do Azure são criptografados com chaves gerenciadas pela
Microsoft. Com as chaves gerenciadas pela Microsoft, a Microsoft mantém as chaves para
criptografar/descriptografar os dados e é responsável por girá-los regularmente. Você também pode optar por
gerenciar suas próprias chaves, o que lhe dá controle sobre o processo de rotação. Se você optar por
criptografar seus compartilhamentos de arquivos com chaves gerenciadas pelo cliente, os arquivos do Azure
serão autorizados a acessar suas chaves para atender a solicitações de leitura e gravação de seus clientes. Com
as chaves gerenciadas pelo cliente, você pode revogar essa autorização a qualquer momento, mas isso significa
que o compartilhamento de arquivos do Azure não estará mais acessível via SMB ou pela API filerest.
Os arquivos do Azure usam o mesmo esquema de criptografia que os outros serviços de armazenamento do
Azure, como o armazenamento de BLOBs do Azure. Para saber mais sobre a SSE (criptografia do serviço de
armazenamento) do Azure, confira criptografia de armazenamento do Azure para dados em repouso.
Camadas de armazenamento
Os arquivos do Azure oferecem duas camadas diferentes de armazenamento, Premium e Standard, para permitir
que você personalize seus compartilhamentos para os requisitos de desempenho e preço do seu cenário:
Compar tilhamentos de arquivos Premium : os compartilhamentos de arquivos Premium são apoiados
por SSDs (unidades de estado sólido) e implantados no tipo de conta de armazenamento de
armazenamento de arquivo. Os compartilhamentos de arquivos Premium fornecem alto desempenho e
baixa latência consistentes em milissegundos de dígito único para a maioria das operações de e/s, para
cargas de trabalho com uso intensivo de e/s. Isso os torna adequados para uma ampla variedade de cargas
de trabalho, como bancos de dados, Hospedagem de site e ambientes de desenvolvimento. Os
compartilhamentos de arquivos Premium estão disponíveis em um modelo de cobrança provisionado. Para
obter mais informações sobre o modelo de cobrança provisionado para compartilhamentos de arquivos
premium, consulte noções básicas sobre provisionamento de compartilhamentos de arquivos Premium.
Compar tilhamentos de arquivos padrão : os compartilhamentos de arquivos padrão são apoiados por
unidades de disco rígido (HDDs) e são implantados no tipo de conta de armazenamento GPv2 (versão
de uso geral 2) . Os compartilhamentos de arquivos padrão fornecem um desempenho confiável para
cargas de trabalho de e/s que são menos sensíveis à variabilidade de desempenho, como compartilhamentos
de arquivos de uso geral e ambientes de desenvolvimento/teste. Os compartilhamentos de arquivos padrão
estão disponíveis apenas em um modelo de cobrança pago conforme o uso.
Em geral, os recursos de arquivos do Azure e a interoperabilidade com outros serviços são os mesmos entre
compartilhamentos de arquivos Premium e compartilhamentos de arquivos padrão, no entanto, há algumas
diferenças importantes:
Modelo de cobrança
Os compartilhamentos de arquivos Premium são cobrados usando um modelo de cobrança
provisionado, o que significa que você paga pela quantidade de armazenamento que você provisiona,
em vez da quantidade de armazenamento que realmente pede.
Os compartilhamentos de arquivos padrão são cobrados usando um modelo pago conforme o uso,
que inclui um custo base de armazenamento para a quantidade de armazenamento que você está
consumindo e, em seguida, um custo de transação adicional com base em como você usa o
compartilhamento. Com compartilhamentos de arquivos padrão, sua fatura aumentará se você usar
(leitura/gravação/montagem) do compartilhamento de arquivos do Azure mais.
Opções de redundância
Os compartilhamentos de arquivos Premium só estão disponíveis para armazenamento com
redundância local (LRS) e com redundância de zona (ZRS).
Os compartilhamentos de arquivos padrão estão disponíveis para o armazenamento localmente
redundante, com redundância de zona, com redundância geográfica (GRS) e com redundância de zona
geográfica (GZRS).
Tamanho máximo do compar tilhamento de arquivos
Os compartilhamentos de arquivos Premium podem ser provisionados para até 100 TiB sem nenhum
trabalho adicional.
Por padrão, os compartilhamentos de arquivos padrão podem abranger até 5 TiB, embora o limite de
compartilhamento possa ser aumentado para 100 TiB, optando pelo sinalizador de recurso de conta
de armazenamento de compartilhamento de arquivo grande . Os compartilhamentos de arquivos
padrão podem abranger até 100 TiB para contas de armazenamento com redundância local ou de
zona. Para obter mais informações sobre como aumentar os tamanhos de compartilhamento de
arquivos, consulte habilitar e criar compartilhamentos de arquivos grandes.
Disponibilidade regional
Os compartilhamentos de arquivos Premium não estão disponíveis em todas as regiões, e o suporte
com redundância de zona está disponível em um subconjunto menor de regiões. Para descobrir se os
compartilhamentos de arquivos premium estão disponíveis atualmente em sua região, confira a
página produtos disponíveis por região para o Azure. Para descobrir quais regiões dão suporte a ZRS,
confira suporte da zona de disponibilidade do Azure por região. Para nos ajudar a priorizar novas
regiões e recursos da camada Premium, preencha esta pesquisa.
Os compartilhamentos de arquivos padrão estão disponíveis em todas as regiões do Azure.
O AKS (serviço kubernetes do Azure) dá suporte a compartilhamentos de arquivos Premium na versão 1,13 e
posterior.
Depois que um compartilhamento de arquivos é criado como um compartilhamento de arquivos Premium ou
Standard, não é possível convertê-lo automaticamente para a outra camada. Se desejar alternar para a outra
camada, você deverá criar um novo compartilhamento de arquivos nessa camada e copiar manualmente os
dados do compartilhamento original para o novo compartilhamento que você criou. É recomendável robocopy
usar o para rsync Windows ou para MacOS e Linux para executar essa cópia.
Noções básicas sobre provisionamento para compartilhamentos de arquivos Premium
Os compartilhamentos de arquivos Premium são provisionados com base em uma taxa de
GiB/IOPS/transferência fixa. Para cada GiB provisionado, o compartilhamento emitirá um IOPS e uma taxa de
transferência de 0,1 MiB/s até os limites máximos por compartilhamento. O provisionamento mínimo permitido
é de 100 GiB, com um IOPS e uma taxa de transferência mínimos.
Com base no melhor esforço, todos os compartilhamentos poderão acumular até três IOPS por GiB de
armazenamento provisionado por 60 minutos ou mais, dependendo do tamanho do compartilhamento. Os
novos compartilhamentos começam com o crédito de intermitência completa com base na capacidade
provisionada.
Os compartilhamentos devem ser provisionados em incrementos de 1 GiB. O tamanho mínimo é 100 GiB, o
próximo tamanho é 101 GiB e assim por diante.
TIP
IOPS de linha de base = 1 * GiB provisionado. (Até um máximo de 100.000 IOPS).
Limite de intermitência = 3 * IOPS de linha de base. (Até um máximo de 100.000 IOPS).
taxa de egresso = 60 MiB/s + 0, 6 * provisionamento GiB
taxa de entrada = 40 MiB/s + 0, 4 * provisionamento GiB
O tamanho do compartilhamento provisionado é especificado por cota de compartilhamento. A cota de

compartilhamento pode ser aumentada a qualquer momento, mas só pode ser reduzida após 24 horas desde o
último aumento. Depois de aguardar 24 horas sem um aumento de cota, você pode diminuir a cota de
compartilhamento quantas vezes desejar, até aumentá-la novamente. As alterações de escala de taxa de
transferência/IOPS entrarão em vigor em alguns minutos após a alteração do tamanho.
É possível diminuir o tamanho do compartilhamento provisionado abaixo do GiB usado. Se você fizer isso, não
perderá dados, mas ainda será cobrado pelo tamanho usado e receberá o desempenho (IOPS de linha de base,
taxa de transferência e IOPS de intermitência) do compartilhamento provisionado, não o tamanho usado.
A tabela a seguir ilustra alguns exemplos dessas fórmulas para os tamanhos de compartilhamento
provisionados:
IO P S DE L IN H A DE IO P S DE
C A PA C IDA DE ( GIB ) B A SE IN T ERM IT ÊN C IA SA ÍDA ( M IB / S) EN T RA DA ( M IB / S)
100 100 Até 300 66 44
500 500 Até 1.500 90 60
1.024 1.024 Até 3.072 122 81
5.120 5.120 Até 15.360 368 245
10.240 10.240 Até 30.720 675 450
33.792 33.792 Até 100.000 2.088 1.392
51.200 51.200 Até 100.000 3.132 2.088
102.400 100.000 Até 100.000 6.204 4.136
NOTE
O desempenho dos compartilhamentos de arquivos está sujeito aos limites de rede da máquina, largura de banda de rede
disponível, tamanhos de e/s, paralelismo, entre muitos outros fatores. Por exemplo, com base no teste interno com 8
tamanhos de e/s de leitura/gravação de KiB, uma única máquina virtual do Windows, F16s_v2 padrão, conectada ao
compartilhamento de arquivos Premium em SMB poderia alcançar IOPS de leitura de 20 mil e IOPS de gravação de
15.000. Com tamanhos de e/s de leitura/gravação de MiB 512, a mesma VM pode atingir a saída de 1,1 GiB/s e a taxa de
transferência de entrada de 370 MiB/s. Para obter a escala de desempenho máxima, distribua a carga entre várias VMs.
Consulte o Guia de solução de problemas para alguns problemas comuns de desempenho e soluções alternativas.
Bursting
Os compartilhamentos de arquivos Premium podem aumentar seu IOPS até um fator de três. A intermitência é
automatizada e opera com base em um sistema de crédito. A intermitência funciona em uma base de melhor
esforço e o limite de intermitência não é uma garantia, os compartilhamentos de arquivos podem aumentar até
o limite.
Os créditos se acumulam em um Bucket de intermitência sempre que o tráfego para o compartilhamento de
arquivos está abaixo do IOPS de linha de base. Por exemplo, um compartilhamento de GiB 100 tem 100 IOPS de
linha de base. Se o tráfego real no compartilhamento era de 40 IOPS para um intervalo específico de 1 segundo,
o IOPS de 60 não utilizado será creditado em um Bucket de intermitência. Esses créditos serão então usados
mais tarde, quando as operações excederem o IOPs de linha de base.
TIP
Tamanho do Bucket de intermitência = IOPS de linha de base * 2 * 3600.
Sempre que um compartilhamento exceder o IOPS de linha de base e tiver créditos em um Bucket de
intermitência, ele será rompido. Os compartilhamentos podem continuar a aumentar, contanto que os créditos
permaneçam, embora os compartilhamentos menores que 50 TiB permanecerão apenas no limite de
intermitência de até uma hora. Compartilhamentos maiores que 50 TiB podem, tecnicamente, exceder esse
limite de hora, até duas horas, mas isso se baseia no número de créditos de intermitência acumulados. Cada e/s
além do IOPS de linha de base consome um crédito e quando todos os créditos são consumidos, o
compartilhamento retornaria ao IOPS de linha de base
Os créditos de compartilhamento têm três Estados:
A acumulação, quando o compartilhamento de arquivos está usando menos do que o IOPS de linha de base.
Recusando, quando o compartilhamento de arquivos estiver intermitente.
Constante restante, quando não há créditos ou IOPS de linha de base em uso.
Novos compartilhamentos de arquivos começam com o número total de créditos em seu Bucket de
intermitência. Os créditos de intermitência não serão acumulados se o IOPS de compartilhamento cair abaixo do
IOPS de linha de base devido à limitação pelo servidor.
Habilitar compartilhamentos de arquivos padrão para abranger até 100 TiB
compartilhamento possa ser aumentado para 100 TiB. Para fazer isso, o recurso de compartilhamento de
arquivos grandes deve ser habilitado no nível da conta de armazenamento. As contas de armazenamento
Premium (contas de armazenamento dearmazenamento de arquivo) não têm o sinalizador de recurso de
compartilhamento de arquivos grandes, já que todos os compartilhamentos de arquivos premium estão
habilitados para provisionamento na capacidade total de 100 Tib.
Você só pode habilitar compartilhamentos de arquivos grandes em contas de armazenamento padrão com
redundância local ou de zona. Depois de habilitar o sinalizador de recurso de compartilhamento de arquivos
grandes, não é possível alterar o nível de redundância para armazenamento com redundância geográfica ou
com redundância geográfica.
Para habilitar compartilhamentos de arquivos grandes em uma conta de armazenamento existente, navegue até
o modo de exibição de configuração no Sumário da conta de armazenamento e alterne a opção de tentativa de
compartilhamento de arquivo grande para habilitado:
Você também pode habilitar compartilhamentos de arquivos 100 Set-AzStorageAccount Tib por meio do
az storage account update cmdlet do PowerShell e o comando CLI do Azure. Para obter instruções detalhadas
sobre como habilitar compartilhamentos de arquivos grandes, consulte habilitar e criar compartilhamentos de
arquivos grandes.
Para saber mais sobre como criar compartilhamentos de arquivos em novas contas de armazenamento, consulte
criando um compartilhamento de arquivos do Azure.
Limitações
Compartilhamentos de arquivos padrão com capacidade de 100 TiB têm certas limitações.
Atualmente, há suporte apenas para contas de armazenamento com redundância local (LRS) e ZRS
(armazenamento com redundância de zona).
Depois de habilitar grandes compartilhamentos de arquivos, você não pode converter contas de
armazenamento para GRS (armazenamento com redundância geográfica) ou contas de GZRS
(armazenamento com redundância de zona geográfica).
Depois de habilitar grandes compartilhamentos de arquivos, você não pode desabilitá-lo.
Redundância
Para proteger os dados em seus compartilhamentos de arquivos do Azure contra perda ou corrupção de dados,
todos os compartilhamentos de arquivos do Azure armazenam várias cópias de cada arquivo à medida que são
gravadas. Dependendo dos requisitos de sua carga de trabalho, você pode selecionar graus adicionais de
redundância. Atualmente, os arquivos do Azure dão suporte às seguintes opções de redundância de dados:
Localmente redundante : o armazenamento com redundância local, geralmente conhecido como lRS,
significa que cada arquivo é armazenado três vezes em um cluster de armazenamento do Azure. Isso protege
contra perda de dados devido a falhas de hardware, como uma unidade de disco defeituosa.
Com redundância de zona : o armazenamento com redundância de zona, geralmente referido como ZRS,
significa que cada arquivo é armazenado três vezes em três clusters de armazenamento do Azure distintos.
Os três diferentes clusters de armazenamento do Azure armazenam o arquivo três vezes, assim como com o
armazenamento com redundância local, e são fisicamente isolados em diferentes zonas de disponibilidadedo
Azure. As zonas de disponibilidade são locais físicos exclusivos em uma região do Azure. Cada zona é
composta por um ou mais datacenters equipados com energia, resfriamento e rede independentes. Uma
gravação no armazenamento não é aceita até que seja gravada nos clusters de armazenamento em todas as
três zonas de disponibilidade.
Com redundância geográfica : o armazenamento com redundância geográfica, geralmente conhecido
como grs, é como um armazenamento com redundância local, no qual um arquivo é armazenado três vezes
em um cluster de armazenamento do Azure na região primária. Em seguida, todas as gravações são
replicadas de forma assíncrona para uma região secundária definida pela Microsoft. O armazenamento com
redundância geográfica fornece seis cópias de seus dados espalhados entre duas regiões do Azure. No caso
de um grande desastre, como a perda permanente de uma região do Azure devido a um desastre natural ou
a outro evento semelhante, a Microsoft executará um failover para que o secundário em vigor se torne o
primário, atendendo a todas as operações. Como a replicação entre as regiões primária e secundária é
assíncrona, no caso de um desastre principal, os dados ainda não replicados para a região secundária serão
perdidos. Você também pode executar um failover manual de uma conta de armazenamento com
redundância geográfica.
Com redundância de zona geográfica : o armazenamento com redundância de zona geográfica,
geralmente conhecido como GZRS, é como o armazenamento com redundância de zona, no qual um arquivo
é armazenado nove vezes em três clusters de armazenamento distintos na região primária. Em seguida, todas
as gravações são replicadas de forma assíncrona para uma região secundária definida pela Microsoft. O
processo de failover para armazenamento com redundância de zona geográfica funciona da mesma forma
que o armazenamento com redundância geográfica.
Os compartilhamentos de arquivos padrão do Azure dão suporte a todos os quatro tipos de redundância,
enquanto os compartilhamentos de arquivos premium do Azure só oferecem suporte a armazenamento com
redundância local
As contas de armazenamento de uso geral versão 2 (GPv2) fornecem duas opções adicionais de redundância
que não têm suporte nos arquivos do Azure: Leia armazenamento com redundância geográfica acessível,
geralmente conhecido como RA-GRS e leia armazenamento com redundância de zona geográfica acessível,
geralmente conhecido como RA-GZRS. Você pode provisionar compartilhamentos de arquivos do Azure em
contas de armazenamento com essas opções definidas, no entanto, os arquivos do Azure não dão suporte à
leitura da região secundária. Os compartilhamentos de arquivos do Azure implantados em contas de
armazenamento com redundância de zona geográfica ou geográfica acessível serão cobrados como
armazenamento com redundância geográfica ou com redundância de zona geográfica, respectivamente.
Migração
Em muitos casos, você não estará estabelecendo um novo compartilhamento de arquivos de rede para sua
organização, mas migrará um compartilhamento de arquivos existente de um servidor de arquivos local ou de
um dispositivo NAS para os arquivos do Azure. Há muitas ferramentas, fornecidas pela Microsoft e por terceiros,
para fazer uma migração para um compartilhamento de arquivos, mas elas podem ser divididas
aproximadamente em duas categorias:
Ferramentas que mantêm atributos do sistema de arquivos, como ACLs e carimbos de
data/hora :
Sincronização de arquivos do Azure : sincronização de arquivos do Azure pode ser usado como
um método para ingerir dados em um compartilhamento de arquivos do Azure, mesmo quando a
implantação final desejada não é manter uma presença local. Sincronização de Arquivos do Azure
pode ser instalado em vigor nas implantações existentes do Windows Server 2012 R2, do Windows
Server 2016 e do Windows Server 2019. Uma vantagem de usar Sincronização de Arquivos do Azure
como um mecanismo de ingestão é que os usuários finais podem continuar a usar o
compartilhamento de arquivos existente no local; o recorte para o compartilhamento de arquivos do
Azure pode ocorrer após a conclusão do carregamento de todos os dados em segundo plano.
Robocopy : Robocopy é uma ferramenta de cópia bem conhecida que é fornecida com o Windows e o
Windows Server. Robocopy pode ser usado para transferir dados para arquivos do Azure montando o
compartilhamento de arquivos localmente e, em seguida, usando a localização montada como o
destino no comando Robocopy.
Ferramentas que não mantêm atributos do sistema de arquivos :
Data Box : data box fornece um mecanismo de transferência de dados offline para enviar dados físicos
para o Azure. Esse método foi projetado para aumentar a taxa de transferência e economizar largura
de banda, mas atualmente não dá suporte a atributos do sistema de arquivos como carimbos de
data/hora e ACLs.
AzCopy : o AzCopy é um utilitário de linha de comando projetado para copiar dados de e para os
Arquivos do Azure e o Armazenamento de Blobs do Azure, usando comandos simples com o
desempenho ideal.
Próximas etapas
Planejando uma implantação de Sincronização de Arquivos do Azure
Implantando Arquivos do Azure
Implantando a Sincronização de Arquivos do Azure
Planejando uma implantação da Sincronização de
Arquivos do Azure
Sincronização de Arquivos do Azure é um serviço que permite armazenar em cache vários

compartilhamentos de arquivos do Azure em um Windows Server ou VM de nuvem local.
Este artigo apresenta Sincronização de Arquivos do Azure conceitos e recursos. Quando estiver familiarizado
com Sincronização de Arquivos do Azure, considere seguir o Guia de implantação de sincronização de
arquivos do Azure para experimentar esse serviço.
Os arquivos serão armazenados na nuvem em compartilhamentos de arquivos do Azure. Os
compartilhamentos de arquivos do Azure podem ser usados de duas maneiras: ao montar diretamente esses
compartilhamentos de arquivos do Azure (SMB) ou armazenar em cache os compartilhamentos de arquivos
do Azure localmente usando o Sincronização de Arquivos do Azure. A opção de implantação escolhida altera
os aspectos que você precisa considerar ao planejar sua implantação.
Montagem direta de um compar tilhamento de arquivos do Azure : como os arquivos do Azure
fornecem acesso SMB, você pode montar compartilhamentos de arquivos do Azure localmente ou na
nuvem usando o cliente SMB padrão disponível no Windows, no MacOS e no Linux. Como os
compartilhamentos de arquivos do Azure são sem servidor, a implantação para cenários de produção
não requer o gerenciamento de um servidor de arquivos ou dispositivo NAS. Isso significa que você
não precisa aplicar patches de software nem trocar discos físicos.
Armazenar em cache o compar tilhamento de arquivos do Azure local com o sincronização
de arquivos do Azure : sincronização de arquivos do Azure permite centralizar os
compartilhamentos de arquivos da sua organização em arquivos do Azure, mantendo, ao mesmo
tempo, a flexibilidade, o desempenho e a compatibilidade de um servidor de arquivos local.
Sincronização de Arquivos do Azure transforma um Windows Server local (ou de nuvem) em um
cache rápido do seu compartilhamento de arquivos do Azure.
Conceitos de gerenciamento
Uma implantação de Sincronização de Arquivos do Azure tem três objetos de gerenciamento fundamentais:
Compar tilhamento de arquivos do Azure : um compartilhamento de arquivos do Azure é um
compartilhamento de arquivos de nuvem sem servidor, que fornece o ponto de extremidade de nuvem de
uma relação de sincronização de sincronização de arquivos do Azure. Os arquivos em um
compartilhamento de arquivos do Azure podem ser acessados diretamente com o protocolo SMB ou
filerest, Embora recomendemos que você acesse principalmente os arquivos por meio do cache do
Windows Server quando o compartilhamento de arquivos do Azure está sendo usado com Sincronização
de Arquivos do Azure. Isso ocorre porque os arquivos do Azure atualmente não têm um mecanismo de
detecção de alteração eficiente, como o Windows Server, portanto, as alterações feitas diretamente no
compartilhamento de arquivos do Azure levarão tempo para serem propagadas de volta para os pontos
de extremidade do servidor.
Ponto de extremidade do ser vidor : o caminho no Windows Server que está sendo sincronizado com
um compartilhamento de arquivos do Azure. Isso pode ser uma pasta específica em um volume ou a raiz
do volume. Vários pontos de extremidade de servidor podem existir no mesmo volume se seus
namespaces não se sobrepõem.
Grupo de sincronização : o objeto que define a relação de sincronização entre um ponto de
extremidade de nuvem , o compartilhamento de arquivos do Azure e um ponto de extremidade do
servidor. Os pontos de extremidade em um grupo de sincronização são mantidos em sincronização entre
si. Se, por exemplo, você tiver dois conjuntos distintos de arquivos que deseja gerenciar com
Sincronização de Arquivos do Azure, você criaria dois grupos de sincronização e adicionará pontos de
extremidade diferentes a cada grupo de sincronização.
Conceitos de gerenciamento de compartilhamento de arquivos do Azure
Os compartilhamentos de arquivos do Azure são implantados em contas de armazenamento, que são
objetos de nível superior que representam um pool de armazenamento compartilhado. Esse pool de
armazenamento pode ser usado para implantar vários compartilhamentos de arquivos, bem como outros
recursos de armazenamento, como contêineres de BLOB, filas ou tabelas. Todos os recursos de
armazenamento implantados em uma conta de armazenamento compartilham os limites que se aplicam a
essa conta de armazenamento. Para ver os limites atuais de uma conta de armazenamento, consulte metas
de desempenho e escalabilidade de arquivos do Azure.
Há dois tipos principais de contas de armazenamento que serão usadas para implantações de arquivos do
Azure:
Contas de armazenamento de uso geral versão 2 (GPv2) : as contas de armazenamento do GPv2
permitem que você implante compartilhamentos de arquivos do Azure em hardware padrão/baseado em
disco rígido (baseado em HDD). Além de armazenar compartilhamentos de arquivos do Azure, as contas
de armazenamento GPv2 podem armazenar outros recursos de armazenamento, como contêineres de
BLOB, filas ou tabelas.
hardware Premium/de estado sólido baseado em disco (SSD). Contas de armazenamento de arquivo só
podem ser usadas para armazenar compartilhamentos de arquivos do Azure; nenhum outro recurso de
armazenamento (contêineres de BLOB, filas, tabelas, etc.) pode ser implantado em uma conta de
Há vários outros tipos de conta de armazenamento que podem ser incluídos no portal do Azure, no
PowerShell ou na CLI. Dois tipos de conta de armazenamento, contas de armazenamento BlockBlobStorage e
BlobStorage, não podem conter compartilhamentos de arquivos do Azure. Os outros dois tipos de conta de
armazenamento que você pode ver são GPv1 (uso geral versão 1) e contas de armazenamento clássicas,
ambos podem conter compartilhamentos de arquivos do Azure. Embora as contas de armazenamento GPv1
e clássico possam conter compartilhamentos de arquivos do Azure, a maioria dos novos recursos dos
arquivos do Azure está disponível apenas nas contas de armazenamento GPv2 e FileStorage. Portanto,
recomendamos que você use apenas contas de armazenamento GPv2 e FileStorage para novas implantações
e atualize as contas de armazenamento GPv1 e clássico se elas já existirem em seu ambiente.
Conceitos de gerenciamento de Sincronização de Arquivos do Azure
Os grupos de sincronização são implantados nos ser viços de sincronização de armazenamento , que
são objetos de nível superior que registram servidores para uso com sincronização de arquivos do Azure e
contêm as relações do grupo de sincronização. O recurso Serviço de Sincronização de Armazenamento é um
par do recurso de conta de armazenamento e pode, de maneira semelhante, ser implantado em grupos de
recursos do Azure. Um serviço de sincronização de armazenamento pode criar grupos de sincronização que
contêm compartilhamentos de arquivos do Azure entre várias contas de armazenamento e vários servidores
Windows registrados.
Antes de criar um grupo de sincronização em um serviço de sincronização de armazenamento, primeiro você
deve registrar um Windows Server com o serviço de sincronização de armazenamento. Isso cria um objeto
de ser vidor registrado , que representa uma relação de confiança entre o servidor ou o cluster e o serviço
de sincronização de armazenamento. Para registrar um serviço de sincronização de armazenamento, você
deve primeiro instalar o agente de Sincronização de Arquivos do Azure no servidor. Um servidor ou cluster
individual pode ser registrado com apenas um serviço de sincronização de armazenamento por vez.
Um grupo de sincronização contém um ponto de extremidade de nuvem, ou compartilhamento de arquivos
do Azure, e pelo menos um ponto de extremidade do servidor. O objeto de ponto de extremidade do servidor
contém as configurações que configuram o recurso de camadas de nuvem , que fornece o recurso de
cache do sincronização de arquivos do Azure. Para sincronizar com um compartilhamento de arquivos do
Azure, a conta de armazenamento que contém o compartilhamento de arquivos do Azure deve estar na
mesma região do Azure que o serviço de sincronização de armazenamento.
Diretrizes de gerenciamento
Ao implantar Sincronização de Arquivos do Azure, recomendamos:
Implantação de compartilhamentos de arquivos do Azure 1:1 com compartilhamentos de arquivos do
Windows. O objeto de ponto de extremidade do servidor oferece um grande grau de flexibilidade na
forma como você configura a topologia de sincronização no lado do servidor da relação de
sincronização. Para simplificar o gerenciamento, faça com que o caminho do ponto de extremidade do
servidor corresponda ao caminho do compartilhamento de arquivos do Windows.
Use o mínimo possível de serviços de sincronização de armazenamento. Isso simplificará o
gerenciamento quando você tiver grupos de sincronização que contêm vários pontos de extremidade
de servidor, já que um servidor Windows só pode ser registrado em um serviço de sincronização de
armazenamento por vez.
Prestar atenção às limitações de IOPS de uma conta de armazenamento ao implantar
compartilhamentos de arquivos do Azure. O ideal é que você mapeie os compartilhamentos de
arquivos 1:1 com contas de armazenamento. no entanto, isso nem sempre pode ser possível devido a
vários limites e restrições, tanto da sua organização quanto do Azure. Quando não for possível ter
apenas um compartilhamento de arquivos implantado em uma conta de armazenamento, considere
quais compartilhamentos serão altamente ativos e quais compartilhamentos serão menos ativas para
garantir que os compartilhamentos de arquivos mais interessantes não sejam colocados na mesma
conta de armazenamento.
Considerações sobre o servidor de arquivos do Windows

Para habilitar o recurso de sincronização no Windows Server, você deve instalar o Sincronização de Arquivos
do Azure agente baixável. O agente de Sincronização de Arquivos do Azure fornece dois componentes
principais FileSyncSvc.exe :, o serviço Windows em segundo plano que é responsável por monitorar
alterações nos pontos de extremidade do servidor e iniciar sessões StorageSync.sys de sincronização, e um
filtro do sistema de arquivos que habilita a camada de nuvem e a recuperação rápida de desastres.
Requisitos do sistema operacional
Há suporte para Sincronização de Arquivos do Azure com as seguintes versões do Windows Server:
O P Ç Õ ES DE IM P L A N TA Ç Ã O C O M
VERSÃ O SK US C O M SUP O RT E SUP O RT E
Windows Server 2019 Datacenter, padrão e IoT Completo e central
Windows Server 2016 Datacenter, padrão e servidor de Completo e central

armazenamento
Windows Server 2012 R2 Datacenter, padrão e servidor de Completo e central

armazenamento
Versões futuras do Windows Server serão adicionadas à medida que forem liberadas.
IMPORTANT
Recomendamos manter todos os servidores usados com a Sincronização de Arquivos do Azure atualizados com as
últimas atualizações do Windows Update.
Recursos mínimos do sistema

O Sincronização de Arquivos do Azure requer um servidor, físico ou virtual, com pelo menos uma CPU e um
mínimo de 2 GiB de memória.
IMPORTANT
Se o servidor estiver sendo executado em uma máquina virtual com memória dinâmica habilitada, a VM deverá ser
configurada com um mínimo de 2048 MiB de memória.
Para a maioria das cargas de trabalho de produção, não recomendamos configurar um servidor de
sincronização de Sincronização de Arquivos do Azure com apenas os requisitos mínimos. Consulte recursos
do sistema recomendados para obter mais informações.
Recursos de sistema recomendados
Assim como qualquer recurso de servidor ou aplicativo, os requisitos de recursos do sistema para
Sincronização de Arquivos do Azure são determinados pela escala da implantação; implantações maiores em
um servidor exigem mais recursos do sistema. Por Sincronização de Arquivos do Azure, a escala é
determinada pelo número de objetos entre os pontos de extremidade do servidor e a rotatividade no
conjunto de um. Um único servidor pode ter pontos de extremidade de servidor em vários grupos de
sincronização e o número de objetos listados nas contas de tabela a seguir para o namespace completo ao
qual um servidor está anexado.
Por exemplo, ponto de extremidade do servidor A com 10 milhões objetos + ponto de extremidade do
servidor B com 10 milhões objetos = 20 milhões objetos. Para essa implantação de exemplo, recomendamos
8 CPUs, 16 GiB de memória para o estado Steady e (se possível) 48 GiB de memória para a migração inicial.
Os dados de namespace são armazenados na memória por motivos de desempenho. Por causa disso,
namespaces maiores exigem mais memória para manter o bom desempenho e mais rotatividade requer
mais CPU para processar.
Na tabela a seguir, fornecemos o tamanho do namespace, bem como uma conversão para capacidade para
compartilhamentos de arquivos de uso geral típicos, em que o tamanho médio do arquivo é 512 KiB. Se os
tamanhos de arquivo forem menores, considere adicionar memória adicional para a mesma quantidade de
capacidade. Baseie sua configuração de memória no tamanho do namespace.
TA M A N H O DO
N A M ESPA C E- A RQ UIVO S & M EM Ó RIA REC O M EN DA DA
DIRETÓ RIO S ( M IL H Õ ES) C A PA C IDA DE T ÍP IC A ( T IB ) N ÚC L EO S DE C P U ( GIB )
3 1.4 2 8 (sincronização inicial)/2

(variação típica)

(rotatividade típica)


50 23,3 16 64 (sincronização inicial)/32

100* 46,6 32 128 (sincronização

inicial)/32 (variação típica)
*A sincronização de mais de 100 milhões arquivos & diretórios não é recomendada neste momento. Esse é
um limite flexível com base em nossos limites testados. Para obter mais informações, consulte escalabilidade
e metas de desempenho dos arquivos do Azure.
TIP
A sincronização inicial de um namespace é uma operação intensiva e é recomendável alocar mais memória até que a
sincronização inicial seja concluída. Isso não é necessário, mas pode acelerar a sincronização inicial.
A rotatividade típica é de 0,5% da alteração do namespace por dia. Para níveis mais altos de variação, considere
adicionar mais CPU.
Um volume anexado localmente formatado com o sistema de arquivos NTFS.

Cmdlet de avaliação
Antes de implantar Sincronização de Arquivos do Azure, você deve avaliar se ele é compatível com seu
sistema usando o cmdlet de avaliação Sincronização de Arquivos do Azure. Esse cmdlet verifica possíveis
problemas com o seu sistema de arquivos e conjunto de banco de arquivo, como caracteres sem suporte ou
uma versão do sistema operacional sem suporte. Suas verificações abordam a maioria dos recursos
mencionados abaixo, mas não todos eles. Recomendamos que você leia o restante desta seção com cuidado
para garantir que sua implantação seja tranqüila.
O cmdlet Evaluation pode ser instalado instalando o módulo AZ PowerShell, que pode ser instalado seguindo
as instruções aqui: instalar e configurar o Azure PowerShell.
Uso
Você pode invocar a ferramenta de avaliação de algumas maneiras diferentes: você pode executar
verificações de sistema, verificações de conjunto de dados ou ambas. Para executar verificações de sistema e
de conjunto de dados:
Invoke-AzStorageSyncCompatibilityCheck -Path <path>
Para testar apenas o conjunto de dados:
Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks
Para testar somente os requisitos do sistema:
Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name>
Para exibir os resultados em CSV:
$errors = Invoke-AzStorageSyncCompatibilityCheck […]

$errors | Select-Object -Property Type, Path, Level, Description | Export-Csv -Path <csv path>
Compatibilidade do sistema de arquivos

Só há suporte para Sincronização de Arquivos do Azure em volumes NTFS anexados diretamente. O
armazenamento com conexão direta, ou DAS, no Windows Server significa que o sistema operacional do
Windows Server possui o sistema de arquivos. O DAS pode ser fornecido por meio da anexação física de
discos ao servidor de arquivos, anexando discos virtuais a uma VM de servidor de arquivos (como uma VM
hospedada pelo Hyper-V) ou até mesmo por meio de ISCSI.
Somente volumes NTFS têm suporte; Não há suporte para ReFS, FAT, FAT32 e outros sistemas de arquivos.
A tabela a seguir mostra o estado de interoperabilidade dos recursos do sistema de arquivos NTFS:
REC URSO STAT US DE SUP O RT E O B SERVA Ç Õ ES
ACLs (listas de controle de acesso) suporte completo As listas de controle de acesso

condicional de estilo do Windows são
preservadas por Sincronização de
Arquivos do Azure e são impostas
pelo Windows Server em pontos de
extremidade de servidor. As ACLs
também podem ser impostas ao
montar diretamente o
compartilhamento de arquivos do
Azure, no entanto, isso requer
configuração adicional. Consulte a
seção identidade para obter mais
informações.
Links físicos Ignorado
Links simbólicos Ignorado
Pontos de montagem Suporte parcial Pontos de montagem podem ser a

raiz de um Ponto de Extremidade de
Servidor, mas serão ignorados se
estiverem contidos no namespace de
um ponto de extremidade de
servidor.
REC URSO STAT US DE SUP O RT E O B SERVA Ç Õ ES
Junções Ignorado Por exemplo, as pastas DFSRoots e

DfrsrPrivate do Sistema de Arquivos
Distribuído.
Pontos de nova análise Ignorado
Compactação NTFS suporte completo
Arquivos esparsos suporte completo Os arquivos esparsos são

sincronizados (não são bloqueados),
mas são sincronizados com a nuvem
como um arquivo completo. Se o
conteúdo do arquivo for alterado na
nuvem (ou em outro servidor), o
arquivo não será mais esparso
quando a alteração for baixada.
ADS (Fluxos de Dados Alternativos) Preservados, mas não sincronizados Por exemplo, as marcas de
classificação criadas pela
Infraestrutura de classificação de
arquivos não são sincronizadas. As
marcas de classificação em arquivos
existentes em cada um dos pontos de
extremidade do servidor são
mantidas.
Sincronização de Arquivos do Azure também irá ignorar determinados arquivos temporários e pastas do
sistema:
A RQ UIVO / PA STA O B SERVA Ç Ã O
pagefile.sys Arquivo específico do sistema
Desktop.ini Arquivo específico do sistema
thumbs.db Arquivo temporário para miniaturas
ehthumbs.db Arquivo temporário para miniaturas de mídia
~$*.* Arquivo temporário do Office
*.tmp Arquivo temporário
*.laccdb Arquivo de bloqueio do banco de dados do Access
635D02A9D91C401B97884B82B3BCDAEA.* Arquivo de sincronização interno
\Informações de Volume do Sistema Pasta específica do volume
$RECYCLE.BIN Pasta
\SyncShareState Pasta para sincronização
Clustering de failover
O clustering de failover do Windows Server tem suporte pela Sincronização de Arquivo do Azure para a
opção de implantação “Servidor de Arquivos de uso geral”. Não há suporte para o Clustering de Failover em
“SOFS (Servidor de Arquivos de Escalabilidade Horizontal) para dados de aplicativos” ou CSVs (Volumes
Compartilhados Clusterizados).
NOTE
O agente de Sincronização de Arquivos do Azure deve ser instalado em cada nó em um Cluster de Failover para a
sincronização funcionar corretamente.
Eliminação de duplicação de dados

Windows Ser ver 2016 e Windows Ser ver 2019
A eliminação de duplicação de dados tem suporte em volumes com a camada de nuvem habilitada no
Windows Server 2016 e Windows Server 2019. Habilitar a eliminação de duplicação de dados em um
volume com camada de nuvem habilitada permite que você armazene em cache mais arquivos localmente
sem provisionar mais armazenamento.
Quando a eliminação de duplicação de dados está habilitada em um volume com disposição em camadas de
nuvem habilitada, os arquivos otimizados para eliminação de duplicatas no local do ponto de extremidade do
servidor serão em camadas semelhantes a um arquivo normal com base nas configurações de política de
camadas de nuvem. Depois que os arquivos otimizados para eliminação de duplicação estiverem em
camadas, o trabalho de coleta de lixo de eliminação de duplicatas de dados será executado automaticamente
para recuperar espaço em disco removendo partes desnecessárias que não são mais referenciadas por
outros arquivos no volume.
Observe que a economia de volume se aplica somente ao servidor; seus dados no compartilhamento de
arquivos do Azure não serão eliminação de duplicação.
NOTE
Para dar suporte à eliminação de duplicação de dados em volumes com camadas de nuvem habilitadas no Windows
Server 2019, o Windows Update KB4520062 deve ser instalado e sincronização de arquivos do Azure versão do
agente 9.0.0.0 ou mais recente é necessária.
Windows Ser ver 2012 R2

Sincronização de Arquivos do Azure não dá suporte à eliminação de duplicação de dados e à camada de
nuvem no mesmo volume no Windows Server 2012 R2. Se a eliminação de duplicação de dados estiver
habilitada em um volume, a camada de nuvem deverá ser desabilitada.
Obser vações
Se a eliminação de duplicação de dados for instalada antes da instalação do agente de Sincronização
de Arquivos do Azure, uma reinicialização será necessária para dar suporte à eliminação de duplicação
de dados e à camada de nuvem no mesmo volume.
Se a eliminação de duplicação de dados estiver habilitada em um volume depois que a disposição em
camadas de nuvem estiver habilitada, o trabalho de otimização de eliminação de duplicação inicial
otimizará os arquivos no volume que ainda não estão em camadas e terá o seguinte impacto na
camada de nuvem:
A política de espaço livre continuará a hierarquizar arquivos de acordo com o espaço livre no
volume usando o calor.
A política de data ignorará a camada de arquivos que, de outra forma, podem ter sido elegíveis
para camadas devido ao trabalho de otimização de eliminação de duplicação que acessa os
arquivos.
Para trabalhos de otimização de eliminação de duplicação em andamento, as camadas de nuvem com
a política de data serão atrasadas pela configuração MinimumFileAgeDays de eliminação de
duplicação de dados, se o arquivo ainda não estiver em camadas.
Exemplo: se a configuração MinimumFileAgeDays for de sete dias e a política de data de camadas
de nuvem for de 30 dias, a política de data terá os arquivos de camada após 37 dias.
Observação: quando um arquivo estiver em camadas por Sincronização de Arquivos do Azure, o
trabalho de otimização de eliminação de duplicação ignorará o arquivo.
Se um servidor que executa o Windows Server 2012 R2 com o agente de Sincronização de Arquivos
do Azure instalado for atualizado para o Windows Server 2016 ou o Windows Server 2019, as etapas
a seguir deverão ser executadas para dar suporte à eliminação de duplicação de dados e à camada de
nuvem no mesmo volume:
Desinstale o agente de Sincronização de Arquivos do Azure para Windows Server 2012 R2 e
reinicie o servidor.
Baixe o agente de Sincronização de Arquivos do Azure para a nova versão do sistema operacional
do servidor (Windows Server 2016 ou Windows Server 2019).
Instale o agente de Sincronização de Arquivos do Azure e reinicie o servidor.
Observação: as definições de configuração do Sincronização de Arquivos do Azure no servidor são
mantidas quando o agente é desinstalado e reinstalado.
DFS (Sistema de Arquivos Distribuído )
A Sincronização de Arquivos do Azure fornece suporte para interoperabilidade com Namespaces de DFS
(DFS-N) e Replicação do DFS (DFS-R).
DFS-N (Namespaces de DFS) : a Sincronização de arquivos do Azure é totalmente suportada em
servidores DFS-N. É possível instalar o agente Sincronização de arquivos do Azure em um ou mais membros
DFS-N para sincronizar dados entre os pontos de extremidade de servidor e o ponto de extremidade da
nuvem. Para obter mais informações, consulte visão geral de Namespaces de DFS.
Replicação do DFS (DFS-r) : como o DFS-r e sincronização de arquivos do Azure são soluções de
replicação, na maioria dos casos, é recomendável substituir DFS-r por sincronização de arquivos do Azure.
No entanto, há vários cenários em que você desejaria usar o DFS-R e Sincronização de Arquivos do Azure
juntos:
Você está migrando de uma implantação de DFS-R para uma implantação de Sincronização de arquivos
do Azure. Para obter mais informações, consulte Migrar uma implantação de DFS-R (Replicação do DFS)
para Sincronização de arquivos do Azure.
Nem todo servidor local que precisa de uma cópia dos dados do arquivo pode ser conectado diretamente
à Internet.
Os servidor de ramificação consolidam dados em um servidor de hub único, para o qual você gostaria de
usar a Sincronização de arquivos do Azure.
Para Sincronização de Arquivos do Azure e o DFS-R funcionar lado a lado:
1. A camada de nuvem da Sincronização de arquivos do Azure deve ser desabilitada em volumes com pastas
replicadas DFS-R.
2. Os pontos de extremidade de servidor não devem ser configurados em pastas de replicação somente
leitura do DFS-R.
Para obter mais informações, consulte Visão geral da Replicação do DFS.
Sysprep
Não há suporte para o uso do Sysprep em um servidor com o agente de Sincronização de Arquivos do Azure
instalado e isso pode levar a resultados inesperados. A instalação do agente e o registro do servidor devem
ocorrer depois da implantação da imagem do servidor e da conclusão da mini-instalação do sysprep.
Windows Search
Se a opção de camadas em nuvem estiver habilitada em um ponto de extremidade do servidor, os arquivos
que estão em camadas serão ignorados e não serão indexados pelo Windows Search. Arquivos sem camadas
são indexados corretamente.
Outras soluções de HSM (Gerenciamento de Armazenamento Hierárquico )
Nenhuma outra solução de HSM deve ser usada com a Sincronização de Arquivos do Azure.
Identidade
Sincronização de Arquivos do Azure trabalha com sua identidade padrão baseada em AD sem qualquer
configuração especial além de configurar a sincronização. Quando você está usando Sincronização de
Arquivos do Azure, a expectativa geral é que a maioria dos acessos percorra os servidores de cache
Sincronização de Arquivos do Azure, em vez de usar o compartilhamento de arquivos do Azure. Como os
pontos de extremidade do servidor estão localizados no Windows Server, e o Windows Server tem suporte
para ACLs de estilo do AD e do Windows há muito tempo, nada é necessário além de garantir que os
servidores de arquivos do Windows registrados com o serviço de sincronização de armazenamento estejam
ingressados no domínio. Sincronização de Arquivos do Azure armazenará ACLs nos arquivos no
compartilhamento de arquivos do Azure e os replicará para todos os pontos de extremidade do servidor.
Embora as alterações feitas diretamente no compartilhamento de arquivos do Azure demorem mais para
serem sincronizadas com os pontos de extremidade do servidor no grupo de sincronização, você também
pode querer garantir que você possa impor suas permissões do AD em seu compartilhamento de arquivos
diretamente na nuvem. Para fazer isso, você deve ingressar o domínio em sua conta de armazenamento no
AD local, assim como os servidores de arquivos do Windows são ingressados no domínio. Para saber mais
sobre o ingresso no domínio de sua conta de armazenamento para um Active Directory de Propriedade do
cliente, consulte visão geral dos arquivos do Azure Active Directory.
IMPORTANT
Não é necessário ingressar no domínio em sua conta de armazenamento no Active Directory para implantar
Sincronização de Arquivos do Azure com êxito. Essa é uma etapa estritamente opcional que permite que o
compartilhamento de arquivos do Azure imponha ACLs locais quando os usuários montam o compartilhamento de
arquivos do Azure diretamente.
Rede
O agente de Sincronização de Arquivos do Azure se comunica com o serviço de sincronização de
armazenamento e o compartilhamento de arquivos do Azure usando o protocolo REST Sincronização de
Arquivos do Azure e o protocolo filerest, ambos sempre usam HTTPS pela porta 443. O SMB nunca é usado
para carregar ou baixar dados entre o Windows Server e o compartilhamento de arquivos do Azure. Como a
maioria das organizações permite o tráfego HTTPS pela porta 443, como um requisito para visitar a maioria
dos sites, normalmente a configuração de rede especial não é necessária para implantar Sincronização de
Arquivos do Azure.
Com base na política da sua organização ou em requisitos regulatórios exclusivos, você pode exigir
comunicação mais restritiva com o Azure e, portanto, Sincronização de Arquivos do Azure fornece vários
mecanismos para você configurar a rede. Com base em seus requisitos, você pode:
Túnel de sincronização e carregamento de arquivos/download por meio de seu ExpressRoute ou VPN do
Azure.
Faça uso de arquivos do Azure e recursos de rede do Azure, como pontos de extremidade de serviço e
pontos de extremidade privados.
Configure Sincronização de Arquivos do Azure para dar suporte ao seu proxy em seu ambiente.
Limitar a atividade de rede de Sincronização de Arquivos do Azure.
Para saber mais sobre como configurar a funcionalidade de rede do Sincronização de Arquivos do Azure,
consulte:
Configurações de proxy e firewall da Sincronização de Arquivos do Azure
Garantindo que a Sincronização de arquivos do Azure seja uma boa vizinha no seu data center
Criptografia
Ao usar Sincronização de Arquivos do Azure, há três camadas diferentes de criptografia a serem
consideradas: criptografia no armazenamento em repouso do Windows Server, criptografia em trânsito entre
o agente de Sincronização de Arquivos do Azure e o Azure, e a criptografia em repouso em seus dados no
compartilhamento de arquivos do Azure.
Criptografia em repouso do Windows Server
Há duas estratégias para criptografar dados no Windows Server que funcionam geralmente com
Sincronização de Arquivos do Azure: criptografia abaixo do sistema de arquivos, de modo que o sistema de
arquivos e todos os dados gravados nele sejam criptografados e criptografia no próprio formato de arquivo.
Esses métodos não são mutuamente exclusivos; Eles podem ser usados juntos, se desejado, uma vez que a
finalidade da criptografia é diferente.
Para fornecer criptografia sob o sistema de arquivos, o Windows Server fornece a caixa de entrada do
BitLocker. O BitLocker é totalmente transparente para Sincronização de Arquivos do Azure. O principal
motivo para usar um mecanismo de criptografia como o BitLocker é impedir a vazamento física de dados do
seu datacenter local por alguém roubar os discos e impedir o Sideload de um sistema operacional não
autorizado para executar leituras/gravações não autorizadas em seus dados. Para saber mais sobre o
BitLocker, confira visão geral do BitLocker.
Os produtos de terceiros que funcionam de forma semelhante ao BitLocker, no que ficam abaixo do volume
NTFS, devem funcionar de forma totalmente transparente com Sincronização de Arquivos do Azure.
O outro método principal para criptografar dados é criptografar o fluxo de dados do arquivo quando o
aplicativo salvar o arquivo. Alguns aplicativos podem fazer isso nativamente, no entanto, geralmente esse
não é o caso. Um exemplo de um método para criptografar o fluxo de dados do arquivo é o Azure
Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS. O
principal motivo para usar um mecanismo de criptografia como o AIP/RMS é impedir vazamento de dados
de dados do seu compartilhamento de arquivos por pessoas que os copiam para locais alternativos, como
em uma unidade flash ou enviá-los por email para uma pessoa não autorizada. Quando o fluxo de dados de
um arquivo é criptografado como parte do formato de arquivo, esse arquivo continuará a ser criptografado
O Sincronização de Arquivos do Azure não interopera com o sistema de arquivos criptografados NTFS (EFS)
ou soluções de criptografia de terceiros que ficam acima do sistema de arquivos, mas abaixo do fluxo de
dados do arquivo.
NOTE
Sincronização de Arquivos do Azure serviço removerá o suporte para TLS 1.0 e 1,1 em agosto de 2020. Todas as
versões de agente Sincronização de Arquivos do Azure com suporte já usam o TLS 1.2 por padrão. Usar uma versão
anterior do TLS pode ocorrer se o TLS 1.2 estivesse desabilitado no servidor ou um proxy for usado. Se você estiver
usando um proxy, recomendamos que verifique a configuração de proxy. Sincronização de Arquivos do Azure regiões
de serviço adicionadas após 5/1/2020 oferecerão suporte apenas a TLS 1.2 e o suporte para TLS 1.0 e 1,1 será
removido das regiões existentes em 2020 de agosto. Para obter mais informações, consulte o Guia de solução de
problemas.
Sincronização de Arquivos do Azure agente se comunica com o serviço de sincronização de armazenamento

e o compartilhamento de arquivos do Azure usando o protocolo REST Sincronização de Arquivos do Azure e
o protocolo filerest, ambos sempre usam HTTPS pela porta 443. Sincronização de Arquivos do Azure não
envia solicitações não criptografadas por HTTP.
As contas de armazenamento do Azure contêm uma opção para exigir criptografia em trânsito, que é
habilitada por padrão. Mesmo que a opção no nível da conta de armazenamento esteja desabilitada, o que
significa que as conexões não criptografadas com seus compartilhamentos de arquivos do Azure são
possíveis, Sincronização de Arquivos do Azure ainda usará canais criptografados para acessar o
O principal motivo para desabilitar a criptografia em trânsito para a conta de armazenamento é dar suporte a
um aplicativo herdado que deve ser executado em um sistema operacional mais antigo, como o Windows
Server 2008 R2 ou a distribuição mais antiga do Linux, conversando diretamente com um compartilhamento
de arquivos do Azure. Se o aplicativo herdado se comunica com o cache do Windows Server do
compartilhamento de arquivos, alternar essa configuração não terá nenhum efeito.
É altamente recomendável garantir que a criptografia de dados em trânsito esteja habilitada.
Criptografia de compartilhamento de arquivos do Azure em repouso
Todos os dados armazenados nos arquivos do Azure são criptografados em repouso usando a SSE
(criptografia do serviço de armazenamento) do Azure. A criptografia do serviço de armazenamento funciona
de forma semelhante ao BitLocker no Windows: os dados são criptografados abaixo do nível do sistema de
arquivos. Como os dados são criptografados abaixo do sistema de arquivos do compartilhamento de
arquivos do Azure, pois eles são codificados no disco, você não precisa ter acesso à chave subjacente no
cliente para ler ou gravar no compartilhamento de arquivos do Azure.
Por padrão, os dados armazenados nos arquivos do Azure são criptografados com chaves gerenciadas pela
Microsoft. Com as chaves gerenciadas pela Microsoft, a Microsoft mantém as chaves para
criptografar/descriptografar os dados e é responsável por girá-los regularmente. Você também pode optar
por gerenciar suas próprias chaves, o que lhe dá controle sobre o processo de rotação. Se você optar por
criptografar seus compartilhamentos de arquivos com chaves gerenciadas pelo cliente, os arquivos do Azure
serão autorizados a acessar suas chaves para atender a solicitações de leitura e gravação de seus clientes.
Com as chaves gerenciadas pelo cliente, você pode revogar essa autorização a qualquer momento, mas isso
significa que o compartilhamento de arquivos do Azure não estará mais acessível via SMB ou pela API
filerest.
Os arquivos do Azure usam o mesmo esquema de criptografia que os outros serviços de armazenamento do
Azure, como o armazenamento de BLOBs do Azure. Para saber mais sobre a SSE (criptografia do serviço de
armazenamento) do Azure, confira criptografia de armazenamento do Azure para dados em repouso.
Camadas de armazenamento
Os arquivos do Azure oferecem duas camadas diferentes de armazenamento, Premium e Standard, para
permitir que você personalize seus compartilhamentos para os requisitos de desempenho e preço do seu
cenário:
Compar tilhamentos de arquivos Premium : os compartilhamentos de arquivos Premium são
apoiados por SSDs (unidades de estado sólido) e implantados no tipo de conta de armazenamento de
armazenamento de arquivo. Os compartilhamentos de arquivos Premium fornecem alto desempenho e
baixa latência consistentes em milissegundos de dígito único para a maioria das operações de e/s, para
cargas de trabalho com uso intensivo de e/s. Isso os torna adequados para uma ampla variedade de
cargas de trabalho, como bancos de dados, Hospedagem de site e ambientes de desenvolvimento. Os
compartilhamentos de arquivos Premium estão disponíveis em um modelo de cobrança provisionado.
Para obter mais informações sobre o modelo de cobrança provisionado para compartilhamentos de
arquivos premium, consulte noções básicas sobre provisionamento de compartilhamentos de arquivos
Premium.
Compar tilhamentos de arquivos padrão : os compartilhamentos de arquivos padrão são apoiados
por unidades de disco rígido (HDDs) e são implantados no tipo de conta de armazenamento GPv2
(versão de uso geral 2) . Os compartilhamentos de arquivos padrão fornecem um desempenho
confiável para cargas de trabalho de e/s que são menos sensíveis à variabilidade de desempenho, como
compartilhamentos de arquivos de uso geral e ambientes de desenvolvimento/teste. Os
compartilhamentos de arquivos padrão estão disponíveis apenas em um modelo de cobrança pago
conforme o uso.
Habilitar compartilhamentos de arquivos padrão para abranger até 100 TiB
compartilhamento possa ser aumentado para 100 TiB. Para fazer isso, o recurso de compartilhamento de
arquivos grandes deve ser habilitado no nível da conta de armazenamento. As contas de armazenamento
Premium (contas de armazenamento dearmazenamento de arquivo) não têm o sinalizador de recurso de
compartilhamento de arquivos grandes, já que todos os compartilhamentos de arquivos premium estão
habilitados para provisionamento na capacidade total de 100 Tib.
Você só pode habilitar compartilhamentos de arquivos grandes em contas de armazenamento padrão com
redundância local ou de zona. Depois de habilitar o sinalizador de recurso de compartilhamento de arquivos
grandes, não é possível alterar o nível de redundância para armazenamento com redundância geográfica ou
com redundância geográfica.
Para habilitar compartilhamentos de arquivos grandes em uma conta de armazenamento existente, navegue
até o modo de exibição de configuração no Sumário da conta de armazenamento e alterne a opção de
tentativa de compartilhamento de arquivo grande para habilitado:
Você também pode habilitar compartilhamentos de arquivos 100 Set-AzStorageAccount Tib por meio do
az storage account update cmdlet do PowerShell e o comando CLI do Azure. Para obter instruções
detalhadas sobre como habilitar compartilhamentos de arquivos grandes, consulte habilitar e criar
compartilhamentos de arquivos grandes.
Para saber mais sobre como criar compartilhamentos de arquivos em novas contas de armazenamento,
consulte criando um compartilhamento de arquivos do Azure.
Compartilhamentos de arquivos padrão com capacidade de 100 TiB têm certas limitações.
Atualmente, há suporte apenas para contas de armazenamento com redundância local (LRS) e ZRS
(armazenamento com redundância de zona).
Depois de habilitar grandes compartilhamentos de arquivos, você não pode converter contas de
armazenamento para GRS (armazenamento com redundância geográfica) ou contas de GZRS
(armazenamento com redundância de zona geográfica).
Depois de habilitar grandes compartilhamentos de arquivos, você não pode desabilitá-lo.
Disponibilidade da região de sincronização de arquivos do Azure

Sincronização de Arquivos do Azure está disponível nas seguintes regiões:
N UVEM DO A Z URE REGIÃ O GEO GRÁ F IC A REGIÃ O DO A Z URE C Ó DIGO DE REGIÃ O
Público Ásia Leste da Ásia eastasia
Público Ásia Sudeste Asiático southeastasia
Público Austrália Leste da Austrália australiaeast
Público Austrália Sudeste da Austrália australiasoutheast
Público Brasil Sul do Brasil brazilsouth
Público Canada Canadá Central canadacentral
Público Canada Leste do Canadá canadaeast
Público Europa Norte da Europa northeurope
Público Europa Europa Ocidental westeurope
Público França França Central francecentral
Público França Sul da França * francesouth
Público Índia Índia Central centralindia
Público Índia Sul da Índia southindia
Público Japão Leste do Japão japaneast
Público Japão Oeste do Japão japanwest
Público Coreia do Sul Coreia Central koreacentral
Público Coreia do Sul Sul da Coreia koreasouth
Público África do Sul Norte da África do Sul southafricanorth
Público África do Sul Oeste da África do Sul * southafricawest

N UVEM DO A Z URE REGIÃ O GEO GRÁ F IC A REGIÃ O DO A Z URE C Ó DIGO DE REGIÃ O
Público EAU EAU Central * uaecentral
Público EAU Norte dos EAU uaenorth
Público Reino Unido Sul do Reino Unido uksouth
Público Reino Unido Oeste do Reino Unido ukwest
Público EUA Centro dos EUA centralus
Público EUA Leste dos EUA eastus
Público EUA Leste dos EUA 2 eastus2
Público EUA Centro-Norte dos EUA northcentralus
Público EUA Centro-Sul dos Estados southcentralus

Unidos
Público EUA Centro-Oeste dos EUA westcentralus
Público EUA Oeste dos EUA westus
Público EUA Oeste dos EUA 2 westus2
Gov dos EUA EUA Governo dos EUA do usgovarizona

Arizona
Gov dos EUA EUA Governo dos EUA do Texas usgovtexas
Gov dos EUA EUA Gov. dos EUA – Virgínia usgovvirginia
A Sincronização de Arquivos do Azure é compatível apenas com um compartilhamento de arquivo do Azure

que esteja na mesma região que o Serviço de Sincronização de Armazenamento.
Para as regiões marcadas com asteriscos, você deve contatar o suporte do Azure para solicitar acesso ao
armazenamento do Azure nessas regiões. O processo é descrito neste documento.
Redundância
Para proteger os dados em seus compartilhamentos de arquivos do Azure contra perda ou corrupção de
dados, todos os compartilhamentos de arquivos do Azure armazenam várias cópias de cada arquivo à
medida que são gravadas. Dependendo dos requisitos de sua carga de trabalho, você pode selecionar graus
adicionais de redundância. Atualmente, os arquivos do Azure dão suporte às seguintes opções de
redundância de dados:
Localmente redundante : o armazenamento com redundância local, geralmente conhecido como lRS,
significa que cada arquivo é armazenado três vezes em um cluster de armazenamento do Azure. Isso
protege contra perda de dados devido a falhas de hardware, como uma unidade de disco defeituosa.
Com redundância de zona : o armazenamento com redundância de zona, geralmente referido como
ZRS, significa que cada arquivo é armazenado três vezes em três clusters de armazenamento do Azure
distintos. Os três diferentes clusters de armazenamento do Azure armazenam o arquivo três vezes, assim
como com o armazenamento com redundância local, e são fisicamente isolados em diferentes zonas de
disponibilidadedo Azure. As zonas de disponibilidade são locais físicos exclusivos em uma região do
Azure. Cada zona é composta por um ou mais datacenters equipados com energia, resfriamento e rede
independentes. Uma gravação no armazenamento não é aceita até que seja gravada nos clusters de
armazenamento em todas as três zonas de disponibilidade.
Com redundância geográfica : o armazenamento com redundância geográfica, geralmente conhecido
como grs, é como um armazenamento com redundância local, no qual um arquivo é armazenado três
vezes em um cluster de armazenamento do Azure na região primária. Em seguida, todas as gravações são
replicadas de forma assíncrona para uma região secundária definida pela Microsoft. O armazenamento
com redundância geográfica fornece seis cópias de seus dados espalhados entre duas regiões do Azure.
No caso de um grande desastre, como a perda permanente de uma região do Azure devido a um desastre
natural ou a outro evento semelhante, a Microsoft executará um failover para que o secundário em vigor
se torne o primário, atendendo a todas as operações. Como a replicação entre as regiões primária e
secundária é assíncrona, no caso de um desastre principal, os dados ainda não replicados para a região
secundária serão perdidos. Você também pode executar um failover manual de uma conta de
armazenamento com redundância geográfica.
Com redundância de zona geográfica : o armazenamento com redundância de zona geográfica,
geralmente conhecido como GZRS, é como o armazenamento com redundância de zona, no qual um
arquivo é armazenado nove vezes em três clusters de armazenamento distintos na região primária. Em
seguida, todas as gravações são replicadas de forma assíncrona para uma região secundária definida pela
Microsoft. O processo de failover para armazenamento com redundância de zona geográfica funciona da
mesma forma que o armazenamento com redundância geográfica.
Os compartilhamentos de arquivos padrão do Azure dão suporte a todos os quatro tipos de redundância,
enquanto os compartilhamentos de arquivos premium do Azure só oferecem suporte a armazenamento com
redundância local
As contas de armazenamento de uso geral versão 2 (GPv2) fornecem duas opções adicionais de redundância
que não têm suporte nos arquivos do Azure: Leia armazenamento com redundância geográfica acessível,
geralmente conhecido como RA-GRS e leia armazenamento com redundância de zona geográfica acessível,
geralmente conhecido como RA-GZRS. Você pode provisionar compartilhamentos de arquivos do Azure em
contas de armazenamento com essas opções definidas, no entanto, os arquivos do Azure não dão suporte à
leitura da região secundária. Os compartilhamentos de arquivos do Azure implantados em contas de
armazenamento com redundância de zona geográfica ou geográfica acessível serão cobrados como
armazenamento com redundância geográfica ou com redundância de zona geográfica, respectivamente.
IMPORTANT
O armazenamento com redundância geográfica e de zona geográfica tem a capacidade de fazer failover manual do
armazenamento para a região secundária. É recomendável que você não faça isso fora de um desastre quando estiver
usando Sincronização de Arquivos do Azure devido à maior probabilidade de perda de dados. No caso de um desastre
em que você gostaria de iniciar um failover manual de armazenamento, será necessário abrir um caso de suporte com
a Microsoft para obter Sincronização de Arquivos do Azure para retomar a sincronização com o ponto de extremidade
secundário.
Migração
Se você tiver um servidor de arquivos do Windows existente, Sincronização de Arquivos do Azure poderá ser
instalado diretamente no local, sem a necessidade de mover dados para um novo servidor. Se você estiver
planejando migrar para um novo servidor de arquivos do Windows como parte da adoção de Sincronização
de Arquivos do Azure, há várias abordagens possíveis para mover dados:
Crie pontos de extremidade do servidor para o compartilhamento de arquivos antigo e o novo
compartilhamento de arquivos e permita que Sincronização de Arquivos do Azure sincronize os dados
entre os pontos de extremidade do servidor. A vantagem dessa abordagem é que ela facilita muito a
assinatura do armazenamento em seu novo servidor de arquivos, pois Sincronização de Arquivos do
Azure é um reconhecimento em camadas de nuvem. Quando estiver pronto, você poderá recortar os
usuários finais para o compartilhamento de arquivos no novo servidor e remover o ponto de
extremidade do servidor do compartilhamento de arquivos antigo.
Crie um ponto de extremidade do servidor somente no novo servidor de arquivos e copie dados para
o compartilhamento de arquivos robocopy antigo usando o. Dependendo da topologia dos
compartilhamentos de arquivos no novo servidor (Quantos compartilhamentos você tem em cada
volume, como a liberação de cada volume é, etc.), talvez seja necessário provisionar temporariamente
o armazenamento adicional robocopy , pois é esperado que, desde o servidor antigo até o novo
servidor em seu datacenter local, seja concluído mais rápido do que sincronização de arquivos do
Azure moverá dados para o Azure.
Também é possível usar Data Box para migrar dados para uma implantação Sincronização de Arquivos do
Azure. Na maioria das vezes, quando os clientes desejam usar Data Box para ingerir dados, eles fazem isso
porque acham que aumentarão a velocidade de sua implantação ou, pois isso ajudará com cenários de
largura de banda restritas. Embora seja verdade que usar um Data Box para ingerir dados em sua
implantação de Sincronização de Arquivos do Azure diminuirá a utilização da largura de banda,
provavelmente será mais rápido para a maioria dos cenários buscar um carregamento de dados online por
meio de um dos métodos descritos acima. Para saber mais sobre como usar Data Box para ingerir dados em
sua implantação de Sincronização de Arquivos do Azure, consulte migrar dados para sincronização de
arquivos do Azure com Azure data Box.
Um erro comum que os clientes fazem ao migrar dados para sua nova implantação de Sincronização de
Arquivos do Azure é copiar dados diretamente para o compartilhamento de arquivos do Azure, em vez de
em seus servidores de arquivos do Windows. Embora Sincronização de Arquivos do Azure identifique todos
os novos arquivos no compartilhamento de arquivos do Azure e sincronize-os de volta para seus
compartilhamentos de arquivos do Windows, isso geralmente é consideravelmente mais lento do que
carregar dados por meio do servidor de arquivos do Windows. Muitas ferramentas de cópia do Azure, como
AzCopy, têm a desvantagem adicional de não copiar todos os metadados importantes de um arquivo, como
carimbos de data/hora e ACLs.
Antivírus
Como os antivírus funcionam com o exame de arquivos em busca de códigos mal-intencionados conhecidos,
um antivírus pode causar o recall de arquivos em camadas. Nas versões 4.0 e acima do agente de
Sincronização de Arquivo do Azure, arquivos em camadas têm o conjunto
FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS de atributo seguro do Windows. Recomendamos consultar o
fornecedor do software para saber como configurar a solução para ignorar a leitura de arquivos com esse
conjunto de atributos (muitos fazem isso automaticamente).
As soluções antivírus internas da Microsoft, o Windows Defender e o System Center Endpoint Protection
(SCEP), ignoram automaticamente a leitura de arquivos que possuem esse atributo definido. Nós os testamos
e identificamos um problema menor: quando você adiciona um servidor a um grupo de sincronização
existente, os arquivos com menos de 800 bytes são recuperados (feitos o download) no novo servidor. Esses
arquivos permanecerão no novo servidor e não serão colocados em camadas, pois não atendem ao requisito
de tamanho em camadas (> 64kb).
NOTE
Os fornecedores de antivírus podem verificar a compatibilidade entre seus produtos e Sincronização de Arquivos do
Azure usando o sincronização de arquivos do Azure antivírus Compatibility Suite, que está disponível para download
no centro de download da Microsoft.
Backup
Como as soluções de antivírus, as soluções de backup podem causar o recall de arquivos em camadas.
Recomendamos o uso de uma solução de backup de nuvem para fazer backup do compartilhamento do
arquivos do Azure, em vez de um produto de backup local.
Se você estiver usando uma solução de backup local, os backups devem ser executados em um servidor no
grupo de sincronização que tem a camada de nuvem desabilitada. Ao executar uma restauração, use as
opções de restauração no nível do volume ou no nível do arquivo. Os arquivos restaurados usando a opção
de restauração no nível do arquivo serão sincronizados com todos os pontos de extremidade no grupo de
sincronização e os arquivos existentes serão substituídos pela versão restaurada do backup. As restaurações
no nível de volume não substituirão as versões de arquivo mais recentes no compartilhamento de arquivos
do Azure ou em outros pontos de extremidade do servidor.
NOTE
A restauração bare-metal (BMR) pode causar resultados inesperados e não é atualmente suportada.
NOTE
Com a versão 9 do agente de Sincronização de Arquivos do Azure, os instantâneos do VSS (incluindo a guia versões
anteriores) agora têm suporte em volumes que têm a camada de nuvem habilitada. No entanto, você deve habilitar a
compatibilidade de versão anterior por meio do PowerShell. Saiba como.
Política de atualização do agente de Sincronização de Arquivo do

Azure
O agente de Sincronização de arquivos do Azure é atualizado regularmente para adicionar novos recursos e
resolver problemas. Recomendamos que você configure o Microsoft Update para obter atualizações para o
agente de Sincronização de arquivos do Azure à medida que elas ficarem disponíveis.
Versões do agente principal versus secundário
As versões do agente principal geralmente contêm novos recursos e têm um número crescente como a
primeira parte do número da versão. Por exemplo: *2.*.**
As versões do agente secundário também são chamadas de "patches" e são lançadas com mais frequência
do que as versões do principal. Geralmente contêm correções de bug e pequenas melhorias, mas sem
novos recursos. Por exemplo: **.3.**
Caminhos de atualização
Há quatro maneiras aprovadas e testadas para instalar as atualizações do agente de Sincronização de
Arquivos do Azure.
1. (Preferencial) Configure o Microsoft Update para baixar e instalar automaticamente as
atualizações do agente.
É sempre recomendável executar todas as atualizações de Sincronização de arquivos do Azure para
garantir que você tenha acesso às últimas correções para o Server Agent. O Microsoft Update simplifica
esse processo, baixando e instalando atualizações automaticamente para você.
2. Use AfsUpdater.exe para baixar e instalar atualizações de agente.
O AfsUpdater.exe está localizado no diretório de instalação do agente. Clique duas vezes no executável
para baixar e instalar atualizações de agente.
3. Corrija um agente de Sincronização de Arquivos do Azure existente usando um arquivo de
patch Microsoft Update ou um executável. msp. O pacote de atualização mais recente do
Sincronização de Arquivos do Azure pode ser baixado do Catálogo de Microsoft Update .
Executar um executável .msp atualizará a instalação de Sincronização de arquivos do Azure com o mesmo
método usado automaticamente pelo Microsoft Update no caminho de atualização anterior. A aplicação
de um patch do Microsoft Update realizará uma atualização no local de uma instalação e Sincronização de
arquivos do Azure.
4. Baixe o instalador do agente de Sincronização de Arquivos do Azure mais recente no centro
de download da Microsoft .
Para fazer upgrade de uma instalação existente do agente de Sincronização de Arquivos do Azure,
desinstale a versão mais antiga e então instale a última versão do instalador baixado. O registro do
servidor, os grupos de sincronização e outras configurações são mantidos pelo instalador de
Sincronização de arquivos do Azure.
Gerenciamento automático do ciclo de vida do agente
Com o Agent versão 6, a equipe de sincronização de arquivos introduziu um recurso de atualização
automática de agente. Você pode selecionar um dos dois modos e especificar uma janela de manutenção na
qual a atualização deve ser tentada no servidor. Esse recurso foi criado para ajudá-lo com o gerenciamento
do ciclo de vida do agente, fornecendo um Guardrail que impede o agente de expiração ou permitindo uma
configuração sem complicações, mantenha-se atualizado.
1. A configuração padrão tentará impedir que o agente expire. Dentro de 21 dias da data de expiração
lançada de um agente, o agente tentará fazer a atualização automática. Ele iniciará uma tentativa de
atualizar uma vez por semana em 21 dias antes da expiração e na janela de manutenção selecionada.
Essa opção não elimina a necessidade de fazer patches de Microsoft Update regulares.
2. Opcionalmente, você pode selecionar se o agente será atualizado automaticamente assim que uma nova
versão do agente se tornar disponível (atualmente não aplicável a servidores clusterizados). Essa
atualização ocorrerá durante a janela de manutenção selecionada e permitirá que o servidor se beneficie
dos novos recursos e aprimoramentos assim que eles forem disponibilizados para o público geral. Essa é
a configuração recomendada e sem preocupações que fornecerá as principais versões do agente, bem
como patches de atualização regulares para o servidor. Cada agente lançado está em qualidade de GA. Se
você selecionar essa opção, a Microsoft irá comprovar a versão mais recente do agente para você. Os
servidores clusterizados são excluídos. Após a conclusão do processamento, o agente também ficará
disponível no centro de download da Microsoft aka.ms/AFS/Agent.
A l t e r a n d o a c o n fi g u r a ç ã o d e a t u a l i z a ç ã o a u t o m á t i c a
As instruções a seguir descrevem como alterar as configurações depois de concluir o instalador, se você
precisar fazer alterações.
Abra um console do PowerShell e navegue até o diretório em que você instalou o agente de sincronização e,
em seguida, importe os cmdlets do servidor. Por padrão, isso seria semelhante a este:
cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll
Você pode executar Get-StorageSyncAgentAutoUpdatePolicy para verificar a configuração de política atual e

determinar se deseja alterá-la.
Para alterar a configuração de política atual para a faixa de atualização atrasada, você pode usar:
Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration
Para alterar a configuração de política atual para a faixa de atualização imediata, você pode usar:
Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest
Garantia de gerenciamento de alterações e ciclo de vida do agente

Sincronização de Arquivos do Azure é um serviço de nuvem, que apresenta continuamente novos recursos e
aprimoramentos. Isso significa que uma versão específica do agente de Sincronização de arquivos do Azure
somente poderá ter suporte por um tempo limitado. Para facilitar sua implantação, as regras a seguir
garantem que você tenha tempo e notificações suficientes para acomodar atualizações/upgrades do agente
em seu processo de gerenciamento de alterações:
As versões do agente principal terão suporte por pelo menos seis meses, a partir da data da versão inicial.
Garantimos que há uma sobreposição de pelo menos três meses entre o suporte das versões do agente
principal.
Avisos para servidores registrados que utilizam um agente que expirará em breve serão emitidos pelo
menos três meses antes da expiração. É possível verificar se um servidor registrado está usando uma
versão mais antiga do agente na seção de servidores registrados de um Serviço de Sincronização de
Armazenamento.
O tempo de vida de uma versão do agente secundário está associado à versão principal associada. Por
exemplo, quando a versão do agente 3.0 for lançada, as versões do agente 2.* serão todas definidas para
expirar conjuntamente.
NOTE
A instalação de uma versão do agente com um aviso de expiração exibirá um aviso, porém com êxito. A tentativa de
instalar ou conectar uma versão do agente expirada não tem suporte e será bloqueada.
Próximas etapas
Considere as configurações de firewall e proxy
Implantar os Arquivos do Azure
Considerações de rede dos Arquivos do Azure
Você pode se conectar a um compartilhamento de arquivo do Azure de duas maneiras:

Acessando o compartilhamento diretamente por meio dos protocolos SMB ou FileREST. Esse padrão de
acesso é empregado principalmente quando é possível eliminar o máximo possível de servidores locais.
Criando um cache do compartilhamento de arquivo do Azure em um servidor local com a Sincronização de
Arquivos do Azure e acessando os dados do compartilhamento de arquivo do servidor local com o
protocolo de sua escolha (SMB, NFS, FTPS etc.) para seu caso de uso. Esse padrão de acesso é útil porque ele
combina o melhor de desempenho local e escala de nuvem e serviços anexáveis sem servidor, como o
Backup do Azure.
Este artigo se concentra em como configurar a rede para quando seu caso de uso chamar o acesso ao
compartilhamento de arquivo do Azure diretamente, em vez de usar a Sincronização de Arquivos do Azure. Para
obter mais informações sobre considerações de rede para uma implantação da Sincronização de Arquivos do
Azure, consulte Como configurar as definições de firewall e proxy da Sincronização de Arquivos do Azure.
A configuração de rede para compartilhamentos de arquivos do Azure é feita na conta de armazenamento do
Azure. Uma conta de armazenamento é um constructo de gerenciamento que representa um pool
compartilhado de armazenamento no qual você pode implantar vários compartilhamentos de arquivos bem
como outros recursos de armazenamento, como filas ou contêineres de blob. As contas de armazenamento
expõem várias configurações que ajudam a proteger o acesso à rede para seus compartilhamentos de arquivos:
pontos de extremidade de rede, configurações de firewall da conta de armazenamento e criptografia em
trânsito.
Recomendamos ler Planejando uma implantação de Arquivos do Azure antes de ler este guia conceitual.
Acessar seus compartilhamentos de arquivos do Azure

Quando você implanta um compartilhamento de arquivo do Azure em uma conta de armazenamento, o
compartilhamento de arquivo é imediatamente acessível por meio do ponto de extremidade público da conta
de armazenamento. Isso significa que as solicitações autenticadas, como solicitações autorizadas pela
identidade de logon de um usuário, podem se originar de maneira segura de dentro ou fora do Azure.
Em muitos ambientes de clientes, uma montagem inicial do compartilhamento de arquivo do Azure em sua
estação de trabalho local falhará, mesmo que as montagens de VMs do Azure tenham tido êxito. O motivo disso
é que muitas organizações e ISPs (provedores de serviços de Internet) bloqueiam a porta que o SMB usa para
se comunicar, a porta 445. Essa prática se origina de diretrizes de segurança sobre versões herdadas e
preteridas do protocolo SMB. Embora o SMB 3.0 seja um protocolo seguro para a Internet, versões mais antigas
do SMB, principalmente o SMB 1.0, não são. Os compartilhamentos de arquivo do Azure só podem ser
acessados externamente por meio do SMB 3.0 e do protocolo FileREST (que também é um protocolo seguro
para a Internet) por meio do ponto de extremidade público.
Como a maneira mais fácil de acessar o compartilhamento de arquivo do Azure local é abrir sua rede local na
porta 445, a Microsoft recomenda as seguintes etapas para remover o SMB 1.0 do seu ambiente:
1. Verifique se o SMB 1.0 foi removido ou desabilitado nos dispositivos de sua organização. Todas as versões
atualmente compatíveis com o Windows e o Windows Server dão suporte à remoção ou à desabilitação do
SMB 1.0 e, desde o lançamento do Windows 10, versão 1709, não há instalação do SMB 1.0 no Windows por
padrão. Para saber mais sobre como desabilitar o SMB 1.0, consulte nossas páginas específicas do sistema
operacional:
Como proteger o Windows/Windows Server
Como proteger o Linux
2. Certifique-se de que nenhum produto em sua organização exija o SMB 1.0 e remova aqueles que o fazem.
Mantemos um Centro de roteamento de produtos do SMB1, que contém todos os produtos da Microsoft e
de terceiros que exigem o SMB 1.0.
3. (Opcional) Use um firewall de terceiros com a rede local de sua organização para impedir o tráfego do SMB
1.0 de sair de seu limite organizacional.
Se a organização exigir que a porta 445 seja bloqueada de acordo com a política ou o regulamento ou sua
organização exigir que o tráfego para o Azure siga um caminho determinístico, você poderá usar o Gateway de
VPN do Azure ou o ExpressRoute para criar um túnel de tráfego para seus compartilhamentos de arquivo do
Azure.
IMPORTANT
Mesmo se você decidir usar um método alternativo para acessar seus compartilhamentos de arquivo do Azure, o
Microsoft ainda recomendará remover o SMB 1.0 do seu ambiente.
Criação de um túnel de tráfego por uma rede privada virtual ou ExpressRoute

Quando você estabelecer um túnel de rede entre a rede local e o Azure, você emparelhará sua rede local com
uma ou mais redes virtuais no Azure. Uma rede virtual, ou VNet, é semelhante a uma rede tradicional que você
operaria no local. Como uma conta de armazenamento do Azure ou uma VM do Azure, uma VNet é um recurso
do Azure que é implantado em um grupo de recursos.
Os Arquivos do Azure dão suporte aos seguintes mecanismos para criar túnel de tráfego entre as estações de
trabalho e servidores locais e o Azure:
Gateway de VPN do Azure: Um gateway de VPN é um tipo específico de gateway de rede virtual que é usado
para enviar tráfego criptografado entre uma rede virtual do Azure e uma localização alternativa (como
localmente) na Internet. Um Gateway de VPN do Azure é um recurso do Azure que pode ser implantado em
um grupo de recursos junto com uma conta de armazenamento ou outros recursos do Azure. Os gateways
de VPN expõem dois tipos diferentes de conexões:
Conexões de gateway de VPN P2S (ponto a site), que são conexões VPN entre o Azure e um cliente
individual. Essa solução é útil principalmente para dispositivos que não fazem parte da rede local de
sua organização, como telecomutadores que desejam poder montar o compartilhamento de arquivo
do Azure de casa, de uma cafeteria ou de um hotel em trânsito. Para usar uma conexão VPN P2S com
os Arquivos do Azure, será preciso configurar uma conexão VPN P2S para cada cliente que desejar se
conectar. Para simplificar a implantação de uma conexão VPN P2S, confira Configurar uma VPN P2S
(Ponto a Site) no Windows para uso com os Arquivos do Azure e Configurar uma VPN P2S (Ponto a
Site) no Linux para uso com os Arquivos do Azure.
VPN S2S (site a site), que são conexões VPN entre o Azure e a rede de sua organização. Uma conexão
VPN S2S permite que você configure uma conexão VPN uma vez, para um servidor VPN ou
dispositivo hospedado na rede de sua organização, em vez de fazer isso para cada dispositivo cliente
que precisar acessar o compartilhamento de arquivo do Azure. Para simplificar a implantação de uma
conexão VPN S2S, confira Configurar uma VPN S2S (Site a Site) para uso com os Arquivos do Azure.
ExpressRoute, que permite que você crie uma rota definida entre o Azure e sua rede local que não atravesse
a Internet. Como o ExpressRoute fornece um caminho dedicado entre o datacenter local e o Azure, ele pode
ser útil quando o desempenho da rede é importante. O ExpressRoute também é uma boa opção quando os
requisitos regulatórios ou de política de sua organização exigem um caminho determinístico para seus
recursos na nuvem.
Independentemente do método de túnel que você usa para acessar seus compartilhamentos de arquivo do
Azure, você precisa de um mecanismo para verificar se o tráfego para sua conta de armazenamento passa pelo
túnel, em vez de pela conexão de Internet regular. É tecnicamente possível rotear para o ponto de extremidade
público da conta de armazenamento. No entanto, isso requer o hard-coding de todos os endereços IP dos
clusters de armazenamento do Azure em uma região, pois as contas de armazenamento podem ser movidas
entre clusters de armazenamento a qualquer momento. Isso também exige a atualização constante dos
mapeamentos de endereços IP, já que novos clusters são adicionados o tempo todo.
Em vez de realizar hard-coding do endereço IP de suas contas de armazenamento para suas regras de
roteamento de VPN, recomendamos usar pontos de extremidade privados, que oferecem à sua conta de
armazenamento um endereço IP do espaço de endereço de uma rede virtual do Azure. Como a criação de um
túnel para o Azure estabelece o emparelhamento entre a rede local e uma ou mais redes virtuais, isso habilita
os roteiros corretos de maneira durável.
Pontos de extremidade privados
Além do ponto de extremidade público padrão para uma conta de armazenamento, os Arquivos do Azure
oferecem a opção de ter um ou mais pontos de extremidade privados. Um ponto de extremidade privado é um
ponto de extremidade que só pode ser acessado dentro de uma rede virtual do Azure. Quando você cria um
ponto de extremidade privado para sua conta de armazenamento, sua conta de armazenamento obtém um
endereço IP privado de dentro do espaço de endereço de sua rede virtual, de maneira semelhante a como um
servidor de arquivos local ou um dispositivo NAS recebe um endereço IP dentro do espaço de endereço
dedicado de sua rede local.
Um ponto de extremidade privado individual está associado a uma sub-rede de rede virtual do Azure específica.
Uma conta de armazenamento pode ter pontos de extremidade privados em mais de uma rede virtual.
O uso de pontos de extremidade privados com Arquivos do Azure permite que você:
Conecte-se com segurança aos compartilhamentos de arquivo do Azure de redes locais usando uma
conexão VPN ou ExpressRoute com emparelhamento privado.
Projeta seus compartilhamentos de arquivo do Azure configurando o firewall da conta de armazenamento
para bloquear todas as conexões no ponto de extremidade público. Por padrão, a criação de um ponto de
extremidade privado não bloqueia conexões com o ponto de extremidade público.
Aumente a segurança da rede virtual permitindo que você bloqueie o vazamento de dados da rede virtual (e
limites de emparelhamento).
Para criar um ponto de extremidade privado, confira Configuração de pontos de extremidade privados para os
Arquivos do Azure.
Pontos de extremidade privados e DNS
Quando você cria um ponto de extremidade privado, por padrão também criamos uma zona DNS privada (ou
atualizamos uma existente) correspondente ao subdomínio privatelink . A rigor, a criação de uma zona DNS
privada não é necessária para usar um ponto de extremidade privado para sua conta de armazenamento, mas é
altamente recomendável em geral e explicitamente necessário ao montar seu compartilhamento de arquivo do
Azure com uma entidade de usuário do Active Directory ou acessar da API FileREST.
NOTE
Este artigo usa o sufixo DNS da conta de armazenamento para as regiões Públicas do Azure, core.windows.net . Esse
comentário também se aplica a nuvens soberanas do Azure, como a nuvem do Governo dos EUA para Azure e a nuvem
do Azure China – só substitua os sufixos apropriados para seu ambiente.
Em sua zona DNS privada, criamos um registro A para storageaccount.privatelink.file.core.windows.net e um

registro CNAME para o nome regular da conta de armazenamento, que segue o padrão
storageaccount.file.core.windows.net . Como a zona DNS privada do Azure está conectada à rede virtual que
contém o ponto de extremidade privado, você pode observar a configuração de DNS ao chamar o cmdlet
Resolve-DnsName do PowerShell em uma VM do Azure (ou nslookup no Windows e no Linux):
Resolve-DnsName -Name "storageaccount.file.core.windows.net"
Nesse exemplo, a conta de armazenamento storageaccount.file.core.windows.net resolve para o endereço IP

privado do ponto de extremidade privado, que é 192.168.0.4 .
Name Type TTL Section NameHost

---- ---- --- ------- --------
storageaccount.file.core.windows. CNAME 29 Answer csostoracct.privatelink.file.core.windows.net
net
Name : storageaccount.privatelink.file.core.windows.net
QueryType : A
TTL : 1769
Section : Answer
IP4Address : 192.168.0.4
Name : privatelink.file.core.windows.net
QueryType : SOA
TTL : 269
Section : Authority
NameAdministrator : azureprivatedns-host.microsoft.com
SerialNumber : 1
TimeToZoneRefresh : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration : 2419200
DefaultTTL : 300
Se você executar o mesmo comando localmente, verá que a mesma conta de armazenamento resolve o
endereço IP público da conta de armazenamento; storageaccount.file.core.windows.net é um registro CNAME
para storageaccount.privatelink.file.core.windows.net , que, por sua vez, é um registro CNAME do cluster de
armazenamento do Azure que hospeda a conta de armazenamento:

---- ---- --- ------- --------
storageaccount.file.core.windows. CNAME 60 Answer storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME 60 Answer file.par20prdstr01a.store.core.windows.net
ore.windows.net
Name : file.par20prdstr01a.store.core.windows.net
QueryType : A
TTL : 60
Section : Answer
IP4Address : 52.239.194.40
Isso reflete o fato de que a conta de armazenamento pode expor o ponto de extremidade público e um ou mais
pontos de extremidade privados. Para verificar se o nome da conta de armazenamento resolve o endereço IP
privado do ponto de extremidade privado, é necessário alterar a configuração em seus servidores DNS locais.
Isso pode ser realizado de várias maneiras:
Modificar os arquivos de hosts em seus clientes para fazer o storageaccount.file.core.windows.net resolver
o endereço IP privado do ponto de extremidade privado desejado. Isso não é recomendável para ambientes
de produção, já que você precisará fazer essas alterações em cada cliente que desejar montar seus
compartilhamentos de arquivo do Azure e as alterações na conta de armazenamento ou no ponto de
extremidade privado não serão manipuladas automaticamente.
Criar um registro A para storageaccount.file.core.windows.net em seus servidores DNS locais. Isso tem a
vantagem de que os clientes em seu ambiente local poderão resolver automaticamente a conta de
armazenamento sem a necessidade de configurar cada cliente; no entanto, essa solução é igualmente frágil à
modificação do arquivo de hosts porque as alterações não são refletidas. Embora essa solução seja frágil, ela
pode ser a melhor opção para alguns ambientes.
Encaminhe a zona core.windows.net de seus servidores DNS locais para a zona DNS privada do Azure. O
host DNS privado do Azure pode ser acessado por meio de um endereço IP especial ( 168.63.129.16 ) que só
pode ser acessado dentro de redes virtuais vinculadas à zona DNS privada do Azure. Para solucionar essa
limitação, você pode executar servidores DNS adicionais dentro de sua rede virtual que encaminharão
core.windows.net para a zona DNS privada do Azure. Para simplificar essa configuração, fornecemos os
cmdlets do PowerShell que implantarão automaticamente os servidores DNS em sua rede virtual do Azure e
os configurarão conforme desejado. Para saber como configurar o encaminhamento de DNS, confira
Configurar DNS com os Arquivos do Azure.
Configurações de firewall da conta de armazenamento

Um firewall é uma política de rede que controla quais solicitações têm permissão para acessar o ponto de
extremidade público para uma conta de armazenamento. Usando o firewall da conta de armazenamento, você
pode restringir o acesso ao ponto de extremidade público da conta de armazenamento a determinados
endereços ou intervalos IP ou a uma rede virtual. Em geral, a maioria das políticas de firewall para uma conta de
armazenamento restringirá o acesso de rede a uma ou mais redes virtuais.
Há duas abordagens para a restrição do acesso a uma conta de armazenamento a uma rede virtual:
Crie um ou mais pontos de extremidade privados para a conta de armazenamento e restrinja todo o acesso
ao ponto de extremidade público. Com isso, apenas o tráfego proveniente de dentro das redes virtuais
desejadas poderá acessar os compartilhamentos de arquivo do Azure dentro da conta de armazenamento.
Restrinja o ponto de extremidade público a uma ou mais redes virtuais. Isso funciona usando uma
funcionalidade da rede virtual denominada pontos de extremidade de serviço. Quando você restringir o
tráfego a uma conta de armazenamento por meio de um ponto de extremidade de serviço, você ainda
acessará a conta de armazenamento por meio do endereço IP público.
Para saber mais sobre como configurar o firewall da conta de armazenamento, confira configurar firewalls de
armazenamento e redes virtuais do Azure.
Por padrão, todas as contas de armazenamento do Azure têm criptografia em trânsito habilitada. Isso significa
que quando você montar um compartilhamento de arquivo via SMB ou acessá-lo por meio do protocolo
FileREST (por exemplo, por meio do portal do Azure, do PowerShell/CLI ou de SDKs do Azure), os Arquivos do
Azure só permitirão a conexão se for feita com o SMB 3.0 e com criptografia ou HTTPS. Os clientes que não são
compatíveis com SMB 3.0 ou os clientes que são compatíveis com SMB 3.0, mas não com a criptografia SMB,
não poderão montar o compartilhamento de arquivo do Azure se a criptografia em trânsito estiver habilitada.
Para obter mais informações sobre quais sistemas operacionais são compatíveis com o SMB 3.0 com
criptografia, consulte nossa documentação detalhada para Windows, macOS e Linux. Todas as versões atuais do
PowerShell, da CLI e dos SDKs são compatíveis com HTTPS.
Você pode desabilitar a criptografia em trânsito para uma conta de armazenamento do Azure. Quando a
criptografia estiver desabilitada, os Arquivos do Azure também permitirão o SMB 2.1, o SMB 3.0 sem
criptografia e as chamadas à API FileREST não criptografadas sobre HTTP. O principal motivo para desabilitar a
criptografia em trânsito é dar suporte a um aplicativo herdado que deve ser executado em um sistema
operacional mais antigo, como o Windows Server 2008 R2 ou a distribuição mais antiga do Linux. Os Arquivos
do Azure só permitem conexões SMB 2.1 na mesma região do Azure que o compartilhamento de arquivo do
Azure. Um cliente SMB 2.1 fora da região do Azure do compartilhamento de arquivo do Azure, como local ou
em uma região diferente do Azure, não será capaz de acessar o compartilhamento de arquivo.
Confira também
Visão geral do Arquivos do Azure
Visão geral da Camada de Nuvem
A camada de nuvem é um recurso opcional da Sincronização de Arquivos do Azure em que arquivos acessados
frequentemente são armazenados em cache localmente no servidor, enquanto todos os outros arquivos são
organizados em camadas para Arquivos do Azure com base nas configurações de política. Quando um arquivo
está disposto em camadas, o filtro do sistema de arquivos da Sincronização de Arquivos do Azure
(StorageSync.sys) substitui o arquivo localmente por um ponteiro ou ponto de nova análise. O ponto de nova
análise representa uma URL para o arquivo nos Arquivos do Azure. Um arquivo em camadas tem o atributo
"offline" e o atributo FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS definidos em NTFS, de modo que aplicativos de
terceiros podem identificar com segurança os arquivos dispostos em camadas.
Quando um usuário abre um arquivo em camadas, Sincronização de Arquivos do Azure rechama diretamente os
dados de arquivo dos arquivos do Azure sem que o usuário precise saber que o arquivo está armazenado no
Azure.
IMPORTANT
Não há suporte para a disposição em camadas na nuvem no volume do sistema do Windows.
IMPORTANT
Para recuperar os arquivos que foram em camadas, a largura de banda da rede deve ser de pelo menos 1 Mbps. Se a
largura de banda da rede for menor que 1 Mbps, os arquivos poderão falhar ao se recuperar com um erro de tempo limite.
Perguntas frequentes das Camadas de Nuvem

Como a disposição em camadas de nuvem funciona?
O filtro do sistema de Sincronização de Arquivos do Azure cria um "mapa de calor" do seu namespace em cada
ponto de extremidade do servidor. Ele monitora acessos (operações leitura e gravação) ao longo do tempo e, em
seguida, com base na frequência de acessos e no quanto eles são recentes, atribui uma pontuação de calor a
todos os arquivos. Um arquivo acessado com frequência que foi aberto recentemente é considerado frequente,
enquanto um arquivo que quase não é usado e que não foi acessado por algum tempo é considerado frio.
Quando o volume de arquivos em um servidor excede o limite de espaço livre do volume definido, ele fará a
disposição dos arquivos mais frios em camadas nos Arquivos do Azure até que o percentual de espaço livre
necessário seja alcançado.
Nas versões 4.0 e superiores do agente de Sincronização de Arquivos do Azure, é possível especificar
adicionalmente uma política de data em cada ponto de extremidade do servidor que classificará os arquivos não
acessados ou modificados em um determinado número de dias.
Qual é o tamanho mínimo do arquivo de um arquivo para uma camada?
Para as versões 9. x e mais recentes do agente, o tamanho mínimo do arquivo para um arquivo para a camada é
baseado no tamanho do cluster do sistema de arquivos (o dobro do tamanho do cluster do sistema de arquivos).
Por exemplo, se o tamanho do cluster do sistema de arquivos NTFS for 4 KB, o tamanho mínimo resultante de um
arquivo para a camada será de 8 KB. Para o Agent versões 8. x e mais antigas, o tamanho mínimo do arquivo para
um arquivo para camada é 64 KB.
Como a política de disposição em camadas do espaço livre no volume funciona?
O espaço livre no volume é a quantidade de espaço livre que você deseja reservar no volume no qual reside um
ponto de extremidade do servidor. Por exemplo, se o espaço livre do volume estiver definido como 20% em um
volume que tenha um ponto de extremidade do servidor, até 80% do espaço do volume será ocupado pelos
arquivos acessados mais recentemente, com quaisquer arquivos restantes que não caibam nesse espaço sendo
dispostos em camadas no Azure. O espaço livre no volume aplica-se no nível do volume, em vez de no nível de
diretórios individuais ou de grupos de sincronização.
Como a política de disposição em camadas para espaço livre no volume funciona com relação a novos pontos
de extremidade do servidor?
Quando um ponto de extremidade do servidor é provisionado recentemente e conectado a um compartilhamento
de arquivos do Azure, o servidor primeiro eliminará o namespace e, em seguida, eliminará os arquivos reais, até
atingir seu limite de espaço livre do volume. Esse processo é também conhecido como recuperação de desastre
rápida ou restauração de namespace rápida.
Como o espaço livre no volume é interpretado quando tenho vários pontos de extremidade do servidor em
um volume?
Quando há mais de um ponto de extremidade do servidor em um volume, o limite de espaço livre no volume
efetivo é o maior espaço livre do volume especificado em qualquer ponto de extremidade do servidor nesse
volume. Os arquivos serão colocados em camadas de acordo com seus padrões de uso, independentemente do
ponto de extremidade do servidor ao qual pertencem. Por exemplo, se houver dois pontos de extremidade do
servidor em um volume, Endpoint1 e Endpoint2, em que o Endpoint1 tenha um limite de espaço livre no volume
de 25% e o Endpoint2 tenha um limite de espaço livre no volume de 50%, o limite de espaço livre no volume dos
dois pontos de extremidade do servidor será de 50%.
Como a política de camada de data funciona em conjunto com a política de camada de espaço livre no volume?
Ao habilitar a camada de nuvem em um ponto de extremidade do servidor, você define uma política de espaço
livre no volume. Ela sempre tem precedência sobre qualquer outra política, incluindo a política de datas.
Opcionalmente, você pode habilitar uma política de data para cada ponto de extremidade do servidor nesse
volume. Essa política gerencia que somente os arquivos acessados (ou seja, lidos ou gravados) dentro do
intervalo de dias que essa política descreve será mantida local. Os arquivos não acessados com o número de dias
especificado serão em camadas.
A camada de nuvem usa o último tempo de acesso para determinar quais arquivos devem ser em camadas. O
driver de filtro de camadas de nuvem (storagesync. sys) acompanha o horário do último acesso e registra as
informações no armazenamento de calor em camadas de nuvem. Você pode ver o armazenamento de calor
usando um cmdlet do PowerShell local.
Import-Module '<SyncAgentInstallPath>\StorageSync.Management.ServerCmdlets.dll'
Get-StorageSyncHeatStoreInformation '<LocalServerEndpointPath>'
IMPORTANT
O carimbo de data/hora Last-acessado não é uma propriedade rastreada por NTFS e, portanto, não é visível por padrão no
explorador de arquivos. Não use o último-modificador-timestamp em um arquivo para verificar se a política de data
funciona conforme o esperado. Esse carimbo de data/hora rastreia apenas gravações, não leituras. Use o cmdlet mostrado
para obter o carimbo de data/hora Last-acessado para essa avaliação.
WARNING
Não ative o recurso NTFS de acompanhamento do carimbo de data/hora Last-acessado para arquivos e pastas. Esse recurso
está desativado por padrão porque tem um grande impacto no desempenho. Sincronização de Arquivos do Azure
acompanhará os últimos tempos acessados de forma automática e eficiente, e não utilizará esse recurso NTFS.
Lembre-se de que a política de espaço livre do volume sempre tem precedência e quando não há espaço livre
suficiente no volume para reter o máximo de dias de arquivos, conforme descrito pela política de data,
Sincronização de Arquivos do Azure continuará a colocar os arquivos frios em camadas até que a porcentagem de
espaço livre do volume seja atendida.
Por exemplo, digamos que você tenha uma política de camada com base em data de 60 dias e uma política de
espaço livre no volume de 20%. Se, depois de aplicar a política de data, houver menos de 20% de espaço livre no
volume, a política de espaço livre no volume será ativada e substituirá a política de data. Isso resultará em mais
arquivos em camadas, de modo que a quantidade de dados mantidos no servidor poderá ser reduzida de 60 dias
para 45 dias. Por outro lado, essa política forçará a colocação em camadas de arquivos fora do intervalo de tempo,
mesmo que não tenha atingido o limite de espaço livre e, portanto, um arquivo com 61 dias será colocado em
camadas mesmo que o volume esteja vazio.
Como determino a quantidade apropriada de espaço livre no volume?
A quantidade de dados que você deve manter armazenada localmente é determinada por alguns fatores: a largura
de banda, o padrão de acesso do seu conjunto de dados e o orçamento. Se você tiver uma conexão com baixa
largura de banda, talvez você queira manter uma parte maior de seus dados localmente para garantir que haja
um atraso mínimo para seus usuários. Caso contrário, você pode baseá-lo na taxa de rotatividade durante um
determinado período. Por exemplo, se você sabe que cerca de 10% do seu conjunto de dados de 1 TB são
alterados ou são ativamente acessados a cada mês, então talvez você queira manter 100 GB armazenados
localmente, de modo que você não fique recuperando arquivos com frequência. Se o volume é de 2 TB, é melhor
que você mantenha 5% (ou 100 GB) localmente, o que significa que o restante de 95% é o percentual de espaço
livre do volume. No entanto, é recomendável que você adicione um buffer para levar em conta os períodos de
maior variação – em outras palavras, começando com um percentual menor de espaço livre no volume e, depois,
ajustando-o mais tarde, se necessário.
Manter mais dados armazenados localmente significará custos de saída menores, já que menos arquivos serão
recuperados do Azure, mas também exigirá que você mantenha uma quantidade maior de armazenamento local,
o que terá o seu próprio custo. Depois de ter uma instância do Sincronização de Arquivos do Azure implantada,
você pode examinar a saída da sua conta de armazenamento para medir aproximadamente se as configurações
de espaço livre do volume são apropriadas para seu uso. Supondo que a conta de armazenamento contém
apenas o ponto de extremidade de nuvem da Sincronização de Arquivos do Azure (ou seja, seu compartilhamento
de sincronização), então uma saída alta significa que muitos arquivos estão sendo recuperados da nuvem, e você
deve considerar aumentar o seu cache local.
Adicionei um novo ponto de extremidade do servidor. Quanto tempo levará até que meus arquivos estejam
nessa camada de servidor?
Nas versões 4,0 e acima do agente de Sincronização de Arquivos do Azure, depois que os arquivos forem
carregados no compartilhamento de arquivos do Azure, eles serão em camadas de acordo com suas políticas
assim que a próxima sessão de camadas for executada, o que acontecerá uma vez por hora. Em agentes mais
antigos, a disposição em camadas pode levar até 24 horas para ocorrer.
Como saber se um arquivo foi distribuído em camadas?
Há várias maneiras de verificar se um arquivo foi colocado em camadas no compartilhamento de arquivos do
Azure:
Verifique os atributos de arquivo no arquivo. Clique com o botão direito do mouse em um arquivo,
navegue até Detalhes e role para baixo até a propriedade Atributos . Um arquivo em camadas tem os
seguintes atributos definidos:
C A RTA DE AT RIB UTO AT RIB UTO DEF IN IÇ Ã O

Um Archive Indica que o arquivo deve ter o

backup feito pelo software de
backup. Esse atributo é sempre
definido independentemente de o
arquivo estar em camadas ou
totalmente armazenado no disco.
P Arquivos esparsos Indica que o arquivo é um arquivo

esparso. Um arquivo esparso é um
tipo especializado de arquivo que o
NTFS oferece para uso eficiente
quando o arquivo no fluxo do disco
está basicamente vazio. A
usa arquivos esparsos, porque um
arquivo é totalmente em camadas ou
parcialmente cancelado. Em um
arquivo totalmente em camadas, o
fluxo de arquivos é armazenado na
nuvem. Em um arquivo que sofreu
recall parcial, essa parte do arquivo já
está no disco. Se o recall de um
arquivo é feito totalmente em disco,
a Sincronização de Arquivos do
Azure o converte de um arquivo
esparso em um arquivo regular. Esse
atributo só é definido no Windows
Server 2016 e mais antigo.
M Recall no acesso a dados Indica que os dados do arquivo não

estão totalmente presentes no
armazenamento local. A leitura do
arquivo fará com que pelo menos
um conteúdo do arquivo seja obtido
de um compartilhamento de
arquivos do Azure ao qual o ponto
de extremidade do servidor está
conectado. Esse atributo só é
definido no Windows Server 2019.
L Ponto de nova análise Indica que o arquivo tem um ponto

de nova análise. Um ponto de nova
análise é um ponteiro especial para
ser usado por um filtro do sistema
de arquivos. A Sincronização de
Arquivos do Azure usa pontos de
nova análise a fim de definir, para o
filtro do sistema de arquivos da
(StorageSync.sys), o local na nuvem
em que o arquivo está armazenado.
Isso dá suporte a acesso contínuo.
Os usuários não precisarão saber
que a Sincronização de Arquivos do
Azure está sendo usada ou como
obter acesso ao arquivo em seu
compartilhamento de arquivos do
Azure. Quando o recall de um
arquivo é totalmente feito, a
remove o ponto de nova análise do
arquivo.
O Offline Indica que parte ou nenhum

conteúdo do arquivo está
armazenado em disco. Quando o
recall de um arquivo é totalmente
feito, a Sincronização de Arquivos do
Azure remove esse atributo.
Você pode ver os atributos de todos os arquivos em uma pasta adicionando o campo Atributos à exibição
de tabela do Explorador de Arquivos. Para fazer isso, clique com o botão direito do mouse em uma coluna
existente (por exemplo, Tamanho ), selecione Mais e depois Atributos na lista suspensa.
Use fsutil para verificar se há pontos de nova análise em um arquivo. Conforme descrito na
opção anterior, um arquivo em camadas sempre tem um conjunto de pontos de nova análise. Um ponteiro
de nova análise é um ponteiro especial para o filtro de sistema de arquivos de Sincronização de Arquivos
do Azure (StorageSync.sys). Para verificar se um arquivo tem um ponto de nova análise, execute o utilitário
fsutil em um prompt de comandos com privilégios elevados ou em uma janela do PowerShell:
fsutil reparsepoint query <your-file-name>
Se o arquivo tiver um ponto de nova análise, você deverá ver um Valor de Marca de Nova Análise:
0x8000001e . Esse valor hexadecimal é o valor do ponto de nova análise que pertence ao Sincronização
de Arquivos do Azure. A saída também contém os dados de nova análise que representam o caminho para
o arquivo no compartilhamento de arquivos do Azure.
WARNING
O comando do utilitário fsutil reparsepoint também tem a capacidade de excluir um ponto de nova análise.
Não execute esse comando, a menos que a equipe de engenharia de Sincronização de Arquivos do Azure lhe solicite
isso. A execução desse comando pode resultar em perda de dados.
Um arquivo que eu desejo usar foi distribuído em camadas. Como é possível fazer o recall do arquivo no disco
para usá-lo localmente?
A maneira mais fácil de fazer o recall de um arquivo em disco é abri-lo. O filtro de sistema de arquivos da
Sincronização de Arquivos do Azure (StorageSync.sys) baixa o arquivo do seu compartilhamento de arquivos do
Azure perfeitamente, sem que você precise fazer nenhum trabalho. Para tipos de arquivo que podem ser lidos
parcialmente, tais como arquivos zip ou multimídia, abrir um arquivo não resultará no download do arquivo
inteiro.
Você também pode usar o PowerShell para forçar o recall de um arquivo. Essa opção poderá ser útil se você
quiser fazer o recall de vários arquivos ao mesmo tempo, por exemplo, todos os arquivos dentro de uma pasta.
Abra uma sessão do PowerShell para o nó de servidor em que a Sincronização de Arquivos do Azure está
instalada e então execute os seguintes comandos do PowerShell:
Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"

Invoke-StorageSyncFileRecall -Path <path-to-to-your-server-endpoint>
Parâmetros opcionais:
-Order CloudTieringPolicy o chamará primeiro os arquivos modificados mais recentemente.
-ThreadCount Determina quantos arquivos podem ser rechamados em paralelo.
-PerFileRetryCount determina com que frequência uma recall será tentada de um arquivo bloqueado no
momento.
-PerFileRetryDelaySeconds determina o tempo em segundos entre tentativas de recuperação e sempre deve
ser usado em combinação com o parâmetro anterior.
NOTE
Se o volume local que hospeda o servidor não tiver espaço livre suficiente para realizar o recall de todos os dados em
camadas, o cmdlet Invoke-StorageSyncFileRecall falha.
Por que, após usar a Sincronização de Arquivos do Azure, a propriedade Tamanho em disco de um arquivo não
corresponde à propriedade Tamanho?
O Explorador de Arquivos do Windows expõe duas propriedades para representar o tamanho de um arquivo:
Tamanho e Tamanho em disco . O significado dessas propriedades difere um pouco. Tamanho representa o
tamanho completo do arquivo. Tamanho em disco representa o tamanho do fluxo de arquivo que é
armazenado no disco. Os valores dessas propriedades podem diferir por vários motivos, como compactação, uso
de eliminação de duplicação de dados ou camadas de nuvem com Sincronização de Arquivos do Azure. Se um
arquivo estiver em camadas para um compartilhamento de arquivos do Azure, o tamanho no disco será zero, pois
o fluxo de arquivos será armazenado no compartilhamento de arquivos do Azure e não no disco. Também é
possível que um arquivo esteja parcialmente em camadas (ou seja parcialmente em recall). Em um arquivo
parcialmente hierárquico, parte do arquivo está no disco. Isso pode acontecer quando os arquivos são lidos
parcialmente por aplicativos como players de multimídia ou utilitários de compactação.
Como posso forçar um arquivo ou diretório a ficar em camadas?
Quando habilitado, o recurso de disposição em camadas na nuvem dispõe os arquivos em camadas
automaticamente com base no último acesso e na última modificação para alcançar o percentual de espaço livre
no volume especificado no ponto de extremidade de nuvem. Às vezes, no entanto, talvez você queira forçar um
arquivo manualmente a ser dividido em camadas. Isso pode ser útil se você salva um arquivo grande que não
pretende usar novamente por um longo período e agora deseja usar o espaço livre no volume para outros
arquivos ou pastas. Você pode forçar a disposição em camadas com os seguintes comandos do PowerShell:

Invoke-StorageSyncCloudTiering -Path <file-or-directory-to-be-tiered>
Por que meus arquivos em camadas não estão mostrando miniaturas ou visualizações no Windows Explorer?
Para arquivos em camadas, miniaturas e visualizações não estarão visíveis no ponto de extremidade do servidor.
Esse comportamento é esperado, pois o recurso de cache em miniatura do Windows ignora intencionalmente a
leitura de arquivos com o atributo offline. Com a camada de nuvem habilitada, a leitura por meio de arquivos em
camadas fará com que eles fossem baixados (rechamados).
Esse comportamento não é específico do Sincronização de Arquivos do Azure, o Windows Explorer exibe um "X
cinza" para todos os arquivos que têm o atributo offline definido. Você verá o ícone X ao acessar arquivos por
SMB. Para obter uma explicação detalhada desse comportamento,
consultehttps://blogs.msdn.microsoft.com/oldnewthing/20170503-00/?p=96105
Próximas etapas
Planejando uma implantação de Sincronização de Arquivos do Azure
Visão geral de instantâneos de compartilhamento
para Arquivos do Azure
Os Arquivos do Azure fornecem a funcionalidade de tirar instantâneos de compartilhamentos de arquivos. Os

instantâneos de compartilhamento capturam o estado de compartilhamento naquele ponto no tempo. Neste
artigo, descreveremos quais recursos os instantâneos de compartilhamento fornecem e como você pode
aproveitá-los no seu caso de uso personalizado.
Quando usar os instantâneos de compartilhamento

Proteção contra corrupção de dados e erro do aplicativo
Os aplicativos que usam compartilhamentos dos Arquivos do Azure executam operações, como leitura, gravação,
armazenamento, transmissão e processamento. Um aplicativo pode ser configurado incorretamente ou ter a
introdução não intencional de um bug que gera a substituição acidental ou danos a alguns blocos. Para ajudar a se
proteger contra esses cenários, você pode tirar um instantâneo de compartilhamento antes de implantar o novo
código de aplicativo. Se um bug ou erro do aplicativo for introduzido com a nova implantação, você poderá voltar
para uma versão anterior dos dados no compartilhamento de arquivos.
Proteção contra exclusões acidentais ou alterações indesejadas
Imagine que você está trabalhando em um arquivo de texto em um compartilhamento de arquivos. Quando o
arquivo de texto é fechado, você perde a capacidade de desfazer suas alterações. Nesses casos, será necessário
recuperar uma versão anterior do arquivo. Você poderá usar instantâneos de compartilhamento para recuperar
versões anteriores do arquivo se ele for renomeado ou excluído acidentalmente.
Objetivos gerais de backup
Depois de criar um compartilhamento de arquivos, você pode criar periodicamente um instantâneo de
compartilhamento do seu compartilhamento de arquivos para usá-lo no backup de dados. O instantâneo de
compartilhamento, quando executado periodicamente, ajuda a manter versões anteriores dos dados que podem
ser usadas em futuras auditorias exigidas ou na recuperação de desastre.
Funcionalidades
O instantâneo de compartilhamento é uma cópia somente leitura dos dados em determinado momento. Você
pode criar, excluir e gerenciar instantâneos usando a API REST. Os mesmos recursos também estão disponíveis na
biblioteca de cliente, na CLI do Azure e no portal do Azure.
Você pode exibir instantâneos de um compartilhamento usando a API REST e o SMB. Você pode recuperar a lista
de versões do diretório ou arquivo e montar uma versão específica diretamente como uma unidade (disponível
apenas no Windows - consulte Limites).
Quando um instantâneo de compartilhamento é criado, ele pode ser lido, copiado ou excluído, mas não
modificado. Você não pode copiar um instantâneo de compartilhamento inteiro para outra conta de
armazenamento. Você deve fazer isto arquivo por arquivo, usando AzCopy ou outros mecanismos de cópias.
A capacidade de instantâneo de compartilhamento é fornecida no nível de compartilhamento de arquivo. A
recuperação é fornecida no nível de arquivo individual, para permitir a restauração de arquivos individuais. Você
pode restaurar um compartilhamento de arquivo completo usando o SMB, a API REST, o portal, a biblioteca de
cliente ou ferramentas de PowerShell/CLI.
Um instantâneo de compartilhamento de um compartilhamento de arquivos é idêntico ao seu compartilhamento
de arquivo de base. A única diferença é que um valor de DateTime é acrescentado ao URI do compartilhamento
para indicar o horário em que o compartilhamento de instantâneo foi tirado. Por exemplo, se um URI de
compartilhamento de arquivos for/http:/StorageSample.Core.File.Windows.net/MyShare, o URI do instantâneo de
compartilhamento será semelhante a:
http://storagesample.core.file.windows.net/myshare?snapshot=2011-03-09T01:42:34.9360000Z
Os instantâneos de compartilhamento persistem até que sejam excluídos deliberadamente. Um instantâneo de

compartilhamento não pode sobreviver além do seu compartilhamento de arquivo base. Você pode enumerar os
instantâneos associados ao compartilhamento de arquivos principal para acompanhar seus instantâneos atuais.
Quando você cria um instantâneo de compartilhamento de um compartilhamento de arquivos, os arquivos que
residem nas propriedades do sistema do compartilhamento são copiados para o instantâneo de
compartilhamento com os mesmos valores. Os arquivos principais e os metadados do compartilhamento de
arquivos também são copiados no instantâneo, a menos que você especifique metadados diferentes para o
instantâneo ao criá-lo.
Você não pode excluir um compartilhamento que tenha instantâneos de compartilhamento sem excluir todos os
seus instantâneos de compartilhamento primeiro.
Uso de espaço
Os instantâneos de compartilhamento são incrementais por natureza. Somente os dados que foram alterados
depois que o instantâneo mais recente do compartilhamento é salvo. Isso minimiza o tempo necessário para criar
o instantâneo de compartilhamento e economiza nos custos de armazenamento. As eventuais operações de
gravação no objeto ou operação de atualização de metadados ou de propriedade são contadas como "conteúdo
alterado" e serão armazenadas no instantâneo de compartilhamento.
Para economizar espaço, você pode excluir o instantâneo de compartilhamento cujo período tenha tido uma
variação maior.
Embora os instantâneos de compartilhamento sejam salvos incrementalmente, você precisa manter somente o
instantâneo mais recente do compartilhamento para restaurá-lo. Quando você exclui um instantâneo de
compartilhamento, somente os dados exclusivos desse instantâneo de compartilhamento são removidos. Os
instantâneos ativos contêm todas as informações necessárias para procurar e restaurar seus dados (da hora em
que o instantâneo de compartilhamento foi tirado) no local original ou em um local alternativo. Você pode
restaurar no nível do item.
Instantâneos não contam em relação ao limite de compartilhamento de 5 TB. Não há nenhum limite para a
quantidade total de espaço ocupado pelo instantâneo de compartilhamento. Os limites de conta de
armazenamento ainda se aplicam.
limites
O número máximo de instantâneos de compartilhamento que os Arquivos do Azure permitem atualmente é 200.
Depois de 200 instantâneos de compartilhamento, os instantâneos mais antigos precisarão ser excluídos para
criar novos instantâneos de compartilhamento.
Não há nenhum limite de chamadas simultâneas para criar o instantâneo de compartilhamento. Não há nenhum
limite de quantidade de espaço que os instantâneos de compartilhamento de determinado compartilhamento de
arquivos pode consumir.
Atualmente, não é possível montar instantâneos compartilhados no Linux. Isso ocorre porque o cliente SMB do
Linux não tem suporte para instantâneos de montagem como o Windows.
Copiando dados para um compartilhamento de um instantâneo de
compartilhamento
As operações de cópia que envolvem arquivos e instantâneos de compartilhamento seguem estas regras:
Você pode copiar arquivos individuais de um instantâneo de compartilhamento de arquivos em seu
compartilhamento base ou em outro local. Você pode restaurar uma versão anterior de um arquivo ou restaurar o
compartilhamento de arquivos completo copiando arquivo por arquivo do instantâneo de compartilhamento. O
instantâneo de compartilhamento não será promovido a compartilhamento base.
O instantâneo de compartilhamento permanece intacto após a cópia, mas o compartilhamento de arquivos base é
substituído por uma cópia dos dados que estavam disponíveis no instantâneo de compartilhamento. Todos os
arquivos restaurados contam como “conteúdo alterado”.
Você pode copiar um arquivo em um instantâneo de compartilhamento para um destino diferente com um nome
diferente. O arquivo de destino resultante é um arquivo gravável que não é um instantâneo de compartilhamento.
Nesse caso, o compartilhamento de arquivos base permanecerá intacto.
Quando um arquivo de destino é substituído por uma cópia, todos os instantâneos de compartilhamento
associados ao arquivo de destino original permanecem intactos.
Práticas recomendadas gerais

Ao executar infraestrutura do Azure, automatize os backups para recuperação de dados sempre que possível. As
ações automáticas são mais confiáveis do que os processos manuais, ajudando a melhorar a capacidade de
recuperação e proteção dos dados. Você pode usar a API REST, o SDK do cliente ou scripts para automação.
Antes de implantar o agendador de instantâneos de compartilhamento, leve em conta cuidadosamente as
configurações de retenção e a frequência dos instantâneos de compartilhamento para evitar incorrer em encargos
desnecessários.
Compartilhamentos de instantâneos fornecem apenas a proteção no nível de arquivo. Compartilhamentos de
instantâneos não impedem exclusões de digitação acidental em uma conta de armazenamento ou
compartilhamento de arquivos. Para ajudar a proteger a conta de armazenamento de exclusões acidentais, você
pode bloquear a conta de armazenamento ou o grupo de recursos.
Próximas etapas
Trabalhar com instantâneos de compartilhamento em:
PowerShell
CLI
Windows
Perguntas frequentes sobre instantâneo de compartilhamento
Redundância do Armazenamento do Azure
O armazenamento do Azure sempre armazena várias cópias de seus dados para que eles sejam protegidos
contra eventos planejados e não planejados, incluindo falhas transitórias de hardware, interrupções de rede ou
energia e desastres naturais em massa. A redundância garante que sua conta de armazenamento atenda ao
SLA (contrato de nível de serviço) do armazenamento do Azure , mesmo diante de falhas.
Ao decidir qual opção de redundância é melhor para seu cenário, considere as compensações entre custos
menores e maior disponibilidade e durabilidade. 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 os dados são replicados para um segundo local que está geograficamente distante para a região
primária, para proteger contra desastres regionais
Se o aplicativo requer acesso de leitura aos dados replicados na região secundária se a região primária ficar
indisponível por qualquer motivo
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
armazenamento do Azure oferece duas opções de como os dados são replicados na região primária:
O LRS (armazenamento com redundância local) copia seus dados de forma síncrona três vezes em um
único local físico na região primária. LRS é a opção de replicação menos cara, mas não é recomendada para
aplicativos que exigem alta disponibilidade.
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, a Microsoft
recomenda usar o ZRS na região primária e também replicar para uma região secundária.
Armazenamento com redundância local
O LRS (armazenamento com redundância local) Replica seus dados três vezes em um único local físico na
região primária. O LRS fornece pelo menos 99,999999999% (11 noves) de durabilidade de objetos em um
determinado ano.
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 um desastre,
como incêndio ou inundação, ocorrer no data center, todas as réplicas de uma conta de armazenamento usando
LRS poderão ser perdidas ou irrecuperáveis. Para atenuar esse risco, a Microsoft recomenda o uso de
armazenamento com redundância de zona (ZRS), armazenamento com redundância geográfica (GRS) ou
armazenamento com redundância de zona geográfica (GZRS).
Uma solicitação de gravação para uma conta de armazenamento que está usando o 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.
LRS é uma boa opção para os seguintes cenários:
Se seu aplicativo armazenar dados que possam ser facilmente reconstruídos, você pode optar por LRS.
Se seu aplicativo estiver restrito a replicar dados somente em um país ou região devido a requisitos de
governança de dados, você poderá optar por LRS. Em alguns casos, as regiões emparelhadas entre as quais
os dados são replicados geograficamente podem estar em outro país ou região. Para obter mais
informações sobre pares de regiões, consulte Regiões do Azure.
Armazenamento com redundância de zona
O ZRS (armazenamento com redundância de zona) replica os dados do armazenamento do Azure de forma
síncrona em três zonas de disponibilidade do Azure na região primária. Cada zona de disponibilidade é um
local físico separado com energia, resfriamento e rede independentes. O ZRS oferece durabilidade para objetos
de dados de armazenamento do Azure de pelo menos 99,9999999999% (12 noves) em um determinado ano.
Com o ZRS, seus dados ainda estarão acessíveis para operações de leitura e gravação, mesmo se uma zona
ficar indisponível. Se uma zona ficar indisponível, o Azure assumirá as atualizações de rede, como o
desapontador de DNS. Essas atualizações podem afetar seu aplicativo se você acessar os dados antes que as
atualizações sejam concluídas. Ao criar aplicativos para ZRS, siga as práticas para tratamento de falhas
transitórias, incluindo a implementação de políticas de repetição 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 entre as três zonas de disponibilidade.
A Microsoft recomenda usar o ZRS na região primária para cenários que exigem consistência, durabilidade e
alta disponibilidade. O ZRS fornece desempenho excelente, baixa latência e resiliência para seus dados se eles
ficarem temporariamente indisponíveis. No entanto, ZRS sozinho 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, a Microsoft recomenda o uso de GZRS ( armazenamento com redundância de zona geográfica ), que
usa o ZRS na região primária e também Replica geograficamente seus dados para uma região secundária.
A tabela a seguir mostra quais tipos de contas de armazenamento dão suporte a ZRS em quais regiões:
T IP O DE C O N TA DE
A RM A Z EN A M EN TO REGIÕ ES C O M SUP O RT E SERVIÇ O S C O M SUP O RT E
Uso geral v21 Sudeste da Ásia Blobs de bloco

Leste da Austrália Blobs de páginas2
Norte da Europa Compartilhamentos de arquivos
Europa Ocidental (padrão)
França Central Tabelas
Leste do Japão Filas
Norte da África do Sul
Sul do Reino Unido
EUA Central
Leste dos EUA
Leste dos EUA 2
Oeste dos EUA 2
BlockBlobStorage1 Europa Ocidental Blobs de blocos somente

Leste dos EUA
Armazenamento de Europa Ocidental Somente arquivos do Azure

Leste dos EUA
1 atualmente, a camada de arquivo morto não tem suporte para contas ZRS.
2 as contas de armazenamento que contêm o Azure Managed disks para máquinas virtuais sempre usam lRS.
Os discos não gerenciados do Azure também devem usar LRS. É possível criar uma conta de armazenamento
para discos não gerenciados do Azure que usa GRS, mas não é recomendável devido a problemas potenciais
com consistência em relação à replicação geográfica assíncrona. Os discos gerenciados ou não não gerenciados
dão suporte a ZRS ou GZRS. Para obter mais informações sobre discos gerenciados, consulte preços para Azure
Managed disks.
Para obter informações sobre quais regiões dão suporte a ZRS, consulte supor te de ser viços por região em
o que são zonas de disponibilidade do Azure?.
Redundância em uma região secundária

Para aplicativos que exigem alta disponibilidade, você pode optar por copiar, além disso, os dados em sua conta
de armazenamento para uma região secundária que está 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, os dados serão duráveis
mesmo no caso de uma interrupção regional completa ou um desastre no qual a região primária não seja
recuperável.
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 com suporte do Azure, consulte regiões do Azure.
O armazenamento do Azure oferece duas opções para copiar seus dados para uma região secundária:
O armazenamento com redundância geográfica (GRS) copia seus dados de forma síncrona três vezes
em um único local físico na região primária usando lRS. Em seguida, ele copia os dados de forma assíncrona
para um único local físico na região secundária.
O GZRS (armazenamento com redundância de zona geográfica) copia seus dados de forma síncrona
em três zonas de disponibilidade do Azure na região primária usando ZRS. Em seguida, ele copia os dados
de forma assíncrona para um único local físico na região secundária.
A principal diferença entre GRS e GZRS é como os dados são replicados na região primária. No local
secundário, os dados são sempre replicados três vezes de forma síncrona, usando LRS.
Com GRS ou GZRS, os dados no local secundário não estão disponíveis para acesso de leitura ou gravação, a
menos que haja um failover para a região secundária. Para acesso de leitura para o local secundário, configure
sua conta de armazenamento para usar o armazenamento com redundância geográfica com acesso de leitura
(RA-GRS) ou o armazenamento com redundância de acesso de leitura (RA-GZRS). Para obter mais informações,
consulte acesso de leitura aos dados na região secundária.
Se a região primária ficar indisponível, você poderá optar por fazer failover para a região secundá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 sobre a recuperação de desastres e sobre como fazer failover para a
região secundária, consulte recuperação de desastre e failover da conta de armazenamento.
IMPORTANT
Como os dados são replicados para a região secundária de forma assíncrona, uma falha que afeta a região primária
poderá resultar em perda de dados se a região primária não puder ser recuperada. O intervalo entre as gravações mais
recentes na região primária e a última gravação na região secundária é conhecido como o RPO (objetivo de ponto de
recuperação). O RPO indica o ponto no tempo em que os dados podem ser recuperados. O armazenamento do Azure
normalmente tem um RPO de menos de 15 minutos, embora atualmente não haja SLA quanto ao tempo necessário para
replicar dados para a região secundária.
Armazenamento com redundância geográfica

O armazenamento com redundância geográfica (GRS) copia seus dados de forma síncrona três vezes em um
único local físico na região primária usando LRS. Em seguida, ele copia os dados de forma assíncrona para um
único local físico em uma região secundária que está a centenas de quilômetros de distância da região primária.
O GRS oferece durabilidade para objetos de dados de armazenamento do Azure de pelo menos
99.99999999999999% (16 9 ' s) em um determinado ano.
Uma operação de gravação é confirmada primeiro no local principal e replicada usando LRS. Em seguida, a
atualização é 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.
Armazenamento com redundância de zona geográfica
O GZRS (armazenamento com redundância de zona geográfica) combina a alta disponibilidade fornecida pela
redundância entre zonas de disponibilidade com proteção contra interrupções regionais fornecidas pela
replicação geográfica. Os dados em uma conta de armazenamento GZRS são copiados em 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. A Microsoft recomenda o uso do GZRS para aplicativos que exigem
consistência máxima, 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 são duráveis
no caso de uma interrupção regional completa ou um desastre no qual a região primária não seja recuperável.
O GZRS foi projetado para fornecer pelo menos a durabilidade de objetos de 99.99999999999999% (16 9) em
um determinado ano.
Somente as contas de armazenamento de uso geral v2 dão suporte a GZRS e RA-GZRS. Para obter mais
informações sobre os tipos de conta de armazenamento, consulte Visão geral da conta de armazenamento do
Azure. GZRS e RA-GZRS dão suporte a blobs de blocos, blobs de páginas (exceto discos VHD), arquivos, tabelas
e filas.
Há suporte para GZRS e RA-GZRS nas seguintes regiões:
Sudeste da Ásia
Norte da Europa
Europa Ocidental
Leste do Japão
Sul do Reino Unido
EUA Central
Leste dos EUA
Leste dos EUA 2
Oeste dos EUA 2
Para obter informações sobre preços, consulte detalhes de preços para BLOBs, arquivos, filase tabelas.
Acesso de leitura aos dados na região secundária

O armazenamento com redundância geográfica (com GRS ou GZRS) Replica seus dados para outro local físico
na região secundária para proteger contra interrupções regionais. No entanto, esses dados estarão disponíveis
para serem lidos somente se o cliente ou a Microsoft iniciar um failover da região primária para a secundária.
Quando você habilita o acesso de leitura para a região secundária, seus dados ficam disponíveis para serem
lidos se a região primária ficar indisponível. Para acesso de leitura à região secundária, habilite o
armazenamento com redundância geográfica com acesso de leitura (RA-GRS) ou o armazenamento com
redundância de acesso de leitura (RA-GZRS).
Projetar seus aplicativos para acesso de leitura ao secundário
Se sua conta de armazenamento estiver configurada para acesso de leitura à região secundária, você poderá
projetar seus aplicativos para alternar diretamente para a leitura de dados da região secundária se a região
primária ficar indisponível por qualquer motivo. A região secundária está sempre disponível para acesso de
leitura, de modo que você pode testar seu aplicativo para certificar-se de que ele será lido do secundário no
caso de uma interrupção. Para obter mais informações sobre como projetar seus aplicativos para alta
disponibilidade, consulte usar redundância geográfica para criar aplicativos altamente disponíveis.
Quando o acesso de leitura ao secundário está habilitado, seus dados podem ser lidos do ponto de extremidade
secundário, bem como do ponto de extremidade primário para sua conta de armazenamento. O ponto de
extremidade secundário acrescenta o sufixo – secundário ao nome da conta. Por exemplo, se o ponto de
extremidade primário para o armazenamento de BLOBs for myaccount.blob.core.windows.net , o ponto de
extremidade secundário será myaccount-secondary.blob.core.windows.net . As chaves de acesso da conta para
sua conta de armazenamento são as mesmas para os pontos de extremidade primários e secundários.
Verificar a propriedade Horário da Última Sincronização
Como os dados são replicados para a região secundária de forma assíncrona, a região secundária geralmente
está atrás da região primária. Se ocorrer uma falha na região primária, é provável que todas as gravações no
primário ainda não tenham sido replicadas para o secundário.
Para determinar quais operações de gravação foram replicadas para a região secundária, seu aplicativo pode
verificar a propriedade hora da última sincronização para sua conta de armazenamento. Todas as operações
de gravação gravadas na região primária antes da hora da última sincronização foram replicadas com êxito
para a região secundária, o que significa que elas estão disponíveis para serem lidas a partir do secundário.
Qualquer operação de gravação gravada na região primária após a hora da última sincronização pode ou não
ter sido replicada para a região secundária, o que significa que elas podem não estar disponíveis para
operações de leitura.
Você pode consultar o valor da última propriedade de hora de sincronização usando Azure PowerShell, CLI
do Azure ou uma das bibliotecas de cliente de armazenamento do Azure. A propriedade hora da última
sincronização é um valor de data/hora GMT. Para obter mais informações, consulte verificar a propriedade
hora da última sincronização de uma conta de armazenamento.
Resumo das opções de redundância

A tabela a seguir mostra como os dados duráveis e disponíveis estão em um determinado cenário, dependendo
de qual tipo de redundância está em vigor para sua conta de armazenamento:
C EN Á RIO L RS Z RS GRS/ RA - GRS GZ RS/ RA - GZ RS
Um nó dentro de um Sim Sim Sim Sim

data center se torna
indisponível
Um data center Não Sim Sim Sim

inteiro (zonal ou não
zonal) fica
indisponível
Ocorre uma Não Não Sim Sim

interrupção em toda
a região
Acesso de leitura aos Não Não Sim (com RA-GRS) Sim (com RA-GZRS)
dados na região
secundária se a
região primária ficar
indisponível
Porcentagem de no mínimo no mínimo no mínimo no mínimo

durabilidade dos 99,999999999% (11 99,9999999999% 99,99999999999999 99,99999999999999
objetos em um 9's) (12 9's) % (16 9's) % (16 9's)
determinado ano1
C EN Á RIO L RS Z RS GRS/ RA - GRS GZ RS/ RA - GZ RS
Tipos de conta de GPv2, GPv1, GPv2, GPv2, GPv1, GPv2

armazenamento com BlockBlobStorage, BlockBlobStorage, BlobStorage
suporte2 BlobStorage, FileStorage
FileStorage
SLA de Pelo menos 99,9% Pelo menos 99,9% Pelo menos 99,9% Pelo menos 99,9%
disponibilidade para (99% para a camada (99% para a camada (99% para a camada (99% para a camada
solicitações de de acesso de acesso de acesso fria) para de acesso fria) para
leitura1 esporádico) esporádico) GRS GZRS
Pelo menos 99,99% Pelo menos 99,99%

(99,9% para a (99,9% para a
camada de acesso camada de acesso
fria) para RA-GRS fria) para RA-GZRS
SLA de Pelo menos 99,9% Pelo menos 99,9% Pelo menos 99,9% Pelo menos 99,9%
disponibilidade para (99% para a camada (99% para a camada (99% para a camada (99% para a camada
solicitações de de acesso de acesso de acesso de acesso
gravação1 esporádico) esporádico) esporádico) esporádico)
1 para obter informações sobre as garantias de armazenamento do Azure quanto à durabilidade e

disponibilidade, consulte o SLA do armazenamento do Azure.
2 para obter
informações sobre tipos de conta de armazenamento, consulte visão geral da conta de
armazenamento.
Todos os dados de todos os tipos de contas de armazenamento são copiados de acordo com a opção de
redundância para a conta de armazenamento. Os objetos, incluindo BLOBs de blocos, blobs de acréscimo, blobs
de página, filas, tabelas e arquivos são copiados. Os dados em todas as camadas, incluindo a camada de
arquivo, são copiados. Para obter mais informações sobre camadas de BLOB, consulte armazenamento de
BLOBs do Azure: camadas de acesso quentes, frias e de arquivo.
Para obter informações sobre preços para cada opção de redundância, consulte preços do armazenamento do
Azure.
NOTE
O Azure Premium Armazenamento em Disco atualmente dá suporte apenas ao LRS (armazenamento localmente
redundante). As contas de armazenamento de blobs de blocos dão suporte a LRS (armazenamento com redundância
local) e a ZRS (armazenamento com redundância de zona) em determinadas regiões.
Integridade de dados
O armazenamento do Azure verifica regularmente a integridade dos dados armazenados usando verificações
de redundância cíclica (CRCs). Se a corrupção de dados for detectada, ela será reparada usando dados
redundantes. O armazenamento do Azure também calcula somas de verificação em todo o tráfego de rede para
detectar corrupção de pacotes de dados ao armazenar ou recuperar dados.
Veja também
Verificar a propriedade hora da última sincronização de uma conta de armazenamento
Alterar a opção de redundância para uma conta de armazenamento
Use a redundância geográfica para criar aplicativos altamente disponíveis
Recuperação de desastres e failover de conta de armazenamento
Recuperação de desastres e failover de conta de
armazenamento
A Microsoft se empenha em garantir que os serviços do Azure estejam sempre disponíveis. No entanto, podem
ocorrer interrupções imprevistas do serviço. Se seu aplicativo exigir resiliência, a Microsoft recomenda usar o
armazenamento com redundância geográfica, para que os dados sejam copiados para uma segunda região. Além
disso, os clientes devem dispor de um plano de recuperação de desastre para lidar com uma interrupção regional
do serviço. Uma parte importante de um plano de recuperação de desastre é a preparação de um failover para o
ponto de extremidade secundário caso o ponto de extremidade primário fique indisponível.
O armazenamento do Azure dá suporte ao failover de conta para contas de armazenamento com redundância
geográfica. Com o failover de conta, é possível iniciar o processo de failover da conta de armazenamento, se o
ponto de extremidade primário ficar indisponível. O failover atualiza o ponto de extremidade secundário para
torná-lo um ponto de extremidade primário de sua conta de armazenamento. Quando o failover estiver
concluído, os clientes poderão começar a gravar no novo ponto de extremidade primário.
O failover de conta está disponível para os tipos de conta de armazenamento de blob v1, de uso geral V2 e de
finalidade com Azure Resource Manager implantações. O failover de conta tem suporte para todas as regiões
públicas, mas não está disponível em nuvens soberanas ou nacionais no momento.
Este artigo descreve os conceitos e o processo envolvidos em um failover de conta e mostra como preparar sua
conta de armazenamento para recuperação com o mínimo de impacto para o cliente. Para saber como iniciar um
failover de conta no portal do Azure ou no PowerShell, consulte Iniciar um failover de conta.
NOTE
Esse recurso ainda não tem suporte em contas que têm um namespace hierárquico (Azure Data Lake Storage Gen2). Para
saber mais, confira recursos de armazenamento de BLOBs disponíveis em Azure data Lake Storage Gen2.
NOTE
Este artigo foi atualizado para usar o novo módulo Az do Azure PowerShell. Você ainda pode usar o módulo AzureRM, que
continuará a receber as correções de bugs até pelo menos dezembro de 2020. Para saber mais sobre o novo módulo Az e a
compatibilidade com o AzureRM, confira Apresentação do novo módulo Az do Azure PowerShell. Para obter instruções de
instalação do módulo Az, confira Instalar o Azure PowerShell.
Escolhendo a opção de redundância correta

O armazenamento do Azure mantém várias cópias da sua conta de armazenamento para garantir durabilidade e
alta disponibilidade. A opção de redundância que será escolhida para sua conta dependerá do grau de resiliência
que você precisa. Para proteção contra interrupções regionais, configure sua conta para armazenamento com
redundância geográfica, com ou sem a opção de acesso de leitura da região secundária:
O grs (armazenamento com redundância geográfica) ou o GZRS (armazenamento com redundância
de zona geográfica) copia seus dados de forma assíncrona em duas regiões geográficas que têm pelo menos
centenas de quilômetros de distância. Se a região primária sofrer uma interrupção, a região secundária
funcionará como uma fonte redundante para seus dados. É possível iniciar um failover para transformar o ponto
de extremidade secundário no ponto de extremidade primário.
O armazenamento com redundância geográfica com acesso de leitura (ra-grs) ou armazenamento
com redundância de zona geográfica com acesso de leitura (ra-GZRS) fornece armazenamento com
redundância geográfica com o benefício adicional de acesso de leitura para o ponto de extremidade secundário.
Se ocorrer uma interrupção no ponto de extremidade primário, os aplicativos configurados para acesso de leitura
para o secundário e projetados para alta disponibilidade poderão continuar a ler do ponto de extremidade
secundário. A Microsoft recomenda RA-GZRS para obter a máxima disponibilidade e durabilidade para seus
aplicativos.
Para obter mais informações sobre redundância no armazenamento do Azure, consulte redundância de
WARNING
O Armazenamento com redundância geográfica envolve risco de perda de dados. Os dados são copiados para a região
secundária de forma assíncrona, o que significa que há um atraso entre o momento em que os dados gravados na região
primária são gravados na região secundária. No caso de uma interrupção, as operações de gravação para o ponto de
extremidade primário que ainda não foram copiadas para o ponto de extremidade secundário serão perdidas.
Projetando para a alta disponibilidade

É importante projetar seu aplicativo para ter uma alta disponibilidade desde o início. Consulte estes recursos do
Azure para obter orientações sobre como projetar seu aplicativo e sobre o planejamento para a recuperação de
desastre:
Criando aplicativos resilientes para o Azure: uma visão geral dos principais conceitos para a arquitetura de
aplicativos altamente disponíveis no Azure.
Lista de verificação de resiliência: uma lista de verificação para verificar se o aplicativo implementa as
melhores práticas de design para alta disponibilidade.
Use a redundância geográfica para criar aplicativos altamente disponíveis: diretrizes de design para a criação
de aplicativos para tirar proveito do armazenamento com redundância geográfica.
Tutorial: criar um aplicativo altamente disponível com o armazenamento de BLOBs: um tutorial que mostra
como criar um aplicativo altamente disponível que alterna automaticamente entre pontos de extremidade
como falhas e recuperações são simuladas.
Além disso, tenha em mente essas práticas recomendadas a fim de manter a alta disponibilidade de seus dados
de armazenamento no Azure:
Discos: Use o backup do Azure para fazer backup dos discos de VM usados por suas máquinas virtuais do
Azure. Considere também usar o Azure Site Recovery para proteger suas VMs em caso de desastre regional.
Blobs de blocos: Ative a exclusão reversível para proteger contra exclusões em nível de objeto e
substituições ou copie blobs de blocos para outra conta de armazenamento em uma região diferente usando
AzCopy, Azure PowerShellou a biblioteca de movimentação de dados do Azure.
Arquivos: Use AzCopy ou Azure PowerShell para copiar os arquivos para outra conta de armazenamento em
uma região diferente.
Tabelas: use o AzCopy para exportar os dados de tabela para outra conta de armazenamento em uma região
diferente.
Acompanhar interrupções
Os clientes podem assinar o Painel de Integridade do Serviço do Azure para acompanhar a integridade e o status
do armazenamento do Azure e de outros serviços do Azure.
A Microsoft também recomenda que você projete seu aplicativo de forma a se preparar para a possibilidade de
falhas de gravação. Seu aplicativo deve expor falhas de gravação de forma que o alerte para a possibilidade de
uma interrupção na região primária.
Entendendo o processo de failover de conta

O failover de conta gerenciada pelo cliente permite que você falhe toda a conta de armazenamento para a região
secundária se a primária ficar indisponível por qualquer motivo. Quando você força um failover para a região
secundária, os clientes podem começar a gravar os dados no ponto de extremidade secundário depois que o
failover estiver concluído. O failover normalmente leva cerca de uma hora.
Como o failover de conta funciona
Em circunstâncias normais, um cliente grava dados em uma conta de armazenamento do Azure na região
primária e esses dados são copiados assincronamente para a região secundária. A imagem a seguir mostra o
cenário quando a região primária está disponível:
Se o ponto de extremidade primário ficar indisponível por algum motivo, o cliente não poderá mais gravar os
dados na conta de armazenamento. A imagem a seguir mostra o cenário em que o ponto de extremidade
primário ficou indisponível, mas nenhuma recuperação aconteceu ainda:
O cliente inicia o failover da conta no ponto de extremidade secundário. O processo de failover atualiza a entrada
DNS fornecida pelo armazenamento do Azure para que o ponto de extremidade secundário se torne o novo
ponto de extremidade primário de sua conta de armazenamento, conforme mostrado na imagem a seguir:
O acesso de gravação é restaurado para contas com redundância geográfica depois que a entrada DNS é
atualizada e as solicitações são direcionadas para o novo ponto de extremidade primário. Os pontos de
extremidade de armazenamento existentes para blobs, tabelas, filas e arquivos permanecem os mesmos após o
failover.
IMPORTANT
Depois que o failover estiver concluído, a conta de armazenamento é configurada para ser localmente redundante no novo
ponto de extremidade primário. Para retomar a replicação para o novo secundário, configure a conta para redundância
geográfica novamente.
Tenha em mente que a conversão de uma conta LRS para usar a redundância geográfica incorre em um custo. Esse custo se
aplica à atualização da conta de armazenamento na nova região primária após um failover.
Prevendo a perda de dados

Cau t i on
Um failover de conta geralmente envolve alguma perda de dados. É importante entender as implicações de
iniciar um failover de conta.
Como os dados são gravados de forma assíncrona da região primária para a região secundária, sempre há um
atraso antes que uma gravação na região primária seja copiada para a região secundária. Se a região primária
ficar indisponível, as gravações mais recentes talvez ainda não tenham sido copiadas para a região secundária.
Ao forçar um failover, todos os dados na região primária são perdidos uma vez que a região secundária se torna a
nova região primária e a conta de armazenamento é configurada para ser localmente redundante. Todos os dados
já copiados para o secundário são mantidos quando o failover ocorre. No entanto, todos os dados gravados no
primário que também não foram copiados para o secundário são perdidos permanentemente.
A propriedade Hora da última sincronização indica o momento mais recente em que os dados da região
primária foram certamente gravados na região secundária. Todos os dados gravados antes da hora da última
sincronização estarão disponíveis na região secundária, enquanto os dados gravados após esse momento podem
não terem sido gravados na região secundária e terem sido perdidos. Use essa propriedade caso ocorra uma
interrupção para estimar a quantidade de perda de dados que poderá incorrer ao iniciar um failover de conta.
Como prática recomendada, projete seu aplicativo de modo que seja possível usar a hora da última sincronização
para avaliar a estimativa de perda de dados. Por exemplo, se você estiver registrando todas as operações de
gravação, será possível comparar o momento das últimas operações de gravação com a hora da última
sincronização a fim de determinar quais gravações não foram sincronizadas na região secundária.
Tendo cuidados ao realizar o fail back para a região primária original
Após realizar o failover da região primária para a região secundária, a conta de armazenamento estará
configurada para ser localmente redundante na nova região primária. Em seguida, você pode configurar a conta
para redundância geográfica novamente. Quando a conta é configurada para redundância geográfica novamente
após um failover, a nova região primária começa imediatamente a copiar dados para a nova região secundária,
que era a primária antes do failover original. No entanto, pode levar algum tempo antes que os dados existentes
no primário sejam totalmente copiados para o novo secundário.
Depois que a conta de armazenamento for reconfigurada para a redundância geográfica, será possível iniciar
outro failover da nova região primária de volta para a nova região secundária. Nesse caso, a região primária
original antes do failover se tornará novamente a região primária e estará configurada para ser localmente
redundante. Todos os dados na região primária após o failover (a região secundária original) serão perdidos. Se a
maioria dos dados na conta de armazenamento não tiver sido copiada para o novo secundário antes de realizar o
failback, você poderá sofrer uma grande perda de dados.
Para evitar uma grande perda de dados, verifique o valor da propriedade Hora da última sincronização antes
de realizar o fail back. Compare a hora da última sincronização com os momentos das últimas vezes que os
dados foram gravados na nova região primária a fim de avaliar a perda de dados esperada.
Iniciar um failover da conta

É possível iniciar um failover de conta do portal do Azure, no PowerShell, na CLI do Azure ou na API de provedor
de recursos do Armazenamento do Azure. Para obter mais informações sobre como iniciar um failover, consulte
Iniciar um failover de conta.
Considerações adicionais
Examine as considerações adicionais descritas nesta seção para entender como seus aplicativos e serviços podem
ser afetados quando você força um failover.
Conta de armazenamento que contém BLOBs arquivados
As contas de armazenamento que contêm BLOBs arquivados dão suporte a failover de conta. Após a conclusão
do failover, todos os BLOBs arquivados precisam ser alimentados em uma camada online antes que a conta possa
ser configurada para redundância geográfica.
Depois que um failover for concluído, os clientes poderão ler novamente e gravar dados do armazenamento do
Azure na nova região primária. No entanto, o provedor de recursos de armazenamento do Azure não faz failover,
portanto, as operações de gerenciamento de recursos ainda devem ocorrer na região primária. Se a região
primária não estiver disponível, você não poderá executar operações de gerenciamento na conta de
armazenamento.
Como o provedor de recursos de armazenamento do Azure não faz failover, a propriedade Location retornará o
local primário original após a conclusão do failover.
Máquinas Virtuais do Azure
As máquinas virtuais (VMs) do Azure não realizarão o failover como parte de um failover de conta. Se a região
primária ficar indisponível, e você fizer o failover para a região secundária, será preciso recriar todas as VMs após
o failover. Além disso, há uma possível perda de dados associada ao failover da conta. A Microsoft recomenda as
seguintes diretrizes de alta disponibilidade e recuperação de desastres específicas para máquinas virtuais no
Azure.
Discos não gerenciados do Azure
Como prática recomendada, a Microsoft aconselha converter os discos não gerenciados em discos gerenciados.
No entanto, se você precisar fazer o failover em uma conta que contenha discos não gerenciados anexados a VMs
do Azure, será necessário desligar a VM antes de iniciar o failover.
Os discos não gerenciados são armazenadas como blobs de páginas no Armazenamento do Azure. Quando uma
VM está em execução no Azure, todos os discos não gerenciados anexados à VM são concedidos. O failover de
conta não poderá continuar se houver uma concessão em um blob. Para realizar o failover, siga estas etapas:
1. Antes de começar, anote os nomes de todos os discos não gerenciados, seus números de unidade lógica (LUN)
e a VM à qual eles estão anexados. Isso facilitará anexar os discos novamente após o failover.
2. Desligue a VM.
3. Exclua a VM, mas mantenha os arquivos VHD para os discos não gerenciados. Anote a hora que você excluiu a
VM.
4. Aguarde até que a Hora da última sincronização seja atualizada, ela deve posterior à hora em que você
excluiu a VM. Esta etapa é importante porque se o ponto de extremidade secundário não foi totalmente
atualizado com os arquivos VHD quando o failover ocorrer, a VM poderá não funcionar corretamente na nova
região primária.
5. Inicie o failover da conta.
6. Aguarde até que o failover da conta esteja concluído e a região secundária tenha se tornado a nova região
primária.
7. Crie uma VM na nova região primária e anexe novamente os VHDs.
8. Inicie a nova VM.
Tenha em mente que todos os dados armazenados em um disco temporário serão perdidos quando a VM for
desligada.
Recursos e serviços sem suporte

Os seguintes recursos e serviços não têm suporte para o failover de conta:
A Sincronização de Arquivos do Azure não oferece suporte ao failover de conta de armazenamento. Não deve
ser realizado o failover das contas de armazenamento que contêm compartilhamentos de arquivos do Azure
que estejam sendo usadas como pontos de extremidade de nuvem na Sincronização de Arquivos do Azure. Se
isso for feito, a sincronização deixará de funcionar e poderá causar a perda inesperada de dados no caso de
arquivos recentes em camadas.
ADLS Gen2 contas de armazenamento (contas que têm o namespace hierárquico habilitado) não têm suporte
no momento.
Não é possível realizar failover em uma conta de armazenamento que contenha blob de blocos premium. As
contas de armazenamento que dão suporte a blobs de bloco premium atualmente não são compatíveis com a
redundância geográfica.
Não é possível fazer failover de uma conta de armazenamento contendo contêineres habilitados da política de
imutabilidade do worm . A retenção baseada em tempo desbloqueada/bloqueada ou as políticas de
manutenção legal impedem o failover para manter a conformidade.
Copiando dados como uma alternativa ao failover

Se sua conta de armazenamento estiver configurada para acesso de leitura para o secundário, você poderá
projetar seu aplicativo para ler o ponto de extremidade secundário. Se você preferir não realizar o failover no
caso de uma interrupção na região primária, será possível usar ferramentas como o AzCopy, o Azure PowerShell
ou a Biblioteca de movimentação de dados do Azure para copiar os dados de sua conta de armazenamento na
região secundária para outra conta de armazenamento em uma região não afetada. Você poderá, então,
direcionar os aplicativos para essa conta de armazenamento para a disponibilidade de leitura e de gravação.
Cau t i on
Um failover de conta não deve ser usado como parte da sua estratégia de migração de dados.
Failover gerenciado pela Microsoft

Em circunstâncias extremas em que uma região for perdida devido a um desastre significativo, a Microsoft
poderá iniciar um failover regional. Nesse caso, nenhuma ação sua é necessária. Você não terá acesso para
gravação na conta de armazenamento até que o failover gerenciado pela Microsoft seja concluído. Seus
aplicativos poderão ler a partir da região secundária se sua conta de armazenamento estiver configurada para
RA-GRS ou RA-GZRS.
Confira também
Iniciar um failover da conta
Tutorial: criar um aplicativo altamente disponível com o armazenamento de BLOBs
Metas de desempenho e escalabilidade do Arquivos
do Azure
O Arquivos do Azure oferece compartilhamentos de arquivos totalmente gerenciados na nuvem, acessíveis por
meio do protocolo SMB padrão no setor. Este artigo discute as metas de escalabilidade e desempenho dos
arquivos do Azure e do Azure File Sync.
As metas de escalabilidade e desempenho listadas aqui são metas avançadas, mas podem ser afetadas por outras
variáveis em sua implantação. Por exemplo, a taxa de transferência para um arquivo pode também ser limitada
pela sua largura de banda de rede disponível, não apenas os servidores que hospedam o serviço de Arquivos do
Azure. É altamente recomendável testar seu padrão de uso para determinar se a escalabilidade e o desempenho
do Arquivos do Azure atende às suas necessidades. É nosso compromisso aumentar esses limites ao longo do
tempo. Não hesite em fazer comentários, na seção de comentários abaixo ou no UserVoice do Arquivos do Azure,
sobre os limites que você gostaria que aumentássemos.
Metas de escalabilidade da conta de armazenamento do Azure

O recurso pai de um compartilhamento de arquivo do Azure é uma conta de armazenamento do Azure. Uma
conta de armazenamento representa um pool de armazenamento do Azure que pode ser usado por vários
serviços de armazenamento, incluindo Arquivos do Azure, para armazenar dados. Outros serviços que
armazenam dados em contas de armazenamento são o armazenamento de Blobs do Azure, armazenamento de
Filas do Azure e armazenamento de Tabelas do Azure. As metas a seguir se aplicam a todos os serviços de
armazenamento que armazenam dados em uma conta de armazenamento:
A tabela a seguir descreve os limites padrão das contas de armazenamento de uso geral v1 e v2, de
Armazenamento de Blobs e de Armazenamento de Blobs de Blocos do Azure. O limite de entrada refere-se a
todos os dados enviados a uma conta de armazenamento. O limite de saída refere-se a todos os dados recebidos
de uma conta de armazenamento.
REC URSO L IM IT E
Número de contas de armazenamento por região por 250

assinatura, incluindo contas de armazenamento Standard e
Premium.
Capacidade máxima da conta de armazenamento 5 PiB 1
Número máximo de contêineres de blob, blobs, Sem limite

compartilhamentos de arquivo, tabelas, filas, entidades ou
mensagens por conta de armazenamento
Taxa1 máxima de solicitação por conta de armazenamento 20 mil solicitações por segundo
Entrada máxima1 por conta de armazenamento (regiões dos 25 Gbps

EUA e Europa)
Entrada máxima1 por conta de armazenamento (regiões fora 5 Gbps se o RA-GRS/GRS estiver habilitado, 10 Gbps para o
dos EUA e da Europa) LRS/ZRS2
REC URSO L IM IT E
Saída máxima para contas de armazenamento de Blobs e de 50 Gbps

uso geral v2 (todas as regiões)
Saída máxima para contas de armazenamento de uso geral 20 Gbps se o RA-GRS/GRS estiver habilitado, 30 Gbps para o
v1 (regiões dos EUA) LRS/ZRS2
Saída máxima para contas de armazenamento de uso geral 10 Gbps se o RA-GRS/GRS estiver habilitado, 15 Gbps para o
v1 (regiões fora dos EUA) LRS/ZRS2
Número máximo de regras de rede virtual por conta de 200

armazenamento
Número máximo de regras de endereço IP por conta de 200

armazenamento
1 As contas padrão do Armazenamento do Azure dão suporte a limites mais altos de capacidade e de entrada por
solicitação. Para solicitar um aumento nos limites de conta, contate o Suporte do Azure.
2 Se sua conta de armazenamento tiver acesso de leitura habilitado com RA-GRS (armazenamento com
redundância geográfica) ou RA-GZRS (armazenamento com redundância de zona geográfica), os destinos de
saída do local secundário serão idênticos aos do local principal. As opções de replicação do Armazenamento do
Azure incluem:
Armazenamento com redundância local (LRS)
Armazenamento com redundância de zona (ZRS)
Armazenamento com redundância geográfica (GRS)
Armazenamento com redundância geográfica com acesso de leitura (RA-GRS)
Armazenamento com redundância de zona geográfica (GZRS)
Armazenamento com redundância de zona geográfica com acesso de leitura (RA-GZRS)
3 O Azure Data Lake Storage Gen2
é um conjunto de funcionalidades dedicadas à análise de Big Data, criado
sobre o Armazenamento de Blobs do Azure.
NOTE
A Microsoft recomenda o uso de contas de armazenamento de uso geral v2 na maioria dos cenários. É possível atualizar
facilmente uma conta do Armazenamento de Blobs do Azure ou de uso geral v1 para uma conta de uso geral v2 sem
tempo de inatividade e sem precisar copiar dados. Para obter mais informações, confira Atualizar para uma conta de
armazenamento de uso geral v2.
Se as necessidades do seu aplicativo excederem as metas de escalabilidade de uma conta única de

armazenamento, você pode preparar seu aplicativo para usar várias contas de armazenamento. Em seguida,
particione seus objetos de dados nessas contas de armazenamento. Para obter informações sobre o preço por
volume, confira Preço do Armazenamento do Azure.
Todas as contas de armazenamento são executadas em uma topologia de rede simples, independentemente de
quando foram criadas. Para obter mais informações sobre a arquitetura de rede simples do armazenamento do
Azure e sobre escalabilidade, confira Armazenamento do Microsoft Azure: um serviço de armazenamento em
nuvem altamente disponível com coerência forte.
Os limites a seguir se aplicam somente quando você executa operações de gerenciamento usando Azure
Resource Manager com o armazenamento do Azure.
REC URSO L IM IT E
Operações de gerenciamento de conta de armazenamento 800 a cada 5 minutos

(leitura)
Operações de gerenciamento de conta de armazenamento 10 por segundo/1200 por hora

(gravação)
Operações de gerenciamento de conta de armazenamento 100 a cada 5 minutos

(lista)
IMPORTANT
A utilização da conta de armazenamento de uso geral de outros serviços de armazenamento afeta os compartilhamentos
de arquivos do Azure em sua conta de armazenamento. Por exemplo, se você atingir a capacidade máxima da conta de
armazenamento com o armazenamento de Blobs do Azure, você não poderá criar novos arquivos em seu
compartilhamento de arquivo do Azure, mesmo se o compartilhamento de arquivo do Azure estiver abaixo do tamanho
máximo do compartilhamento.
Destinos de escala de Arquivos do Azure

Há três categorias de limitações a serem consideradas para os arquivos do Azure: contas de armazenamento,
compartilhamentos e arquivos.
Por exemplo: com compartilhamentos de arquivos premium, um único compartilhamento pode atingir 100.000
IOPS e um único arquivo pode ser dimensionado para até 5.000 IOPS. Portanto, se você tiver três arquivos em
um único compartilhamento, o máximo de IOPS que você pode obter desse compartilhamento é 15.000.
Limites de conta de armazenamento Standard
Consulte a seção destinos de escala da conta de armazenamento do Azure para esses limites.
Limites da conta de armazenamento Premium
Os arquivos Premium usam uma conta de armazenamento exclusiva chamada FileStorage . Esse tipo de conta é
projetado para cargas de trabalho com IOPS alto, alta taxa de transferência com baixa latência consistente. O
armazenamento de arquivos Premium é dimensionado com o tamanho de compartilhamento provisionado.
Á REA DEST IN O
Tamanho máximo provisionado 100 TiB
Compartilhamentos Ilimitado
IOPS 100.000
Entrada 4.136 MiB/s
Saída 6.204 MiB/s

IMPORTANT
Os limites da conta de armazenamento são aplicados a todos os compartilhamentos. O dimensionamento até o máximo
para contas de armazenamento de filebackup só será atingível se houver apenas um compartilhamento por conta de
Destinos de escala de arquivo e compartilhamento de arquivos
NOTE
Compartilhamentos de arquivos padrão maiores que 5 TiB têm determinadas limitações. Para obter uma lista de limitações
e instruções para habilitar tamanhos maiores de compartilhamento de arquivos, consulte a seção habilitar
compartilhamentos de arquivos maiores em compartilhamentos de arquivos padrão do guia de planejamento.
C O M PA RT IL H A M EN TO S DE A RQ UIVO S C O M PA RT IL H A M EN TO S DE A RQ UIVO S
REC URSO PA DRÃ O P REM IUM
Tamanho mínimo de um Sem mínimo; pré-pago 100 GiB; provisionado

compartilhamento de arquivo
Tamanho máximo de um 100 TiB *, 5 TiB 100 TiB

compartilhamento de arquivos
Tamanho máximo de um arquivo em 1 TiB 1 TiB

um compartilhamento de arquivos
Número máximo de arquivos em um Sem limite Sem limite

IOPS máximo por compartilhamento 10.000 IOPS *, 1.000 IOPS 100.000 IOPS
Número máximo de políticas de acesso 5 5

armazenadas por compartilhamento de
arquivos
Taxa de transferência de destino para até 300 MiB/s *, até 60 MiB/s, Consulte valores de entrada e saída do
um único compartilhamento de compartilhamento de arquivos
arquivos Premium
Egresso máxima de um único Consulte taxa de transferência de Até 6.204 MiB/s

compartilhamento de arquivo destino de compartilhamento de
arquivos padrão
Máximo de entrada para um único Consulte taxa de transferência de Até 4.136 MiB/s
compartilhamento de arquivos destino de compartilhamento de
arquivos padrão
Máximo de identificadores abertos por 2.000 identificadores abertos 2.000 identificadores abertos
arquivo
Número máximo de instantâneos de 200 instantâneos de compartilhamento 200 instantâneos de compartilhamento

compartilhamento
Tamanho máximo do nome do objeto 2.048 caracteres 2.048 caracteres

(diretórios e arquivos)
C O M PA RT IL H A M EN TO S DE A RQ UIVO S C O M PA RT IL H A M EN TO S DE A RQ UIVO S
REC URSO PA DRÃ O P REM IUM
Componente de nome de caminho 255 caracteres 255 caracteres

máximo (no caminho \A\B\C\D, cada
letra é um componente)
*O padrão em compartilhamentos de arquivos padrão é 5 TiB, consulte habilitar e criar grandes

compartilhamentos de arquivos para obter os detalhes sobre como aumentar os compartilhamentos de arquivos
padrão escalando verticalmente para 100 Tib.
Limites de nível de compartilhamento de arquivo Premium adicionais
Á REA DEST IN O
Aumento/diminuição de tamanho mínimo 1 GiB
IOPS de linha de base 1 IOPS por GiB, até 100.000
Intermitência de IOPS 3x IOPS por GiB, até 100.000
Taxa de egresso 60 MiB/s + 0, 6 * GiB provisionados
Taxa de entrada 40 MiB/s + 0, 4 * GiB provisionados
Limites de nível de arquivo
Á REA A RQ UIVO P REM IUM A RQ UIVO PA DRÃ O
Tamanho 1 TiB 1 TiB
IOPS máxima por arquivo 5.000 1,000
Identificadores simultâneos 2.000 2.000
Saída 300 MiB/s Consulte valores de taxa de

transferência de arquivo padrão
Entrada 200 MiB/segundo Consulte valores de taxa de

transferência de arquivo padrão
Produtividade Consulte valores de entrada/saída do Até 60 MiB/s

arquivo Premium
Destinos de escala de Sincronização de Arquivos do Azure

A sincronização de Arquivos do Azure foi projetado com o objetivo de uso ilimitado, mas o uso ilimitado nem
sempre é possível. A tabela a seguir indica os limites do teste da Microsoft e também indica quais destinos são
limites rígidos:
REC URSO DEST IN O L IM IT E RÍGIDO
Serviços de Sincronização de 20 serviços de sincronização de Sim

Armazenamento por região armazenamento
REC URSO DEST IN O L IM IT E RÍGIDO
Grupos de sincronização por Serviço de 100 grupos de sincronização Sim

Sincronização de Armazenamento
Servidores registrados por Serviço de 99 servidores Sim

Pontos de extremidade de nuvem por 1 ponto de extremidade de nuvem Sim

grupo de sincronização
Pontos de extremidade do servidor por 50 pontos de extremidade de servidor Não

grupo de sincronização
Pontos de extremidade de servidor por 30 pontos de extremidade de servidor Sim

servidor
Objetos do sistema de arquivos 100 milhões objetos Não

(diretórios e arquivos) por grupo de
sincronização
Número máximo de objetos do sistema 5 milhões objetos Sim

de arquivos (diretórios e arquivos) em
um diretório
Tamanho máximo do descritor de 64 KiB Sim

segurança (diretórios e arquivos) do
objeto
Tamanho do arquivo 100 GiB Não
Tamanho mínimo do arquivo para que V9: com base no tamanho do cluster Sim
um arquivo seja colocado em camadas do sistema de arquivos (tamanho de
cluster de sistema de arquivos duplo).
Por exemplo, se o tamanho do cluster
do sistema de arquivos for 4 KB, o
tamanho mínimo do arquivo será 8 KB.
V8 e mais antigo: 64 KiB
NOTE
Um ponto de extremidade Sincronização de Arquivos do Azure pode ser escalado verticalmente para o tamanho de um
compartilhamento de arquivos do Azure. Se o limite de tamanho do compartilhamento de arquivos do Azure for atingido,
a sincronização não será capaz de operar.
Métricas de desempenho de sincronização de arquivos do Azure

Como o agente do Azure File Sync é executado em um computador Windows Server que se conecta aos
compartilhamentos de arquivos do Azure, o desempenho de sincronização efetivo depende de vários fatores em
sua infraestrutura: Windows Server e a configuração de disco subjacente, largura de banda de rede entre o
servidor e o Azure armazenamento, tamanho do arquivo, tamanho total do conjunto de dados e atividade no
conjunto de dados. Desde que a sincronização de arquivos do Azure funciona no nível de arquivo, as
características de desempenho de uma solução de sincronização de arquivos do Azure melhor é medido em
número de objetos (arquivos e diretórios) processado por segundo.
Para sincronização de arquivos do Azure, o desempenho for crítico em dois estágios:
1. O provisionamento inicial única : para otimizar o desempenho no provisionamento inicial, consulte
integração com sincronização de arquivos do Azure para os detalhes de implantação ideal.
2. Sincronização em andamento : depois que os dados inicialmente são propagados em compartilhamentos
de arquivos do Azure, a sincronização de arquivos do Azure mantém vários pontos de extremidade em
sincronia.
Para ajudá-lo a planejar a implantação para cada um dos estágios, abaixo são os resultados observados durante o
teste interno em um sistema com uma configuração
C O N F IGURA Ç Ã O DO SIST EM A
CPU 64 núcleos virtuais com o cache de MiB L3 64
Memória 128 GiB
Disco Cache de discos SAS com RAID 10 com bateria de reserva
Rede Rede de 1 Gbps
Carga de trabalho Servidor de arquivos de uso geral
P RO VISIO N A M EN TO IN IC IA L DE USO ÚN IC O
Número de objetos 25 milhões de objetos
Tamanho do conjunto de dados ~ 4,7 TiB
Tamanho médio de arquivo ~ 200 KiB (maior arquivo: 100 GiB)
Carregue a taxa de transferência 20 objetos por segundo por grupo de sincronização
Fazer o download do Namespace * 400 objetos por segundo
* Quando um novo ponto de extremidade do servidor é criado, o agente do Azure File Sync não faz o download
de nenhum conteúdo do arquivo. Sincronizar primeiro namespace completo e, em seguida, os gatilhos em
segundo plano Lembre-se de fazer o download dos arquivos, em sua totalidade ou, se camadas na nuvem está
habilitado para a política de camadas de nuvem definido no ponto de extremidade do servidor.
SIN C RO N IZ A Ç Ã O C O N T ÍN UA
Número de objetos sincronizados 125.000 objetos (aproximadamente 1% rotatividade)
Tamanho do conjunto de dados 50 GiB
Tamanho médio de arquivo ~500 KiB
Carregue a taxa de transferência 20 objetos por segundo por grupo de sincronização
Taxa de transferência do Download completo* 60 objetos por segundo
*Se nuvem camadas estiver habilitada, provavelmente a observar um desempenho melhor com apenas o arquivo
de dados são baixados. Sincronização de arquivos do Azure fazer o download somente os dados de arquivos
armazenados em cache quando forem alteradas em qualquer um dos pontos de extremidade. Para todos os
arquivos em camadas ou recentemente criados, o agente não baixar os dados de arquivo e em vez disso, apenas
o namespace para todos os pontos de extremidade do servidor é sincronizado. O agente também oferece
suporte parciais downloads de arquivos em camadas como eles são acessados pelo usuário.
NOTE
Os números acima não são uma indicação do desempenho que você terá. O desempenho real dependerá vários fatores
conforme descrito no início desta seção.
Como um guia geral para sua implantação, você deve manter alguns pontos em mente:
A taxa de transferência do objeto é dimensionado aproximadamente proporcionalmente ao número de
grupos de sincronização no servidor. Dividir dados em vários grupos de sincronização em um servidor resulta
em melhor taxa de transferência, que também é limitada pelo servidor e rede.
A taxa de transferência do objeto é inversamente proporcional à MiB por segundo taxa de transferência. Para
os arquivos menores, você terá maior taxa de transferência em termos de número de objetos processados por
segundo, mas inferior MiB por segundo taxa de transferência. Por outro lado, para arquivos maiores, você terá
menos objetos processados por segundo, mas superior MiB por segundo taxa de transferência. A MiB por
segundo taxa de transferência é limitada pelos destinos de escala de arquivos do Azure.
Confira também
Visão geral do suporte de autenticação baseada em
identidade de arquivos do Azure para acesso SMB
Os arquivos do Azure oferecem suporte à autenticação baseada em identidade sobre o protocolo SMB por meio
do Active Directory Domain Services local (AD DS) (visualização) e Azure Active Directory Domain Services
(Azure AD DS). Este artigo se concentra em como os compartilhamentos de arquivos do Azure podem usar os
serviços de domínio, no local ou no Azure, para dar suporte ao acesso baseado em identidade aos
compartilhamentos de arquivos do Azure por SMB. Habilitar o acesso baseado em identidade para seus
compartilhamentos de arquivos do Azure permite que você substitua servidores de arquivos existentes por
compartilhamentos de arquivos do Azure sem substituir o serviço de diretório existente, mantendo acesso
contínuo de usuário a compartilhamentos.
Os arquivos do Azure impõe a autorização no acesso do usuário ao compartilhamento e aos níveis de
diretório/arquivo. A atribuição de permissão de nível de compartilhamento pode ser executada em usuários do
Azure Active Directory (Azure AD) ou grupos gerenciados por meio do modelo RBAC (controle de acesso
baseado em função) . Com o RBAC, as credenciais usadas para o acesso ao arquivo devem estar disponíveis ou
sincronizadas com o Azure AD. Você pode atribuir funções RBAC internas como o leitor de compartilhamento
SMB de dados de arquivo de armazenamento a usuários ou grupos no Azure AD para conceder acesso de leitura
a um compartilhamento de arquivos do Azure.
No nível de diretório/arquivo, os arquivos do Azure dão suporte à preservação, herança e imposição de DACLs
do Windows , assim como qualquer servidor de arquivos do Windows. Você pode optar por manter as DACLs do
Windows ao copiar dados via SMB entre o compartilhamento de arquivos existente e os compartilhamentos de
arquivos do Azure. Se você planeja impor autorização ou não, pode usar compartilhamentos de arquivos do
Azure para fazer backup de ACLs junto com seus dados.
Para saber como habilitar a autenticação de Active Directory Domain Services local para compartilhamentos de
arquivos do Azure (versão prévia), consulte habilitar a autenticação de Active Directory Domain Services local
sobre SMB para compartilhamentos de arquivos do Azure.
Para saber como habilitar a autenticação de AD DS do Azure para compartilhamentos de arquivos do Azure,
consulte habilitar a autenticação de Azure Active Directory Domain Services em arquivos do Azure.
Glossário
É útil entender alguns termos-chave relacionados à autenticação do serviço de domínio do Azure AD sobre SMB
para compartilhamentos de arquivos do Azure:
Autenticação Kerberos
Kerberos é um protocolo de autenticação usado para verificar a identidade de um usuário ou host. Para
obter mais informações sobre Kerberos, consulte Visão geral da autenticação do Kerberos.
Protocolo SMB (Ser ver Message Block)
O SMB é um protocolo de compartilhamento de arquivos de rede padrão do setor. O SMB também é
conhecido como Common Internet File System ou CIFS. Para obter mais informações sobre o SMB,
consulte Protocolo SMB da Microsoft e Visão geral do protocolo CIFS.
Azure Active Director y (Azure AD)
O Azure Active Directory (AD do Azure) é o serviço de gerenciamento de identidade e diretório
multilocatário baseado em nuvem da Microsoft. O Azure AD combina serviços de diretório principais,
gerenciamento de acesso a aplicativos e proteção de identidade em uma única solução. As VMs
(máquinas virtuais) do Windows ingressadas no Azure AD podem acessar compartilhamentos de
arquivos do Azure com suas credenciais do Azure AD. Para obter mais informações, confira O que é Azure
Active Directory?
Azure Active Director y Domain Ser vices (Azure AD DS)
O Azure AD DS fornece serviços de domínio gerenciados, como ingresso no domínio, diretivas de grupo,
LDAP e autenticação Kerberos/NTLM. Esses serviços são totalmente compatíveis com Active Directory
Domain Services. Para obter mais informações, consulte Azure Active Directory Domain Services.
Active Director y Domain Ser vices local (AD DS)
A integração do AD DS (Active Directory Domain Services local) com os arquivos do Azure (versão prévia)
fornece os métodos para armazenar dados de diretório e, ao mesmo tempo, disponibilizá-los para
usuários e administradores de rede. A segurança é integrada com AD DS por meio de autenticação de
logon e controle de acesso a objetos no diretório. Com um único logon de rede, os administradores
podem gerenciar dados de diretório e organização em toda a rede, e os usuários de rede autorizados
podem acessar recursos em qualquer lugar da rede. O AD DS é normalmente adotado por empresas em
ambientes locais e AD DS credenciais são usadas como a identidade do controle de acesso. Para obter
mais informações, consulte Active Directory Domain Services visão geral.
RBAC (Controle de Acesso Baseado em Função) do Azure
O RBAC (controle de acesso baseado em função) do Azure permite o gerenciamento de acesso refinado
para o Azure. Usando o RBAC, você pode gerenciar o acesso aos recursos concedendo aos usuários o
mínimo de permissões necessárias para que eles realizem seus trabalhos. Para obter mais informações
sobre o RBAC, consulte o que é o RBAC (controle de acesso baseado em função) no Azure?.
Casos de uso comuns

A autenticação baseada em identidade e o suporte para ACLs do Windows em arquivos do Azure é melhor
aproveitado para os seguintes casos de uso:
Substituir servidores de arquivos locais
Reprovar e substituir servidores de arquivos locais dispersos é um problema comum que cada empresa
encontra em sua jornada de modernização de ti. Compartilhamentos de arquivos do Azure com autenticação AD
DS local (versão prévia) é o melhor ajuste aqui, quando você pode migrar os dados para os arquivos do Azure.
Uma migração completa permitirá que você aproveite os benefícios de alta disponibilidade e escalabilidade,
minimizando também as alterações no lado do cliente. Ele fornece uma experiência de migração direta aos
usuários finais, para que eles possam continuar acessando seus dados com as mesmas credenciais usando seus
computadores ingressados no domínio existentes.
Migrar e deslocar aplicativos para o Azure
Ao migrar e deslocar aplicativos para a nuvem, você deseja manter o mesmo modelo de autenticação para seus
dados. À medida que estendemos a experiência de controle de acesso com base em identidade para
compartilhamentos de arquivos do Azure, ele elimina a necessidade de alterar seu aplicativo para métodos de
autenticação modernos e agilizar a adoção da nuvem. Os compartilhamentos de arquivos do Azure fornecem a
opção de integração com o Azure AD DS ou o AD DS local (versão prévia) para autenticação. Se seu plano for ser
de 100% na nuvem nativa e minimizar os esforços de gerenciamento de infraestruturas de nuvem, o Azure AD
DS seria uma melhor opção como um serviço de domínio totalmente gerenciado. Se precisar de compatibilidade
total com recursos de AD DS, convém considerar estender seu ambiente de AD DS para a nuvem por meio da
hospedagem automática de controladores de domínio em VMs. De qualquer forma, fornecemos a flexibilidade
para escolher os serviços de domínio que atendam às suas necessidades de negócios.
Recuperação de desastres e backup (DR )
Se você estiver mantendo seu armazenamento de arquivos primário local, os compartilhamentos de arquivos do
Azure podem servir como um armazenamento ideal para backup ou DR, para melhorar a continuidade dos
negócios. Você pode usar compartilhamentos de arquivos do Azure para fazer backup de seus dados de
servidores de arquivos existentes, preservando as DACLs do Windows. Para cenários de DR, você pode
configurar uma opção de autenticação para dar suporte à imposição de controle de acesso adequada no failover.
Cenários com suporte

A tabela a seguir resume os cenários de autenticação de compartilhamentos de arquivos do Azure com suporte
para o Azure AD DS e o AD DS local (versão prévia). É recomendável selecionar o serviço de domínio que você
adotou para o seu ambiente de cliente para integração com os arquivos do Azure. Se você tiver AD DS (versão
prévia) já configurado no local ou no Azure, em que seus dispositivos estão ingressados no domínio, você deve
optar por aproveitar AD DS (versão prévia) para a autenticação de compartilhamentos de arquivos do Azure. Da
mesma forma, se você já tiver adotado o Azure AD DS (GA), deverá usá-lo para autenticação de
compartilhamentos de arquivos do Azure.
A UT EN T IC A Ç Ã O DE A D DS DO A Z URE A UT EN T IC A Ç Ã O A D DS LO C A L ( VERSÃ O P RÉVIA )
As máquinas Windows ingressadas no AD DS do Azure As máquinas com Windows AD DS ingressadas no local

podem acessar compartilhamentos de arquivos do Azure podem acessar compartilhamentos de arquivos do Azure
com as credenciais do Azure AD sobre SMB. com as credenciais de Active Directory locais que são
sincronizadas com o Azure AD por SMB.
Cenários sem suporte

O Azure AD DS e a autenticação de AD DS local não dão suporte à autenticação em relação às contas de
computador. Em vez disso, você pode considerar o uso de uma conta de logon de serviço.
A autenticação de AD DS do Azure não oferece suporte à autenticação em dispositivos ingressados no Azure
AD.
Vantagens da autenticação baseada em identidade

A autenticação baseada em identidade para arquivos do Azure oferece vários benefícios em relação ao uso da
autenticação de chave compartilhada:
Estenda a experiência tradicional de acesso ao compar tilhamento de arquivos baseado em
identidade para a nuvem com AD DS local e o Azure AD DS
Se você planeja levantar e deslocar seu aplicativo para a nuvem, substituindo os servidores de arquivos
tradicionais por compartilhamentos de arquivos do Azure, convém que seu aplicativo seja autenticado
com as credenciais locais AD DS ou do Azure AD DS para acessar os dados do arquivo. Os arquivos do
Azure dão suporte ao uso de AD DS locais ou de credenciais do Azure AD DS para acessar
compartilhamentos de arquivos do Azure via SMB de AD DS locais ou de VMs ingressadas no domínio do
Azure AD DS.
Impor o controle de acesso granular em compar tilhamentos de arquivos do Azure
Você pode conceder permissões a uma identidade específica no nível de compartilhamento, diretório ou
arquivo. Por exemplo, suponha que você tenha várias equipes usando um compartilhamento de arquivos
do Azure único para colaboração em projetos. Você pode conceder acesso para todas as equipes a
diretórios não confidenciais, ao mesmo tempo em que limita o acesso a diretórios que contenham dados
financeiros confidenciais apenas para sua equipe de Finanças.
Fazer backup de ACLs do Windows (também conhecido como NTFS) junto com seus dados
Você pode usar compartilhamentos de arquivos do Azure para fazer backup de seus compartilhamentos
de arquivos locais existentes. Os arquivos do Azure preservam suas ACLs junto com seus dados quando
você faz backup de um compartilhamento de arquivos para compartilhamentos de arquivos do Azure via
SMB.
Como isso funciona

Os compartilhamentos de arquivos do Azure dão suporte à autenticação Kerberos para integração com o Azure
AD DS ou o AD DS local (versão prévia). Antes de habilitar a autenticação nos compartilhamentos de arquivos do
Azure, primeiro você deve configurar seu ambiente de domínio. Para a autenticação de AD DS do Azure, você
deve habilitar Azure AD Domain Services e ingressar no domínio as VMs das quais você planeja acessar dados
de arquivo. Sua VM ingressada no domínio deve residir na mesma rede virtual (VNET) que o AD DS do Azure. Da
mesma forma, para a autenticação local AD DS (versão prévia), você precisa configurar seu controlador de
domínio e ingressar no domínio em seus computadores ou máquinas virtuais.
Quando uma identidade associada a um aplicativo em execução em uma VM tenta acessar dados em
compartilhamentos de arquivos do Azure, a solicitação é enviada para o Azure AD DS para autenticar a
identidade. Se a autenticação for bem-sucedida, o Azure AD DS retornará um token Kerberos. O aplicativo envia
uma solicitação que inclui o token Kerberos e os compartilhamentos de arquivos do Azure usam esse token para
autorizar a solicitação. Os compartilhamentos de arquivos do Azure recebem apenas o token e não mantêm as
credenciais de AD DS do Azure. A autenticação AD DS local funciona de maneira semelhante, em que seu AD DS
fornece o token Kerberos.
Habilitar a autenticação baseada em identidade

Você pode habilitar a autenticação baseada em identidade com o Azure AD DS ou o AD DS local (versão prévia)
para compartilhamentos de arquivos do Azure em suas contas de armazenamento novas e existentes. Somente
um serviço de domínio pode ser usado para autenticação de acesso a arquivos na conta de armazenamento, que
se aplica a todos os compartilhamentos de arquivos na conta. Orientações detalhadas sobre como configurar
seus compartilhamentos de arquivos para autenticação com o Azure AD DS em nosso artigo habilitar a
autenticação Azure Active Directory Domain Services em arquivos do Azure e diretrizes para AD DS locais
(versão prévia) em nosso outro artigo, habilite a autenticação de Active Directory Domain Services local sobre
SMB para compartilhamentos de arquivos do Azure.
Configurar permissões no nível de compartilhamento para Arquivos do Azure
Quando a autenticação do AD DS do Azure ou do AD DS local (versão prévia) estiver habilitada, você poderá usar
funções RBAC internas ou configurar funções personalizadas para identidades do Azure AD e atribuir direitos de
acesso a quaisquer compartilhamentos de arquivos em suas contas de armazenamento. A permissão atribuída
permite que a identidade concedida obtenha acesso somente ao compartilhamento, nada mais, nem mesmo o
diretório raiz. Você ainda precisa configurar separadamente as permissões no nível do diretório ou do arquivo
para compartilhamentos de arquivos do Azure.
Configurar permissões no nível do diretório ou do arquivo para arquivos do Azure
Os compartilhamentos de arquivos do Azure impõem permissões de arquivo padrão do Windows no nível do
diretório e do arquivo, incluindo o diretório raiz. A configuração de permissões no nível do diretório ou do
arquivo é suportada tanto pelo SMB quanto pelo REST. Monte o compartilhamento de arquivos de destino de
sua VM e configure permissões usando o explorador de arquivos do Windows, o Windows icaclsou o comando
Set-ACL .
Use a chave de conta de armazenamento para permissões de superusuário
Um usuário com a chave da conta de armazenamento pode acessar compartilhamentos de arquivos do Azure
com permissões de superusuário. As permissões de superusuário ignoram todas as restrições de controle de
acesso.
IMPORTANT
Nossa prática recomendada de segurança recomendada é evitar compartilhar suas chaves de conta de armazenamento e
aproveitar a autenticação baseada em identidade sempre que possível.
Preservar ACLs de diretório e arquivo ao importar dados para compartilhamentos de arquivos do Azure
Os arquivos do Azure dão suporte à preservação de ACLs de nível de diretório ou arquivo ao copiar dados para
compartilhamentos de arquivos do Azure. Você pode copiar ACLs em um diretório ou arquivo para
compartilhamentos de arquivos do Azure usando Sincronização de Arquivos do Azure ou conjuntos de
ferramentas de movimentação de arquivos comuns. Por exemplo, você pode usar o Robocopy com /copy:s o
sinalizador para copiar dados, bem como ACLs para um compartilhamento de arquivos do Azure. As ACLs são
preservadas por padrão, não é necessário habilitar a autenticação baseada em identidade em sua conta de
armazenamento para preservar ACLs.
Preços
Não há nenhum encargo de serviço adicional para habilitar a autenticação baseada em identidade sobre SMB
em sua conta de armazenamento. Para obter mais informações sobre preços, consulte preços de arquivos do
Azure e preços de Azure AD Domain Services.
Próximas etapas
Para obter mais informações sobre os arquivos do Azure e a autenticação baseada em identidade sobre o SMB,
consulte estes recursos:
Habilitar a autenticação de Active Directory Domain Services local sobre SMB para compartilhamentos de
arquivos do Azure
Habilitar a autenticação de Azure Active Directory Domain Services nos arquivos do Azure
Criptografia de armazenamento do Azure para
dados em repouso
O armazenamento do Azure criptografa automaticamente os dados quando eles são persistidos para a nuvem.
A criptografia de armazenamento do Azure protege seus dados e para ajudá-lo a atender aos compromissos de
segurança e conformidade da organização.
Sobre a criptografia de armazenamento do Azure

Os dados no armazenamento do Azure são criptografados e descriptografados de forma transparente usando a
criptografia AESde 256 bits, uma das codificações de bloco mais fortes disponíveis e é compatível com o FIPS
140-2. A criptografia de armazenamento do Azure é semelhante à criptografia BitLocker no Windows.
A criptografia de armazenamento do Azure está habilitada para todas as contas de armazenamento, incluindo as
contas do Resource Manager e do armazenamento clássico. A criptografia de armazenamento do Azure não
pode ser desabilitada. Como os dados são protegidos por padrão, você não precisa modificar seu código ou
aplicativos para tirar proveito da criptografia de armazenamento do Azure.
Os dados em uma conta de armazenamento são criptografados independentemente do nível de desempenho
(Standard ou Premium), camada de acesso (quente ou frio) ou modelo de implantação (Azure Resource
Manager ou clássico). Todos os BLOBs na camada de arquivo também são criptografados. Todas as opções de
redundância de armazenamento do Azure dão suporte à criptografia e todos os dados nas regiões primária e
secundária são criptografados quando a replicação geográfica está habilitada. Todos os recursos de
armazenamento do Azure são criptografados, incluindo BLOBs, discos, arquivos, filas e tabelas. Todos os
metadados de objeto também são criptografados. Não há nenhum custo adicional para a criptografia de
Todos os blobs de blocos, BLOB de acréscimo ou BLOB de páginas que foram gravados no armazenamento do
Azure após 20 de outubro de 2017 são criptografados. Os BLOBs criados antes dessa data continuam a ser
criptografados por um processo em segundo plano. Para forçar a criptografia de um blob que foi criado antes
de 20 de outubro de 2017, você pode reescrever o blob. Para saber como verificar o status de criptografia de um
blob, consulte verificar o status de criptografia de um blob.
Para obter mais informações sobre os módulos de criptografia subjacentes à criptografia de armazenamento do
Azure, consulte API de criptografia: próxima geração.
Sobre o gerenciamento de chaves de criptografia

Os dados em uma nova conta de armazenamento são criptografados com chaves gerenciadas pela Microsoft.
Você pode contar com chaves gerenciadas pela Microsoft para a criptografia de seus dados ou pode gerenciar a
criptografia com suas próprias chaves. Se você optar por gerenciar a criptografia com suas próprias chaves, terá
duas opções:
Você pode especificar uma chave gerenciada pelo cliente com Azure Key Vault a ser usada para criptografar e
descriptografar dados no armazenamento de BLOBs e em arquivos do Azure. 1, 2 para obter mais
informações sobre chaves gerenciadas pelo cliente, consulte usar chaves gerenciadas pelo cliente com Azure
Key Vault para gerenciar a criptografia de armazenamento do Azure.
Você pode especificar uma chave fornecida pelo cliente em operações de armazenamento de BLOBs. Um
cliente que faz uma solicitação de leitura ou gravação no armazenamento de blob pode incluir uma chave de
criptografia na solicitação de controle granular sobre como os dados de blob são criptografados e
descriptografados. Para obter mais informações sobre chaves fornecidas pelo cliente, consulte fornecer uma
chave de criptografia em uma solicitação para o armazenamento de BLOBs (versão prévia).
A tabela a seguir compara as principais opções de gerenciamento de criptografia do armazenamento do Azure.
C H AVES GEREN C IA DA S C H AVES GEREN C IA DA S C H AVES F O RN EC IDA S P ELO

P EL A M IC RO SO F T P ELO C L IEN T E C L IEN T E
Operações de Azure Azure Azure

criptografia/descriptografia
Serviços de armazenamento Todos Armazenamento de BLOBs, Armazenamento de Blobs

do Azure com suporte arquivos do Azure1, 2
Armazenamento de chaves Repositório de chaves da Cofre de Chave do Azure Repositório de chaves

Microsoft próprio do cliente
Responsabilidade de Microsoft Cliente Cliente

rotação de chave
Controle de chave Microsoft Cliente Cliente
1 para obter informações sobre como criar uma conta que ofereça suporte ao uso de chaves gerenciadas pelo
cliente com o armazenamento de filas, consulte criar uma conta que dê suporte a chaves gerenciadas pelo
cliente para filas.
2 para obter informações sobre como criar uma conta que ofereça suporte ao uso de chaves gerenciadas pelo
cliente com o armazenamento de tabelas, consulte criar uma conta que dê suporte a chaves gerenciadas pelo
cliente para tabelas.
Próximas etapas
O que é o Azure Key Vault?
Configurar as chaves gerenciadas pelo cliente para a criptografia do Armazenamento do Azure do portal do
Azure
Configurar as chaves gerenciadas pelo cliente para a criptografia do Armazenamento do Azure do
PowerShell
Configurar as chaves gerenciadas pelo cliente para a criptografia do Armazenamento do Azure do CLI do
Azure
Usar chaves gerenciadas pelo cliente com Azure Key
Vault para gerenciar a criptografia de
armazenamento do Azure
Você pode usar sua própria chave de criptografia para proteger os dados em sua conta de armazenamento.
Quando você especifica uma chave gerenciada pelo cliente, essa chave é usada para proteger e controlar o acesso
à chave que criptografa os dados. Chaves gerenciadas pelo cliente oferecem maior flexibilidade para gerenciar
controles de acesso.
Você deve usar Azure Key Vault para armazenar as chaves gerenciadas pelo cliente. Você pode criar suas próprias
chaves e armazená-las em um cofre de chaves ou pode usar as APIs de Azure Key Vault para gerar chaves. A conta
de armazenamento e o cofre de chaves devem estar na mesma região e no mesmo locatário Azure Active
Directory (Azure AD), mas podem estar em assinaturas diferentes. Para obter mais informações sobre Azure Key
Vault, consulte o que é Azure Key Vault?.
Sobre chaves gerenciadas pelo cliente

O diagrama a seguir mostra como o armazenamento do Azure usa Azure Active Directory e Azure Key Vault para
fazer solicitações usando a chave gerenciada pelo cliente:
A lista a seguir explica as etapas numeradas no diagrama:

1. Um administrador de Azure Key Vault concede permissões a chaves de criptografia para a identidade
gerenciada associada à conta de armazenamento.
2. Um administrador de armazenamento do Azure configura a criptografia com uma chave gerenciada pelo
cliente para a conta de armazenamento.
3. O armazenamento do Azure usa a identidade gerenciada associada à conta de armazenamento para autenticar
o acesso a Azure Key Vault por meio de Azure Active Directory.
4. O armazenamento do Azure encapsula a chave de criptografia da conta com a chave do cliente em Azure Key
Vault.
5. Para operações de leitura/gravação, o armazenamento do Azure envia solicitações para Azure Key Vault para
desencapsular a chave de criptografia da conta para executar operações de criptografia e descriptografia.
Criar uma conta que dê suporte a chaves gerenciadas pelo cliente para
filas e tabelas
Os dados armazenados nos serviços de fila e tabela não são automaticamente protegidos por uma chave
gerenciada pelo cliente quando as chaves gerenciadas pelo cliente são habilitadas para a conta de
armazenamento. Opcionalmente, você pode configurar esses serviços no momento em que cria a conta de
armazenamento a ser incluída nessa proteção.
Para obter mais informações sobre como criar uma conta de armazenamento que dá suporte a chaves
gerenciadas pelo cliente para filas e tabelas, consulte criar uma conta que dê suporte a chaves gerenciadas pelo
cliente para tabelas e filas.
Os dados nos serviços BLOB e arquivo são sempre protegidos por chaves gerenciadas pelo cliente quando as
chaves gerenciadas pelo cliente são configuradas para a conta de armazenamento.
Habilitar chaves gerenciadas pelo cliente para uma conta de

armazenamento
As chaves gerenciadas pelo cliente podem ser habilitadas somente em contas de armazenamento existentes. O
cofre de chaves deve ser provisionado com políticas de acesso que concedem permissões de chave para a
identidade gerenciada associada à conta de armazenamento. A identidade gerenciada está disponível somente
depois que a conta de armazenamento é criada.
Quando você configura uma chave gerenciada pelo cliente, o armazenamento do Azure encapsula a chave de
criptografia de dados raiz para a conta com a chave gerenciada pelo cliente no cofre de chaves associado. A
habilitação de chaves gerenciadas pelo cliente não afeta o desempenho e entra em vigor imediatamente.
Quando você modifica a chave que está sendo usada para a criptografia de armazenamento do Azure habilitando
ou desabilitando chaves gerenciadas pelo cliente, atualizando a versão da chave ou especificando uma chave
diferente, a criptografia da chave raiz é alterada, mas os dados em sua conta de armazenamento do Azure não
precisam ser criptografados novamente.
Quando você habilita ou desabilita as chaves gerenciadas pelo cliente, ou quando você modifica a chave ou a
versão da chave, a proteção da chave de criptografia raiz é alterada, mas os dados em sua conta de
armazenamento do Azure não precisam ser criptografados novamente.
Para saber como usar as chaves gerenciadas pelo cliente com o Azure Key Vault para a criptografia de
armazenamento do Azure, consulte um destes artigos:
Configurar chaves gerenciadas pelo cliente com o Key Vault para a criptografia de armazenamento do Azure do
portal do Azure
PowerShell
Configurar chaves gerenciadas pelo cliente com o Key Vault para criptografia de armazenamento do Azure do
CLI do Azure
IMPORTANT
As chaves gerenciadas pelo cliente dependem de identidades gerenciadas para recursos do Azure, um recurso do Azure AD.
Identidades gerenciadas não têm suporte a cenários entre diretórios. Quando você configura chaves gerenciadas pelo cliente
no portal do Azure, uma identidade gerenciada é automaticamente atribuída à sua conta de armazenamento nos bastidores.
Se, posteriormente, você mover a assinatura, o grupo de recursos ou a conta de armazenamento de um diretório do Azure
AD para outro, a identidade gerenciada associada à conta de armazenamento não será transferida para o novo locatário,
portanto, as chaves gerenciadas pelo cliente poderão deixar de funcionar. Para obter mais informações, consulte
transferindo uma assinatura entre diretórios do Azure ad em perguntas frequentes e problemas conhecidos com
identidades gerenciadas para recursos do Azure.
Armazenar chaves gerenciadas pelo cliente no Azure Key Vault

Para habilitar chaves gerenciadas pelo cliente em uma conta de armazenamento, você deve usar um Azure Key
Vault para armazenar suas chaves. Você deve habilitar a exclusão reversível e não limpar as propriedades no
cofre de chaves.
Somente as chaves RSA de 2048 bits e RSA-HSM têm suporte com a criptografia de armazenamento do Azure.
Para obter mais informações sobre chaves, consulte Key Vault chaves em sobre Azure Key Vault chaves,
segredos e certificados.
Girar chaves gerenciadas pelo cliente

Você pode girar uma chave gerenciada pelo cliente em Azure Key Vault de acordo com suas políticas de
conformidade. Quando a chave é girada, você deve atualizar a conta de armazenamento para usar o novo URI de
versão de chave. Para saber como atualizar a conta de armazenamento para usar uma nova versão da chave no
portal do Azure, consulte a seção intitulada atualizar a versão da chave em Configurar chaves gerenciadas pelo
cliente para o armazenamento do Azure usando o portal do Azure.
A rotação da chave não aciona a nova criptografia dos dados na conta de armazenamento. Não há nenhuma ação
adicional necessária do usuário.
Revogar o acesso a chaves gerenciadas pelo cliente

Você pode revogar o acesso da conta de armazenamento para a chave gerenciada pelo cliente a qualquer
momento. Depois que o acesso às chaves gerenciadas pelo cliente for revogado ou depois que a chave tiver sido
desabilitada ou excluída, os clientes não poderão chamar operações que lidam ou gravam em um BLOB ou em
seus metadados. As tentativas de chamar qualquer uma das seguintes operações falharão com o código de erro
403 (proibido) para todos os usuários:
Listar BLOBsquando chamado com o include=metadata parâmetro no URI de solicitação
Get Blob
Get Blob Properties
Get Blob Metadata
Definir Metadados de Blob
Blob de instantâneo, quando chamado com x-ms-meta-name o cabeçalho de solicitação
Copiar blob
Copiar BLOB da URL
Definir camada do Blob
Colocar bloco
Colocar bloco da URL
Acrescentar Bloco
Anexar bloco da URL
Colocar Blob
Colocar Página
Colocar página da URL
Blob de cópia incremental
Para chamar essas operações novamente, restaure o acesso à chave gerenciada pelo cliente.
Todas as operações de dados que não estão listadas nesta seção podem continuar depois que as chaves
gerenciadas pelo cliente são revogadas ou uma chave é desabilitada ou excluída.
Para revogar o acesso às chaves gerenciadas pelo cliente, use o PowerShell ou CLI do Azure.
Chaves gerenciadas pelo cliente para Azure Managed disks

As chaves gerenciadas pelo cliente também estão disponíveis para gerenciar a criptografia de Azure Managed
disks. Chaves gerenciadas pelo cliente se comportam de maneira diferente para discos gerenciados do que para
recursos de armazenamento do Azure Para obter mais informações, consulte criptografia no servidor de Azure
Managed disks para Windows ou criptografia do lado do servidor de Azure Managed disks para Linux.
Próximas etapas
portal do Azure
PowerShell
Configurar chaves gerenciadas pelo cliente com o Key Vault para criptografia de armazenamento do Azure do
CLI do Azure
Criptografia de armazenamento do Azure para dados em repouso
Configurar preferência de roteamento de rede para o
Armazenamento do Microsoft Azure (versão prévia)
Você pode configurar a preferência de roteamento (versão prévia) para sua conta de armazenamento do Azure
para especificar como o tráfego de rede é roteado para sua conta de clientes pela Internet. Por padrão, o tráfego da
Internet é roteado para o ponto de extremidade público de sua conta de armazenamento sobre a rede global da
Microsoft. O Armazenamento do Microsoft Azure fornece opções adicionais para configurar como o tráfego é
roteado para sua conta de armazenamento.
Configurar a preferência de roteamento oferece a flexibilidade para otimizar o tráfego para um desempenho de
rede Premium ou para otimizar custos. Ao configurar uma preferência de roteamento, você especifica como o
tráfego será direcionado para o ponto de extremidade público para sua conta de armazenamento por padrão. Você
também pode publicar pontos de extremidade específicos de rota para sua conta de armazenamento.
Rede global da Microsoft versus roteamento da Internet

Por padrão, os clientes fora do ambiente do Azure acessam sua conta de armazenamento pela rede global da
Microsoft. A rede global da Microsoft é otimizada para seleção de caminho de baixa latência para fornecer um
desempenho de rede Premium com alta confiabilidade. Tanto o tráfego de entrada quanto de saída são roteados
pelo ponto de presença (POP) mais próximo do cliente. Essa configuração de roteamento padrão garante que o
tráfego de e para sua conta de armazenamento percorra a rede global da Microsoft em grande parte de seu
caminho, maximizando o desempenho da rede.
Você pode alterar a configuração de roteamento para sua conta de armazenamento para que o tráfego de entrada
e de saída seja roteado para e de clientes fora do ambiente do Azure por meio do POP mais próximo da conta de
armazenamento. Essa rota minimiza a passagem de seu tráfego pela rede global da Microsoft, entregando-a para o
ISP de trânsito na primeira oportunidade. Usar essa configuração de roteamento reduz os custos de rede.
O diagrama a seguir mostra como o tráfego flui entre o cliente e a conta de armazenamento para cada preferência
de roteamento:
Para obter mais informações sobre a preferência de roteamento no Azure, consulte O que é preferência de
roteamento (visualização)?.
Configuração de roteamento
Você pode escolher entre a rede global da Microsoft e o roteamento da Internet como a preferência de roteamento
padrão para o ponto de extremidade público da sua conta de armazenamento. A preferência de roteamento padrão
se aplica a todo o tráfego de clientes fora do Azure e afeta os pontos de extremidade para o Azure Data Lake
Storage Gen2, armazenamento de blobs, Arquivos do Azure e sites estáticos. Não há suporte para configurar a
preferência de roteamento para Filas do Azure ou Tabelas do Azure.
Você também pode publicar pontos de extremidade específicos de rota para sua conta de armazenamento. Quando
você publica pontos de extremidade específicos a uma rota, o Armazenamento do Microsoft Azure cria novos
pontos de extremidade públicos para sua conta de armazenamento que roteiam o tráfego no caminho desejado.
Essa flexibilidade permite direcionar o tráfego para sua conta de armazenamento em uma rota específica sem
alterar a preferência de roteamento padrão.
Por exemplo, a publicação de um ponto de extremidade específico de uma rota da Internet para o
“StorageAccountA” publicará os seguintes pontos de extremidades para sua conta de armazenamento:
SERVIÇ O DE A RM A Z EN A M EN TO P O N TO S DE EXT REM IDA DE ESP EC ÍF IC O S À ROTA
Serviço Blob StorageAccountA-internetrouting.blob.core.windows.net
Armazenamento do Data Lake Gen2 StorageAccountA-internetrouting.dfs.core.windows.net
Serviço de arquivos StorageAccountA-internetrouting.file.core.windows.net
Sites estáticos StorageAccountA-internetrouting.web.core.windows.net

Se você tiver um armazenamento com redundância geográfica com acesso de leitura (RA-GRS) ou uma conta de
armazenamento com redundância de zona geográfica com acesso de leitura (RA-GZRS), a publicação de pontos de
extremidade específicos da rota também criará automaticamente os pontos de extremidade correspondentes na
região secundária para acesso de leitura.
P O N TO DE EXT REM IDA DE SEC UN DÁ RIO SO M EN T E L EIT URA

SERVIÇ O DE A RM A Z EN A M EN TO ESP EC ÍF IC O À ROTA
Serviço Blob StorageAccountA-internetrouting-

secondary.blob.core.windows.net
Armazenamento do Data Lake Gen2 StorageAccountA-internetrouting-

secondary.dfs.core.windows.net
Serviço de arquivos StorageAccountA-internetrouting-

secondary.file.core.windows.net
Sites estáticos StorageAccountA-internetrouting-

secondary.web.core.windows.net
As cadeias de conexão para os pontos de extremidade específicos à rota publicados podem ser copiadas pelo portal
do Azure. Essas cadeias de conexão podem ser usadas para a autorização de chave compartilhada com todos os
SDKs e APIs do Armazenamento do Microsoft Azure existentes.
Sobre a visualização
A preferência de roteamento para o Armazenamento do Microsoft Azure está disponível nas seguintes regiões:
Sul da França
Centro-Norte dos EUA
Centro-Oeste dos EUA
Os seguintes problemas conhecidos afetam a visualização de preferência do roteamento para o Armazenamento
do Microsoft Azure:
As solicitações de acesso para o ponto de extremidade específico à rota para a rede global da Microsoft falham
com o erro HTTP 404 ou equivalente. O roteamento pela rede global da Microsoft funciona conforme o
esperado quando é definido como a preferência de roteamento padrão para o ponto de extremidade público.
Preços e cobrança
Para obter os detalhes de preços e cobranças, consulte a seção Preços em O que é preferência de roteamento
(visualização)?.
Próximas etapas
O que é preferência de roteamento (visualização)?
Configurar redes virtuais e firewalls do Armazenamento do Microsoft Azure
Recomendações de segurança para o armazenamento de blobs
Ofertas de conformidade do Armazenamento do
Azure
Para ajudar as organizações a atenderem aos requisitos nacionais, regionais e específicos do setor que controlam a
coleta e o uso de dados de indivíduos, o Microsoft Azure e o Armazenamento do Azure oferecem o conjunto mais
abrangente de certificações e atestados que qualquer provedor de serviços de nuvem.
Encontre abaixo as ofertas de conformidade do Armazenamento do Azure para garantir que seu serviço esteja
regulamentado ao usar o serviço de Armazenamento do Azure. Elas são aplicáveis às ofertas do Armazenamento
do Azure a seguir: Blobs, Arquivos, Filas, Tabelas, Discos, Armazenamento Esporádico e Armazenamento Premium.
Global
CSA-STAR-Attestation
CSA-Star-Certification
CSA-STAR-Self-Assessment
ISO 20000-1:2011
ISO 22301
ISO 27001
ISO 27017
ISO 27018
ISO 9001
WCAG 2.0
Governo dos EUA

DoD DISA L2, L4, L5
DoE 10 CFR Parte 810
EAR (US Export Administration Regulations)
FDA CFR Título 21 Parte 11
FedRAMP
FERPA
FIPS 140-2
NIST 800-171
VPATS Seção 508
Setor
23 NYCRR Parte 500
APRA (Austrália)
CDSA
DPP (Reino Unido)
FACT (Reino Unido)
FCA (Reino Unido)
FFIEC
FISC (Japão)
GLBA
GxP
HIPAA/HITECH
HITRUST
MARS-E
MAS + ABS (Singapura)
MPAA
NEN-7510 (Países Baixos)
PCI DSS
Avaliações compartilhadas
SOX
Regional
BIR 2012 (Países Baixos)
C5 (Alemanha)
CCSL/IRAP (Austrália)
CS Gold Mark (Japão)
DJCP (China)
ENISA IAF (UE)
ENS (Espanha)
Cláusulas de modelo da UE
Blindagem de privacidade UE-EUA
GB 18030 (China)
GDPR (UE)
IT Grundschutz Workbook (Alemanha)
LOPD (Espanha)
MTCS (Singapura)
My Number (Japão)
NZ CC Framework (Nova Zelândia)
PASF (Reino Unido)
PDPA (Argentina)
PIPEDA (Canadá)
TRUCS (China)
UK-G-Cloud
Próximas etapas
O Microsoft Azure e o Armazenamento do Azure mantêm a liderança em ofertas de conformidade. Encontre a
cobertura mais recente e detalhes no Microsoft TrustCenter.
Gerenciando a simultaneidade no Armazenamento
do Microsoft Azure
Aplicativos modernos baseados na Internet normalmente têm vários usuários exibindo e atualizando dados
simultaneamente. Isso exige que os desenvolvedores de aplicativos pensem cuidadosamente sobre como fornecer
uma experiência previsível para os usuários finais, especialmente para cenários em que vários usuários podem
atualizar os mesmos dados. Existem três estratégias de simultaneidade de dados principais que os desenvolvedores
normalmente consideram:
1. Simultaneidade otimista: um aplicativo realizando uma atualização verificará, como parte da atualização, se os
dados foram alterados desde a última vez que o aplicativo leu tais dados. Por exemplo, se dois usuários
visualizando uma página wiki fazem uma atualização na mesma página, a plataforma wiki deve garantir que a
segunda atualização não substitua a primeira e que os dois usuários entendam se suas respectivas atualizações
foram bem-sucedidas ou não. Essa estratégia é usada com mais frequência em aplicativos Web.
2. Simultaneidade pessimista: um aplicativo procurando realizar uma atualização bloqueará um objeto, impedindo
que outros usuários atualizem os dados até que o bloqueio seja liberado. Por exemplo, em um cenário de
replicação de dados mestre/subordinado em que somente o mestre executará atualizações, o mestre
normalmente manterá um bloqueio exclusivo por um período de tempo estendido nos dados para garantir que
ninguém mais possa atualizá-lo.
3. Último a gravar vence: uma abordagem que permite que quaisquer operações de atualização prossigam sem
verificar se algum outro aplicativo atualizou os dados desde que o aplicativo leu os dados pela primeira vez.
Essa estratégia (ou falta de uma estratégia formal) normalmente é usada em locais em que os dados estão
particionados de tal forma que não há probabilidade de vários usuários acessarem os mesmos dados. Ela
também pode ser útil em locais em que fluxos de dados de curta duração estão sendo processados.
Este artigo fornece uma visão geral de como a plataforma de Armazenamento do Azure simplifica o
desenvolvimento fornecendo suporte de primeira classe para essas três estratégias de simultaneidade.
O armazenamento do Azure simplifica o desenvolvimento na nuvem

O serviço de Armazenamento do Azure oferece suporte para as três estratégias, embora seja distinto em sua
capacidade de fornecer suporte completo para a simultaneidade otimista e pessimista, pois foi projetado para
englobar um modelo de consistência sólido, o qual garante que quando o serviço de Armazenamento confirma
uma operação de atualização ou inserção de dados, todos os acessos adicionais a tais dados possam ver a
atualização mais recente. As plataformas de armazenamento que usam um modelo de consistência eventual
apresentam um retardo entre o momento em que uma gravação é realizada por um usuário e o momento em que
os dados atualizados podem ser visualizados por outros usuários, o que complica o desenvolvimento de aplicativos
cliente para evitar que as inconsistências afetem os usuários finais.
Além de selecionar uma estratégia de simultaneidade adequada, os desenvolvedores também devem estar cientes
de como uma plataforma de armazenamento isola as alterações, especialmente as alterações no mesmo objeto
entre as transações. O serviço de Armazenamento do Azure usa o isolamento de instantâneo para permitir que as
operações de leitura ocorram simultaneamente às operações de gravação em uma única partição. Diferente de
outros níveis de isolamento, o isolamento de instantâneo garante que todas as leituras vejam um instantâneo
consistente dos dados mesmo durante atualizações, retornando basicamente os últimos valores confirmados
enquanto uma transação de atualização é processada.
Gerenciando a simultaneidade no armazenamento de BLOBs
Você pode optar por usar modelos de simultaneidade otimista ou pessimista para gerenciar o acesso a BLOBs e
contêineres no serviço BLOB. Se você não especificar explicitamente uma estratégia, o padrão será último a gravar
vence.
Simultaneidade otimista para blobs e contêineres
O serviço de Armazenamento atribui um identificador a todo objeto armazenado. Esse identificador é atualizado
sempre que uma operação de atualização é realizada em um objeto. O identificador é retornado para o cliente
como parte de uma resposta de HTTP GET usando o cabeçalho ETag (marca de entidade) que está definido no
protocolo HTTP. Um usuário realizando uma atualização em tal objeto pode enviar a Etag original juntamente com
um cabeçalho condicional para garantir que a atualização ocorra apenas se uma determinada condição for
atendida; nesse caso, a condição é um cabeçalho "If-Match", que exige que o Serviço de Armazenamento garanta
que o valor de Etag especificado na solicitação de atualização seja igual ao armazenado no Serviço de
Armazenamento.
A estrutura desse processo é a seguinte:
1. Recupere um blob do serviço de Armazenamento, a resposta inclui um valor de cabeçalho HTTP ETag que
identifica a versão atual do objeto no serviço de Armazenamento.
2. Ao atualizar o blob, inclua o valor de ETag recebido na etapa 1 no cabeçalho condicional If-Match da solicitação
enviada para o serviço.
3. O serviço compara o valor da ETag na solicitação com o valor da ETag atual do blob.
4. Se o valor da ETag atual do blob for uma versão diferente da ETag no cabeçalho condicional If-Match na
solicitação, o serviço retornará um erro 412 para o cliente. Isso indica para o cliente que outro processo
atualizou o blob desde que ele o recuperou.
5. Se o valor atual de ETag do blob for a mesma versão de ETag no cabeçalho condicional If-Match na solicitação,
o serviço realizará a operação solicitada e atualizará o valor da ETag atual do blob para mostrar que foi criada
uma nova versão.
O snippet de C# a seguir (usando a Client Storage Library 4.2.0) mostra um exemplo simples de como criar um If-
Match AccessCondition com base no valor da ETag acessado nas propriedades de um blob que foi recuperado
ou inserido anteriormente. Ele usa então o objeto AccessCondition quando atualiza o blob: o objeto
AccessCondition adiciona o cabeçalho If-Match à solicitação. Se outro processo tiver atualizado o blob, o serviço
blob retornará uma mensagem de status HTTP 412 (falha na pré-condição). Você pode baixar o exemplo completo
aqui: Gerenciando a Simultaneidade usando o Armazenamento do Azure.
// Retrieve the ETag from the newly created blob
// Etag is already populated as UploadText should cause a PUT Blob call
// to storage Blob service which returns the ETag in response.
string originalETag = blockBlob.Properties.ETag;
// This code simulates an update by a third party.

string helloText = "Blob updated by a third party.";
// No ETag provided so original blob is overwritten (thus generating a new ETag)

blockBlob.UploadText(helloText);
Console.WriteLine("Blob updated. Updated ETag = {0}",
blockBlob.Properties.ETag);
// Now try to update the blob using the original ETag provided when the blob was created
try
{
Console.WriteLine("Trying to update blob using original ETag to generate if-match access condition");
blockBlob.UploadText(helloText,accessCondition:
AccessCondition.GenerateIfMatchCondition(originalETag));
}
catch (StorageException ex)
{
if (ex.RequestInformation.HttpStatusCode == (int)HttpStatusCode.PreconditionFailed)
{
Console.WriteLine("Precondition failure as expected. Blob's original ETag no longer matches");
// TODO: client can decide on how it wants to handle the 3rd party updated content.
}
else
throw;
}
O armazenamento do Azure também inclui suporte para cabeçalhos condicionais adicionais, como If-Modified-
Since , If-inmodified-Since e If-None-Match , bem como combinações das mesmas. Para obter mais
informações, consulte especificando cabeçalhos condicionais para operações do serviço blob.
A tabela a seguir resume as operações de contêiner que aceitam cabeçalhos condicionais como If-Match na
solicitação e retornam um valor de ETag na resposta.
RETO RN A O VA LO R DE ETA G DO
O P ERA Ç Ã O C O N T ÊIN ER A C EITA C A B EÇ A L H O S C O N DIC IO N A IS
Create Container Sim Não
Get Container Properties Sim Não
Get Container Metadata Sim Não
Set Container Metadata Sim Sim
Get Container ACL Sim Não
Set Container ACL Sim Sim (*)
Delete Container Não Sim
Lease Container Sim Sim
Listar Blobs Não Não

(*) As permissões definidas por SetContainerACL são armazenadas em cache e as atualizações dessas permissões
levam 30 segundos para serem propagadas, período durante o qual não há garantia de que as atualizações são
consistentes.
A tabela a seguir resume as operações de blob que aceitam cabeçalhos condicionais como If-Match na solicitação
e retornam um valor de ETag na resposta.
O P ERA Ç Ã O RETO RN A O VA LO R DE ETA G A C EITA C A B EÇ A L H O S C O N DIC IO N A IS
Put Blob Sim Sim
Get Blob Sim Sim
Get Blob Properties Sim Sim
Set Blob Properties Sim Sim
Get Blob Metadata Sim Sim
Set Blob Metadata Sim Sim
Lease Blob (*) Sim Sim
Blob de instantâneo Sim Sim
Copiar blob Sim Sim (para o blob de origem e destino)
Anular copiar Blob Não Não
Delete Blob Não Sim
Put Block Não Não
Put Block List Sim Sim
Get Block List Sim Não
Put Page Sim Sim
Get Page Ranges Sim Sim
(*) Lease Blob não altera a ETag em um blob.

Simultaneidade pessimista para blobs
Para bloquear um blob para uso exclusivo, é possível obter uma concessão sobre ele. Ao adquirir uma concessão,
você especifica por quanto tempo precisa dela: esse período pode ser entre 15 e 60 segundos ou infinito, o que
resulta em um bloqueio exclusivo. Você pode renovar uma concessão finita para estendê-la e pode liberar qualquer
concessão quando terminar de trabalhar com ela. O serviço blob lança automaticamente concessões finitas quando
elas expiram.
As concessões permitem que diferentes estratégias de sincronização sejam suportadas, incluindo gravação
exclusiva/leitura compartilhada, gravação exclusiva/leitura exclusiva e gravação compartilhada/leitura exclusiva.
Nos locais em que há uma concessão, o serviço de Armazenamento impõe gravações exclusivas (operações de
exclusão, definição e colocação), mas a garantia de exclusividade para operações de leitura requer que o
desenvolvedor garanta que todos os aplicativos cliente usam uma ID de concessão e que apenas um cliente de
cada vez tem uma ID de concessão válida. As operações de leitura que não incluem uma ID de concessão resultam
em leituras compartilhadas.
O snippet de C# a seguir mostra um exemplo de aquisição de uma concessão exclusiva por 30 segundos em um
blob, atualizando o conteúdo do blob e liberando a concessão. Se já houver uma concessão válida no blob quando
você tentar adquirir uma nova concessão, o serviço blob retornará um resultado de status "conflito de HTTP (409)".
O snippet de código a seguir usa um objeto AccessCondition para encapsular as informações da concessão
quando ela faz uma solicitação para atualizar o blob no serviço de Armazenamento. Você pode baixar o exemplo
completo aqui: Gerenciando a Simultaneidade usando o Armazenamento do Azure.
// Acquire lease for 15 seconds

string lease = blockBlob.AcquireLease(TimeSpan.FromSeconds(15), null);
Console.WriteLine("Blob lease acquired. Lease = {0}", lease);
// Update blob using lease. This operation will succeed

const string helloText = "Blob updated";
var accessCondition = AccessCondition.GenerateLeaseCondition(lease);
blockBlob.UploadText(helloText, accessCondition: accessCondition);
Console.WriteLine("Blob updated using an exclusive lease");
//Simulate third party update to blob without lease

try
{
// Below operation will fail as no valid lease provided
Console.WriteLine("Trying to update blob without valid lease");
blockBlob.UploadText("Update without lease, will fail");
}
{
if (ex.RequestInformation.HttpStatusCode == (int)HttpStatusCode.PreconditionFailed)
Console.WriteLine("Precondition failure as expected. Blob's lease does not match");
else
throw;
}
Se você tentar realizar uma operação de gravação em um blob sob concessão sem enviar a ID de concessão, a
solicitação falhará com um erro 412. Observe que se a concessão expirar antes de chamar o método UploadText ,
mas você ainda utilizar a ID de concessão, a solicitação também falhará com um erro 412 . Para obter mais
informações sobre como gerenciar tempos de expiração de concessão e IDs de concessão, consulte a
documentação REST do blob de concessão .
As operações de blob a seguir podem usar concessões para gerenciar a simultaneidade pessimista:
Put Blob
Get Blob
Get Blob Properties
Set Blob Properties
Get Blob Metadata
Set Blob Metadata
Delete Blob
Put Block
Put Block List
Get Block List
Put Page
Get Page Ranges
Snapshot Blob - ID de concessão opcional se existir uma concessão
Copy Blob - ID de concessão obrigatória se existir uma concessão no blob de destino
Abort Copy Blob - ID de concessão obrigatória se existir uma concessão infinita no blob de destino
Lease Blob
Simultaneidade pessimista para contêineres
As concessões em contêineres permitem que as mesmas estratégias de sincronização sejam suportadas como nos
blobs (gravação exclusiva/leitura compartilhada, gravação exclusiva/leitura exclusiva e gravação
compartilhada/leitura exclusiva), no entanto, diferente dos blobs, o serviço de Armazenamento impõe
exclusividade apenas em operações de exclusão. Para excluir um contêiner com uma concessão ativa, o cliente deve
incluir a ID da concessão ativa com a solicitação de exclusão. Todas as outras operações de contêiner obtiveram
êxito em um contêiner sob concessão sem incluir a ID de concessão, caso em que são operações compartilhadas.
Se a exclusividade das operações de leitura ou atualização (colocação ou definição) for obrigatória, os
desenvolvedores devem garantir que todos os clientes usem uma ID de concessão e que apenas um cliente de cada
vez tenha uma ID de concessão válida.
As operações de contêiner a seguir podem usar concessões para gerenciar a simultaneidade pessimista:
Delete Container
Get Container Properties
Get Container Metadata
Set Container Metadata
Get Container ACL
Set Container ACL
Lease Container
Para obter mais informações, consulte:
Especificando cabeçalhos condicionais para operações do serviço Blob
Lease Container
Blob de concessão
Gerenciando a simultaneidade no armazenamento de tabelas

O serviço tabela usa verificações de simultaneidade otimista como o comportamento padrão quando você está
trabalhando com entidades, diferentemente do serviço BLOB, onde você deve optar explicitamente por executar
verificações de simultaneidade otimistas. A outra diferença entre os serviços de tabela e blob é que você só pode
gerenciar o comportamento de simultaneidade de entidades, enquanto com o serviço BLOB, você pode gerenciar a
simultaneidade de contêineres e blobs.
Para usar a simultaneidade otimista e verificar se outro processo modificou uma entidade desde que você a
recuperou do serviço de armazenamento de tabela, é possível usar o valor da ETag recebido quando o serviço
Tabela retorna uma entidade. A estrutura desse processo é a seguinte:
1. Recupere uma entidade do serviço de armazenamento de tabela, a resposta inclui um valor de ETag que
identifica o identificador atual associado a essa entidade no serviço de Armazenamento.
2. Ao atualizar a entidade, inclua o valor da ETag recebido na etapa 1 no cabeçalho obrigatório If-Match da
solicitação enviada para o serviço.
3. O serviço compara o valor da ETag na solicitação com o valor da ETag atual da entidade.
4. Se o valor da ETag atual da entidade for diferente da ETag no cabeçalho obrigatório If-Match na solicitação, o
serviço retornará um erro 412 para o cliente. Isso indica para o cliente que outro processo atualizou a entidade
desde que ele a recuperou.
5. Se o valor da ETag atual da entidade for o mesmo da ETag no cabeçalho obrigatório If-Match na solicitação ou o
cabeçalho If-Match contiver o caractere curinga (*), o serviço realizará a operação solicitada e atualizará o valor
da ETag atual da entidade para mostrar que ela foi atualizada.
Observe que, diferentemente do serviço BLOB, o serviço tabela requer que o cliente inclua um cabeçalho If-Match
em solicitações de atualização. No entanto, é possível forçar uma atualização incondicional (estratégia último a
gravar vence) e ignorar as verificações de simultaneidade se o cliente definir o cabeçalho If-Match com o caractere
curinga (*) na solicitação.
O snippet de C# a seguir mostra uma entidade de cliente que foi criada ou recuperada anteriormente tendo seu
endereço de email atualizado. A operação de recuperação ou inserção inicial armazena o valor da ETag no objeto do
cliente e, como a amostra usa a mesma instância de objeto ao executar a operação de substituição, ela
automaticamente envia o valor da ETag de volta ao serviço Tabela, permitindo que o serviço verifique se há
violações de simultaneidade. Se outro processo atualizou a entidade no armazenamento de tabela, o serviço
retorna uma mensagem de status HTTP 412 (Falha de precondição). Você pode baixar o exemplo completo aqui:
Gerenciando a Simultaneidade usando o Armazenamento do Azure.
try
{
customer.Email = "updatedEmail@contoso.org";
TableOperation replaceCustomer = TableOperation.Replace(customer);
customerTable.Execute(replaceCustomer);
Console.WriteLine("Replace operation succeeded.");
}
{
if (ex.RequestInformation.HttpStatusCode == 412)
Console.WriteLine("Optimistic concurrency violation – entity has changed since it was retrieved.");
else
throw;
}
Para desabilitar explicitamente a verificação de simultaneidade, você deve definir a propriedade ETag do objeto
employee para "*" antes de executar a operação de substituição.
customer.ETag = "*";
A tabela a seguir resume como as operações de entidade de tabela usam os valores de ETag:
REQ UER O C A B EÇ A L H O DE
O P ERA Ç Ã O RETO RN A O VA LO R DE ETA G SO L IC ITA Ç Ã O IF - M ATC H
Query Entities Sim Não
Insert Entity Sim Não
Update Entity Sim Sim
Merge Entity Sim Sim
Delete Entity Não Sim
Insert or Replace Entity Sim Não
Insert or Merge Entity Sim Não
Observe que as operações Inser t or Replace Entity e *Insert or Merge Entity***não realizam nenhuma
verificação de simultaneidade, pois não enviam um valor de ETag para o serviço Tabela.
Em geral, os desenvolvedores usando tabelas devem recorrer à simultaneidade otimista ao desenvolver aplicativos
escalonáveis. Se o bloqueio pessimista for necessário, uma abordagem que os desenvolvedores podem adotar ao
acessar tabelas é atribuir um blob designado para cada tabela e tentar obter uma concessão no blob antes de
operar na tabela. Essa abordagem exige que o aplicativo garanta que todos os caminhos de acesso de dados
obtenham a concessão antes de operar na tabela. Você também deve observar que o tempo mínimo de concessão
é de 15 segundos, o que exige uma consideração cuidadosa quanto à escalabilidade.
Operações em entidades
Gerenciando a simultaneidade no serviço Fila

Um cenário em que a simultaneidade é uma preocupação no serviço de filas ocorre quando vários clientes
recuperam mensagens de uma fila. Quando uma mensagem é recuperada da fila, a resposta inclui a mensagem e
um valor de recebimento pop, que é necessário para excluir a mensagem. A mensagem não é automaticamente
excluída da fila, mas após ser recuperada, não fica visível para outros clientes pelo intervalo de tempo especificado
pelo parâmetro visibilitytimeout. Espera-se que o cliente que recuperou a mensagem a exclua após ela ser
processada e antes do tempo especificado pelo elemento TimeNextVisible da resposta, que é calculado com base
no valor do parâmetro visibilitytimeout. O valor de visibilitytimeout é adicionado ao horário em que a mensagem é
recuperada para determinar o valor de TimeNextVisible.
O serviço Fila não tem suporte para a simultaneidade pessimista ou otimista e, por essa razão, os clientes que
processam mensagens recuperadas de uma fila devem garantir que elas sejam processadas de uma maneira
idempotente. A estratégia último a gravar vence é usada para operações de atualização, como
SetQueueServiceProperties, SetQueueMetaData, SetQueueACL e UpdateMessage.
API REST do serviço Fila
Receber mensagens
Gerenciando a simultaneidade em arquivos do Azure

O serviço Arquivo pode ser acessado usando dois pontos de extremidade de protocolo diferentes: SMB e REST. O
serviço REST não tem suporte para o bloqueio otimista ou pessimista e todas as atualizações seguirão a estratégia
último a gravar vence. Os clientes SMB que montam compartilhamentos de arquivos podem utilizar os
mecanismos de bloqueio do sistema de arquivos para gerenciar o acesso aos arquivos compartilhados, incluindo a
capacidade de realizar o bloqueio pessimista. Quando um cliente SMB abre um arquivo, ele especifica o modo de
compartilhamento e de acesso do arquivo. Configurar uma opção de Acesso ao Arquivo de “Gravação” ou
“Leitura/Gravação” juntamente com um modo de Compartilhamento de Arquivo de “Nenhum” resultará no
bloqueio do arquivo por um cliente SMB até o arquivo ser fechado. Se houver a tentativa de realização da operação
REST em um arquivo em que um cliente SMB tenha o arquivo bloqueado, o serviço REST retornará o código de
status 409 (Conflito) com o código de erro SharingViolation.
Quando um cliente SMB abre um arquivo para exclusão, ele marca o arquivo como exclusão pendente até que
todos os outros identificadores abertos do cliente SMB em tal arquivo sejam fechados. Enquanto um arquivo
estiver marcado como com exclusão pendente, todas as operações REST em tal arquivo retornarão o código de
status 409 (Conflito) com o código de erro SMBDeletePending. O código de status 404 (Não encontrado) não é
retornado, uma vez que é possível que o cliente SMB remova o sinalizador de exclusão pendente antes de fechar o
arquivo. Em outras palavras, o código de status 404 (Não encontrado) é esperado apenas se o arquivo tiver sido
removido. Observe que enquanto um arquivo estiver em um estado de exclusão pendente de SMB, ele não será
incluído nos resultados de Listar Arquivos. Observe também que as operações REST Delete File e REST Delete
Directory são confirmadas de forma atômica e não resultam no estado de exclusão pendente.
Gerenciando bloqueios de arquivo
Próximas etapas
Para encontrar o aplicativo de amostra completo citado nesse blog:
Gerenciando a simultaneidade usando o Armazenamento do Azure — aplicativo de amostra
Para obter mais informações sobre Armazenamento do Azure, consulte:
Página inicial do Armazenamento do Microsoft Azure
Introdução ao Armazenamento do Azure
Introdução ao Armazenamento para Blob, Tabela, Filas e Arquivos
Arquitetura de Armazenamento – Azure Storage: A Highly Available Cloud Storage Service with Strong
Consistency (Armazenamento do Azure: um serviço de armazenamento em nuvem altamente disponível com
coerência forte)
Conceder acesso limitado aos recursos de
armazenamento do Azure usando SAS (assinaturas
de acesso compartilhado)
Uma SAS (assinatura de acesso compartilhado) fornece acesso delegado seguro aos recursos em sua conta de
armazenamento sem comprometer a segurança de seus dados. Com uma SAS, você tem controle granular sobre
como um cliente pode acessar seus dados. Você pode controlar quais recursos o cliente pode acessar, quais
permissões eles têm sobre esses recursos e por quanto tempo a SAS é válida, entre outros parâmetros.
Tipos de assinaturas de Acesso compartilhado.

O armazenamento do Azure dá suporte a três tipos de assinaturas de acesso compartilhado:
SAS de delegação de usuário. Uma SAS de delegação de usuário é protegida com as credenciais do
Azure Active Directory (AD do Azure) e também pelas permissões especificadas para a SAS. Uma SAS de
delegação de usuário se aplica somente ao armazenamento de BLOB.
Para obter mais informações sobre a SAS de delegação de usuário, consulte criar uma delegação de usuário
de SAS (API REST).
SAS de Ser viço. Uma SAS de serviço é protegida com a chave da conta de armazenamento. Uma SAS de
serviço Delega acesso a um recurso em apenas um dos serviços de armazenamento do Azure:
armazenamento de BLOBs, armazenamento de filas, armazenamento de tabelas ou arquivos do Azure.
Para obter mais informações sobre a SAS do serviço, consulte criar um serviço SAS (API REST).
SAS de Conta. Uma SAS de conta é protegida com a chave da conta de armazenamento. Uma SAS de
conta delega acesso a recursos em um ou mais dos serviços de armazenamento. Todas as operações
disponíveis por meio de uma SAS de delegação de serviço ou de usuário também estão disponíveis por
meio de uma SAS de conta. Além disso, com a SAS da conta, você pode delegar acesso a operações que se
aplicam ao nível do serviço, como obter/definir propriedades de ser viço e obter as operações de
Estatísticas de ser viço . Você também pode delegar acesso a operações de leitura, gravação e exclusão
em contêineres de blob, tabelas, filas e compartilhamentos de arquivos que não são permitidos com um
SAS de serviço.
Para obter mais informações sobre a SAS da conta, crie uma SAS da conta (API REST).
NOTE
A Microsoft recomenda que você use as credenciais do Azure AD quando possível como uma prática recomendada de
segurança, em vez de usar a chave de conta, que pode ser mais facilmente comprometida. Quando o design do aplicativo
exigir assinaturas de acesso compartilhado para acesso ao armazenamento de BLOB, use as credenciais do Azure AD para
criar uma SAS de delegação de usuário quando possível para segurança superior.
Uma assinatura de acesso compartilhado pode assumir uma destas duas formas:
SAS ad hoc: Quando você cria uma SAS ad hoc, a hora de início, a hora de expiração e as permissões para a
SAS são todas especificadas no URI de SAS (ou implícita, se a hora de início for omitida). Qualquer tipo de SAS
pode ser uma SAS ad hoc.
SAS de ser viço com política de acesso armazenada: Uma política de acesso armazenada é definida em
um contêiner de recursos, que pode ser um contêiner de BLOBs, uma tabela, uma fila ou um compartilhamento
de arquivos. A política de acesso armazenada pode ser usada para gerenciar restrições para uma ou mais
assinaturas de acesso compartilhado do serviço. Quando você associa uma SAS de serviço a uma política de
acesso armazenada, a SAS—herda as restrições de hora de início, hora de—expiração e permissões definidas
para a política de acesso armazenada.
NOTE
Uma SAS de delegação de usuário ou uma SAS de conta deve ser uma SAS ad hoc. As políticas de acesso armazenadas não
têm suporte para a SAS de delegação de usuário ou a SAS da conta.
Como funciona uma assinatura de acesso compartilhado

Uma assinatura de acesso compartilhado é um URI assinado que aponta para um ou mais recursos de
armazenamento e inclui um token que contém um conjunto especial de parâmetros de consulta. O token indica
como os recursos podem ser acessados pelo cliente. Um dos parâmetros de consulta, a assinatura, é construído a
partir dos parâmetros de SAS e assinado com a chave que foi usada para criar a SAS. Esta assinatura é usada pelo
armazenamento do Azure para autorizar o acesso ao recurso de armazenamento.
Assinatura SAS
Você pode assinar uma SAS de uma das duas maneiras:
Com uma chave de delegação de usuário que foi criada usando as credenciais do Azure Active Directory
(AD do Azure). Uma SAS de delegação de usuário é assinada com a chave de delegação de usuário.
Para obter a chave de delegação de usuário e criar a SAS, uma entidade de segurança do Azure AD deve ser
atribuída a uma função de RBAC (controle de acesso baseado em função) que inclui a ação Microsoft.
Storage/storageAccounts/blobser vices/generateUserDelegationKey . Para obter informações
detalhadas sobre as funções RBAC com permissões para obter a chave de delegação de usuário, consulte
criar uma delegação de usuário (API REST).
Com a chave da conta de armazenamento. Uma SAS de serviço e uma SAS de conta são assinadas com a
chave da conta de armazenamento. Para criar uma SAS que é assinada com a chave de conta, um aplicativo
deve ter acesso à chave de conta.
Token SAS
O token SAS é uma cadeia de caracteres que você gera no lado do cliente, por exemplo, usando uma das
bibliotecas de cliente do armazenamento do Azure. O token SAS não é acompanhado pelo armazenamento do
Azure de nenhuma forma. Você pode criar um número ilimitado de tokens SAS no lado do cliente. Depois de criar
uma SAS, você pode distribuí-la aos aplicativos cliente que exigem acesso aos recursos em sua conta de
armazenamento.
Quando um aplicativo cliente fornece um URI de SAS para o armazenamento do Azure como parte de uma
solicitação, o serviço verifica os parâmetros SAS e a assinatura para verificar se ele é válido para autorizar a
solicitação. Se o serviço verificar que a assinatura é válida, a solicitação será autorizada. Caso contrário, a
solicitação será recusada com o código de erro 403 (proibido).
Aqui está um exemplo de um URI de SAS de serviço, mostrando o URI de recurso e o token SAS:
Quando usar uma assinatura de acesso compartilhado
Use uma SAS quando desejar fornecer acesso seguro aos recursos em sua conta de armazenamento para qualquer
cliente que não tenha permissões para esses recursos.
Um cenário comum em que uma SAS é útil é um serviço onde os usuários leem e gravam seus próprios dados na
sua conta de armazenamento. Em um cenário em que uma conta de armazenamento armazena dados do usuário,
há dois padrões de design comuns:
1. Os clientes carregam e baixam dados por meio de um serviço de proxy front-end, que executa a
autenticação. Esse serviço de proxy front-end tem a vantagem de permitir a validação de regras de negócio,
mas, para grandes quantidades de dados ou transações de alto volume, a criação de um serviço que possa
ser dimensionado de acordo com a demanda pode ser difícil ou dispendiosa.
2. Um serviço leve autentica o cliente conforme necessário e gera uma SAS. Depois que o aplicativo cliente
recebe a SAS, ele pode acessar os recursos da conta de armazenamento diretamente com as permissões
definidas pela SAS e para o intervalo permitido pela SAS. A SAS reduz a necessidade de roteamento de
todos os dados por meio do serviço de proxy front-end.
Muitos serviços reais podem usar uma combinação dessas duas abordagens. Por exemplo, alguns dados podem
ser processados e validados por meio do proxy front-end, enquanto outros são salvos e/ou lidos diretamente
usando SAS.
Além disso, uma SAS é necessária para autorizar o acesso ao objeto de origem em uma operação de cópia em
determinados cenários:
Quando você copia um blob para outro que reside em uma conta de armazenamento diferente, deve usar uma
SAS para autorizar acesso ao blob de origem. Outra opção é usar uma SAS para também autorizar acesso ao
blob de destino.
Quando você copia um arquivo para outro que reside em uma conta de armazenamento diferente, deve usar
uma SAS para autorizar acesso ao arquivo de origem. Outra opção é usar uma SAS para também autorizar
acesso ao arquivo de destino.
Quando você estiver copiando um blob em um arquivo, ou um arquivo em um blob, use uma SAS para
autorizar acesso ao objeto de origem, mesmo se os objetos de origem e destino residirem dentro da mesma
Práticas recomendadas ao usar SAS

Ao usar assinaturas de acesso compartilhado nos seus aplicativos, você precisará estar ciente de dois riscos
possíveis:
Se ocorrer perda de uma SAS, ela poderá ser usada por qualquer pessoa que a obtiver, o que poderá
comprometer a sua conta de armazenamento.
Se uma SAS fornecida para um aplicativo cliente expirar e o aplicativo não conseguir recuperar uma nova SAS
do seu serviço, a funcionalidade do aplicativo poderá ser prejudicada.
As recomendações a seguir para usar assinaturas de acesso compartilhado podem ajudar a atenuar esses riscos:
Sempre use HTTPS para criar ou distribuir uma SAS. Se uma SAS for passada por HTTP e interceptada, um
invasor que estiver realizando um ataque intermediário poderá lê-la e, em seguida, usá-la exatamente como o
usuário previsto, o que poderá comprometer dados confidenciais ou gerar dados corrompidos pelo usuário
mal-intencionado.
Use uma SAS de delegação de usuário quando possível. Uma SAS de delegação de usuário fornece
segurança superior a uma SAS de serviço ou a uma SAS de conta. Uma SAS de delegação de usuário é
protegida com as credenciais do Azure AD, para que você não precise armazenar sua chave de conta com seu
código.
Ter um plano de revogação em vigor para uma SAS. Verifique se você está preparado para responder se
uma SAS está comprometida.
Defina uma política de acesso armazenada para uma SAS de ser viço. As políticas de acesso
armazenadas oferecem a opção de revogar permissões para uma SAS de serviço sem a necessidade de
regenerar as chaves da conta de armazenamento. Defina o vencimento para um momento muito distante no
futuro (ou infinito) e certifique-se de que ela seja atualizada regularmente para uma data ainda mais além no
futuro.
Use tempos de expiração de cur to prazo em uma SAS do ser viço SAS ad hoc ou SAS da conta.
Dessa forma, mesmo se uma SAS for comprometida, ela será válida apenas por um breve período. Esta prática
será especialmente importante se você não puder fazer referência a uma política de acesso armazenada.
Períodos de vencimento breves também limitam a quantidade de dados que podem ser gravados em um blob,
limitando o tempo disponível para carregá-los.
Faça com que os clientes renovem a SAS automaticamente, se necessário. Os clientes devem renovar
a SAS bem antes da expiração, para que haja tempo para novas tentativas, caso o serviço que fornece a SAS
não esteja disponível. Se o SAS se destinar a ser usado para um pequeno número de operações imediatas e de
curta duração que devem ser concluídas no período de expiração, isso poderá ser desnecessário, pois não se
espera que a SAS seja renovada. No entanto, se você tiver um cliente que está sempre fazendo solicitações via
SAS, surge a possibilidade de expiração. A principal consideração consiste em equilibrar a necessidade de curta
duração da SAS (como mencionado acima) com a necessidade de garantir que o cliente solicite renovação com
antecedência suficiente (para evitar uma interrupção devido ao vencimento da SAS antes de uma renovação
bem-sucedida).
Tenha cuidado com a hora de início da SAS. Se você definir a hora de início de uma SAS para agora ,
poderão ser observadas falhas intermitentemente para os primeiros minutos devido à defasagem horária
(diferenças na hora atual de acordo com computadores diferentes). Em geral, defina a hora de início para pelo
menos 15 minutos no passado. Ou então, simplesmente não a defina, o que a tornará imediatamente válida em
todos os casos. Em geral, o mesmo também se aplica à hora de vencimento – lembre-se de que pode haver até
15 minutos de defasagem horária em um dos dois sentidos em qualquer solicitação. Para os clientes que usam
uma versão de REST anterior à 2012-02-12, a duração máxima de uma SAS que não faz referência a uma
política de acesso armazenada é 1 hora, e qualquer política que especifique um período maior do que esse
falhará.
Tenha cuidado com o formato de data e hora SAS. Se você definir a hora de início e/ou a expiração de
uma SAS, para alguns utilitários (por exemplo, para o utilitário de linha de comando AzCopy), você precisará do
formato DateTime como ' +% Y-% m-% dT% H:%M:% SZ ', especificamente incluindo os segundos para que ele
funcione usando o token SAS.
Seja específico com o recurso a ser acessado. Uma prática recomendada de segurança consiste em
fornecer os privilégios mínimos necessários a um usuário. Se um usuário precisar apenas de acesso de leitura a
uma única entidade, conceda-lhe acesso de leitura a essa única entidade, e não acesso de
leitura/gravação/exclusão a todas as entidades. Isso também ajuda a reduzir o dano caso uma SAS seja
comprometida, pois a SAS terá menos poder nas mãos de um invasor.
Entenda que sua conta será cobrada por qualquer uso, incluindo por meio de uma SAS. Se você
fornecer acesso de gravação a um blob, um usuário poderá optar por carregar um blob de 200 GB. Se você
também tiver concedido o acesso de leitura, será possível baixá-la 10 vezes, incorrendo em 2 TB de custos de
saída. Como mencionado, forneça permissões limitadas para ajudar a reduzir a ações em potencial de usuários
mal-intencionados. Use SAS de curta duração para reduzir essa ameaça (mas, tenha cuidado com a defasagem
horária na hora de término).
Validar os dados gravados usando uma SAS. Quando um aplicativo cliente gravar dados na sua conta de
armazenamento, tenha em mente de que poderá haver problemas com esses dados. Se o seu aplicativo
necessitar de que esses dados sejam validados ou autorizados antes que estejam prontos para uso, você deverá
realizar essa validação depois que os dados forem gravados e antes que eles sejam usados pelo seu aplicativo.
Essa prática também protegerá contra dados corrompidos ou mal-intencionados que estiverem sendo
gravados na sua conta por um usuário que adquiriu a SAS de forma adequada ou por um usuário que estiver
explorando uma SAS vazada.
Saiba quando não usar uma SAS. Às vezes, os riscos associados a uma determinada operação em relação à
sua conta de armazenamento superam os benefícios do uso de uma SAS. Para essas operações, crie um serviço
de camada intermediária que grave na sua conta de armazenamento após a validação, a autenticação e a
auditoria da regra de negócio. Além disso, algumas vezes é mais simples de gerenciar o acesso de outras
maneiras. Por exemplo, se quiser tornar todos os blobs de um contêiner publicamente legíveis, você poderá
tornar o contêiner Público, em vez de fornecer uma SAS para o acesso de cada cliente.
Use Azure Monitor e logs de armazenamento do Azure para monitorar seu aplicativo. Você pode
usar o Azure Monitor e o log da análise de armazenamento para observar qualquer pico nas falhas de
autorização devido a uma interrupção no serviço do provedor SAS ou à remoção inadvertida de uma política
de acesso armazenada. Para obter mais informações, consulte métricas de armazenamento do Azure em log de
Azure monitor e análise de armazenamento do Azure.
Introdução à SAS
Para começar a usar as assinaturas de acesso compartilhado, consulte os artigos a seguir para cada tipo de SAS.
SAS de delegação de usuário
Criar uma SAS de delegação de usuário para um contêiner ou BLOB com o PowerShell
Criar uma SAS de delegação de usuário para um contêiner ou BLOB com o CLI do Azure
Criar uma SAS de delegação de usuário para um contêiner ou BLOB com .NET
SAS do serviço
Criar uma SAS de serviço para um contêiner ou BLOB com .NET
SAS da conta
Criar uma SAS de conta com .NET
Próximas etapas
Delegar acesso com uma assinatura de acesso compartilhado (API REST)
Criar uma SAS de delegação de usuário (API REST)
Criar uma SAS de serviço (API REST)
Criar uma SAS de conta (API REST)
Monitoramento, diagnóstico e solução de problemas de
Armazenamento do Microsoft Azure
Visão geral
Questões de diagnóstico e de solução de problemas em um aplicativo distribuído hospedado em um ambiente de nuvem podem ser mais
complexas que em ambientes tradicionais. Aplicativos podem ser implantados em uma infraestrutura PaaS ou IaaS, no local, em um
dispositivo móvel ou em alguma combinação desses ambientes. Normalmente, o tráfego de rede do seu aplicativo pode passar por redes
privadas e públicas e o seu aplicativo pode usar múltiplas tecnologias de armazenamento tais como: Tabelas de Armazenamento, Blobs,
Filas e Arquivos do Microsoft Azure, além de outros repositórios de dados, tais como: bancos de dados de documentos e relacionais.
Para gerenciar esses aplicativos com êxito, monitore-os de forma proativa e entenda todos os aspectos de como se faz o diagnóstico e a
solução de problemas deles e de suas tecnologias dependentes. Como usuário dos serviços de Armazenamento do Azure, monitore
continuamente o serviços de Armazenamento que o seu aplicativo utiliza para qualquer mudança inesperada em comportamento (como
um tempo maior de resposta do que o normal) e faça o login para coletar mais dados detalhados para analisar o problema em
profundidade. As informações de diagnósticos que você obtiver tanto do monitoramento como do registro em log irão ajudá-lo a
determinar a raiz do problema que o seu aplicativo encontrou. Você poderá solucionar o problema e determinar as etapas apropriadas
que você pode tomar para corrigi-lo. O Armazenamento do Azure é um serviço básico do Azure e é parte importante da maioria das
soluções que os clientes implantam para a infraestrutura Azure. O Armazenamento do Azure inclui capacidades de simplificar questões de
monitoramento, diagnóstico e de soluções de problemas de armazenamento em seus aplicativos em nuvem.
NOTE
O Arquivos do Azure não dá suporte ao registro em log neste momento.
Para obter um guia prático para solução de problemas de ponta a ponta em aplicativos de armazenamento do Azure, consulte Solução de
problemas de ponta a ponta usando métricas de armazenamento do Azure e registro em log, AzCopy e Message Analyzer.
Introdução
Como este guia é organizado
Monitorando seu serviço de armazenamento
Monitoramento da integridade do serviço
Capacidade de monitoramento
Monitoramento de disponibilidade
Monitoramento de desempenho
Diagnóstico de problemas de armazenamento
Problemas de integridade do serviço
Problemas de desempenho
Diagnóstico de erros
Problemas de emulador de armazenamento
Ferramentas de log de armazenamento
Uso de ferramentas de log de rede
Rastreamento de ponta a ponta
Correlacionando dados de log
ID de solicitação do cliente
ID de solicitação do servidor
Carimbos de data/hora
Diretriz de solução de problemas
As métricas mostram alta AverageE2ELatency e baixa AverageServerLatency
As métricas mostram baixa AverageE2ELatency e baixa AverageServerLatency, mas o cliente está recebendo uma latência alta
As métricas mostram alta AverageServerLatency
Você está sofrendo atrasos inesperados na entrega de mensagens na fila
As métricas mostram um aumento em PercentThrottlingError
As métricas mostram um aumento em PercentTimeoutError
As métricas mostram um aumento em PercentNetworkError
O cliente está recebendo mensagens HTTP 403 (Proibido)
O cliente está recebendo mensagens HTTP 404 (não encontrado)
O cliente está recebendo mensagens HTTP 409 (conflito)
As métricas mostram uma baixa PercentSuccess ou as entradas de log analíticas têm operações com status de transação de
ClientOtherErrors
As métricas de capacidade mostram um aumento inesperado no uso da capacidade de armazenamento
Seu problema apareceu por usar o emulador de armazenamento para desenvolvimento ou teste
Você encontrou problemas ao instalar o SDK do Azure para .NET
Você tem um problema diferente com um serviço de armazenamento
Solução de problemas de VHDs em máquinas virtuais Windows
Solução de problemas de VHDs em máquinas virtuais Linux
Solução de problemas do Arquivos do Azure com Windows
Solução de problemas do Arquivos do Azure com Linux
Apêndices
Apêndice 1: usando o Fiddler para capturar o tráfego HTTP e HTTPS
Apêndice 2: usando o Wireshark para capturar o tráfego de rede
Anexo 3: Usando o Microsoft Message Analyzer para capturar o tráfego de rede
Apêndice 4: usando o Excel para exibir métricas e dados de log
Apêndice 5: monitoramento com o Application Insights para o Azure DevOps
Introdução
Esse guia mostra como você usa recursos como o Armazenamento Analítico do Azure, a biblioteca de armazenamento do cliente Azure
com login do lado do cliente e outras ferramentas de terceiros para identificar, diagnosticar e solucionar problemas relacionados ao
Esse guia deve ser lido primeiramente pelos desenvolvedores de serviços online que usam os Serviços Armazenamento do Azure e
profissionais de TI para gerenciar esses serviços online. Os objetivos desse guia são:
Ajudar a manter a integridade e o desempenho de suas contas de Armazenamento do Azure.
Oferecer os processos e as ferramentas necessários para ajudá-lo a decidir se um problema em um aplicativo está ou não relacionado
ao Armazenamento do Microsoft Azure.
Oferecer diretrizes de ações para resolver problemas relacionados ao armazenamento do Azure.
Como esse guia está organizado
A seção "[Monitoramento do seu serviço de armazenamento]“ descreve como monitorar a integridade e o desempenho de seus serviços
de armazenamento do Azure usando as métricas analíticas de armazenamento do Azure (Métricas de Armazenamento).
A seção "Diagnóstico de problemas de armazenamento" descreve como diagnosticar os problemas ao usar o log de armazenamento
analítico (Log de Armazenamento). Ela também descreve como habilitar o log do lado do cliente usando as facilidades em uma das
bibliotecas do cliente, como a Bibliotecas de Cliente de Armazenamento para .NET ou o SDK do Azure para Java.
A seção "Rastreamento de ponta a ponta" descreve como você correlaciona as informações contidas em vários arquivos de log e em
dados de métrica.
A seção "[Diretrizes de solução de problemas]" oferece diretrizes para a solução dos problemas mais comuns relacionados a
armazenamento que você possa encontrar.
Os "[Anexos]" incluem informações sobre o uso de ferramentas como o Wireshark e Netmon para a análise de dados de pacote de rede,
Fiddler para a análise de mensagens HTTP/HTTPS e o Microsoft Message Analyzer para correlacionar os dados de log.
Monitoramento do seu serviço de armazenamento

Se você está acostumado com o monitoramento de desempenho do Windows, é possível entender as Métricas de Armazenamento como
equivalentes aos contadores do Monitor de Desempenho do Windows. Nas Métricas de Armazenamento, você encontrará um grupo
detalhado de métricas (contadores com terminologia de Monitor de Desempenho do Windows) como disponibilidade de serviço, número
total de solicitações de serviço ou percentual de êxito em solicitações de serviço. Para obter uma lista completa das métricas disponíveis,
confira Esquema da tabela de métricas da análise do armazenamento. Você pode especificar se deseja que o serviço de armazenamento
colete e agregue as métricas a cada hora e ou cada minuto. Para mais informações sobre como habilitar as métricas e monitorar suas
contas de armazenamento, confira Habilitação das métricas de armazenamento e exibição dos dados de métrica.
Você pode escolher quais intervalos de hora das métricas que você quer exibir no Portal do Azure e configurar as regras de notificação
dos administradores por email caso a métrica a cada hora ultrapasse um valor particular. Para obter mais informações, consulte receber
notificações de alerta.
Recomendamos que você examine Azure monitor para armazenamento (versão prévia). É um recurso do Azure Monitor que oferece
monitoramento abrangente de suas contas de armazenamento do Azure, fornecendo uma exibição unificada de desempenho, capacidade
e disponibilidade dos serviços de armazenamento do Azure. Ele não exige que você habilite ou configure nada, e você pode exibir
imediatamente essas métricas dos gráficos interativos predefinidos e de outras visualizações incluídas.
O serviço de armazenamento coleta as métricas usando o melhor esforço, porém pode não registrar todas as operações de
armazenamento.
No Portal do Azure, você pode exibir as métricas de disponibilidade, total de solicitações e números das médias de latência para uma
conta de armazenamento. Uma regra de notificação também foi configurada para alertar um administrador caso uma disponibilidade caia
abaixo de um certo nível. Para exibir esses dados uma possível área para investigação é a tabela de porcentagem de êxito estar abaixo de
100% (para obter mais informações, consulte a seção "As métricas mostram uma baixa PercentSuccess ou as entradas de log analíticas
têm operações com status de transação de ClientOtherErrors").
Monitore continuamente seus aplicativos do Azure para garantir que sua integridade e desempenho estejam como esperados ao:
Estabelecer algumas métricas de linha de base para aplicativos que permitirão que você compare os dados atuais e identifique
qualquer mudança significativa em comportamento do armazenamento do Azure e seu aplicativo. Os valores para as métricas de linha
de base irão, em muitos casos, ser específicos para cada aplicativo e você deverá estabelecê-los ao realizar um teste de desempenho do
seu aplicativo.
Registrar métricas a cada minuto e usá-las para monitorar ativamente cada erros e anomalias inesperados tais como: picos em
contagem de erros ou taxas de solicitação.
Registrar métricas a cada hora e usá-las para monitorar os valores médios como: médias de contagem de erros ou taxas de solicitação.
Investigar os potenciais problemas usando as ferramentas de diagnóstico como discutido anteriormente na seção "Diagnóstico de
problemas de armazenamento“.
Os gráficos na imagem a seguir ilustram como a média que acontece nas métricas de hora em hora podem esconder picos em atividade.
As métricas de hora em hora parecem mostrar uma taxa constante de solicitações, enquanto as métricas de minuto em minuto revelam as
flutuações que estão realmente acontecendo.
O restante desta seção descreve quais as métricas que você deve monitorar e o porquê.
Monitoramento da integridade do serviço
Você pode usar o Portal do Azure para exibir a integridade do serviço de armazenamento (e outros serviços do Azure) em todas as
regiões do Azure no mundo. O monitoramento permite que você veja imediatamente se um problema fora do seu controle está afetando
o serviço de armazenamento na região em que você usa o seu aplicativo.
O Portal do Azure pode também fornecer notificações de incidentes que afetam os diversos serviços do Azure. Nota: Essa informação está
disponível anteriormente, juntamente com os dados históricos, no Painel de Serviços do Azure.
Enquanto o Portal do Azure coleta informações sobre integridade de dentro dos centros de dados do Azure (monitoramento inside-out),
você também pode considerar a adoção de uma abordagem outside-in para gerar transações sintéticas que acessam periodicamente o
seu aplicativo Web hospedado no Azure de vários locais. Os serviços oferecidos pelo Dynatrace e Application Insights no Azure DevOps
são exemplos dessa abordagem. Para obter mais informações sobre o Application Insights no Azure DevOps, confira o anexo "Anexo 5:
Monitoramento com o Application Insights no Azure DevOps".
Monitoramento de capacidade
As métricas de armazenamento apenas armazena as métricas de capacidade do serviço blob porque os blobs normalmente são
responsáveis pela maior proporção dos dados armazenados (no momento em que se escreve, não é possível usar as métricas de
armazenamento para monitorar a capacidade de suas tabelas e filas). Você pode encontrar esses dados na tabela $MetricsCapacityBlob
se você tiver habilitado o monitoramento para o serviço blob. As métricas de armazenamento registram esses dados uma vez ao dia e
você pode usar o valor do RowKey para determinar se uma linha contém uma entidade que se relaciona aos dados do usuário (dados do
valor) ou dados analíticos (valor analítico ). Cada entidade armazenada contém informações sobre a quantidade de armazenamento
usada (Capacidade medida em bytes) e o número atual de contêineres (ContainerCount ) e blobs (ObjectCount ) em uso em cada
conta de armazenamento. Para saber mais sobre as métricas de capacidade armazenadas na tabela $MetricsCapacityBlob , consulte
Esquema da tabela de métricas da análise de armazenamento.
NOTE
Monitore esses valores por meio de um aviso antecipado de que você está se aproximando dos limites de capacidade de sua conta de armazenamento.
No Portal do Azure, você pode adicionar as regras de alertas para notificá-lo se o uso de armazenamento agregado excede ou está abaixo dos limites
que você especificou.
Para ajudar na estimativa do tamanho dos diversos objetos de armazenamento, tais como os blobs, consulte a postagem no blog
Compreendendo a cobrança do Armazenamento do Azure – Largura de banda, transações e capacidade.
Monitoramento de disponibilidade
Monitore a disponibilidade dos serviços de monitoramento em sua conta de armazenamento monitorando os valores na coluna de
Disponibilidade nas tabelas métricas de hora em hora ou de minuto em minuto — $MetricsHourPrimar yTransactionsBlob ,
$MetricsHourPrimar yTransactionsTable , $MetricsHourPrimar yTransactionsQueue ,
$MetricsMinutePrimar yTransactionsBlob , $MetricsMinutePrimar yTransactionsTable ,
$MetricsMinutePrimar yTransactionsQueue , $MetricsCapacityBlob . A coluna Disponibilidade contém um valor percentual que
indica a disponibilidade do serviço ou da operação API representada pela linda (a RowKey mostra se uma linha contém as métricas para
o serviço como um todo ou para uma operação API específica).
Qualquer valor inferior a 100% indica que houve falha em algumas solicitações de armazenamento. Você pode ver porque estão falhando
ao examinar as outras colunas nos dados de métricas que mostras os números de solicitações com diferentes tipos de erros, tais como
Ser verTimeoutError . Espere para ver a Disponibilidade cair temporariamente abaixo de 100% devido a razões como tempo limite do
servidor transitório enquanto o serviço muda as partições para melhor balancear a carga da solicitação; a lógica de nova tentativa no
aplicativo do seu cliente deve lidar com tais condições intermitentes. O artigo Operações registradas e mensagens de status da análise de
armazenamento lista os tipos de transação que as Métricas de armazenamento incluem em seu cálculo de Disponibilidade .
No Portal do Azure, você pode adicionar as regras de alertas para notificá-lo se a Disponibilidade de um serviço está abaixo dos limites
que você especificou.
A seção "[Diretrizes para solução de problemas]" deste guia descreve alguns dos problemas mais comuns de armazenamento
relacionados a disponibilidade.
Monitoramento de desempenho
Para monitorar o desempenho dos serviços de armazenamento, você pode usar as seguintes métricas das tabelas de hora em hora ou
minuto em minuto.
Os valores nas colunas AverageE2ELatency e AverageSer verLatency mostram o tempo médio do serviço de armazenamento ou
do tipo da operação de API que está sendo usado para processar as solicitações. AverageE2ELatency é uma medida de latência de
ponta a ponta que inclui o tempo levado para ler as solicitações e enviar a resposta, além do tempo levado para processar a solicitação
(por isso, inclui a latência de rede uma vez que a solicitação atinge o serviço de armazenamento); AverageSer verLatency é a medida
apenas do tempo de processamento e, por isso, exclui qualquer latência de rede relacionada à comunicação com o cliente. Consulte a
seção "As métricas mostram alta AverageE2ELatency e baixa AverageServerLatency" posteriormente neste guia para uma discussão
sobre porque pode haver uma diferença significante entre esses dois valores.
Os valores nas colunas TotalIngress e TotalEgress mostram um valor total de dados, em bytes, entrando e saindo do seu serviço de
armazenamento ou por um tipo de operação API específica.
Os valores na coluna TotalRequests mostram o número total de solicitações que o serviço de armazenamento da operação API está
recebendo. TotalRequests é o número total de solicitações que o serviço de armazenamento recebe.
Normalmente, você irá monitorar as mudanças inesperadas em qualquer um desses valores como indicador de que você tem um
problema que requer uma investigação.
No Portal do Azure, você pode adicionar as regras de alertas para notificá-lo se quaisquer métricas de desempenho desse serviço estão
abaixo dos limites que você especificou.
A seção "[Diretrizes para solução de problemas]" deste guia descreve alguns dos problemas mais comuns de armazenamento
relacionados a desempenho.
Diagnóstico de problemas de armazenamento

Há inúmeros caminhos que você pode ter para ficar ciente de um problema em seu aplicativo, incluindo:
Uma grande falha que faz com que o aplicativo entre em pane ou pare de funcionar.
Mudanças significativas dos valores de linha de base em métricas que você está monitorando como descritas na seção anterior "
[Monitoramento do seu serviço de armazenamento]“.
Relatórios de usuários do seu aplicativo informando que uma operação em particular não foi concluída como esperado ou que algum
recurso não está funcionando.
Erros gerados dentro do seu aplicativo que aparecem nos arquivos de log ou em outros métodos de notificação.
Normalmente, problemas relacionados aos serviços de armazenamento do Azure estão entre uma das quatro grandes categorias:
Seu aplicativo apresenta um problema de desempenho, relatado por um de seus usuários ou revelado por mudanças nas métricas de
desempenho.
Há um problema com a infraestrutura de armazenamento do Azure em uma ou mais regiões.
Seu aplicativo está encontrando um erro, relatado por um de seus usuários ou revelado por um aumento em uma das métricas de
contagem de erro que você monitora.
Durante o desenvolvimento e o teste, você talvez esteja usando o emulador de armazenamento local; você pode encontrar alguns
problemas relacionados especificamente ao uso do emulador de armazenamento.
As seguintes seções apresentam as etapas que você deve seguir para diagnosticar e solucionar os problemas em cada uma dessas quatro
categorias. A seção "[Diretrizes de solução de problemas]" posteriormente nesse guia dará mais detalhes para alguns dos problemas mais
comuns que você pode encontrar.
Problemas de integridade do serviço
Problemas de integridade do serviço são normalmente fora do seu controle. O Portal do Azure dá informações sobre quaisquer
problemas existentes com os serviços do Azure inclusive com os serviços de armazenamento. Se você tiver optado pelo Armazenamento
com Redundância Geográfica com Acesso de Leitura quando criou sua conta de armazenamento, então, no caso de seus dados estarem
indisponíveis no local principal, o aplicativo pode mudar temporariamente para cópia somente leitura em um local secundário. Para fazer
a leitura do local secundário, o aplicativo deve ser capaz de alternar entre o uso de locais de armazenamento principal e secundário e ser
capaz de trabalhar em modo de funcionamento reduzido com dados somente leitura. As bibliotecas do cliente de armazenamento do
Azure permitem que você defina uma política de tentativa que pode ler a partir do armazenamento secundário caso a leitura do
armazenamento principal falhar. Seu aplicativo também precisa estar ciente que os dados do local secundário são consistentes. Para saber
mais, consulte no blog a postagem Opções de redundância do Armazenamento do Azure e armazenamento com redundância geográfica
do acesso de leitura.
Problemas de desempenho
O desempenho de um aplicativo pode ser subjetivo, especialmente da perspectiva de um usuário. Por isso, é importante ter métricas de
linha de base disponíveis para ajudá-lo a identificar onde pode haver um problema de desempenho. Muitos fatores podem afetar o
desempenho de um serviço de armazenamento do Azure da perspectiva do aplicativo do cliente. Esses fatores podem operar em um
serviço de armazenamento, no cliente ou em uma infraestrutura de rede; portanto, é importante ter uma estratégia para identificar a
origem do problema de desempenho.
Após ter identificado o possível local da causa do problema de desempenho a partir das métricas, você pode usar os arquivos de log para
encontrar as informações detalhadas para diagnosticar e solucionar o problema mais profundamente.
A seção "[Diretrizes de solução de problemas]" posteriormente nesse guia dará mais detalhes para alguns dos problemas mais comuns
que você pode encontrar.
Diagnóstico de erros
Usuários do seu aplicativo podem notificá-lo de erros registrados pelo aplicativo do cliente. Métricas de armazenamento também
registram contagens de diferentes tipos de erros do seus serviços de armazenamento, tais como NetworkError , ClientTimeoutError ou
AuthorizationError . Enquanto as métricas de armazenamento apenas registram as contagens de diferentes tipos de erros, você obter
mais detalhes sobre solicitações individuais ao examinar os logs do servidor, do cliente e da rede. Normalmente, o código de status HTTP
que voltam para o serviço de armazenamento darão uma indicação da razão da falha da solicitação.
NOTE
Lembre-se de que você deve esperar ver alguns erros intermitentes: por exemplo, erros devido a condições transitórias da rede ou erros de aplicativo.
Os seguintes recursos são úteis para compreender os status relacionados a armazenamento e os códigos de erro:
Códigos de erro comuns da API REST
Códigos de erro do serviço blob
Códigos de erro do serviço Fila
Códigos de erro do serviço tabela
Códigos de erro do serviço de arquivo
Problemas de emulador de armazenamento
O SDK do Azure inclui um emulador de armazenamento que você pode executar em uma estação de trabalho de desenvolvimento. Esse
emulador simula a maior parte do comportamento dos serviços de armazenamento do Azure e é útil durante o desenvolvimento e o
teste, permitindo que você execute aplicativos que você usam serviços de armazenamento do Azure sem a necessidade de uma assinatura
e uma conta de armazenamento do Azure.
A seção "[Diretrizes de solução de problemas]" deste guia descreve alguns dos problemas mais comuns usando o emulador de
armazenamento.
Ferramentas de log de armazenamento
O log de armazenamento oferece o log do lado do servidor para solicitações de armazenamento na sua conta de armazenamento do
Azure. Para saber mais sobre como habilitar o log do lado do servidor e acessar os dados de log, consulte Enabling Storage Logging and
Accessing Log Data(Como habilitar o registro em log do armazenamento e o acesso aos dados do log).
A biblioteca do cliente de armazenamento para .NET habilita você a coletar dados de log do cliente relacionados as operações de
armazenamento realizadas pelo seu aplicativo. Para saber mais, consulte Registro em log no lado do cliente com a biblioteca do cliente de
armazenamento para .NET.
NOTE
Em algumas circunstâncias (tais como falhas de autorizações SAS) um usuário pode informar um erro pelo qual você não pode encontrar nenhum dado
de solicitação nos logs de armazenamento do lado do cliente. Você pode usar as capacidades de log da biblioteca do cliente de armazenamento para
investigar se a causa desse problema está no cliente ou use as as ferramentas de monitoramento de rede para investigar a rede.
Uso de ferramentas de log de rede

Você pode capturar o tráfego entre o cliente e o servidor para dar informações detalhadas sobre os dados que o cliente e o servidor estão
trocando e as condições subjacentes de rede. Ferramentas úteis de log de rede incluem:
Fiddler é um proxy de depuração Web gratuito que permite que você examine os cabeçalhos e dados de conteúdo das solicitações
HTTP e HTTPS e as mensagens de resposta. Para saber mais, consulte Anexo 1: Usando o Fiddler para capturar o tráfego HTTP e HTTPS.
Monitor de Rede da Microsoft (Netmon) e Wireshark são analisadores de protocolo de rede gratuitos que permitem que você exiba
informações detalhadas de pacote de uma vasta gama de protocolos de rede. Para obter mais informações sobre o Wireshark, consulte
"Anexo 2: Usando o Wireshark para capturar o tráfego de rede".
O Microsoft Message Analyzer é uma ferramenta da Microsoft que substitui o Netmon e que além de capturar os dados de pacote de
rede, a ajuda a exibir e analisar os dados de log capturados das outras ferramentas. Para saber mais, consulte "Anexo 3: Usando o
Microsoft Message Analyzer para capturar o tráfego de rede".
Se você quer realizar um teste de conectividade básico para verificar que a máquina do cliente pode se conectar ao serviço de
armazenamento do Azure pela rede, você não pode fazer isso usando a ferramenta padrão ping no cliente. No entanto, você pode usar
a ferramenta tcping para verificar a conectividade.
Em muitos casos, os dados de log a partir do log de armazenamento e da biblioteca do cliente serão suficientes para diagnosticar um
problema, porém, em alguns cenários, você poderá precisar de informações mais detalhadas que podem ser providas por essas
ferramentas de log de rede. Por exemplo, usando o Fiddler para ver as mensagens HTTP e HTTPS permitem que você exiba o cabeçalho e
os dados de carga enviados para e a partir dos serviços de armazenamento, o qual permite que você examine como o aplicativo do cliente
repete as operações de armazenamento. Analisadores de protocolo, tais como Wireshark opera em nível de pacote permitindo que você
exiba os dados TCP, os quais permitem que você solucione problemas de pacotes perdidos e problemas de conectividade. O Message
Analyzer pode operar tanto em camadas HTTP como TCP.
Rastreamento de ponta a ponta

O rastreamento de ponta a ponta usando uma variedade de arquivos de log é uma técnica útil para a investigação de potenciais
problemas. Você pode usar as informações de dia/hora de seus dados de métrica como uma indicação de onde começar a procurar nos
arquivos de log para informações mais detalhadas que irão ajudá-lo a solucionar o problema.
Correlacionamento de dados de log
Ao exibir os logs dos aplicativos do cliente, rastreamento de rede e log de armazenamento do servidor é fundamental ser capaz de
correlacionar as solicitações com os diferentes arquivos de log. Os arquivos de log incluem inúmeros campos diferentes que são úteis
como identificadores de correlação. A ID de solicitação do cliente é o campo mais útil para usa para correlacionar entradas em logs
diferentes. Entretanto, algumas vezes, pode ser útil usar ou a ID de solicitação do servidor ou os carimbos de data/hora. As seções a seguir
fornecem mais detalhes sobre essas opções.
ID de solicitação do cliente
A Biblioteca de Clientes de Armazenamento gera automaticamente uma ID de solicitação do cliente exclusiva para cada solicitação.
No log do lado do cliente criado pela Biblioteca de Clientes de Armazenamento, a ID de solicitação do cliente aparece no campo ID de
solicitação do cliente de cada entrada de log relacionada à solicitação.
No rastreamento da rede tal como uma capturada pelo Fiddler, a ID de solicitação do cliente está visível em mensagens de solicitação
como o valor do cabeçalho HTTP x-ms-client-request-id .
No log de armazenamento do lado do servidor, a ID de solicitação do cliente aparece na coluna ID da solicitação do cliente.
NOTE
É possível que várias solicitações compartilhem a mesma ID de solicitação do cliente porque o cliente pode atribuir esse valor (embora a Biblioteca de
Clientes de Armazenamento atribua um novo valor automaticamente). No caso de novas tentativas do cliente, todas as tentativas compartilham a
mesma ID de solicitação do cliente. No caso de um lote enviado pelo cliente, o lote tem uma única ID de solicitação de cliente.
ID de solicitação do servidor
O serviço de armazenamento gera automaticamente IDs de solicitação do servidor.
No log de armazenamento do lado do servidor, a ID de solicitação do servidor aparece na coluna Cabeçalho da ID de solicitação .
Em um rastreamento de rede como um capturado pelo Fiddler, a ID de solicitação do servidor aparece em mensagens de resposta
como o valor do cabeçalho http x-MS-Request-ID .
No log do lado do cliente criado pela Biblioteca de Clientes de Armazenamento, a ID de solicitação do cliente aparece na coluna Texto
de Operação para a entrada de log mostrando detalhes da resposta do servidor.
NOTE
O serviço de armazenamento sempre atribui uma única ID de solicitação de servidor para cada solicitação recebida, de modo que cada tentativa do
cliente e cada operação incluída no lote tenha uma ID de solicitação do servidor exclusiva.
Se a biblioteca do cliente de armazenamento aciona uma StorageException no cliente, a propriedade RequestInformation contém um
objeto RequestResult que inclui uma propriedade Ser viceRequestID . Você também pode acessar um objeto RequestResult a partir de
uma instância de OperationContext .
O exemplo de código abaixo demonstra como definir um valor personalizado de ClientRequestId ao anexar um objeto
OperationContext à solicitação para o serviço de armazenamento. Isso também mostra como recuperar p valor de Ser verRequestId
de uma mensagem de resposta.
//Parse the connection string for the storage account.

const string ConnectionString = "DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key";
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConnectionString);
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
// Create an Operation Context that includes custom ClientRequestId string based on constants defined within the application along
with a Guid.
OperationContext oc = new OperationContext();
oc.ClientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());
try
{
CloudBlobContainer container = blobClient.GetContainerReference("democontainer");
ICloudBlob blob = container.GetBlobReferenceFromServer("testImage.jpg", null, null, oc);
var downloadToPath = string.Format("./{0}", blob.Name);
using (var fs = File.OpenWrite(downloadToPath))
{
blob.DownloadToStream(fs, null, null, oc);
Console.WriteLine("\t Blob downloaded to file: {0}", downloadToPath);
}
}
catch (StorageException storageException)
{
Console.WriteLine("Storage exception {0} occurred", storageException.Message);
// Multiple results may exist due to client side retry logic - each retried operation will have a unique ServiceRequestId
foreach (var result in oc.RequestResults)
{
Console.WriteLine("HttpStatus: {0}, ServiceRequestId {1}", result.HttpStatusCode, result.ServiceRequestID);
}
}
Carimbos de data/hora
Você também pode usar o carimbo de data/hora para localizar as entradas de log relacionadas, porém cuidado com qualquer distorção
que possa existir entre o relógio do cliente e do servidor. Pesquise por mais ou menos 15 minutos para coincidir as entradas do lado do
servidor com base no carimbo de data/hora do cliente. Lembre-se que os metadados de blob para os blobs contendo métricas indicam o
intervalo de tempo para as métricas armazenadas no blob. Esse intervalo de tempo será útil se você tiver muitos blobs de métricas para o
mesmo minuto ou hora.
Diretriz de solução de problemas

Essa seção irá ajudá-lo com o diagnóstico e com a solução de alguns dos problemas mais comuns que seu aplicativo pode encontrar ao
usar os serviços de armazenamento do Azure. Use a lista abaixo para localizar as informações relevantes para o seu problema específico.
Ár vore de decisão de solução de problemas
O seu problema está relacionado ao desempenho de um dos serviços de armazenamento?

O seu problema está relacionado à disponibilidade de um dos serviços de armazenamento?

O seu aplicativo do cliente está recebendo uma resposta HTTP 4XX (tal como 404) de um serviço de armazenamento?
O cliente está recebendo mensagens HTTP 403 (Proibido)
O cliente está recebendo mensagens HTTP 404 (não encontrado)
O cliente está recebendo mensagens HTTP 409 (conflito)
ClientOtherErrors
As métricas de capacidade mostram um aumento inesperado no uso da capacidade de armazenamento
[Você está enfrentando reinicializações inesperadas das Máquinas Virtuais que contêm um grande número de VHDs anexados]

A figura abaixo da ferramenta de monitoramento do portal do Azure mostra um exemplo em que a AverageE2ELatency é
significantemente mais alta que a AverageSer verLatency .
O serviço de armazenamento calcula apenas a métrica AverageE2ELatency para solicitações de êxito e, ao contrário de
AverageSer verLatency , inclui o tempo que o cliente leva para enviar os dados e receber a confirmação do serviço de armazenamento.
Portanto, a diferença entre a AverageE2ELatency e a AverageSer verLatency pode ser ou devido a lentidão de resposta do aplicativo
do cliente ou devido às condições da rede.
NOTE
Você também pode exibir E2ELatency e Ser verLatency das operações de armazenamento individual nos dados de registro do log de
Armazenamento.
Investigação dos problemas de desempenho do cliente

Entre as possíveis razões para a lentidão de resposta do cliente estão: ter um número limitado de conexões ou threads disponíveis ou ter
poucos recursos, como CPU, memória ou largura de banda de rede. Você pode ser capaz de resolver os problemas ao modificar o código
do cliente para ser mais eficiente (por exemplo ao usar chamadas assíncronas para o serviço de armazenamento) ou usar uma máquina
virtual maior (com mais cores e mais memória).
Para os serviços tabela e fila, o algoritmo Nagle também pode causar alta AverageE2ELatency em comparação com
AverageSer verLatency : para obter mais informações, consulte o algoritmo do post Nagle não é amigável em direção a pequenas
solicitações. Você pode desabilitar o algoritmo de Nagle em código ao usar a classe Ser vicePointManager no namespace System.Net .
Faça isso antes de fazer qualquer chamada para os serviços de tabela ou fila no seu aplicativo já que isso não afeta as conexões que já
estão abertas. O exemplo a seguir vem do método Application_Star t em uma função de trabalho.
var storageAccount = CloudStorageAccount.Parse(connStr);

ServicePoint tableServicePoint = ServicePointManager.FindServicePoint(storageAccount.TableEndpoint);
tableServicePoint.UseNagleAlgorithm = false;
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(storageAccount.QueueEndpoint);
queueServicePoint.UseNagleAlgorithm = false;
Verifique os logs do lado do cliente para ver quantas solicitações seu aplicativo do cliente está enviando e verifique se há gargalos gerais
de desempenho relacionados ao .NET no seu cliente, tais como CPU, coleta de lixo .NET, utilização da rede ou memória. Como ponto de
partida para solucionar problemas de aplicativos do cliente .NET, confira Depuração, rastreamento e criação de perfil.
Investigando os problemas de latência de rede
Normalmente a alta latência de ponta a ponta causada pela rede é devido a condições transitórias. Você pode investigar tantos os
problemas de rede persistentes ou transitórios, tais como pacotes ignorados ao usar ferramentas, tais como Wireshark ou Microsoft
Message Analyzer.
Para saber mais sobre o uso do Wireshark para a solução de problemas de rede, consulte o "[Anexo 2: Usando o Wireshark para capturar
o tráfego de rede]".
Para saber mais sobre o uso do Microsoft Message Analyzer para a solução de problemas de rede, consulte o "Anexo 3: Usando o
Nesse cenário, o caso mais provável é um atraso nas solicitações de armazenamento chegando no serviço de armazenamento. Investigue
porque as solicitações do cliente não estão passando pelo serviço de blob.
Uma das possíveis razões para o atraso do cliente em enviar solicitações é que há um número limitado de conexões ou threads
disponíveis.
Verifique também se o cliente está realizando várias novas tentativas e investigue a razão, se for o caso. Para determinar se o cliente está
realizando várias tentativas, é possível:
Examine os logs da Análise de Armazenamento. Se estiverem ocorrendo várias repetições, você verá várias operações com a mesma ID
de solicitação do cliente, mas com IDs de solicitação de servidor diferentes.
Examine os logs do cliente. O log detalhado indica que ocorreu uma repetição.
Depure seu código e verifique as propriedades do objeto OperationContext associado à solicitação. Se a operação foi repetida, a
propriedade RequestResults incluirá várias IDs de solicitação de servidor exclusivas. Você também pode verificar as horas de início e
término de cada solicitação. Para obter mais informações, veja o exemplo de código na seção ID de solicitação do servidor.
Se não houver problemas no cliente, investigue os possíveis problemas de rede, tais como perda de pacote. Você pode usar as
ferramentas, tais como Wireshark ou Microsoft Message Analyzer para investigar os problemas de rede.
Para saber mais sobre o uso do Wireshark para a solução de problemas de rede, consulte o "[Anexo 2: Usando o Wireshark para capturar
o tráfego de rede]".
Para saber mais sobre o uso do Microsoft Message Analyzer para a solução de problemas de rede, consulte o "Anexo 3: Usando o
No caso de alta AverageSer verLatency para as solicitações de download de blob, você deve usar os logs de log de armazenamento
para ver se há solicitações repetidas para o mesmo blob (ou para grupos de blobs). Para solicitações de carregamento de blob, você deve
investigar qual tamanho de bloco o cliente está usando (por exemplo, blocos inferiores a 64 mil em tamanho podem resultar em
sobrecargas ao menos que leituras também sejam inferiores a 64 mil partes) e se múltiplos clientes estiverem carregando blocos no
mesmo blob em paralelo. Você também deve verificar as métricas por minuto para ver se há picos no número de solicitações que
excedem as metas de escalabilidade por segundo: veja também “As métricas mostram um aumento em PercentTimeoutError”.
No caso de alta AverageSer verLatency para as solicitações de download de blob, você deve usar os registros de log de armazenamento
para ver se há solicitações repetidas para o mesmo blob (ou para grupos de blobs). Para solicitações de carregamento, você pode
aprimorar a produtividade usando um tamanho maior de bloco. Para consultas às tabelas, também é possível implementar o cache no
lado do cliente nos clientes que realizam as mesmas operações de consulta e nos casos em que os dados não mudam com frequência.
Valores altos de AverageSer verLatency podem também ser um sintoma de tabelas ou consultas mal desenhadas que resultam em
operações de digitalização ou que seguem a anti-sequência acrescentar/preceder. Para obter mais informações, consulte "As métricas
mostram um aumento em PercentThrottlingError".
NOTE
É possível encontrar uma lista de verificação de desempenho abrangente aqui: Lista de verificação de escalabilidade e desempenho do Armazenamento
do Microsoft Azure.

Se você estiver sofrendo um atraso entre o tempo um aplicativo adiciona uma mensagem à fila e o tempo que ela fica disponível para a
leitura da fila, então siga as seguintes etapas para diagnosticar o problemas:
Verifique se o aplicativo está efetivamente adicionando as mensagens à fila. Verifique se o aplicativo não está tentando o método
AddMessage várias vezes antes de conseguir. Os logs da biblioteca do cliente de armazenamento irá mostrar qualquer tentativa
repetida de operações de armazenamento.
Verifique se não há nenhum distorção no relógio entre a função de trabalho que adiciona a mensagem à fila e a função de trabalho que
lê a mensagem da fila que faz parecer como se houvesse um atraso em processamento.
A função de trabalho lê as mensagens da fila que tem falhas. Se um cliente de fila chama o método GetMessage , mas falha em
responder com uma confirmação, a mensagem permanecerá invisível na fila até que o período de invisibilityTimeout expire. Nesse
momento, a mensagem se torna disponibilidade para ser processada novamente.
Verifique se o tamanho da fila está aumentando com o tempo. Isso pode acontecer se você não tiver operadores disponíveis o
suficiente para processar todas as mensagens que os outros operadores estão colocando na fila. Verifique também as métricas para
ver se as solicitações excluídas estão falhando e a retirada da fila conta as mensagens as quais podem indicar falhas repetidas de
tentativas para excluir a mensagem.
Examine os logs de log de armazenamento para qualquer operação de fila que possa estar mais alta do que a E2ELatency esperada e
dos valor Ser verLatency durante um período mais longo de tempo do que de costume.
Erros de limitação acontecem quando você excede os alvos de escalabilidade de um serviço de armazenamento. O serviço de
armazenamento aplica limitações para garantir que nenhum cliente ou locatário possa usar o serviço à custa de outros. Para obter mais
informações, consulte escalabilidade e metas de desempenho para contas de armazenamento Standard para obter detalhes sobre metas
de escalabilidade para contas de armazenamento e metas de desempenho para partições nas contas de armazenamento.
Se a métrica de PercentThrottlingError mostra um aumento na porcentagem de solicitações que estão falhando com um erro de
limitação, você precisa investigar um dos dois cenários:
Aumento transitório em PercentThrottlingError
Aumento permanente no erro de PercentThrottlingError
Um aumento em PercentThrottlingError frequentemente acontece ao mesmo tempo que há um aumento no número de solicitações de
armazenamento ou quando você está fazendo um teste de carga inicial do seu aplicativo. Isso pode também manifestar no cliente como
mensagens de status HTTP "503 Server Busy" ou "500 Operation Timeout" a partir das operações de armazenamento.
Aumento transitório em PercentThrottlingError
Se estiver vendo picos no valor do PercentThrottlingError que coincidam com períodos de alta atividade para o aplicativo, você deverá
implementar uma estratégia de retirada exponencial (não linear) para novas tentativas em seu cliente. As novas tentativas de retirada
reduzem a carga imediata na partição e ajudam seu aplicativo a atenuar os picos no tráfego. Para obter mais informações sobre como
implementar políticas de repetição usando a biblioteca de cliente de armazenamento, consulte o namespace Microsoft. Azure. Storage.
RetryPolicies.
NOTE
Você também pode ver os picos no valor de PercentThrottlingError que não coincidem com períodos de alta atividade para o aplicativo: a causa
mais provável aqui é o serviço de armazenamento estar movendo partições para melhorar o balanceamento de carga.
Aumento permanente em erro de PercentThrottlingError

Se você está vendo constantemente um valor alto para PercentThrottlingError seguido de um aumento permanente nos seus volumes
de transações ou quando você está realizando os seus testes de carga iniciais no seu aplicativo, então você deve avaliar como o seu
aplicativo está usando as partições de armazenamento e se está atingindo os alvos de escalabilidade para a conta de armazenamento. Por
exemplo, se você está vendo erros de limitação na fila (o qual conta como uma partição única), então considere usar filas adicionais para
espalhar as transações entre diversas partições. Se você está vendo erros de limitação em uma tabela, você precisa considerar usar um
esquema de partições diferentes para espalhar suas transações entre as diversas partições usando uma gama maior de valores chave de
partição. Uma causa comum desse problema é a colocar/acrescentar antipadrão onde você seleciona a data como a chave de partição e,
em seguida, todos os dados em um determinado dia são gravados em uma partição: sob carga, isso pode resultar em um gargalo de
gravação. Considere um design de partição diferente ou avalie se usar um armazenamento de blob pode ser uma solução melhor.
Verifique também se a limitação está ocorrendo como resultado de picos no tráfego e investigue as formas de suavizar o padrão de
solicitações.
Se você distribuir suas transações entre diversas partições, você ainda deve levar em consideração os limites de escalabilidade definidos
para a conta de armazenamento. Por exemplo, se você usa dez filas cada processando no máximo 2.000 mensagens de 1KB por segundo,
você estará no limite total de 20.000 mensagens por segundo para cada conta de armazenamento. Se você precisa processar mais de
20.000 entidades por segundo, você deve considerar usar diversas contas de armazenamento. Você também deve ter em mente que o
tamanho de suas solicitações e entidades tem um impacto no quando o serviço de armazenamento limita seus clientes: se você tiver
maiores solicitações e entidades, você pode estar limitada mais cedo.
Designs de consultas ineficientes podem causar também que você atinja os limites de escalabilidade para as partições de tabela. Por
exemplo, uma consulta com um filtro que seleciona apenas um por cento das entidades em uma partição, mas que digitaliza todas as
entidades em uma partição precisará ter acesso a cada entidade. Toda entidade lida irá contar para um número total de transações
naquela partição, portanto, você pode facilmente atingir os alvos de escalabilidade.
NOTE
Seu teste de desempenho deve revelar qualquer design de consulta ineficiente em sua partição.

Suas métricas mostram um aumento em PercentTimeoutError para um dos seus serviços de armazenamento. Ao mesmo tempo, o
cliente recebe um volume alto de mensagens de status HTTP "500 Operation Timeout" a partir das operações de armazenamento.
NOTE
Você pode ver temporariamente erros de tempo limite enquanto o serviço de armazenamento balanceia a carga de solicitações movendo um partição
para um novo servidor.
A métrica PercentTimeoutError é uma agregação das seguintes métricas: ClientTimeoutError , AnonymousClientTimeoutError ,

SASClientTimeoutError , Ser verTimeoutError , AnonymousSer verTimeoutError e SASSer verTimeoutError .
Os tempos limites do servidor são causados por um erro no servidor. Os tempos limites do cliente acontecem porque uma operação no
servidor excedeu o tempo limite especificado pelo cliente; por exemplo, um cliente usando a biblioteca do cliente de armazenamento pode
definir um tempo limite para uma operação usando a propriedade Ser verTimeout da classe QueueRequestOptions .
Os tempos limites indicam um problema com o serviço de armazenamento que requer uma investigação detalhada. Você pode usar as
métricas para ver se você está atingindo os limites de escalabilidade do servidor e para identificar quaisquer picos de tráfego que pode
estar causando esse problema. Se o problema for intermitente, pode ser devido à atividade de balanceamento de carga no serviço. Se o
problema for persistente e não for causado por atingir os limites de escalabilidade do serviço, acione um problema de suporte. Para os
tempos limites do cliente, você deve decidir se os tempos limites estão definidos com um valor apropriado no cliente e alterar o valor
definido para o tempo limite no cliente ou investigar como você pode melhorar o desempenho das operações no serviço de
armazenamento, por exemplo, otimizando suas consultas de tabela ou reduzindo o tamanho de suas mensagens.
Suas métricas mostram um aumento em PercentNetworkError para um dos seus serviços de armazenamento. A métrica
PercentNetworkError é uma agregação das seguintes métricas: NetworkError , AnonymousNetworkError e SASNetworkError .
Eles ocorrem quando o serviço de armazenamento detecta um erro de rede quando o cliente faz uma solicitação de armazenamento.
A causa mais comum desse erro é um cliente desconectando antes do tempo limite expirar no serviço de armazenamento. Investigue o
código no cliente para entender porque e quando o cliente desconecta do serviço de armazenamento. Você também pode usar o
Wireshark, o Microsoft Mensagem Analyzer ou o Tcping para investigar os problemas de conectividade de rede do cliente. Essas
ferramentas estão descritas nos [Anexos].
O cliente está recebendo mensagens HTTP 403 (Proibido )
Se o seu aplicativo do cliente está emitindo erros HTTP 403 (Proibido), uma possível causa é que o cliente esteja usando uma assinatura
de acesso compartilhado (SAS) expirada quando envia uma solicitação de armazenamento (embora outras causas possíveis incluem
distorção de relógio, chaves inválidas e cabeçalhos vazios). Se uma chave SAS expirada for a causa, você não verá nenhuma entrada nos
dados de registro de log de armazenamento do lado do servidor. A tabela a seguir mostra um exemplo de log do lado do cliente gerado
pela biblioteca do cliente de armazenamento que ilustra esse problema acontecendo:
ID DE SO L IC ITA Ç Ã O DO
FONT E DETA L H A M EN TO DETA L H A M EN TO C L IEN T E T EXTO DE O P ERA Ç Ã O
Microsoft. Azure. Storage Informações do 3 85d077ab-… Inicialização da operação

com o local principal por
modo de local
PrimaryOnly.
Microsoft. Azure. Storage Informações do 3 85d077ab -… Iniciando solicitação

síncrona
parahttps://domemaildist.bl
ob.core.windows.netazurei
mblobcontainer/blobCreate
dViaSAS.txt?sv=2014-02-
14&sr=c&si=mypolicy&sig
=OFnd4Rd7z01fIvh%2Bmc
R6zbudIH2F5Ikm%2FyhNY
ZEmJNQ%3D&api-
version=2014-02-14
Microsoft. Azure. Storage Informações do 3 85d077ab -… Esperando uma resposta.
Microsoft. Azure. Storage Aviso 2 85d077ab -… Exceção acionada enquanto

aguarda a resposta: o
servidor remoto retornou
um erro: (403) Proibido.
FONT E DETA L H A M EN TO DETA L H A M EN TO C L IEN T E T EXTO DE O P ERA Ç Ã O
Microsoft. Azure. Storage Informações do 3 85d077ab -… Resposta recebida. Status

code = 403, Request ID =
9d67c64a-64ed-4b0d-
9515-3b14bbcdc63d,
Content-MD5 = , ETag = .
Microsoft. Azure. Storage Aviso 2 85d077ab -… Exceção emitida durante a

operação: O servidor
remoto retornou um erro:
(403) Proibido.
Microsoft. Azure. Storage Informações do 3 85d077ab -… Verificando se a operação

deve ser repetida.
Contagem de repetição =
0, Código de status HTTP
= 403, Exceção = O
Microsoft. Azure. Storage Informações do 3 85d077ab -… O próximo local deve ser

definido como principal,
com base no modo de
local.
Microsoft. Azure. Storage Erro do 1 85d077ab -… A política de repetição não

permitiu uma nova
tentativa. Falha com O
Nesse cenário, você deve investigar porque o token de SAS está expirando antes do cliente enviar o token para o servidor:
Normalmente, você não deveria definir um tempo de início quando você cria uma SAS para um cliente para usar imediatamente. Se
houver pequenas diferenças entre os relógios do hospedeiro que gera o SAS usando o horário atual e o serviço de armazenamento,
então é possível que o serviço de armazenamento receba uma SAS que não seja válida.
Não defina um tempo de expiração muito curto em uma SAS. Novamente, pequenas diferenças entre os relógios do hospedeiro
gerando a SAS e o serviço de armazenamento pode levar a uma SAS aparentemente expirando mais cedo do que esperado.
O parâmetro de versão na chave SAS (por exemplo, VA = 2015-04-05 ) corresponde à versão da biblioteca de cliente de
armazenamento que você está usando? Recomendamos que você sempre use a versão mais recente da biblioteca de cliente de
armazenamento.
Se você regenerar suas chaves de acesso de armazenamento, isso poderá invalidar quaisquer tokens de SAS existentes. Esse problema
poderá surgir se você gerar tokens de SAS com um tempo de expiração longo para aplicativos de cliente para o cache.
Se você estiver usando a biblioteca do cliente de armazenamento para gerar tokens de SAS, então será fácil compilar um token válido. No
entanto, se você estiver usando a API REST de armazenamento e construindo os tokens SAS manualmente, consulte delegando acesso
com uma assinatura de acesso compartilhado.
O cliente está recebendo mensagens HTTP 404 (Não encontrado )
Se o aplicativo do cliente recebe uma mensagem HTTP 404 (Não encontrado) do ser, isso implica que o objeto do cliente estava tentando
usar (tais como: uma entidade, tabela, blob, contêiner ou fila) não existe no serviço de armazenamento. Existem muitas razões para isso,
tais como:
O cliente ou outro processo excluiu anteriormente o objeto
Um problema de autorização de assinatura de acesso compartilhado (SAS)
O código JavaScript do lado do cliente não tem permissão para acessar o objeto
Falha de rede
O cliente ou outro processo excluiu anteriormente o objeto
Em cenários onde o cliente está tentando ler, atualizar ou excluir dados em um serviço de armazenamento é, normalmente, fácil de se
identificar nos logs do lado do servidor uma operação anterior que excluiu o objeto em questão de um serviço de armazenamento.
Frequentemente, os dados de log mostram que um outro usuário ou processo excluiu o objeto. No registro de log de armazenamento no
lado do servidor, as colunas do tipo de operação e de chave de objeto solicitado mostram quando um cliente excluiu um objeto.
No cenário onde um cliente está tentando inserir um objeto, pode não ser imediatamente óbvio porque isso resulta em uma resposta
HTTP 404 (Não encontrado) dado que o cliente está criando um novo objeto. Entretanto, se o cliente estiver criando um blob, é possível
achar o contêiner do blob, se o cliente estiver criando uma mensagem, é possível encontrar a fila e se o cliente estiver adicionando uma
coluna é possível encontrar uma tabela.
Você pode usar o log do lado do cliente a partir da biblioteca do cliente de armazenamento para obter uma compreensão mais detalhada
de quando o cliente envia solicitações específicas para o serviço de armazenamento.
O seguinte log do lado do cliente gerado pela biblioteca do cliente de armazenamento ilustra o problema quando o cliente não pode
encontrar o contêiner para o blob que está criando. Esse log inclui detalhes das seguintes operações de armazenamento:
ID DE SO L IC ITA Ç Ã O O P ERA Ç Ã O
07b26a5d-... DeleteIfExists para excluir o contêiner do blob. Observe que essa

operação inclui uma solicitação HEAD para verificar a existência do
contêiner.
e2d06d78… CreateIfNotExists para criar o contêiner do blob. Observe que essa

operação inclui uma solicitação HEAD que verifica a existência do contêiner.
HEAD retorna uma mensagem 404, porém continua.
de8b1c3c-... UploadFromStream para criar um blob. A solicitação PUT falha com uma
mensagem 404
Entradas de log:
ID DE SO L IC ITA Ç Ã O T EXTO DE O P ERA Ç Ã O
07b26a5d-... Iniciando solicitação síncrona para

https://domemaildist.blob.core.windows.net/azuremmblobcontainer .
07b26a5d-... StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-

date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-
14./domemaildist/azuremmblobcontainer.restype:container.
07b26a5d-... Esperando uma resposta.
07b26a5d-... Resposta recebida. Status code = 200, Request ID = eeead849-...Content-

MD5 = , ETag = "0x8D14D2DC63D059B".
07b26a5d-... Cabeçalhos da resposta foram processados com êxito, procedendo com o

resto da operação.
07b26a5d-... Baixar o corpo da resposta.
07b26a5d-... Operação concluída com sucesso.
07b26a5d-... Iniciando solicitação síncrona para

07b26a5d-... StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-

07b26a5d-... Esperando uma resposta.
07b26a5d-... Resposta recebida. Status code = 202, Request ID = 6ab2a4cf-..., Content-

MD5 = , ETag = .
07b26a5d-... Cabeçalhos da resposta foram processados com êxito, procedendo com o

07b26a5d-... Baixar o corpo da resposta.
07b26a5d-... Operação concluída com sucesso.
e2d06d78-... Iniciando solicitação assíncrona para

e2d06d78-... StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-

e2d06d78-... Esperando uma resposta.
de8b1c3c-... Iniciando solicitação síncrona para

https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt
.
de8b1c3c-... StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-

type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun
2014 10:33:12 GMT.x-ms-version:2014-02-
14./domemaildist/azuremmblobcontainer/blobCreated.txt.
de8b1c3c-... Preparação para gravar os dados solicitados.
e2d06d78-... Exceção acionada enquanto aguarda a resposta: O servidor remoto

retornou um erro: (404) Não encontrado.
e2d06d78-... Resposta recebida. Status code = 404, Request ID = 353ae3bc-..., Content-

MD5 = , ETag = .
e2d06d78-... Cabeçalhos da resposta foram processados com êxito, procedendo com o

e2d06d78-... Baixar o corpo da resposta.
e2d06d78-... Operação concluída com sucesso.
e2d06d78-... Iniciando solicitação assíncrona para

e2d06d78-... StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-

e2d06d78-... Esperando uma resposta.
de8b1c3c-... Gravação dos dados solicitados.
de8b1c3c-... Esperando uma resposta.
e2d06d78-... Exceção acionada enquanto aguarda a resposta: O servidor remoto

retornou um erro: (409) Conflito.
e2d06d78-... Resposta recebida. Status code = 409, Request ID = c27da20e-..., Content-

MD5 = , ETag = .
e2d06d78-... Erro ao baixar o corpo da resposta.
de8b1c3c-... Exceção acionada enquanto aguarda a resposta: O servidor remoto

retornou um erro: (404) Não encontrado.
de8b1c3c-... Resposta recebida. Status code = 404, Request ID = 0eaeab3e-..., Content-

MD5 = , ETag = .
de8b1c3c-... Exceção emitida durante a operação: O servidor remoto retornou um erro:

(404) Não encontrado.
de8b1c3c-... A política de repetição não permitiu uma nova tentativa. Falha com o
servidor remoto retornou um erro: (404) Não encontrado.
e2d06d78-... A política de repetição não permitiu uma nova tentativa. Falha com o
servidor remoto retornou um erro: (409) Conflito.
Neste exemplo, o log mostra que o cliente está intercalando solicitações do método CreateIfNotExists (ID da solicitação e2d06d78...)
com as solicitações do método UploadFromStream (de8b1c3c-...). Essa intercalação acontece porque o aplicativo cliente está invocando
esses métodos de forma assíncrona. Modifique o código assíncrono no cliente para garantir que ele crie o contêiner antes de tentar
carregar qualquer dado para o blob nesse contêiner. Idealmente, crie todos os contêineres antes.
Um problema de autorização de assinatura de acesso compartilhado (SAS)
Se o aplicativo do cliente tentar usar uma chave de SAS que não inclui as permissões necessárias para a operação, o serviço de
armazenamento retorna uma mensagem HTTP 404 (Não encontrado) para o cliente. Ao mesmo tempo, você também verá um valor
diferente de zero para SASAuthorizationError nas métricas.
A tabela a seguir mostra um exemplo de mensagem d log do lado do servidor a partir do arquivo de registro de log de armazenamento:
NOME VA LO R
Hora de início da solicitação 2014-05-30T06:17:48.4473697Z
Tipo de operação GetBlobProperties
Status da solicitação SASAuthorizationError
Código de status HTTP 404
Tipo de autenticação Sas
Tipo de serviço Blob
URL de Solicitação https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.
?sv=2014-02-14&sr=c&si=mypolicy&sig=XXXXX&;api-version=2014-02-
14
Cabeçalho da ID de solicitação a1f348d5-8032-4912-93ef-b393e5252a3b
ID de solicitação do cliente 2d064953-8436-4ee0-aa0c-65cb874f7929
Investigue por que o aplicativo de cliente está tentando realizar uma operação para a qual ele não tem permissão.
O código JavaScript do lado do cliente não tem permissão para acessar o objeto
Se você estiver usando um cliente JavaScript e um serviço de armazenamento está retornando mensagens HTTP 404 (Não encontrado),
verifique os seguintes erros JavaScript no navegador:
SEC7120: Origin http://localhost:56309 not found in Access-Control-Allow-Origin header.

SCRIPT7002: XMLHttpRequest: Network Error 0x80070005, Access is denied.
NOTE
Você pode usar a ferramenta de desenvolvedor F12 no Internet Explorer para rastrear as mensagens trocadas entre o navegador e o serviço de
armazenamento quando você estiver solucionando os problemas JavaScript do lado do cliente.
Esses erros acontecem porque o navegador da Web implementa a restrição de segurança de política de mesma origem , que impede uma
página da Web de chamar uma API em um domínio diferente do domínio de onde a página vem.
Para resolver o problema JavaScript, configure o compartilhamento de recursos entre origens (CORS) para o serviço de armazenamento
que o cliente está acessando. Para saber mais, veja Suporte de CORS (Compartilhamento de Recursos entre Origens) para os Serviços de
Armazenamento do Azure.
O código a seguir mostra como configurar seu serviço blob para permitir que o JavaScript execute o domínio Contoso para acessar um
blob no seu serviço de armazenamento de blob:
CloudBlobClient client = new CloudBlobClient(blobEndpoint, new StorageCredentials(accountName, accountKey));
// Set the service properties.
ServiceProperties sp = client.GetServiceProperties();
sp.DefaultServiceVersion = "2013-08-15";
CorsRule cr = new CorsRule();
cr.AllowedHeaders.Add("*");
cr.AllowedMethods = CorsHttpMethods.Get | CorsHttpMethods.Put;
cr.AllowedOrigins.Add("http://www.contoso.com");
cr.ExposedHeaders.Add("x-ms-*");
cr.MaxAgeInSeconds = 5;
sp.Cors.CorsRules.Clear();
sp.Cors.CorsRules.Add(cr);
client.SetServiceProperties(sp);
Falha de rede
Em algumas circunstâncias, os pacotes de rede perdidos podem levar o serviço de armazenamento a retornar mensagens HTTP 404 para
o cliente. Por exemplo, quando o seu aplicativo do cliente está excluindo uma entidade do serviço de tabela, você pode ver o cliente emitir
uma exceção de armazenamento relatando uma mensagem de status "HTTP 404 (Não encontrado)" do serviço de tabela. Quando você
investiga a tabela no serviço de armazenamento da tabela, é possível ver que o serviço excluiu a entidade como solicitado.
Os detalhes da exceção no cliente incluem a ID da solicitação (7e84f12d...) atribuída pelo serviço Tabela para a solicitação: você pode usar
essas informações para localizar os detalhes da solicitação nos logs de armazenamento no lado do servidor pesquisando na coluna
request-id-header no arquivo de log. Você pode também usar as métricas para identificar quando falhas como essa ocorrem e
pesquisar os arquivos de log com base no horário que as métricas registraram esse erro. Essa entrada de log mostram a falha excluída
com uma mensagem de status "HTTP (404) Outro Erro do Cliente". A mesma entrada de log também inclui a ID da solicitação gerada pelo
cliente na coluna cliente-solicitação-ID (813ea74f...).
O log do lado do servidor inclui também uma outra entrada com o mesmo valor client-request-id (813ea74f…) para uma operação de
exclusão com sucesso para a mesma entidade e do mesmo cliente. A operação de exclusão com êxito aconteceu um pouco antes da
solicitação de exclusão falhar.
O caso mais provável nesse cenário é que o cliente enviou uma solicitação excluída da entidade para o serviço de tabela, a qual teve êxito,
mas não recebeu uma confirmação do servidor (talvez devido a problemas temporários de rede). O cliente repetiu a operação
automaticamente (usando o mesmo client-request-id ) e essa tentativa falhou porque a entidade já tinha sido excluída.
Se esse problema ocorre com frequência, investigue porque o cliente não está recebendo as confirmações do serviço de tabela. Se o
problema for intermitente, intercepte o erro "HTTP (404) Não encontrado" e log no cliente, mas permita que o cliente continue.
O cliente está recebendo mensagens HTTP 409 (Conflito )
A tabela a seguir mostra um trecho do log do lado do servidor para duas operações de cliente: DeleteIfExists seguida imediatamente de
CreateIfNotExists , ambas usando o mesmo nome de contêiner de blob. Cada operação do cliente resulta em duas solicitações enviadas
para o servidor, primeiro uma solicitação GetContainerProper ties para verificar se o contêiner existe, seguida por uma solicitação de
DeleteContainer ou CreateContainer .
T IM ESTA M P O P ERA Ç Ã O RESULT N O M E DO C O N T ÊIN ER C L IEN T E
05:10:13.7167225 GetContainerProperties 200 mmcont c9f52c89-…
05:10:13.8167325 DeleteContainer 202 mmcont c9f52c89-…
05:10:13.8987407 GetContainerProperties 404 mmcont bc881924-…
05:10:14.2147723 CreateContainer 409 mmcont bc881924-…
O código no aplicativo cliente exclui e, em seguida, recria imediatamente um contêiner de blob usando o mesmo nome: o método
CreateIfNotExists (ID de solicitação de cliente bc881924-...), eventualmente, falha com o erro de HTTP 409 (Conflito). Quando um cliente
exclui contêineres de blob, tabelas ou filas há um breve período antes do nome ficar disponível novamente.
O aplicativo do cliente deve usar nomes de contêiner exclusivos sempre que criar novos contêineres caso o padrão excluir/recriar for
comum.
ClientOtherErrors
As métricas de PercentSuccess capturam a porcentagem das operações que tiveram êxito com base nos códigos de status HTTP. As
operações com códigos de status 2XX contam como bem-sucedidas, enquanto as operações com código de status de intervalos 3XX, 4XX
e 5XX são contadas como sem sucesso e inferiores aos valores de métricas PercentSuccess . Nos arquivos de log do lado do servidor,
essas operações são registradas com um status de transação de ClientOtherErrors .
É importante observar que essas operações foram concluídas com sucesso e por isso não afetam as outras métricas como a de
disponibilidade. Alguns exemplos de operações que executam com sucesso, mas que podem resultar em códigos de status HTTP sem
sucesso incluem:
ResourceNotFound (Não encontrado 404), por exemplo, de uma solicitação GET para o blob que não existe.
ResourceAlreadyExists (Conflito 409), por exemplo, de uma operação CreateIfNotExist em que o recurso já existe.
ConditionNotMet (Não Modificado 304), por exemplo, de uma operação condicional tal como quando o cliente envia um valor ETag
e um cabeçalho HTTP If-None-Match para solicitar uma imagem apenas se ela tiver sido carregada desde a última operação.
Você pode encontrar uma lista de códigos de erro comuns da API REST que os serviços de armazenamento retornam na página Códigos
de erro comuns da API REST.
As métricas de capacidade mostram um aumento inesperado em uso de capacidade de armazenamento
Se você vê mudanças repentinas, inesperadas na capacidade de uso na sua conta de armazenamento, você pode investigar as razões,
primeiramente olhando as métricas de disponibilidade; por exemplo, um aumento no número de falhas de solicitações de exclusão pode
levar a um aumento na quantidade de armazenamento de blobs que você está usando, já que operações de limpeza específicas de
aplicativo que você esperava que estivessem liberando espaço podem não estar funcionando como esperado (por exemplo, porque os
tokens SAS usados para liberação de espaço expiraram).
Você normalmente usa o emulador de armazenamento durante o desenvolvimento e teste para evitar o requisito de uma conta de
armazenamento do Azure. Os problemas comuns que podem ocorrer quando você estiver usando o emulador de armazenamento são:
O recurso "X" não está funcionando no emulador de armazenamento
Erro "o valor de um dos cabeçalhos HTTP não está no formato correto" ao usar o emulador de armazenamento
A execução do emulador de armazenamento requer privilégios administrativos
O recurso "X” não está funcionando no emulador de armazenamento
O emulador de armazenamento não é compatível com todos os recursos dos serviços de armazenamento do Azure, como o serviço de
arquivo. Para saber mais, confira Usar o Emulador de Armazenamento do Azure para desenvolvimento e teste.
Para os recursos que não são compatíveis com o emulador de armazenamento, use o serviço de armazenamento do Azure em nuvem.
Erro "O valor de um dos cabeçalhos HTTP não está no formato correto" ao usar o emulador de armazenamento
Você está testando o seu aplicativo (que usa a Biblioteca de Clientes de Armazenamento) no emulador de armazenamento local e
chamadas de método como CreateIfNotExists falham com uma mensagem de erro "O valor para um dos cabeçalhos HTTP não está no
formato correto". Isso indica que a versão do emulador de armazenamento que você está usando não é compatível com a versão da
biblioteca do cliente de armazenamento que você está usando. A biblioteca do cliente de armazenamento adiciona um cabeçalho x-ms-
version em todas as solicitações que ela faz. Se o emulador de armazenamento não reconhecer o valor no cabeçalho x-ms-version , ele
rejeita a solicitação.
Você pode usar os logs de clientes de biblioteca de armazenamento para ver o valor do cabeçalho x-ms-version que está enviando.
Você também pode ver o valor do cabeçalho x-ms-version se você usar o Fiddler para rastrear as solicitações do aplicativo do cliente.
Esse cenário normalmente acontece se você instalar e usar a versão mais recente da biblioteca do cliente de armazenamento sem atualizar
o emulador de armazenamento. Instale a versão mais recente do emulador de armazenamento ou use o armazenamento em nuvem em
vez do emulador para desenvolvimento ou teste.
A execução do emulador de armazenamento requer privilégios administrativos
Você pode solicitar credenciais para o administrador quando você executar o emulador de armazenamento. Isso acontece apenas quando
você inicializar o emulador de armazenamento pela primeira vez. Após você ter inicializado o emulador de armazenamento, você não
precisa de privilégios de administrador para executá-lo novamente.
Para saber mais, confira Usar o Emulador de Armazenamento do Azure para desenvolvimento e teste. Você também pode inicializar o
emulador de armazenamento no Visual Studio, o que também exige privilégios administrativos.
Quando você tenta instalar o SDK, ele falhar ao tentar instalar o emulador de armazenamento no seu computador local. O log de
instalação contém uma das seguintes mensagens:
CAQuietExec: Erro: Não é possível acessar a instância do SQL
CAQuietExec: Erro: Não é possível criar o banco de dados
A causa é um problema com a instalação LocalDB existente. Por padrão, o emulador de armazenamento usa o LocalDB para persistir os
dados quando simula os serviços de armazenamento do Azure. Você pode reiniciar a sua instância LocalDB ao executar os seguintes
comando na janela de prompt de comando antes de tentar instalar o SDK.
sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0
O comando delete remove qualquer arquivo de bancos de dado antigo das instalações anteriores do emulador de armazenamento.
Se as seções anteriores de solução de problemas não incluem os problemas que você está tendo com o serviço de armazenamento, adote
a seguinte abordagem para diagnosticar a solução de seu problema.
Verifique as métricas para ver se há qualquer mudança de comportamento da linha de base esperada. A partir das métricas, você pode
determinar se o problema é transitório ou permanente, e quais as operações de armazenamento que o problema está afetando.
Você pode usar as informações de métricas para ajudá-lo a procurar os dados de log do lado do servidor para obter informações mais
detalhadas sobre qualquer erro que esteja ocorrendo. Essa informação pode ajudá-lo a encontrar e a solucionar o problema.
Se a informação nos logs do lado do servidor não forem suficientes para resolver o problema com êxito, você pode usar os logs do
lado do cliente da biblioteca do cliente de armazenamento para investigar o comportamento do seu aplicativo do cliente e ferramentas,
tais como Fiddler, Wireshark e Microsoft Message Analyzer para investigar a sua rede.
Para saber mais sobre como usar o Fiddler, consulte "[Anexo 1: Usando o Fiddler para capturar o tráfego HTTP e HTTPS]".
Para saber mais sobre usar o Wireshark, veja “[Anexo 2: Usando o Wireshark para capturar o tráfego de rede]”.
Para saber mais sobre como usar o Microsoft Message Analyzer, consulte o "Anexo 3: Usando o Microsoft Message Analyzer para capturar
o tráfego de rede".
Apêndices
Os anexos descrevem várias ferramentas que você pode achar úteis ao diagnosticar ou solucionar os problemas com o armazenamento
do Azure (e outros serviços). Essas ferramentas não são parte do armazenamento do Azure e alguns são produtos de terceiros. Como tal,
as ferramentas discutidas nesses anexos não são cobertas por nenhum contrato de suporte que você possa ter com o Microsoft Azure ou
Armazenamento do Azure e, portanto, como parte de seu processo de avaliação examine as opções de licença e de suporte disponíveis
pelos fornecedores dessas ferramentas.
Anexo 1: Usando o Fiddler para capturar o tráfego HTTP e HTTPS
O Fiddler é uma ferramenta útil para analisar o tráfego HTTP e HTTPS entre o aplicativo cliente e o serviço de armazenamento do Azure
que você está usando.
NOTE
O Fiddler pode decodificar o tráfego HTTPS; leia a documentação do Fiddler cuidadosamente para entender como ele faz isso e para entender as
implicações de segurança.
Esse anexo dá um breve passo a passo de como configurar o Fiddler para capturar o tráfego entre o computador local onde você instalou
o Fiddler e os serviços de armazenamento do Azure.
Após você ter iniciado o Fiddler, ele começará capturar o tráfego HTTP e HTTPS da sua máquina local. A seguir há alguns comandos úteis
para controlar o Fiddler:
Parar e iniciar a captura de tráfego. No menu principal, vá para Arquivo e clique em Capturar Tráfego para alternar entre captura
ativada e desativada.
Salve os dados de tráfego capturados. No menu principal, vá até Arquivo , clique em Salvar e, em seguida, clique em Todas as
Sessões : isso permite que você salve o tráfego em um arquivo de sessão. Você pode recarregar um Session Archive mais tarde para
análise ou enviá-lo se solicitado pelo suporte Microsoft.
Para limitar a quantidade de tráfego capturada pelo Fiddler, você pode usar filtros que você configura na guia filtros . A captura de tela a
seguir mostra um filtro que captura somente o tráfego enviado para o ponto de extremidade de armazenamento
contosoemaildist.Table.Core.Windows.net :
Anexo 2: Usando o Wireshark para capturar o tráfego de rede
Wireshark é um analisar de protocolo de rede que permite que você exiba informações detalhadas de pacote de uma vasta gama de
protocolos de rede.
O procedimento a seguir mostra como capturar informações detalhadas de pacote para tráfego a partir do computador local onde você
instalou o Wireshark para o serviço de tabela na sua conta de armazenamento do Azure.
1. Habilite o Wireshark no seu computador local.
2. Na seção Iniciar , selecione a interface de rede local ou as interfaces que estão conectadas à Internet.
3. Clique em Opções de Captura .
4. Adicione um filtro à caixa de texto Filtro de Captura . Por exemplo, o host contosoemaildist.table.core.windows.net
configurará o Wireshark para capturar apenas os pacotes enviados para ou a partir do ponto de extremidade de serviço tabela na
conta de armazenamento contosoemaildist . Confira a Lista completa de filtros de captura.
5. Clique em Iniciar . O Wireshark capturará agora todos pacotes enviados para ou a partir do ponto de extremidade do serviço de
tabela enquanto você usa o aplicativo do cliente no seu computador local.
6. Quando você tiver terminado, no menu principal clique em Capturar e em Parar .
7. Para salvar os dados capturados no arquivo de captura do Wireshark, no menu principal clique em Arquivo e em Salvar .
O Wireshark irá realçar qualquer erro que existir na janela packetlist . Você também pode usar a janela Informações do Especialista
(clique em Analisar e em Informações do Especialista ) para exibir um resumo dos erros e avisos.
Você também pode escolher exibir os dados de TCP conforme vistos pela camada de aplicativo, clicando com o botão direito do mouse
nos dados de TCP e selecionando Seguir o Fluxo TCP . Isso será útil se você tiver capturado o despejo sem o filtro de captura. Para saber
mais, confira Como seguir fluxos TCP.
NOTE
Para saber mais sobre como usar o Wireshark, veja o Guia de Usuários do Wireshark.
Anexo 3: Usando o Microsoft Message Analyzer para capturar o tráfego de rede

Você pode usar o Microsoft Message Analyzer para capturar o tráfego HTTP e HTTPS de uma forma similar ao Fiddler e capturar o tráfego
de rede de uma forma similar ao Wireshark.
Configure a sessão de rastreamento Web usando o Microsoft Message Analyzer
Para configurar a sessão de rastreamento Web para tráfego HTTP e HTTPS usando o Microsoft Message Analyzer, execute o aplicativo
Microsoft Message Analyzer e, no menu Arquivo , clique em Capturar/Rastrear . Na lista de cenários de rastreamento disponíveis,
selecione Proxy da Web . Em seguida, no painel Rastrear Configuração de Cenário , na caixa de texto HostnameFilter , adicione os
nomes dos pontos de extremidade de armazenamento (você pode procurar esses nomes no Portal do Azure). Por exemplo, se o nome da
sua conta de armazenamento do Azure é contosodata , adicione a seguinte caixa de diálogo HostnameFilter :
contosodata.blob.core.windows.net contosodata.table.core.windows.net contosodata.queue.core.windows.net
NOTE
Um caractere de espaço separa o nome de host.
Quando você estiver pronto para coletar os dados de rastreamento, clique no botão Iniciar Com .
Para saber mais sobre o rastreamento de Proxy da Web do Microsoft Message Analyzer, consulte Provedor Microsoft-PEF-WebProxy.
O rastreamento interno de Proxy da Web no Microsoft Message Analyzer é com base no Fiddler; ele pode capturar o tráfego do lado do
cliente e exibir as mensagens HTTPS não criptografadas. O rastreamento Proxy da Web funciona ao configurar um proxy local para todo
o tráfego HTTP e HTTPS que dá acesso às mensagens não criptografadas.
Diagnóstico dos problemas de rede usando o Microsoft Message Analyzer
Além de usar o rastreamento de Proxy da Web do Microsoft Message Analyzer para capturar detalhes do tráfego HTTP/HTTPS entre o
aplicativo do cliente e o serviço de armazenamento, você pode usar também o rastreamento interno Camada de Link Local para
capturar as informações do pacote de rede. Isso permite que você capture os dados similares aos que você pode capturar com o
Wireshark e que diagnostique os problemas de rede tal como os pacotes ignorados.
A seguinte captura de tela mostra um exemplo de rastreamento de Camada de Link Local com algumas mensagens informativas na
coluna DiagnosisTypes . Clicar no ícone na coluna DiagnosisTypes mostra detalhes da mensagem. Neste exemplo, o servidor
retransmitiu a mensagem nº 305 porque ele não recebeu uma confirmação do cliente:
Quando você cria uma sessão de rastreamento no Microsoft Message Analyzer, é possível especificar filtros para reduzir a quantidade de
ruídos no rastreamento. Na página Capturar/Rastrear na qual você define o rastreamento, clique no link Configurar próximo a
Microsoft-Windows-NDIS-PacketCapture . A seguinte captura de tela mostra a configuração que filtra o tráfego TCP para os
endereços de IP de três serviços de armazenamento:
Para obter mais informações sobre o rastreamento de Camada de Link Local do Microsoft Message Analyzer, consulte Provedor do
Microsoft-PEF-NDIS-PacketCapture.
Anexo 4: Usando o Excel para exibir as métricas e os dados de log
Muitas ferramentas permitem que você baixe os dados de métricas de armazenamento a partir do armazenamento de tabela do Azure em
um formato delimitado que o torna fácil para se carregado no Excel para exibição e análise. Os dados de log de armazenamento do
armazenamento de blob do Azure já estão em um formato delimitado que pode ser carregado no Excel. Entretanto, você precisará
adicionar cabeçalhos apropriados às colunas com base na informação no Formato de Log Analítico de Armazenamento e no Esquema de
Tabela de Métricas Analíticas de Armazenamento.
Para importar os dados de log de armazenamento para o Excel após ter baixado do armazenamento de blob:
No menu Dados , clique em Do Texto .
Procure o arquivo de log que deseja exibir e clique em Impor tar .
Na etapa 1 do Assistente de Impor tação de Texto , selecione Delimitado .
Na etapa 1 do Assistente de Impor tação de Texto , selecione Ponto e vírgula como o único delimitador e escolha aspas duplas como
Qualificador de texto . Clique em Concluir e escolha onde colocar os dados na sua pasta de trabalho.
Anexo 5: Monitoramento com o Application Insights no Azure DevOps
Você pode também usar o recurso Application Insights no Azure DevOps como parte do seu monitoramento de desempenho e
disponibilidade. Essa ferramenta pode:
Garantir que seu aplicativo da Web esteja disponível e respondendo. Se o seu aplicativo é um site ou um aplicativo de dispositivo que
usa um serviço Web, você pode testar a sua URL a cada minuto de locais ao redor do mundo e ser avisado se houver um problema.
Diagnostique rapidamente qualquer problema de desempenho ou exceções no seu serviço da Web. Descubra se a CPU ou outros
recursos estão sendo alongados, receba rastreamento de linhas de exceções e pesquise facilmente pelos rastreamentos de log. Se o
desempenho do aplicativo cair abaixo dos limites aceitáveis, a Microsoft poderá lhe enviar um email. Você pode monitorar os serviços
Web .NET e Java.
Você pode encontrar mais informações em O que é o Application Insights.
Próximas etapas
Para obter mais informações sobre análise no armazenamento do Azure, consulte estes recursos:
Monitorar uma conta de armazenamento no portal do Azure
Análise de armazenamento
Métricas de análise de armazenamento
Esquema de tabela de métricas da análise de armazenamento
Logs da análise de armazenamento
Formato de log da análise de armazenamento
Migração de métricas de Armazenamento do Azure
Alinhado com a estratégia de unificar a experiência do Azure Monitor, o Armazenamento do Microsoft Azure
integra métricas à plataforma do Azure Monitor. No futuro, o serviço das métricas antigas terminará com uma
notificação antecipada com base em Azure Policy. Se você depender de métricas de armazenamento antigas,
precisará migrar antes da data de término do serviço para manter as informações da métrica.
Este artigo mostra como migrar das métricas antigas para as novas métricas.
Reconhecer as métricas antigas gerenciadas pelo Armazenamento do

Microsoft Azure
O Armazenamento do Microsoft Azure coleta valores de métrica antigas, agrega e armazena-os nas tabelas $Metric
dentro da mesma conta de armazenamento. Você pode usar o portal do Azure para configurar um gráfico de
monitoramento. Também é possível usar os SDKs de Armazenamento do Microsoft Azure para ler os dados das
tabelas $Metric com base no esquema. Para obter mais informações, consulte Análise de Armazenamento.
As métricas antigas fornecem métricas de capacidade apenas no Azure Storage Blob. Métricas antigas fornecem
métricas de transação em armazenamento de Blobs, armazenamento de Tabelas, Arquivos do Azure e
armazenamento de Filas.
Métricas antigas são projetadas em um esquema simples. O design resulta em valor de métrica zero quando você
não tem os padrões de tráfego que ativam a métrica. Por exemplo, o valor Ser verTimeoutError é definido como
0 em tabelas $Metric, mesmo quando você não recebe nenhum erro de tempo limite do servidor do tráfego
dinâmico para uma conta de armazenamento.
Entender as nova métricas gerenciadas pelo Azure Monitor

Para novas métricas de armazenamento, o Armazenamento do Microsoft Azure emite os dados de métrica para o
back-end do Azure Monitor. O Azure Monitor fornece uma experiência de monitoramento unificada, incluindo
dados do portal, bem como ingestão de dados. Para obter mais detalhes, você pode consultar este artigo.
As novas métricas fornecem as métricas de capacidade e métricas de transação no Blob, Tabela, Arquivo e Fila.
Multidimensão é um dos recursos que o Azure Monitor fornece. O Armazenamento do Azure adota o design ao
definir o novo esquema de métrica. Para dimensões com suporte em métricas, você pode localizar os detalhes em
Métricas de Armazenamento do Microsoft Azure no Azure Monitor. O design multidimensional fornece economia
em largura de banda de ingestão e a capacidade de armazenar métricas. Consequentemente, se o tráfego não
ativou métricas relacionadas, os dados relacionados de métrica não serão gerados. Por exemplo, se o tráfego não
disparou nenhum erro de tempo limite do servidor, o Azure Monitor não retornará nenhum dado quando você
consultar o valor da métrica Transações com dimensão ResponseType igual a Ser verTimeoutError .
Mapeamento de métricas entre métricas antigas e novas métricas

Se você lê dados da métrica programaticamente, você precisa adotar o novo esquema de métricas em seus
programas. Para reconhecer melhor as alterações, você pode consultar o mapeamento listado na tabela a seguir:
Métricas de capacidade
M ÉT RIC A A N T IGA N O VA M ÉT RIC A
Capacity BlobCapacity com a dimensão BlobType igual a BlockBlob

ou PageBlob
ObjectCount BlobCount com a dimensão BlobType igual a BlockBlob ou

PageBlob
ContainerCount ContainerCount
As métricas a seguir são novas ofertas que as métricas antigas não dão suporte:
TableCapacity
TableCount
TableEntityCount
QueueCapacity
QueueCount
QueueMessageCount
FileCapacity
FileCount
FileShareCount
UsedCapacity
Métricas de transação
AnonymousAuthorizationError Transações com dimensão ResponseType igual a

AuthorizationError e dimensão de Autenticação igual a
Anônimo
AnonymousClientOtherError Transações com dimensão ResponseType igual a

ClientOtherError e dimensões de Autenticação igual a
Anônimo
AnonymousClientTimeoutError Transações com dimensão ResponseType igual a

ClientTimeoutError e dimensões de Autenticação igual a
Anônimo
AnonymousNetworkError Transações com dimensão ResponseType igual a

NetworkError e dimensões de Autenticação igual a
Anônimo
AnonymousSer verOtherError Transações com dimensão ResponseType igual a

Ser verOtherError e dimensões de Autenticação igual a
Anônimo
AnonymousSer verTimeoutError Transações com dimensão ResponseType igual a

Ser verTimeoutError e dimensões de Autenticação igual a
Anônimo
AnonymousSuccess Transações com dimensão ResponseType igual a Sucesso e

dimensões de Autenticação igual a Anônimo
AnonymousThrottlingError Transações com dimensão ResponseType igual a

ClientThrottlingError ou Ser verBusyError e dimensão
deAutenticação igual a Anônimo
AuthorizationError Transações com a dimensão ResponseType igual a

AuthorizationError
Disponibilidade Disponibilidade
AverageE2ELatency SuccessE2ELatency
AverageSer verLatency SuccessSer verLatency
ClientOtherError Transações com a dimensão ResponseType igual a

ClientOtherError
ClientTimeoutError Transações com a dimensão ResponseType igual a

ClientTimeoutError
NetworkError Transações com a dimensão ResponseType igual a

NetworkError
PercentAuthorizationError Transações com a dimensão ResponseType igual a

AuthorizationError
PercentClientOtherError Transações com a dimensão ResponseType igual a

ClientOtherError
PercentNetworkError Transações com a dimensão ResponseType igual a

NetworkError
PercentClientOtherError Transações com a dimensão ResponseType igual a

Ser verOtherError
PercentSuccess Transações com a dimensão ResponseType igual a Success
PercentThrottlingError Transações com a dimensão ResponseType igual a

ClientThrottlingError ou Ser verBusyError
PercentTimeoutError Transações com a dimensão ResponseType igual a

Ser verTimeoutError ou ResponseType igual a
ClientTimeoutError
SASAuthorizationError Transações com dimensão ResponseType igual a

AuthorizationError e dimensão de Autenticação igual a
SAS
SASClientOtherError Transações com dimensão ResponseType igual a

ClientOtherError e dimensões de Autenticação igual a
SAS
SASClientTimeoutError Transações com dimensão ResponseType igual a

ClientTimeoutError e dimensões de Autenticação igual a
SAS
SASNetworkError Transações com dimensão ResponseType igual a

NetworkError e dimensões de Autenticação igual a SAS
SASSer verOtherError Transações com dimensão ResponseType igual a

Ser verOtherError e dimensões de Autenticação igual a
SAS
SASSer verTimeoutError Transações com dimensão ResponseType igual a

Ser verTimeoutError e dimensões de Autenticação igual a
SAS
SASSuccess Transações com dimensão ResponseType igual a Sucesso e

dimensões de Autenticação igual a SAS
SASThrottlingError Transações com dimensão ResponseType igual a

ClientThrottlingError ou Ser verBusyError e dimensão
deAutenticação igual a SAS
Ser verOtherError Transações com a dimensão ResponseType igual a

Ser verOtherError
Ser verTimeoutError Transações com a dimensão ResponseType igual a

Ser verTimeoutError
Êxito Transações com a dimensão ResponseType igual a Success
ThrottlingError Transações com a dimensão ResponseType igual a

ClientThrottlingError ou Ser verBusyError
TotalBillableRequests Transactions
TotalEgress Saída
TotalIngress Entrada
TotalRequests Transactions
Como posso migrar o regras de alerta existentes?
Se você criou regras de alerta clássicas com base em métricas de armazenamento antigas, será necessário criar
novas regras de alerta com base no novo esquema de métrica.
Os novos dados de métrica são armazenados na mesma conta de armazenamento por padrão?
Não. Para arquivar os dados de métrica em uma conta de armazenamento, use a API de configuração de
diagnóstico do Azure Monitor.
Próximas etapas
Azure Monitor
Métricas de armazenamento no Azure Monitor
Métricas da análise de armazenamento do Azure
(clássico)
A análise de armazenamento pode armazenar métricas que incluem estatísticas de transação agregadas e os dados
de capacidade sobre solicitações para um serviço de armazenamento. As transações são relatadas no nível de
operação da API, bem como no nível de serviço de armazenamento, e a capacidade é relatada no nível de serviço
de armazenamento. Os dados de métricas podem ser usados para analisar o uso do serviço de armazenamento,
diagnosticar problemas com solicitações feitas no serviço de armazenamento e melhorar o desempenho de
aplicativos que usam um serviço.
A métrica da Análise de Armazenamento vem habilitada por padrão nas novas contas de armazenamento. Você
pode configurar as métricas no portal do Azure; para obter detalhes, consulte monitorar uma conta de
armazenamento no portal do Azure. Você também pode habilitar a análise de armazenamento programaticamente
por meio da API REST ou da biblioteca de cliente. Use as operações definir propriedades de serviço para habilitar o
Análise de Armazenamento para cada serviço.
NOTE
Análise de Armazenamento métricas estão disponíveis para os serviços BLOB, fila, tabela e arquivo. As métricas de Análise de
Armazenamento agora são métricas clássicas. A Microsoft recomenda o uso de métricas de armazenamento em Azure
monitor em vez de análise de armazenamento métricas.
Métricas de transação
Um conjunto robusto de dados é registrado em intervalos de horas ou minutos para cada serviço de
armazenamento e operações de API solicitadas, incluindo ingresso/egresso, disponibilidade, erros e percentuais da
solicitação categorizados. Você pode ver uma lista completa dos detalhes da transação no tópico Esquema da
tabela de métricas da análise de armazenamento .
Os dados de transação são registrados em dois níveis: nível de serviço e nível de operação da API. No nível de
serviço, as estatísticas que resumem todas as operações de API solicitadas são gravadas em uma entidade de
tabela a cada hora, mesmo que nenhuma solicitação seja feita ao serviço. No nível de operação da API, as
estatísticas serão gravadas somente em uma entidade se a operação foi solicitada nessa hora.
Por exemplo, se você executar uma operação GetBlob no serviço Blob, as métricas do Storage Analytics vão
registrar a solicitação e as incluirá nos dados agregados para o serviço Blob, bem como a operação GetBlob . No
entanto, se nenhuma operação getBlob for solicitada durante a hora, uma entidade não será gravada no
$MetricsTransactionsBlob para essa operação.
As métricas de transações são registradas para solicitações de usuários e solicitações feitas pela própria análise de
armazenamento. Por exemplo, solicitações pela análise de armazenamento para gravar logs e entidades de tabela
são registradas.
Métricas de capacidade
NOTE
Atualmente, as métricas de capacidade somente estão disponíveis para o serviço Blob.
Os dados de capacidade são gravados diariamente para serviço de Blob de uma conta de armazenamento e duas
entidades de tabela são gravadas. Uma entidade fornece estatísticas para dados de usuário e a outra fornece
estatísticas sobre o contêiner de blob $logs usado pela análise de armazenamento. A tabela $MetricsCapacityBlob
inclui as seguintes estatísticas:
Capacidade : a quantidade de armazenamento usado pelo serviço Blob da conta de armazenamento, em
bytes.
ContainerCount : o número de contêineres de blob no serviço Blob da conta de armazenamento.
ObjectCount : o número de blobs de blocos ou páginas confirmados e não confirmados no serviço Blob da
Para saber mais sobre as métricas de capacidade, consulte Esquema da tabela de métricas da Análise de
Armazenamento.
Como as métricas são armazenadas

Todos os dados de métricas para cada um dos serviços de armazenamento são armazenados em três tabelas
reservadas para esse serviço: uma tabela para informações de transação, uma tabela de informações de transações
de minutos e outra tabela para informações de capacidade. Informações de transações de transação de minuto
consistem em dados de solicitação e resposta, e informações de capacidade consistem em dados de uso de
armazenamento. As métricas de horas, minutos e a capacidade para o serviço Blob de uma conta de
armazenamento podem ser acessadas nas tabelas chamadas da seguinte maneira conforme descrito na tabela a
seguir:
N ÍVEL DE M ÉT RIC A S N O M ES DE TA B EL A SUP O RT E PA RA VERSÕ ES
Métricas por hora, local principal -$MetricsTransactionsBlob Versões anteriores a 15-08-2013

-$MetricsTransactionsTable apenas. Embora esses nomes ainda ter
-$MetricsTransactionsQueue suporte, é recomendável que você
alterne para usar as tabelas listadas
abaixo.
Métricas por hora, local principal -$MetricsHourPrimaryTransactionsBlob Todas as versões. O suporte para
-$MetricsHourPrimaryTransactionsTable métricas de serviço de arquivo está
- disponível somente na versão 2015-04-
$MetricsHourPrimaryTransactionsQueu 05 e posterior.
e
-$MetricsHourPrimaryTransactionsFile
Métricas por minuto, local principal - Todas as versões. O suporte para

$MetricsMinutePrimaryTransactionsBlo métricas de serviço de arquivo está
b disponível somente na versão 2015-04-
- 05 e posterior.
$MetricsMinutePrimaryTransactionsTabl
e
-
$MetricsMinutePrimaryTransactionsQue
ue
-$MetricsMinutePrimaryTransactionsFile
N ÍVEL DE M ÉT RIC A S N O M ES DE TA B EL A SUP O RT E PA RA VERSÕ ES
Métricas por hora, local secundário - Todas as versões. A replicação de

$MetricsHourSecondaryTransactionsBlo redundância geográfica com acesso de
b leitura deve estar habilitada.
-
$MetricsHourSecondaryTransactionsTabl
e
-
$MetricsHourSecondaryTransactionsQu
eue
Métricas por minuto, local secundário - Todas as versões. A replicação de

$MetricsMinuteSecondaryTransactionsB redundância geográfica com acesso de
lob leitura deve estar habilitada.
-
$MetricsMinuteSecondaryTransactionsT
able
-
$MetricsMinuteSecondaryTransactions
Queue
Capacidade (apenas serviço Blob) $MetricsCapacityBlob Todas as versões.
Essas tabelas são criadas automaticamente quando Análise de Armazenamento está habilitado para um ponto de
extremidade de serviço de armazenamento. Eles são acessados por meio do namespace da conta de
armazenamento, https://<accountname>.table.core.windows.net/Tables("$MetricsTransactionsBlob") por exemplo:.
As tabelas de métricas não aparecem em uma operação de listagem e devem ser acessadas diretamente por meio
do nome da tabela.
Habilitar métricas usando o portal do Azure

Siga estas etapas para habilitar as métricas no portal do Azure:
1. Navegue até sua conta de armazenamento.
2. Selecione configurações de diagnóstico (clássico) no painel de menus .
3. O Status deve ser definido como Ativado .
4. Selecione as métricas para os serviços que deseja monitorar.
5. Especifica uma política de retenção para indicar por quanto tempo deve-se manter as métricas e os dados de
log.
6. Clique em Salvar .
O portal do Azure não permite atualmente configurar métricas de minuto em sua conta de armazenamento.
Habilite a métrica de minutos usando o PowerShell ou programaticamente.
Habilitar métricas de armazenamento usando o PowerShell

Você pode usar o PowerShell em seu computador local para configurar as métricas de armazenamento em sua
conta de armazenamento usando o cmdlet Azure PowerShell Get-AzStorageSer viceMetricsProper ty para
recuperar as configurações atuais e o cmdlet set-AzStorageSer viceMetricsProper ty para alterar as
configurações atuais.
Os cmdlets que controlam as métricas de armazenamento usam os seguintes parâmetros:
Ser viceType , o valor possível são blob , fila , tabela e arquivo .
Valorespossíveis metricstype , os valores possíveis são Hour e minute .
MetricsLevel , os valores possíveis são:
Nenhum : desativa o monitoramento.
Ser viço : coleta métricas como entrada/saída, disponibilidade, latência e porcentagens de êxito, que são
agregadas para os serviços BLOB, fila, tabela e arquivo.
Ser viceAndApi : além das métricas de serviço, o coleta o mesmo conjunto de métricas para cada operação de
armazenamento na API do serviço de armazenamento do Azure.
Por exemplo, o comando a seguir alterna as métricas de minuto para o serviço blob em sua conta de
armazenamento com o período de retenção definido como cinco dias:
NOTE
Esse comando pressupõe que você tenha entrado em sua assinatura do Azure usando Connect-AzAccount o comando.
$storageAccount = Get-AzStorageAccount -ResourceGroupName "<resource-group-name>" -AccountName "<storage-

account-name>"
Set-AzStorageServiceMetricsProperty -MetricsType Minute -ServiceType Blob -MetricsLevel ServiceAndApi -

RetentionDays 5 -Context $storageAccount.Context
Substitua o <resource-group-name> valor do espaço reservado pelo nome do seu grupo de recursos.
Substitua o valor de espaço reservado <storage-account-name> pelo nome da sua conta de armazenamento.
O comando a seguir recupera o nível de métricas por hora atual e dias de retenção para o serviço blob na conta de
armazenamento padrão:
Get-AzStorageServiceMetricsProperty -MetricsType Hour -ServiceType Blob -Context $storagecontext.Context
Para saber mais sobre como configurar os cmdlets do PowerShell do Azure para funcionar com sua assinatura do
Azure e como selecionar a conta de armazenamento padrão para usar, consulte: Como instalar e configurar o
PowerShell do Azure.
Habilitar métricas de armazenamento programaticamente

Além de usar os cmdlets portal do Azure ou Azure PowerShell para controlar as métricas de armazenamento, você
também pode usar uma das APIs de armazenamento do Azure. Por exemplo, se estiver usando uma linguagem
.NET, você poderá usar a Biblioteca do Cliente de Armazenamento.
As classes CloudBlobClient , CloudQueueClient , CloudTableClient e CloudFileClient têm métodos como
Setser vicesproper ties e SetSer viceProper tiesAsync que usam um objeto ser viceproper ties como um
parâmetro. Você pode usar o objeto Ser viceProper ties para configurar Métricas de Armazenamento. Por
exemplo, o seguinte snippet de C# mostra como alterar o nível de métricas e os dias de retenção para as métricas
de fila de hora:
var storageAccount = CloudStorageAccount.Parse(connStr);

var queueClient = storageAccount.CreateCloudQueueClient();
var serviceProperties = queueClient.GetServiceProperties();
serviceProperties.HourMetrics.MetricsLevel = MetricsLevel.Service;
serviceProperties.HourMetrics.RetentionDays = 10;
queueClient.SetServiceProperties(serviceProperties);
Para obter mais informações sobre como usar uma linguagem .NET para configurar as métricas de
armazenamento, consulte biblioteca de cliente de armazenamento para .net.
Para obter informações gerais sobre como configurar as métricas de armazenamento usando a API REST, consulte
Habilitando e Configurando análise de armazenamento.
Exibindo as métricas de armazenamento

Após configurar as métricas Análise de Armazenamento para monitorar sua conta de armazenamento, a Análise de
Armazenamento registra as métricas em um conjunto conhecido de tabelas na sua conta de armazenamento. Você
pode configurar gráficos para exibir as métricas por hora no portal do Azure:
1. Navegue até sua conta de armazenamento no portal do Azure.
2. Selecione métricas (clássicas) na folha do menu para o serviço cujas métricas você deseja exibir.
3. Clique no gráfico que você deseja configurar.
4. No Editar gráfico folha, selecione o inter valo de tempo , tipo de gráfico e as métricas que deseja exibir no
gráfico.
Na seção monitoramento (clássico) da folha do menu da sua conta de armazenamento no portal do Azure, você
pode configurar regras de alerta, como enviar alertas de email para notificá-lo quando uma métrica específica
atingir um determinado valor.
Se você quiser baixar as métricas para armazenamento de longo prazo ou analisá-las localmente, deverá usar uma
ferramenta ou escrever algum código para ler as tabelas. Você deve baixar a métrica de minutos para análise. As
tabelas não aparecem quando você lista todas as tabelas em sua conta de armazenamento, mas você pode acessá-
las diretamente por nome. Muitas ferramentas de navegação de armazenamento estão cientes dessas tabelas e
permitem exibi-las diretamente (consulte ferramentas de cliente de armazenamento do Azure para obter uma lista
de ferramentas disponíveis).
Métricas Nomes de tabela Obser vações
Métricas por hora $MetricsHourPrimaryTransactionsBlob Em versões anteriores a 15-08-2013,

essas tabelas eram conhecidas como:
$MetricsHourPrimaryTransactionsTable
$MetricsTransactionsBlob
$MetricsHourPrimaryTransactionsQueu
e $MetricsTransactionsTable
$MetricsHourPrimaryTransactionsFile $MetricsTransactionsQueue
As métricas para o serviço de arquivo

estão disponíveis a partir da versão
2015-04-05.
Métricas por minuto $MetricsMinutePrimaryTransactionsBlo Só podem ser habilitadas usando o

b PowerShell ou de forma programática.
$MetricsMinutePrimaryTransactionsTabl As métricas para o serviço de arquivo

e estão disponíveis a partir da versão
2015-04-05.
$MetricsMinutePrimaryTransactionsQue
ue
$MetricsMinutePrimaryTransactionsFile
Capacity $MetricsCapacityBlob Serviço de blob somente.

Você pode encontrar detalhes completos dos esquemas para essas tabelas no Esquema da tabela de métricas da
análise de armazenamento. As linhas de exemplo a seguir mostram apenas um subconjunto das colunas
disponíveis, mas ilustram alguns recursos importantes da maneira como as métricas de armazenamento salvam
essas métricas:
Par titi RowKe Timest TotalR TotalBi TotalIn TotalE Dispo Avera Avera Percen
onKey y amp eques llableR gress gress nibilid geE2E geSer v tSucce
ts eques ade Latenc erLate ss
ts y ncy
20140 user;All 2014- 7 7 4003 46801 100 104.42 6.8571 100

522T1 05- 86 43
100 22T11:
01:16.7
65025
0Z
20140 usuário 2014- 5 5 2694 45951 100 143.8 7.8 100

522T1 ;Query 05-
100 Entities 22T11:
01:16.7
64025
0Z
20140 user;Q 2014- 1 1 538 633 100 3 3 100

522T1 ueryEn 05-
100 tity 22T11:
01:16.7
65025
0Z
20140 user;U 2014- 1 1 771 217 100 9 6 100

522T1 pdateE 05-
100 ntity 22T11:
01:16.7
65025
0Z
Neste exemplo dos dados de métrica de minutos, a chave de partição usa o tempo de resolução minuto. A chave
de linha identifica o tipo de informação que é armazenado na linha, e isso é composto de duas partes de
informações, o tipo de acesso e o tipo de solicitação:
O tipo de acesso é user ou system , em que user refere-se a todas as solicitações do usuário para o serviço
de armazenamento e system refere-se a solicitações feitas pela Análise de Armazenamento.
O tipo de solicitação é all e, nesse caso, é uma linha de resumo, ou identifica a API específica, como
Quer yEntity ou UpdateEntity .
Os dados de exemplo acima mostram todos os registros para um único minuto (começando às 11h), assim, o
número de solicitações Quer yEntities mais o número de solicitações Quer yEntity mais o número de solicitações
UpdateEntity totalizam sete, que é o total mostrado na linha user :All . Da mesma forma, você pode derivar a
latência média de ponta a ponta 104,4286 na linha user :All calculando ((143,8 * 5) + 3 + 9)/7.
Alertas de métricas
Você deve considerar a configuração de alertas no portal do Azure para que você seja notificado automaticamente
sobre alterações importantes no comportamento de seus serviços de armazenamento. Se você usar uma
ferramenta de Gerenciador de armazenamento para baixar esses dados de métricas em um formato delimitado,
você pode usar o Microsoft Excel para analisar os dados. Confira Ferramentas de Cliente do Armazenamento do
Azure para obter uma lista de ferramentas do gerenciador de armazenamento disponíveis. Você pode configurar
alertas na folha aler ta (clássico) , acessível em monitoramento (clássico) na folha do menu da conta de
armazenamento.
IMPORTANT
Pode haver um atraso entre um evento de armazenamento e quando os dados de métricas por hora ou minuto
correspondentes são registrados. No caso de métricas por minuto, diversos minutos de dados podem ser gravados de uma
só vez. Isso pode levar à agregação de transações de minutos anteriores à transação do minuto atual. Quando isso acontece,
o serviço de alerta pode não ter todos os dados de métricas disponíveis para o intervalo de alerta configurado, o que pode
levar ao acionamento inesperado de alertas.
Acessando dados de métrica programaticamente

A listagem a seguir mostra o código C# de exemplo, que acessa a métrica de minutos para um intervalo de
minutos e exibe os resultados em uma janela de console. O exemplo de código usa a biblioteca de cliente de
armazenamento do Azure versão 4. x ou posterior, que inclui a classe CloudAnalyticsClient que simplifica o
acesso às tabelas de métricas no armazenamento.
private static void PrintMinuteMetrics(CloudAnalyticsClient analyticsClient, DateTimeOffset startDateTime,
DateTimeOffset endDateTime)
{
// Convert the dates to the format used in the PartitionKey
var start = startDateTime.ToUniversalTime().ToString("yyyyMMdd'T'HHmm");
var end = endDateTime.ToUniversalTime().ToString("yyyyMMdd'T'HHmm");
var services = Enum.GetValues(typeof(StorageService));

foreach (StorageService service in services)
{
Console.WriteLine("Minute Metrics for Service {0} from {1} to {2} UTC", service, start, end);
var metricsQuery = analyticsClient.CreateMinuteMetricsQuery(service, StorageLocation.Primary);
var t = analyticsClient.GetMinuteMetricsTable(service);
var opContext = new OperationContext();
var query =
from entity in metricsQuery
// Note, you can't filter using the entity properties Time, AccessType, or TransactionType
// because they are calculated fields in the MetricsEntity class.
// The PartitionKey identifies the DataTime of the metrics.
where entity.PartitionKey.CompareTo(start) >= 0 && entity.PartitionKey.CompareTo(end) <= 0
select entity;
// Filter on "user" transactions after fetching the metrics from Table Storage.
// (StartsWith is not supported using LINQ with Azure Table storage)
var results = query.ToList().Where(m => m.RowKey.StartsWith("user"));
var resultString = results.Aggregate(new StringBuilder(), (builder, metrics) =>
builder.AppendLine(MetricsString(metrics, opContext))).ToString();
Console.WriteLine(resultString);
}
}
private static string MetricsString(MetricsEntity entity, OperationContext opContext)

{
var entityProperties = entity.WriteEntity(opContext);
var entityString =
string.Format("Time: {0}, ", entity.Time) +
string.Format("AccessType: {0}, ", entity.AccessType) +
string.Format("TransactionType: {0}, ", entity.TransactionType) +
string.Join(",", entityProperties.Select(e => new KeyValuePair<string, string>(e.Key.ToString(),
e.Value.PropertyAsObject.ToString())));
return entityString;
}
Cobrança sobre métricas de armazenamento

Gravar solicitações para criar entidades de tabela para métricas são cobradas de acordo com as taxas padrão
aplicáveis a todas as operações de armazenamento do Azure.
As solicitações de leitura e exclusão de dados de métricas por um cliente também são faturáveis com tarifas
padrão. Se você configurou uma política de retenção de dados, que não seja cobrado quando o armazenamento do
Azure excluir dados de métricas antigos. No entanto, se você excluir dados de análise, sua conta será cobrada para
as operações de exclusão.
A capacidade usada pelas tabelas de métricas também é faturável. Você pode usar o seguinte para estimar a
quantidade de capacidade usada para armazenar dados de métricas:
Se a cada hora um serviço utilizar cada API em cada serviço, aproximadamente 148KB de dados serão
armazenados a cada hora nas tabelas de transação de métricas se você tiver habilitado o resumo no nível de
serviço e de API.
Se, em cada hora, um serviço utilizar cada API no serviço, aproximadamente 12KB de dados serão armazenados
a cada hora nas tabelas de transação de métricas se você tiver habilitado apenas o resumo de nível de serviço.
A tabela de capacidade para BLOBs tem duas linhas adicionadas por dia, desde que você tenha optado por logs.
Isso implica que, todos os dias, o tamanho dessa tabela aumenta em até cerca de 300 bytes.
Próximas etapas
Como monitorar uma conta de armazenamento
Esquema da tabela de métricas da análise de armazenamento
Mensagens de operações e status registradas de análise de armazenamento
Registro em log da Análise de Armazenamento
Perguntas frequentes sobre o Azure Files
Os arquivos do Azure oferecem compartilhamentos de arquivos totalmente gerenciados na nuvem que são
acessíveis por meio do {SM} protocolo de padrão do setor. Você pode montar compartilhamentos de arquivos do
Azure simultaneamente em implantações locais ou na nuvem do Windows, do Linux e do macOS. Também é
possível armazenar em cache os compartilhamentos de arquivos do Azure em computadores Windows Server
usando a Sincronização de Arquivos do Azure para acesso rápido próximo ao local em que os dados são usados.
Este artigo responde perguntas frequentes sobre funcionalidades e recursos do serviço Arquivos do Azure,
inclusive sobre o uso dele em combinação com a Sincronização de Arquivos do Azure. Se você não vir a resposta
para sua pergunta aqui, poderá entrar em contato conosco pelos seguintes canais (em ordem progressiva):
1. A seção de comentários deste artigo.
2. Fórum do armazenamento do Azure.
3. O UserVoice do Arquivos do Azure.
4. O Suporte da Microsoft. Para criar uma nova solicitação de suporte, no Portal do Azure, na guia Ajuda ,
selecione o botão Ajuda + supor te e, em seguida, selecione Nova solicitação de supor te .
Geral
Por que o ser viço Arquivos do Azure é útil?
Você pode usar o serviço Arquivos do Azure para criar compartilhamentos de arquivos na nuvem sem ser
responsável por gerenciar a sobrecarga de um servidor físico ou dispositivo. Nós fazemos o trabalho
monótono para você, incluindo a aplicação de atualizações do sistema operacional e a substituição de
discos defeituosos. Para saber mais sobre os cenários em que os Arquivos do Azure podem ajudar, confira
Por que o serviço Arquivos do Azure é útil.
Quais são as diferentes maneiras de acessar arquivos nos arquivos do Azure?
Você pode montar o compartilhamento de arquivos no computador local usando o protocolo SMB 3.0 ou
pode usar ferramentas como o Gerenciador de Armazenamento para acessar os arquivos no
compartilhamento de arquivos. No aplicativo, você pode usar bibliotecas de cliente de armazenamento,
APIs REST, o PowerShell ou a CLI do Azure para acessar os arquivos no compartilhamento de arquivos do
Azure.
O que é a Sincronização de arquivos do Azure?
Você pode usar a Sincronização de Arquivos do Azure para centralizar os compartilhamentos de arquivos
da sua organização no serviço Arquivos do Azure sem abrir mão da flexibilidade, do desempenho e da
compatibilidade de um servidor de arquivos local. A Sincronização de Arquivos do Azure transforma
computadores Windows Server em um cache rápido do seu compartilhamento de arquivos do Azure. Você
pode usar qualquer protocolo disponível no Windows Server para acessar seus dados localmente, incluindo
o SMB, o NFS (sistema de arquivos de rede) e o FTPS (serviço de protocolo de transferência de arquivos).
Você pode ter tantos caches quantos precisar em todo o mundo.
Por que usar um compar tilhamento de arquivos do Azure em vez do armazenamento de
BLOBs do Azure para meus dados?
Tanto o serviço Arquivos do Azure quanto o Armazenamento de Blobs do Azure fornecem uma maneira de
armazenar grandes quantidades de dados na nuvem, mas são úteis para fins ligeiramente diferentes.
O Armazenamento de Blobs do Azure é útil para aplicativos de grande escala e nativos de nuvem que
precisam armazenar dados não estruturados. Para maximizar o desempenho e o dimensionamento, o
Armazenamento de Blobs do Azure é uma abstração de armazenamento mais simples do que um sistema
de arquivos real. O Armazenamento de Blobs do Azure só pode ser acessado por bibliotecas de cliente
baseadas em REST (ou diretamente por meio do protocolo baseado em REST).
O serviço Arquivos do Azure é especificamente um sistema de arquivos. O serviço Arquivos do Azure tem
todos os resumos de arquivo que você conhece e adora após anos de trabalho com sistemas operacionais
locais. Assim como o Armazenamento de Blobs do Azure, o serviço Arquivos do Azure oferece uma
interface REST e bibliotecas de cliente baseadas em REST. Ao contrário do Armazenamento de Blobs do
Azure, o serviço Arquivos do Azure oferece acesso via SMB a compartilhamentos de arquivos do Azure.
Usando SMB, você pode montar um compartilhamento dos Arquivos do Azure diretamente no Windows,
no Linux ou no macOS, localmente ou em VMs na nuvem, sem escrever nenhum código nem anexar drivers
especiais ao sistema de arquivos. Você também pode armazenar em cache os compartilhamentos de
arquivos do Azure em servidores de arquivos locais usando a Sincronização de Arquivos do Azure para
acesso rápido, perto de onde os dados são usados.
Para obter uma descrição mais detalhada sobre as diferenças entre os arquivos do Azure e o
armazenamento de BLOBs do Azure, consulte introdução aos serviços principais de armazenamento do
Azure. Para saber mais sobre o Armazenamento de Blobs do Azure, confira Introdução ao armazenamento
de Blobs.
Por que usar um compar tilhamento de arquivos do Azure em vez dos Discos do Azure?
Um disco nos Discos do Azure é simplesmente um disco. Para obter valor do serviço Discos do Azure, você
deve anexar um disco a uma máquina virtual que está em execução no Azure. O serviço Discos do Azure
pode ser usado para todos os fins para os quais você usaria um disco em um servidor local. Você pode usá-
lo como um disco de sistema do SO, como espaço de permuta para um SO ou como armazenamento
dedicado para um aplicativo. Um uso interessante do serviço Discos do Azure é a criação de um servidor de
arquivos na nuvem para uso nos mesmos locais em que você usaria um compartilhamento de arquivos do
Azure. Implantar um servidor de arquivos em Máquinas Virtuais do Azure é uma maneira fantástica e de
alto desempenho de obter o armazenamento de arquivos no Azure quando você precisa de opções de
implantação que atualmente não têm suporte pelo serviço Arquivos do Azure (como suporte a protocolo
NFS ou armazenamento Premium).
No entanto, executar um servidor de arquivos com os Discos do Azure como armazenamento de back-end
geralmente é muito mais caro do que usar um compartilhamento de arquivos do Azure, por vários motivos.
Primeiro, além de pagar pelo armazenamento em disco, você também precisa pagar a despesa de execução
de uma ou mais VMs do Azure. Em segundo lugar, você também deve gerenciar as VMs que são usadas
para executar o servidor de arquivos. Por exemplo, você é responsável por atualizações do SO. Por fim, se
precisar que dados sejam armazenados em cache localmente, caberá a você configurar e gerenciar as
tecnologias de replicação, por exemplo, a DFSR (Replicação do Sistema de Arquivos Distribuído) para fazer
com que isso aconteça.
Uma abordagem para obter o melhor tanto do serviço Arquivos do Azure quando de um servidor de
arquivos hospedado em Máquinas Virtuais do Azure (além de usar o serviço Discos do Azure como
armazenamento de back-end) é instalar a Sincronização de Arquivos do Azure no servidor de arquivos
hospedado em uma VM na nuvem. Se o compartilhamento dos Arquivos do Azure está na mesma região
que o servidor de arquivos, você pode habilitar a disposição em camadas na nuvem e definir o percentual
do volume de espaço livre para o máximo (99%). Isso garante o mínimo de duplicação de dados. Você
também pode usar quaisquer aplicativos que desejar com seus servidores de arquivo, assim como
aplicativos que exigem suporte a protocolo NFS.
Para obter informações sobre uma opção para definição de um servidor de arquivos de alto desempenho e
alta disponibilidade no Azure, confira Implantando clusters convidados em VMs IaaS no Microsoft Azure.
Para obter uma descrição mais detalhada das diferenças entre os arquivos do Azure e os discos do Azure,
consulte introdução aos serviços principais de armazenamento do Azure. Para saber mais sobre os Discos
do Azure, confira Visão geral do Azure Managed Disks.
Como posso começar a usar os Arquivos do Azure?
É fácil começar a usar o serviço Arquivos do Azure. Primeiro, crie um compartilhamento de arquivos e, em
seguida, monte-o no seu sistema operacional preferido:
Montar no Windows
Montar no Linux
Montar no macOS
Para obter um guia mais detalhado sobre como implantar um compartilhamento dos Arquivos do
Azure para substituir os compartilhamentos de arquivos de produção em sua organização, confira
Planejando a implantação dos Arquivos do Azure.
Quais opções de redundância de armazenamento têm supor te pelos Arquivos do Azure?
Atualmente, os arquivos do Azure oferecem suporte a armazenamento com redundância local (LRS),
armazenamento com redundância de zona (ZRS), armazenamento com redundância geográfica (GRS) e
armazenamento com redundância de zona geográfica (GZRS). Planejamos dar suporte para RA-GRS
(redundância geográfica com acesso de leitura) no futuro, mas não temos linhas do tempo para
compartilhar nesse momento.
Atualmente, quais camadas de armazenamento têm supor te no ser viço Arquivos do Azure?
Os arquivos do Azure dão suporte a duas camadas de armazenamento: Premium e Standard. Os
compartilhamentos de arquivos padrão são criados em contas de armazenamento de uso geral (GPv1 ou
GPv2) e os compartilhamentos de arquivos Premium são criados em contas de armazenamento de
armazenamento de arquivo. Saiba mais sobre como criar compartilhamentos de arquivos padrão e
compartilhamentos de arquivos Premium.
NOTE
Você não pode criar compartilhamentos de arquivos do Azure de contas de armazenamento de BLOBs ou contas de
armazenamento Premium de uso geral (GPv1 ou GPv2). Os compartilhamentos de arquivos padrão do Azure devem
ser criados somente em contas de uso geral padrão e compartilhamentos de arquivos premium do Azure devem ser
criados somente em contas de armazenamento de armazenamento. As contas de armazenamento de uso geral
Premium (GPv1 e GPv2) são apenas para BLOBs de páginas Premium.
Eu realmente quero ver um recurso específico adicionado aos arquivos do Azure. Você pode
adicioná-lo?
A equipe do serviço Arquivos do Azure quer ouvir todos os comentários que você tem a fazer sobre nosso
serviço. Vote nas solicitações de recurso no UserVoice do Arquivos do Azure! Estamos ansiosos para
surpreendê-lo com muitos recursos novos.
Os arquivos do Azure dão supor te ao bloqueio de arquivos?
Sim, os arquivos do Azure dão suporte total ao bloqueio de arquivo de estilo SMB/Windows, Consulte
detalhes.

Quais regiões têm supor te para Sincronização de Arquivos do Azure?
A lista de regiões disponíveis pode ser encontrada na seção Disponibilidade de região da guia de
planejamento da Sincronização de Arquivos do Azure. Adicionaremos suporte continuamente para outras
regiões, incluindo regiões não públicas.
É possível ter ser vidores ingressados e não ingressados no domínio no mesmo grupo de
sincronização?
Sim. Sim, um grupo de sincronização poderá conter pontos de extremidade do servidor com diferentes
associações do Active Directory, mesmo se eles não forem ingressados no domínio. Embora essa
configuração funcione tecnicamente, não recomendamos isso como uma configuração típica, já que as
ACLs (listas de controle de acesso) que são definidas para arquivos e pastas em um servidor podem não ser
impostas por outros servidores no grupo de sincronização. Para obter melhores resultados, recomendamos
a sincronização entre servidores na mesma floresta do Active Directory entre servidores que estão em
diferentes florestas do Active Directory mas têm relações de confiança estabelecidas ou então entre
servidores que não estão em um domínio. Recomendamos que você evite usar uma mistura dessas
configurações.
Criei um arquivo diretamente no meu compar tilhamento de arquivos do Azure usando SMB
ou no Por tal. Quanto tempo leva para que o arquivo seja sincronizado com os ser vidores no
grupo de sincronização?
As alterações feitas ao compartilhamento de Arquivos do Azure usando o Portal do Azure ou SMB não são
detectadas e replicadas imediatamente como as alterações no Ponto de extremidade do servidor são. Os
Arquivos do Azure ainda não têm notificações/diário de alteração, portanto, não há nenhuma maneira de
iniciar automaticamente uma sessão de sincronização quando os arquivos são alterados. No Windows
Server, a sincronização de Arquivos do Azure usa o diário de USN do Windows para iniciar
automaticamente uma sessão de sincronização quando os arquivos são alterados.
Para detectar alterações para o compartilhamento de arquivos do Azure, a sincronização de arquivos do
Azure tem um trabalho agendado chamado um alterar o trabalho de detecção. Um trabalho de detecção de
alteração enumera todos os arquivos no compartilhamento de arquivos e, em seguida, compara a versão
de sincronização para esse arquivo. Quando o trabalho de detecção de alteração determina que os arquivos
foram alterados, a sincronização de Arquivos do Azure inicia uma sessão de sincronização. O trabalho de
detecção de alteração é iniciado a cada 24 horas. Como o trabalho de detecção de alteração funciona
enumerando todos os arquivos no compartilhamento de Arquivos do Azure, a detecção de troca demora
mais nos namespaces grandes do que namespaces menores. Para esses namespaces, pode levar mais de
uma vez a cada 24 horas para determinar quais arquivos foram alterados.
Para sincronizar imediatamente os arquivos que são alterados no compartilhamento de arquivos do Azure,
o cmdlet Invoke-AzStorageSyncChangeDetection do PowerShell pode ser usado para iniciar
manualmente a detecção de alterações no compartilhamento de arquivos do Azure. Esse cmdlet destina-se
a cenários em que algum tipo de processo automatizado está fazendo alterações no compartilhamento de
arquivos do Azure ou as alterações são feitas por um administrador (como mover arquivos e diretórios
para o compartilhamento). Para alterações do usuário final, a recomendação é instalar o agente de
Sincronização de Arquivos do Azure em uma VM IaaS e fazer com que os usuários finais acessem o
compartilhamento de arquivos por meio da VM IaaS. Dessa forma, todas as alterações serão rapidamente
sincronizadas com outros agentes sem a necessidade de usar o cmdlet Invoke-
AzStorageSyncChangeDetection. Para saber mais, confira a documentação do Invoke-
AzStorageSyncChangeDetection .
NOTE
As alterações feitas em um compartilhamento de arquivos do Azure usando REST não atualizam a hora da última
modificação do SMB e não serão vistas como uma alteração por sincronização.
Estamos explorando adicionar detecção de alteração para um compartilhamento de arquivos do Azure

semelhante ao USN para volumes no Windows Server. Ajude-nos a priorizar esse recurso para
desenvolvimento futuro votando no UserVoice de Arquivos do Azure.
Se o mesmo arquivo for alterado em dois ser vidores quase ao mesmo tempo, o que
acontecerá?
A Sincronização de Arquivos do Azure usa uma estratégia simples de resolução de conflitos: mantemos
ambas as alterações aos arquivos que são alterados em dois servidores simultaneamente. A alteração
gravada mais recentemente mantém o nome do arquivo original. O arquivo mais antigo tem o computador
de "origem" e o número do conflito anexado ao nome. Ele segue esta taxonomia:
<FileNameWithoutExtension>-<MachineName>[-#].<ext>
Por exemplo, o primeiro conflito de CompanyReport.docx se tornaria CompanyReport-CentralServer.docx
se CentralServer fosse o local em que a gravação mais antiga ocorreu. O segundo conflito seria nomeado
CompanyReport-CentralServer-1.docx. O Sincronização de Arquivos do Azure dá suporte a arquivos de
conflito 100 por arquivo. Depois que o número máximo de arquivos de conflito for atingido, o arquivo não
será sincronizado até que o número de arquivos de conflito seja menor que 100.
Há supor te para armazenamento com redundância geográfica na Sincronização de arquivos
do Azure?
Sim, o serviço Arquivos do Azure dá suporte tanto ao LRS (armazenamento com redundância local) quanto
ao GRS (armazenamento com redundância geográfica). Se você iniciar um failover de conta de
armazenamento entre regiões emparelhadas de uma conta configurada para GRS, a Microsoft recomenda
que você trate a nova região como um backup de dados somente. A Sincronização de Arquivos do Azure
não inicia automaticamente a sincronização com a nova região primária.
Por que o tamanho na Propriedade do disco para um arquivo corresponde à propriedade size
depois de usar sincronização de arquivos do Azure?
Confira Understanding Cloud Tiering (Noções básicas sobre a Camada de Nuvem).
Como posso saber se um arquivo foi colocado em camadas?
Um arquivo que desejo usar foi colocado em camadas. Como posso recuperar o arquivo no
disco para usá-lo localmente?
Como fazer forçar um arquivo ou diretório a ser colocado em camadas?
Como o espaço livre no volume é interpretado quando há vários pontos de extremidade do
ser vidor em um volume?
Quais arquivos ou pastas são excluídas automaticamente pela Sincronização de arquivos do
Azure?
Consulte arquivos ignorados.
Posso usar a Sincronização de Arquivos do Azure com o Windows Ser ver 2008 R2, Linux ou o
dispositivo NAS (armazenamento conectado à rede)?
Atualmente, Sincronização de Arquivos do Azure dá suporte apenas ao Windows Server 2019, ao Windows
Server 2016 e ao Windows Server 2012 R2. Neste momento, não há outros planos que possamos divulgar,
mas gostaríamos de dar suporte a outras plataformas com base na demanda dos clientes. Informe-nos
quais plataformas você deseja que tenham suporte no UserVoice do Arquivos do Azure.
Por que os arquivos em camadas existem fora o namespace de ponto de extremidade do
ser vidor?
Antes do agente do Azure File Sync - Sincronização de Arquivos do Azure versão 3, o Azure File Sync
bloqueava a movimentação de arquivos em camadas fora do ponto de extremidade do servidor, mas no
mesmo volume que o ponto de extremidade do servidor. Operações de cópia, move arquivos não
hierárquico e de em camadas para outros volumes foram afetados. O motivo para esse comportamento foi
a suposição implícita de que o Explorador de Arquivos e outras APIs do Windows que têm essas operações
de movimentação no mesmo volume são operações de renomeação (quase) instantâneas. Isso significa que
move fará o Explorador de arquivos ou outros métodos de movimentação (como a linha de comando ou o
PowerShell) pode parecer não estar respondendo enquanto a sincronização de arquivos do Azure recupera
os dados da nuvem. A partir do agente do Azure File Sync versão 3.0.12.0 , o Azure File Sync permitirá que
você mova um arquivo em camadas fora do ponto de extremidade do servidor. Evitamos os efeitos
negativos mencionados anteriormente, permitindo que o arquivo em camadas exista como um arquivo em
camadas fora do terminal do servidor e, em seguida, recuperando o arquivo em segundo plano. Isso
significa que movimentações no mesmo volume são instantâneas e fazemos todo o trabalho para
recuperar o arquivo no disco após a movimentação ser concluída.
Estou tendo um problema com Sincronização de Arquivos do Azure no meu ser vidor
(sincronização, camadas de nuvem, etc.). Devo remover e recriar meu ponto de extremidade
do ser vidor?
Não: a remoção de um ponto de extremidade do servidor não é como reinicializar um servidor! Remover e
recriar o ponto de extremidade do servidor quase nunca é uma solução apropriada para corrigir problemas
com sincronização, camadas de nuvem ou outros aspectos de Sincronização de Arquivos do Azure. A
remoção de um ponto de extremidade do servidor é uma operação destrutiva. Isso pode resultar em perda
de dados, caso os arquivos em camadas existam fora do namespace do ponto de extremidade do servidor.
Veja por que arquivos em camadas existem fora do namespace do ponto de extremidade do servidor para
obter mais informações. Ou pode resultar em arquivos inacessíveis para arquivos em camadas que existem
dentro do namespace do ponto de extremidade do servidor. Esses problemas não serão resolvidos quando
o ponto de extremidade do servidor for recriado. Arquivos em camadas podem existir em seu ponto de
extremidade do servidor, mesmo se você nunca tiver habilitado nuvem em camadas. É por isso que é
recomendável não remover o ponto de extremidade do servidor, a menos que você queira parar de usar
Sincronização de Arquivos do Azure com essa pasta específica ou tenha sido instruído explicitamente a
fazer isso por um engenheiro da Microsoft. Para obter mais informações sobre remover pontos de
extremidade do servidor, consulte remover um ponto de extremidade do servidor.
Posso mover o ser viço de sincronização de armazenamento e/ou a conta de armazenamento
para um grupo de recursos ou assinatura diferente?
Sim, o serviço de sincronização de armazenamento e/ou a conta de armazenamento podem ser movidos
para um grupo de recursos ou assinatura diferente dentro do locatário do Azure AD existente. Se a conta de
armazenamento for movida, você precisará conceder o acesso do Serviço de Sincronização de Arquivos
Híbrido para a conta de armazenamento (consulte Certifique-se de que a Sincronização de Arquivos do
Azure tenha acesso à conta de armazenamento).
NOTE
A Sincronização de Arquivos do Azure não oferece suporte para mover a assinatura para um locatário do Azure AD
diferente.
Sincronização de arquivos do Azure preser va o nível de diretório/arquivo ACLs do NTFS,

juntamente com os dados armazenados em arquivos do Azure?
A partir de fevereiro de 24, 2020, as ACLs novas e existentes em camadas pela sincronização de arquivos
do Azure serão persistidas no formato NTFS e as modificações de ACL feitas diretamente no
compartilhamento de arquivos do Azure serão sincronizadas com todos os servidores no grupo de
sincronização. As alterações nas ACLs feitas nos arquivos do Azure serão sincronizadas por meio da
sincronização de arquivos do Azure. Ao copiar dados para arquivos do Azure, certifique-se de usar o SMB
para acessar o compartilhamento e preservar suas ACLs. As ferramentas baseadas em REST existentes,
como AzCopy ou Gerenciador de Armazenamento, não persistem ACLs.
Se você tiver habilitado o backup do Azure em seus compartilhamentos de arquivos gerenciados de
sincronização de arquivos, as ACLs de arquivo poderão continuar a ser restauradas como parte do fluxo de
trabalho de restauração de backup. Isso funciona para todo o compartilhamento ou arquivos/diretórios
individuais.
Se você estiver usando instantâneos como parte da solução de backup autogerenciado para
compartilhamentos de arquivos gerenciados pela sincronização de arquivos, suas ACLs poderão não ser
restauradas corretamente para ACLs NTFS se os instantâneos tiverem sido feitos antes de 24 de fevereiro
de 2020. Se isso ocorrer, considere entrar em contato com o suporte do Azure.
Segurança, autenticação e controle de acesso

O controle de acesso e a autenticação baseada em identidade são compatíveis com os
arquivos do Azure?
Sim, os arquivos do Azure oferecem suporte à autenticação baseada em identidade e ao controle de acesso.
Você pode escolher uma das duas maneiras de usar o controle de acesso baseado em identidade: Active
Directory Domain Services local (visualização) ou Azure Active Directory Domain Services (Azure AD DS). O
Active Directory Domain Services local (AD DS) dá suporte à autenticação usando AD DS computadores
ingressados no domínio, no local ou no Azure, para acessar compartilhamentos de arquivos do Azure por
SMB. A autenticação do Azure AD DS sobre o SMB para arquivos do Azure permite que o Azure AD DS VMs
do Windows ingressadas no domínio acessem compartilhamentos, diretórios e arquivos usando as
credenciais do Azure AD. Para obter mais detalhes, consulte visão geral do suporte à autenticação baseada
em identidade de arquivos do Azure para acesso SMB.
O Azure Files oferece duas maneiras adicionais de gerenciar o controle de acesso:
Você pode usar SAS (assinaturas de acesso compartilhado) para gerar tokens que têm permissões
específicas e que são válidos para um intervalo de tempo especificado. Por exemplo, você pode gerar
um token com acesso somente leitura a um arquivo específico que tem validade de 10 minutos.
Qualquer pessoa que tem esse token enquanto ele é válido tem acesso somente leitura ao arquivo
por 10 minutos. As chaves de assinatura de acesso compartilhado têm suporte apenas por meio da
API REST ou nas bibliotecas de cliente. Você deve montar o compartilhamento de arquivos do Azure
no SMB usando as chaves de conta de armazenamento.
A Sincronização de Arquivos do Azure preserva e replica todas as ACLs discricionárias ou DACLs
(sejam elas baseadas no Active Directory ou locais) para todos os pontos de extremidade do servidor
aos quais ela é sincronizada.
Você pode consultar autorizar o acesso ao armazenamento do Azure para uma representação abrangente
de todos os protocolos com suporte nos serviços de armazenamento do Azure.
Os arquivos do Azure Azure Active Director y Domain Ser vices autenticação (AD DS do Azure)
dão supor te ao acesso SMB usando as credenciais do Azure AD de dispositivos ingressados ou
registrados com o Azure AD?
Não, este cenário não é suportado.
Existem APIs REST para dar supor te a Get/Set/copiar diretório/arquivo ACLs do NTFS?
Sim, damos suporte a APIs REST que obtêm, definem ou copiam ACLs NTFS para diretórios ou arquivos ao
usar a API REST 2019-07-07 (ou posterior).
Posso acessar compar tilhamentos de arquivos do Azure com as credenciais do Azure AD de
uma VM em uma assinatura diferente?
Se a assinatura sob a qual o compartilhamento de arquivos está implantado estiver associada ao mesmo
locatário do Azure AD que a implantação de AD DS do Azure na qual a VM está ingressada no domínio,
você poderá acessar os compartilhamentos de arquivos do Azure usando as mesmas credenciais do Azure
AD. A limitação é imposta não na assinatura, mas no locatário associado do Azure AD.
Posso habilitar o Azure AD DS ou a autenticação de AD DS local para compar tilhamentos de
arquivos do Azure usando um locatário do Azure AD que seja diferente do locatário principal
do compar tilhamento de arquivos do Azure?
Não, os arquivos do Azure dão suporte apenas ao Azure AD DS ou à integração de AD DS local com um
locatário do Azure AD que reside na mesma assinatura que o compartilhamento de arquivos. Somente uma
assinatura pode ser associada a um locatário do Azure AD. Essa limitação se aplica tanto ao AD DS do Azure
quanto aos métodos de autenticação de AD DS locais. Ao usar AD DS locais para autenticação, a credencial
de AD DS deve ser sincronizada com o Azure ad ao qual a conta de armazenamento está associada.
O Azure AD DS ou a autenticação de AD DS local para compar tilhamentos de arquivos do
Azure dão supor te a VMs do Linux?
Não, não há suporte para autenticação de VMs do Linux.
Os compar tilhamentos de arquivos gerenciados pelo Sincronização de Arquivos do Azure dão
supor te a autenticação do Azure AD DS ou AD DS local (versão prévia)?
Sim, você pode habilitar o Azure AD DS ou a autenticação de AD DS local em um compartilhamento de
arquivos gerenciado pelo Sincronização de Arquivos do Azure. As alterações nas ACLs de NTFS de
diretório/arquivo em servidores de arquivos locais serão enfileiradas em arquivos do Azure e vice-versa.
Como posso verificar se eu habilitei a autenticação AD DS na minha conta de armazenamento
e recupero as informações de domínio?
Para obter instruções, consulte aqui.
Como garantir que o compar tilhamento de arquivos do Azure está criptografado em repouso?
Sim. Para obter mais informações, consulte criptografia do serviço de armazenamento do Azure.
Como posso fornecer acesso a um arquivo específico usando um navegador da Web?
Você pode usar assinaturas de acesso compartilhado para gerar tokens que têm permissões específicas e
que são válidos para um intervalo de tempo especificado. Por exemplo, você pode gerar um token que dá
acesso somente leitura a um arquivo específico para um período de tempo definido. Qualquer pessoa que
tem a URL pode acessar o arquivo diretamente em qualquer navegador da Web enquanto o token é válido.
Você pode gerar uma chave de assinatura de acesso compartilhado facilmente por meio de uma interface
do usuário como o Gerenciador de Armazenamento.
É possível especificar permissões somente leitura ou somente gravação em pastas no
compar tilhamento?
Se você montar o compartilhamento de arquivos via SMB, você não terá controle em nível de pasta sobre
as permissões. No entanto, se você criar uma assinatura de acesso compartilhado usando a API REST ou as
bibliotecas de cliente, você poderá especificar permissões somente leitura ou somente gravação em pastas
contidas no compartilhamento.
Posso implementar restrições de IP para um compar tilhamento de Arquivos do Azure?
Sim. O acesso ao compartilhamento de arquivos do Azure pode ser restringido ao nível de conta de
armazenamento. Para obter mais informações, consulte configurar redes virtuais e firewalls de
A quais políticas de conformidade de dados o ser viço Arquivos do Azure dá supor te?
O Arquivos do Azure é executado com base na mesma arquitetura de armazenamento usada em outros
serviços de armazenamento no Armazenamento do Azure. O Arquivos do Azure aplica as mesmas políticas
de conformidade de dados que são usadas em outros serviços de armazenamento do Azure. Para obter
mais informações sobre a conformidade de dados do Armazenamento do Azure, você pode consultar as
ofertas de conformidade do Armazenamento do Microsoft Azure e ir à Central de Confiabilidade da
Microsoft.
Autenticação do AD
A autenticação do Azure AD do Azure files dá supor te a VMs do Linux?
Não, não há suporte para autenticação de VMs do Linux.
A autenticação de AD DS local para compar tilhamentos de arquivos do Azure dá supor te à
integração com um ambiente de AD DS usando várias florestas?
Os arquivos do Azure local AD DS autenticação se integram apenas à floresta do serviço de domínio em
que a conta de armazenamento está registrada. Para dar suporte à autenticação de outra floresta, seu
ambiente deve ter uma relação de confiança de floresta configurada corretamente. O modo pelo qual os
arquivos do Azure se registram AD DS quase o mesmo que um servidor de arquivos regular, em que ele
cria uma identidade (conta de logon do computador ou serviço) no AD DS para autenticação. A única
diferença é que o SPN registrado da conta de armazenamento termina com "file.core.windows.net", que não
corresponde ao sufixo do domínio. Consulte o administrador de domínio para ver se alguma atualização
para sua política de roteamento DNS é necessária para habilitar a autenticação de várias florestas devido ao
sufixo de domínio diferente.
Quais regiões estão disponíveis para a autenticação de AD DS de arquivos do Azure (versão
prévia)?
Consulte AD DS disponibilidade regional para obter detalhes.
Posso aproveitar a autenticação do AD (Active Director y de arquivos do Azure) (versão
prévia) em compar tilhamentos de arquivos gerenciados pelo Sincronização de Arquivos do
Azure?
Sim, você pode habilitar a autenticação do AD em um compartilhamento de arquivos gerenciado pela
sincronização de arquivos do Azure. As alterações nas ACLs de NTFS de diretório/arquivo em servidores de
arquivos locais serão enfileiradas em arquivos do Azure e vice-versa.
Como posso verificar se eu habilitei a autenticação do AD na minha conta de armazenamento
e as informações de domínio do AD?
Você pode consultar as instruções fornecidas aqui para validar se a autenticação do AD do Azure files está
habilitada em sua conta de armazenamento e recuperar as informações de domínio do AD.
Há alguma diferença na criação de uma conta de computador ou conta de logon de ser viço
para representar minha conta de armazenamento no AD?
Criar uma conta de computador (padrão) ou uma conta de logon de serviço não tem nenhuma diferença
em como a autenticação funcionaria com os arquivos do Azure. Você pode fazer sua própria escolha sobre
como representar uma conta de armazenamento como uma identidade em seu ambiente do AD. O
DomainAccountType padrão definido no cmdlet Join-AzStorageAccountForAuth é a conta de computador.
No entanto, a idade de expiração de senha configurada no seu ambiente do AD pode ser diferente para a
conta de logon do computador ou do serviço e você precisa levar isso em consideração para atualizar a
senha da sua identidade de conta de armazenamento no AD.
Acesso local
Meu ISP ou bloqueia a por ta 445 que está falhando na montagem de arquivos do Azure. O
que devo fazer?
Você pode aprender sobre várias maneiras de solucionar a porta de solução de bloqueio 445 aqui. Os
arquivos do Azure só permitem conexões usando SMB 3,0 (com suporte de criptografia) de fora da região
ou Datacenter. O protocolo SMB 3,0 introduziu muitos recursos de segurança, incluindo a criptografia de
canal, que é muito segura para uso pela Internet. No entanto, é possível que a porta 445 tenha sido
bloqueada devido a motivos históricos de vulnerabilidades encontradas em versões SMB inferiores. No
caso ideal, a porta deve ser bloqueada apenas para o tráfego SMB 1,0 e o SMB 1,0 deve ser desativado em
todos os clientes.
Preciso usar o Azure ExpressRoute para me conectar aos Arquivos do Azure ou para usar a
Sincronização de arquivos do Azure localmente?
Não. O ExpressRoute não é necessário para acessar um compartilhamento de arquivos do Azure. Se você
está montando um compartilhamento de arquivos do Azure diretamente localmente, basta ter a porta 445
(TCP de saída) aberta para acesso à Internet (essa é a porta pela qual o SMB se comunica). Se você está
usando a Sincronização de Arquivos do Azure, basta ter a porta 443 (TCP de saída) para acesso HTTPS (não
é necessário usar SMB). No entanto, você pode usar ExpressRoute com qualquer uma dessas opções de
acesso.
Como posso montar um compar tilhamento de arquivos do Azure no meu computador local?
Você poderá montar o compartilhamento de arquivos por meio do protocolo SMB, desde que a porta 445
(TCP de Saída) esteja aberta e o cliente dê suporte ao protocolo SMB 3.0 (por exemplo, se você estiver
usando o Windows 10 ou o Windows Server 2016). Se a porta 445 está bloqueada pela política da sua
organização ou por pelo ISP, você pode usar a Sincronização de Arquivos do Azure para acessar o
Backup
Como posso fazer backup do meu compar tilhamento de arquivos do Azure?
Você pode usar instantâneos de compartilhamento periódicos para proteção contra exclusões acidentais. Use o
AzCopy, o Robocopy ou uma ferramenta de backup de terceiros que possa fazer backup de um
compartilhamento de arquivos montado. O Backup do Azure oferece backup do Azure Files. Saiba mais sobre
fazer dos compartilhamos de arquivo do Azure pelo Backup do Microsoft Azure.
Instantâneos de compartilhamento
Instantâneos de compartilhamento: geral
O que são os instantâneos de compar tilhamento de arquivo?
Você pode usar os instantâneos de compartilhamento de arquivos do Azure para criar versões somente
leitura de seus compartilhamentos de arquivos. Você também pode usar o serviço Arquivos do Azure para
copiar uma versão anterior do conteúdo para o mesmo compartilhamento ou para um local alternativo no
Azure ou local para modificações adicionais. Para saber mais sobre instantâneos de compartilhamento,
consulte a Visão geral de instantâneos de compartilhamento.
Onde os instantâneos de compar tilhamento são armazenados?
Os instantâneos de compartilhamento são armazenados na mesma conta de armazenamento do
Os instantâneos de compar tilhamento são consistentes com o aplicativo?
Não, os instantâneos de compartilhamento não são consistentes com o aplicativo. O usuário deve liberar as
gravações do aplicativo para o compartilhamento antes de tirar um instantâneo de compartilhamento.
Há limites para o número de instantâneos de compar tilhamento que posso usar?
Sim. O serviço Arquivos do Azure pode armazenar um máximo de 200 instantâneos de compartilhamento.
Os instantâneos de compartilhamento não são considerados na cota de compartilhamento e, portanto, não
há nenhum limite por compartilhamento no espaço total utilizado por todos os instantâneos de
compartilhamento. Os limites de conta de armazenamento ainda se aplicam. Depois de 200 instantâneos
de compartilhamento, os instantâneos mais antigos precisarão ser excluídos para que seja possível criar
novos instantâneos de compartilhamento.
Quanto custam os instantâneos de compar tilhamento?
Transação padrão e custo de armazenamento padrão serão aplicados ao instantâneo. Os instantâneos de
compartilhamento são incrementais por natureza. O instantâneo base é o próprio compartilhamento. Todos
os instantâneos subsequentes são incrementais e armazenam somente a diferença do instantâneo de
anterior. Isso significa que as alterações delta que serão vistas na lista serão mínimas se a variação de carga
de trabalho for mínima. Consulte a Página de preços para obter informações sobre preços os arquivos do
Standard Azure Files. Hoje a forma de olhar o tamanho consumido por compartilhamento de instantâneo é
comparando a capacidade cobrada com capacidade utilizada. Estamos trabalhando em ferramentas para
melhorar a emissão de relatórios.
São as ACLs do NTFS em diretórios e arquivos mantidos em instantâneos de
compar tilhamento?
ACLs do NTFS em diretórios e arquivos são mantidas em instantâneos de compartilhamento.
Criar instantâneos de compartilhamento
Posso criar instantâneo de compar tilhamento de arquivos individuais?
Os instantâneos de compartilhamento são criados no nível do compartilhamento de arquivos. Você pode
restaurar arquivos individuais do instantâneo de compartilhamento de arquivos, mas não é possível criar
instantâneos de compartilhamento no nível do arquivo. No entanto, se você tirou um instantâneo no nível
do compartilhamento e desejar listar instantâneos de compartilhamento em que determinado arquivo foi
alterado, pode fazer isso em Versões Anteriores em um compartilhamento montado no Windows.
Se você precisar de um recurso de instantâneo de arquivo, informe-nos em UserVoice do Arquivos do
Azure.
Posso criar instantâneos de um compar tilhamento de arquivos criptografado?
Você pode tirar um instantâneo de compartilhamento de compartilhamentos de arquivos do Azure que têm
a opção de criptografia em repouso habilitada. Você pode restaurar arquivos de um instantâneo de
compartilhamento em um compartilhamento de arquivos criptografado. Se o compartilhamento for
criptografado, o instantâneo de compartilhamento também será criptografado.
Meus instantâneos de compar tilhamento têm redundância geográfica?
O instantâneo de compartilhamento tem a mesma redundância que o compartilhamento de arquivos do
Azure para o qual ele foi criado. Se você tiver selecionado o armazenamento com redundância geográfica
para sua conta, o instantâneo de compartilhamento também será armazenado de forma redundante na
região emparelhada.
Gerenciar instantâneos de compartilhamento
Posso navegar pelos meus instantâneos de compar tilhamento no Linux?
Você pode usar a CLI do Azure para criar, listar, procurar e restaurar instantâneos de compartilhamento no
Linux.
Posso copiar os instantâneos de compar tilhamento em uma conta de armazenamento
diferente?
Você pode copiar arquivos dos instantâneos de compartilhamento para outro local, mas não pode copiar os
instantâneos compartilhamento propriamente ditos.
Restaurar dados de instantâneos de compartilhamento
Posso promover um instantâneo de compar tilhamento a compar tilhamento base?
Você pode copiar dados de um instantâneo de compartilhamento para qualquer outro destino. Você não
pode promover um instantâneo de compartilhamento para o compartilhamento base.
Posso restaurar dados do meu instantâneo de compar tilhamento em uma conta de
armazenamento diferente?
Sim. Arquivos de um compartilhamento de instantâneo podem ser copiados para o local original ou para
um local alternativo que inclua a mesma conta de armazenamento ou uma conta de armazenamento
diferente, na mesma região ou em regiões diferentes. Você também pode copiar arquivos para uma
localização local ou para qualquer outra nuvem.
Limpar instantâneos de compartilhamento
Posso excluir meu compar tilhamento sem excluir os instantâneos de compar tilhamento?
Se você tiver instantâneos de compartilhamento ativos no compartilhamento, não será possível excluí-lo.
Você pode usar uma API para excluir compartilhamentos de instantâneos, juntamente com o
compartilhamento. Você também pode excluir os instantâneos de compartilhamento e o compartilhamento
no Portal do Azure.
O que acontece com meus instantâneos de compar tilhamento se eu excluo minha conta de
armazenamento?
Se você excluir sua conta de armazenamento, os instantâneos de compartilhamento também serão
excluídos.
Cobrança e preços
O tráfego de rede entre uma VM do Azure e um compar tilhamento de arquivos do Azure
conta como largura de banda externa cobrada na assinatura?
Se o compartilhamento de arquivos e a VM estiverem na mesma região do Azure, não há encargos
adicionais para o tráfego entre o compartilhamento de arquivos e a VM. Se o compartilhamento de
arquivos e a VM estiverem em regiões diferentes, o tráfego entre eles será cobrado como largura de banda
externa.
Quanto custam os instantâneos de compar tilhamento?
Durante a versão prévia, não há nenhum encargo para a capacidade do compartilhamento de instantâneo.
Os custos de saída e de transação do armazenamento Standard se aplicam. Após a disponibilidade geral, as
assinaturas serão cobradas por capacidade e por transações de instantâneos de compartilhamento.
Os instantâneos de compartilhamento são incrementais por natureza. O instantâneo de compartilhamento
base é o próprio compartilhamento. Todos os instantâneos de compartilhamento subsequentes são
incrementais e armazenam somente a diferença do instantâneo de compartilhamento anterior. Você será
cobrado somente pelo conteúdo alterado. Se você tiver um compartilhamento com 100 GiB de dados, mas
apenas 5 GiB foram alterados após o último instantâneo de compartilhamento, este consumirá apenas 5
GiB adicionais e você será cobrado por 105 GiB. Para obter mais informações sobre encargos de transações
e de saída Standard, consulte a Página de preços.
Escala e desempenho
Quais são os limites de escala dos arquivos do Azure?
Para obter informações sobre as metas de escalabilidade e desempenho do Arquivos do Azure, consulte
Metas de escalabilidade e desempenho do Arquivos do Azure.
Quais tamanhos estão disponíveis para compar tilhamentos de arquivos do Azure?
Os tamanhos de compartilhamento de arquivos do Azure (Premium e Standard) podem ser escalados
verticalmente para 100 TiB. Consulte a seção integração a compartilhamentos de arquivos maiores
(camada Standard) do guia de planejamento para obter instruções de integração para os
compartilhamentos de arquivos maiores para a camada Standard.
A expansão da cota de compar tilhamento de arquivos afeta minhas cargas de trabalho ou
Sincronização de Arquivos do Azure?
Não. Expandir a cota não afetará suas cargas de trabalho ou Sincronização de Arquivos do Azure.
Quantos clientes podem acessar o mesmo arquivo simultaneamente?
Há uma cota de 2.000 identificadores abertos em um único arquivo. Quando você tem 2.000
identificadores abertos, uma mensagem de erro é exibida informando que a cota foi atingida.
O desempenho é lento quando eu descompacto arquivos em arquivos do Azure. O que devo
fazer?
Para transferir grandes quantidades de arquivos para o Arquivos do Azure, recomendamos o uso do
AzCopy (para Windows, em versão prévia para Linux e UNIX) ou do Azure PowerShell. Essas ferramentas
foram otimizadas para transferência de rede.
Por que o desempenho está lento após eu montar meu compar tilhamento de arquivos do
Azure no Windows Ser ver 2012 R2 ou no Windows 8.1?
Há um problema conhecido ao montar um compartilhamento de arquivos do Azure no Windows Server
2012 R2 e no Windows 8.1. O problema foi corrigido na atualização cumulativa de abril de 2014 para o
Windows 8.1 e o Windows Server 2012 R2. Para um melhor desempenho, verifique se todas as instâncias
do Windows Server 2012 R2 e do Windows 8.1 têm esse patch aplicado. (Você sempre deve receber
patches do Windows por meio do Windows Update.) Para obter mais informações, consulte o artigo
associado da base de dados de conhecimento Microsoft sobre o desempenho lento ao acessar os arquivos
do Azure do Windows 8.1 ou do Server 2012 R2.
Recursos e interoperabilidade com outros serviços

É possível usar o compar tilhamento de arquivos do Azure como uma Testemunha de
Compar tilhamento de Arquivos para o Cluster de Failover do Windows Ser ver?
Atualmente, em um compartilhamento de arquivos do Azure, não há suporte para essa configuração. Para
saber mais sobre como configurar isso para o Armazenamento de Blobs do Azure, confira Implantar uma
testemunha de nuvem em um cluster de failover.
Posso montar um compar tilhamento de arquivos do Azure em uma instância de Contêiner do
Azure?
Sim, os compartilhamentos de arquivos do Azure são uma opção fantástica para manter informações além
do tempo de vida de uma instância de contêiner. Para obter mais informações, consulte Montar um
compartilhamento de arquivos do Azure com Instâncias de Contêiner do Azure.
Há uma operação de renomeação na API REST?
Não no momento.
Posso configurar compar tilhamentos aninhados? Em outras palavras, um compar tilhamento
em um compar tilhamento?
Não. O compartilhamento de arquivos é o driver virtual que você pode montar; portanto, não há suporte
para compartilhamentos aninhados.
Como posso usar os Arquivos do Azure com o IBM MQ?
A IBM liberou um documento que ajuda clientes do IBM MQ a configurar o Arquivos do Azure juntamente
com o serviço IBM. Para obter mais informações, consulte Como configurar o gerenciador de filas com
várias instâncias do IBM MQ com o serviço Arquivos do Microsoft Azure.
Consulte também
Solucionar problemas do Arquivos do Azure no Windows
Solucionar problemas do Arquivos do Azure no Linux
Para criar um compartilhamento de arquivos do Azure, você precisa responder a três perguntas sobre como
você irá usá-lo:
Quais são os requisitos de desempenho para o compar tilhamento de arquivos do Azure?
Os arquivos do Azure oferecem compartilhamentos de arquivos padrão, que são hospedados em
hardware com base em disco rígido (baseado em HDD) e compartilhamentos de arquivos premium,
que são hospedados em hardware baseado em disco de estado sólido (baseado em SSD).
De que tamanho o compar tilhamento de arquivos você precisa?
Os compartilhamentos de arquivos padrão podem abranger até 100 TiB, no entanto, esse recurso não
está habilitado por padrão; Se você precisar de um compartilhamento de arquivos com mais de 5 TiB,
será necessário habilitar o recurso de compartilhamento de arquivos grandes para sua conta de
armazenamento. Os compartilhamentos de arquivos Premium podem abranger até 100 TiB sem
nenhuma configuração especial, no entanto, os compartilhamentos de arquivos Premium são
provisionados, em vez de pagar conforme o uso de compartilhamentos de arquivos padrão. Isso
significa que o provisionamento de um compartilhamento de arquivos muito maior do que o
necessário aumentará o custo total de armazenamento.
Quais são seus requisitos de redundância para o compar tilhamento de arquivos do Azure?
Compartilhamentos de arquivos padrão oferecem armazenamento com redundância local (LRS), com
redundância de zona (ZRS), com redundância geográfica (GRS) ou com redundância de zona
geográfica (GZRS), no entanto, o recurso de compartilhamento de arquivo grande tem suporte apenas
em compartilhamentos de arquivos com redundância local e com redundância de zona. Os
compartilhamentos de arquivos Premium não dão suporte a qualquer forma de redundância
geográfica.
Os compartilhamentos de arquivos premium estão disponíveis com redundância local na maioria das
regiões que oferecem contas de armazenamento e com redundância de zona em um subconjunto
menor de regiões. Para descobrir se os compartilhamentos de arquivos premium estão disponíveis
atualmente em sua região, confira a página produtos disponíveis por região para o Azure. Para obter
informações sobre regiões que dão suporte a ZRS, consulte redundância de armazenamento do Azure.
Para obter mais informações sobre essas três opções, consulte planejando uma implantação de arquivos do
Azure.
Pré-requisitos
Este artigo pressupõe que você já criou uma assinatura do Azure. Se você ainda não tiver uma assinatura,
crie uma conta gratuita antes de começar.
Se você pretende usar Azure PowerShell, Instale a versão mais recente.
Se você pretende usar o CLI do Azure, Instale a versão mais recente.

Os compartilhamentos de arquivos do Azure são implantados em contas de armazenamento, que são objetos
de nível superior que representam um pool de armazenamento compartilhado. Esse pool de armazenamento
pode ser usado para implantar vários compartilhamentos de arquivos.
O Azure dá suporte a vários tipos de contas de armazenamento para diferentes cenários de armazenamento
que os clientes podem ter, mas há dois tipos principais de contas de armazenamento para arquivos do Azure.
O tipo de conta de armazenamento que você precisa criar depende se você deseja criar um
compartilhamento de arquivos padrão ou um compartilhamento de arquivos Premium:
Contas de armazenamento de uso geral versão 2 (GPv2) : as contas de armazenamento do
GPv2 permitem que você implante compartilhamentos de arquivos do Azure em hardware
padrão/baseado em disco rígido (baseado em HDD). Além de armazenar compartilhamentos de
arquivos do Azure, as contas de armazenamento GPv2 podem armazenar outros recursos de
armazenamento, como contêineres de BLOB, filas ou tabelas.
hardware Premium/de estado sólido baseado em disco (SSD). Contas de armazenamento de arquivo
só podem ser usadas para armazenar compartilhamentos de arquivos do Azure; nenhum outro
recurso de armazenamento (contêineres de BLOB, filas, tabelas, etc.) pode ser implantado em uma
conta de armazenamento de File.
Portal
PowerShell
CLI do Azure
Para criar uma conta de armazenamento por meio do portal do Azure, selecione + criar um recurso no
painel. Na janela de pesquisa resultante do Azure Marketplace, procure conta de armazenamento e
selecione o resultado da pesquisa resultante. Isso levará a uma página de visão geral para contas de
armazenamento; Selecione criar para continuar com o assistente de criação de conta de armazenamento.
A seção noções básicas

A primeira seção a ser concluída para criar uma conta de armazenamento é rotulada noções básicas . Isso
contém todos os campos obrigatórios para criar uma conta de armazenamento. Para criar uma conta de
armazenamento GPv2, verifique se o botão de opção desempenho está definido como padrão e se a lista
suspensa tipo de conta está selecionada para StorageV2 (uso geral v2).
Para criar uma conta de armazenamento do FileStorage, verifique se o botão de opção desempenho está
definido como Premium e se a lista suspensa tipo de conta está selecionada para armazenamentoem File.
Os outros campos básicos são independentes da escolha da conta de armazenamento:

Assinatura : a assinatura da conta de armazenamento a ser implantada.
Grupo de recursos : o grupo de recursos para a conta de armazenamento a ser implantada. Você pode
criar um novo grupo de recursos ou usar um grupo de recursos existente. Um grupo de recursos é um
contêiner lógico para agrupar seus serviços do Azure. Quando você cria uma conta de armazenamento,
tem a opção de criar um novo grupo de recursos ou usar um grupo de recursos existente.
Nome da conta de armazenamento : o nome do recurso da conta de armazenamento a ser criado. Esse
nome deve ser globalmente exclusivo, mas, caso contrário, pode ser qualquer nome desejado. O nome da
conta de armazenamento será usado como o nome do servidor quando você montar um
compartilhamento de arquivos do Azure via SMB.
Local : a região da conta de armazenamento a ser implantada. Isso pode ser a região associada ao grupo
de recursos ou qualquer outra região disponível.
Replicação : embora isso seja rotulado como replicação, esse campo significa, na verdade, redundância ;
Este é o nível de redundância desejado: redundância local (LRS), redundância de zona (ZRS), redundância
geográfica (GRS) e redundância de zona geográfica. Essa lista suspensa também contém a redundância
geográfica com acesso de leitura (RA-GRS) e a redundância de zona geográfica com acesso de leitura (RA-
GZRS), que não se aplica aos compartilhamentos de arquivos do Azure; qualquer compartilhamento de
arquivos criado em uma conta de armazenamento com esses selecionados será, na verdade, com
redundância geográfica ou com redundância de zona geográfica, respectivamente. Dependendo de sua
região ou tipo de conta de armazenamento selecionado, algumas opções de redundância podem não ser
permitidas.
Camada de acesso : esse campo não se aplica aos arquivos do Azure, portanto, você pode escolher um
dos botões de opção.
A folha rede
A seção rede permite que você configure as opções de rede. Essas configurações são opcionais para a criação
da conta de armazenamento e podem ser configuradas posteriormente, se desejado. Para obter mais
informações sobre essas opções, consulte considerações de rede de arquivos do Azure.
A folha avançado
A seção avançado contém várias configurações importantes para compartilhamentos de arquivos do Azure:
Transferência segura necessária : Este campo indica se a conta de armazenamento requer criptografia
em trânsito para comunicação com a conta de armazenamento. É recomendável que isso seja deixado
habilitado. no entanto, se você precisar de suporte a SMB 2,1, você deve desabilitar isso. Recomendamos
se você desabilitar a criptografia para restringir o acesso de sua conta de armazenamento a uma rede
virtual com pontos de extremidade de serviço e/ou pontos de extremidade privados.
Compar tilhamentos de arquivos grandes : esse campo habilita a conta de armazenamento para
compartilhamentos de arquivos que abrangem até 100 Tib. Habilitar esse recurso limitará sua conta de
armazenamento somente a opções de armazenamento com redundância local e com redundância de
zona. Depois que uma conta de armazenamento GPv2 tiver sido habilitada para grandes
compartilhamentos de arquivos, você não poderá desabilitar o recurso de compartilhamento de arquivo
grande. Contas de armazenamento de armazenamento de arquivo (contas de armazenamento para
compartilhamentos de arquivos Premium) não têm essa opção, pois todos os compartilhamentos de
arquivos Premium podem ser escalados verticalmente para 100 TiB.
As outras configurações disponíveis na guia Avançado (exclusão reversível de BLOB, namespace hierárquico
para Azure Data Lake armazenamento Gen 2 e NFSv3 para armazenamento de BLOB) não se aplicam aos
arquivos do Azure.
Marcas
As marcas são pares de nome/valor que permitem categorizar recursos e exibir a cobrança consolidada
aplicando a mesma marca a vários recursos e grupos de recursos. Eles são opcionais e podem ser aplicados
após a criação da conta de armazenamento.
Examinar + criar
A etapa final para criar a conta de armazenamento é selecionar o botão criar na guia revisar + criar . Esse
botão não estará disponível se todos os campos obrigatórios para uma conta de armazenamento não
estiverem preenchidos.
Criar o compartilhamento de arquivos

Depois de criar sua conta de armazenamento, tudo o que resta é criar o compartilhamento de arquivos. Esse
processo é praticamente o mesmo, independentemente de você estar usando um compartilhamento de
arquivos Premium ou um compartilhamento de arquivos padrão. A principal diferença é a cota e o que ela
representa.
Para compartilhamentos de arquivos padrão, ele é um limite superior do compartilhamento de arquivos do
Azure, além do qual os usuários finais não podem ir. O objetivo principal da cota de um compartilhamento de
arquivos padrão é o orçamentário: "não quero que esse compartilhamento de arquivos cresça além desse
ponto". Se uma cota não for especificada, o compartilhamento de arquivos padrão poderá abranger até 100
TiB (ou 5 TiB se a propriedade compartilhamentos de arquivos grandes não estiver definida para uma conta
de armazenamento).
Para compartilhamentos de arquivos premium, a cota é sobrecarregada para significar o tamanho
provisionado . O tamanho provisionado é o valor para o qual você será cobrado, independentemente do uso
real. Ao provisionar um compartilhamento de arquivos premium, você deve considerar dois fatores: 1) o
crescimento futuro do compartilhamento de uma perspectiva de utilização de espaço e 2) o IOPS necessário
para sua carga de trabalho. Cada GiB provisionada lhe dá direito a IOPS reservada e de intermitência
adicional. Para obter mais informações sobre como planejar um compartilhamento de arquivos premium,
consulte Provisionando compartilhamentos de arquivos Premium.
Portal
PowerShell
CLI do Azure
Se você acabou de criar sua conta de armazenamento, poderá navegar até ela na tela de implantação
selecionando ir para o recurso . Se você já tiver criado a conta de armazenamento, poderá navegar para ela
por meio do grupo de recursos que a contém. Uma vez na conta de armazenamento, selecione o bloco
rotulado compar tilhamentos de arquivos (você também pode navegar até compar tilhamentos de
arquivos por meio do Sumário da conta de armazenamento).
Na listagem compartilhamento de arquivos, você deve ver os compartilhamentos de arquivos criados

anteriormente nesta conta de armazenamento; uma tabela vazia se nenhum compartilhamento de arquivos
tiver sido criado ainda. Selecione + compar tilhamento de arquivos para criar um novo compartilhamento
de arquivos.
A folha novo compartilhamento de arquivos deve aparecer na tela. Preencha os campos na folha novo
compartilhamento de arquivos para criar um compartilhamento de arquivos:
Nome : o nome do compartilhamento de arquivos a ser criado.
Cota : a cota do compartilhamento de arquivos para compartilhamentos de arquivos padrão; o tamanho
provisionado do compartilhamento de arquivos para compartilhamentos de arquivos premium.
Selecione criar para concluir a criação do novo compartilhamento. Observe que se sua conta de
armazenamento estiver em uma rede virtual, você não poderá criar com êxito um compartilhamento de
arquivos do Azure, a menos que o cliente também esteja na rede virtual. Você também pode contornar essa
limitação pontual usando o cmdlet Azure PowerShell New-AzRmStorageShare .
NOTE
O nome do seu compartilhamento de arquivo deve estar em minúsculas. Para obter detalhes completos sobre como
nomear arquivos e compartilhamentos de arquivos, consulte nomenclatura e referência de compartilhamentos,
diretórios, arquivos e metadados.
Próximas etapas
Planeje uma implantação de arquivos do Azure ou planeje uma implantação de sincronização de arquivos
do Azure.
Visão geral da rede.
Conecte e monte um compartilhamento de arquivos no Windows, no MacOSe no Linux.
Habilitar e criar compartilhamentos de arquivos
grandes
Quando você habilita grandes compartilhamentos de arquivos em sua conta de armazenamento, seus
compartilhamentos de arquivos podem ser escalados verticalmente até 100 TiB. Você pode habilitar esse
dimensionamento em suas contas de armazenamento existentes para seus compartilhamentos de arquivos
existentes.
Pré-requisitos
Se você pretende usar o CLI do Azure, Instale a versão mais recente.
Se você pretende usar Azure PowerShell, Instale a versão mais recente.
Restrições
Por enquanto, você só pode usar LRS (armazenamento com redundância local) ou ZRS (armazenamento com
redundância de zona) em contas habilitadas para compartilhamento de arquivos grandes. Você não pode usar
armazenamento com redundância de zona geográfica (GZRS), armazenamento com redundância geográfica
(GRS), armazenamento com redundância geográfica com acesso de leitura (RA-GRS) ou armazenamento com
redundância de acesso de leitura (RA-GZRS).
A habilitação de grandes compartilhamentos de arquivos em uma conta é um processo irreversível. Depois de
habilitá-lo, você não conseguirá converter sua conta em GZRS, GRS, RA-GRS ou RA-GZRS.
Criar uma nova conta de armazenamento

Portal
1. Entre no portal do Azure.
2. Na portal do Azure, selecione todos os ser viços .
3. Na lista de recursos, insira contas de armazenamento . A lista filtra com base em sua entrada, à medida
que você digita. Selecione contas de armazenamento .
4. Na janela contas de armazenamento que aparece, selecione Adicionar .
5. Selecione a assinatura que você usará para criar a conta de armazenamento.
6. No campo Grupo de recursos , selecione Criar novo . Insira um nome para o novo grupo de recursos.
7. Em seguida, insira um nome para sua conta de armazenamento. O nome deve ser exclusivo em todo o
Azure. O nome também deve ter de 3 a 24 caracteres de comprimento e só pode ter números e letras
minúsculas.
8. Selecione um local para sua conta de armazenamento.
9. Defina a replicação para armazenamento com redundância local ou armazenamento com
redundância de zona .
10. Deixe esses campos com seus valores padrão:
CAMPO VA LO R
Desempenho Standard
11. Selecione avançado e, em seguida, selecione o botão de opção habilitado à direita de grandes
compar tilhamentos de arquivos .
CLI
Primeiro, Instale a versão mais recente do CLI do Azure para que você possa habilitar grandes
compartilhamentos de arquivos.
Para criar uma conta de armazenamento com grandes compartilhamentos de arquivos habilitados, use o
comando a seguir. Substitua <yourStorageAccountName> , <yourResourceGroup> e <yourDesiredRegion> pelas suas
informações.
## This command creates a large file share–enabled account. It will not support GZRS, GRS, RA-GRS, or RA-
GZRS.
az storage account create --name <yourStorageAccountName> -g <yourResourceGroup> -l <yourDesiredRegion> --
sku Standard_LRS --kind StorageV2 --enable-large-file-share
PowerShell
Primeiro, Instale a versão mais recente do PowerShell para que você possa habilitar compartilhamentos de
arquivos grandes.
Para criar uma conta de armazenamento com grandes compartilhamentos de arquivos habilitados, use o
comando a seguir. Substitua <yourStorageAccountName> , <yourResourceGroup> e <yourDesiredRegion> pelas suas
informações.
## This command creates a large file share–enabled account. It will not support GZRS, GRS, RA-GRS, or RA-
GZRS.
New-AzStorageAccount -ResourceGroupName <yourResourceGroup> -Name <yourStorageAccountName> -Location
<yourDesiredRegion> -SkuName Standard_LRS -EnableLargeFileShare;
Habilitar compartilhamentos de arquivos grandes em uma conta

existente
Você também pode habilitar compartilhamentos de arquivos grandes em suas contas existentes. Se você
habilitar grandes compartilhamentos de arquivos, não será possível converter em GZRS, GRS, RA-GRS ou RA-
GZRS. A habilitação de grandes compartilhamentos de arquivos é irreversível nessa conta de armazenamento.
Portal
1. Abra o portal do Azuree vá para a conta de armazenamento onde você deseja habilitar grandes
compartilhamentos de arquivos.
2. Abra a conta de armazenamento e selecione configuração .
3. Selecione habilitado em compar tilhamentos de arquivos grandes e, em seguida, selecione salvar .
4. Selecione visão geral e selecione Atualizar .
Agora você habilitou grandes compartilhamentos de arquivos em sua conta de armazenamento. Em seguida,
você deve atualizar a cota do compartilhamento existente para tirar proveito da maior capacidade e escala.
Se você receber a mensagem de erro "grandes compartilhamentos de arquivos não estão disponíveis para a
conta ainda", sua região poderá estar no meio da conclusão de sua distribuição. Entre em contato com o suporte
se você tiver uma necessidade urgente de grandes compartilhamentos de arquivos.
CLI
Para habilitar grandes compartilhamentos de arquivos em sua conta existente, use o comando a seguir. Substitua
<yourStorageAccountName> e <yourResourceGroup> por suas informações.
az storage account update --name <yourStorageAccountName> -g <yourResourceGroup> --enable-large-file-share
PowerShell
Para habilitar grandes compartilhamentos de arquivos em sua conta existente, use o comando a seguir. Substitua
<yourStorageAccountName> e <yourResourceGroup> por suas informações.
Set-AzStorageAccount -ResourceGroupName <yourResourceGroup> -Name <yourStorageAccountName> -

EnableLargeFileShare
Criar um compartilhamento de arquivos grande
Depois de habilitar grandes compartilhamentos de arquivos em sua conta de armazenamento, você poderá criar
compartilhamentos de arquivos nessa conta com cotas maiores.
Portal
A criação de um compartilhamento de arquivos grande é quase idêntica à criação de um compartilhamento de
arquivos padrão. A principal diferença é que você pode definir uma cota de até 100 TiB.
1. Em sua conta de armazenamento, selecione compar tilhamentos de arquivos .
2. Selecione + compar tilhamento de arquivos .
3. Insira um nome para o compartilhamento de arquivos. Você também pode definir o tamanho da cota que
deseja, até 100 TiB. Em seguida, selecione Criar .
CLI
Para criar um compartilhamento de arquivos grande, use o comando a seguir. Substitua
<yourStorageAccountName> , <yourStorageAccountKey> e <yourFileShareName> pelas suas informações.
az storage share create --account-name <yourStorageAccountName> --account-key <yourStorageAccountKey> --name

<yourFileShareName>
PowerShell
Para criar um compartilhamento de arquivos grande, use o comando a seguir. Substitua
<YourStorageAccountName> , <YourStorageAccountKey> e <YourStorageAccountFileShareName> pelas suas
informações.
##Config
$storageAccountName = "<YourStorageAccountName>"
$storageAccountKey = "<YourStorageAccountKey>"
$shareName="<YourStorageAccountFileShareName>"
$ctx = New-AzStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $storageAccountKey
New-AzStorageShare -Name $shareName -Context $ctx
Expandir compartilhamentos de arquivos existentes

Depois de habilitar grandes compartilhamentos de arquivos em sua conta de armazenamento, você também
pode expandir os compartilhamentos de arquivos existentes nessa conta para a cota mais alta.
Portal
1. Em sua conta de armazenamento, selecione compar tilhamentos de arquivos .
2. Clique com o botão direito do mouse no compartilhamento de arquivos e selecione cota .
3. Insira o novo tamanho desejado e selecione OK .
CLI
Para definir a cota para o tamanho máximo, use o comando a seguir. Substitua <yourStorageAccountName> ,
<yourStorageAccountKey> e <yourFileShareName> pelas suas informações.
az storage share update --account-name <yourStorageAccountName> --account-key <yourStorageAccountKey> --name

<yourFileShareName> --quota 102400
PowerShell
Para definir a cota para o tamanho máximo, use o comando a seguir. Substitua <YourStorageAccountName> ,
<YourStorageAccountKey> e <YourStorageAccountFileShareName> pelas suas informações.
##Config
$storageAccountName = "<YourStorageAccountName>"
$storageAccountKey = "<YourStorageAccountKey>"
$shareName="<YourStorageAccountFileShareName>"
$ctx = New-AzStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $storageAccountKey
# update quota
Set-AzStorageShareQuota -ShareName $shareName -Context $ctx -Quota 102400
Próximas etapas
Conectar e montar um compartilhamento de arquivos no Windows
Conectar e montar um compartilhamento de arquivos no Linux
Conectar e montar um compartilhamento de arquivos no macOS
Como criar um compartilhamento de arquivos
premium do Azure
Os compartilhamentos de arquivos Premium são oferecidos na mídia de armazenamento de SSD (disco de estado
sólido) e são úteis para cargas de trabalho com uso intensivo de e/s, incluindo bancos de dados de hospedagem e
HPC (computação de alto desempenho). Os compartilhamentos de arquivos Premium são hospedados em um tipo
de conta de armazenamento de finalidade especial, chamado de conta de armazenamento de arquivo. Os
compartilhamentos de arquivos Premium são projetados para aplicativos de alto desempenho e escala
empresarial, fornecendo compartilhamentos de baixa latência, IOPS e alta taxa de transferência consistentes.
Este artigo mostra como criar esse novo tipo de conta usando portal do Azure, Azure PowerShell e CLI do Azure.
Pré-requisitos
Para acessar os recursos do Azure, incluindo compartilhamentos de arquivos premium do Azure, você precisará de
uma assinatura do Azure. Se você ainda não tiver uma assinatura, crie uma conta gratuita antes de começar.
Criar um compartilhamento de arquivos Premium usando o portal do

Azure
Entrar no Azure
Criar uma conta de armazenamento do FileStorage
Agora você está pronto para criar sua conta de armazenamento.
Cada conta de armazenamento deve pertencer a um grupo de recursos do Azure. Um grupo de recursos é um
contêiner lógico para agrupar seus serviços do Azure. Quando você cria uma conta de armazenamento, tem a
opção de criar um novo grupo de recursos ou usar um grupo de recursos existente. Este artigo mostra como criar
um novo grupo de recursos.
1. No portal do Azure, selecione contas de armazenamento no menu à esquerda.
7. Para desempenho , selecione Premium .
8. Selecione tipo de conta e escolha FileStorage .
9. Deixe a replicação definida com seu valor padrão de armazenamento com REDUNDÂNCIA local
(LRS) .
Depois que o recurso da conta de armazenamento tiver sido criado, navegue até ele.
1. No menu à esquerda da conta de armazenamento, role até a seção ser viço de arquivo e selecione arquivos .
2. Selecione compar tilhamento de arquivos para criar um compartilhamento de arquivos premium.
3. Insira um nome e uma cota desejada para o compartilhamento de arquivos e, em seguida, selecione criar .
NOTE
Os tamanhos de compartilhamento provisionados são especificados pela cota de compartilhamento, os compartilhamentos
de arquivos são cobrados no tamanho provisionado, consulte a página de preços para obter mais detalhes.
Limpar os recursos
Se você quiser limpar os recursos criados neste artigo, bastará excluir o grupo de recursos. Excluir o grupo de
recursos também exclui a conta de armazenamento associada, bem como quaisquer outros recursos associados ao
grupo de recursos.
Criar um compartilhamento de arquivos Premium usando o PowerShell

Criar uma conta usando o PowerShell
Primeiro, instale a última versão do módulo PowerShellGet do PowerShell.
Em seguida, atualize seu módulo do PowerShell, entre na sua assinatura do Azure, crie um grupo de recursos e, em
seguida, crie uma conta de armazenamento.
Atualizar seu módulo do PowerShell
Para interagir com um compartilhamento de arquivos premium do com o PowerShell, você precisará instalar um
módulo AZ. Storage versão 1.4.0 ou o módulo AZ. Storage mais recente.
Comece abrindo uma sessão do PowerShell com permissões elevadas.
Instale o módulo AZ. Storage:
Install-Module Az.Storage -Repository PSGallery -AllowClobber -Force
Entre em sua Assinatura do Azure

Use o comando Connect-AzAccount e siga as instruções na tela para fazer a autenticação.
Connect-AzAccount

Para criar um novo grupo de recursos com o PowerShell, use o comando New-AzResourceGroup:
# put resource group in a variable so you can use the same group name going forward,
# without hardcoding it repeatedly
$resourceGroup = "storage-how-to-resource-group"
$location = "westus2"
New-AzResourceGroup -Name $resourceGroup -Location $location

Para criar uma conta de armazenamento do FileStorage do PowerShell, use o comando New-AzStorageAccount :
$storageAcct = New-AzStorageAccount -ResourceGroupName $resourceGroup -Name "fileshowto" -SkuName

"Premium_LRS" -Location "westus2" -Kind "FileStorage"

Agora que você tem uma conta de armazenamento de arquivo, é possível criar um compartilhamento de arquivos
premium. Use o cmdlet New-AzStorageShare para criar um.
NOTE
New-AzStorageShare `
-Name myshare `
-Context $storageAcct.Context
Limpar os recursos
Para remover o grupo de recursos e seus recursos associados, incluindo a nova conta de armazenamento, use o
comando Remove-AzResourceGroup:
Remove-AzResourceGroup -Name $resourceGroup
Criar um compartilhamento de arquivos Premium usando CLI do Azure

Para iniciar o Azure Cloud Shell, entre no portal do Azure.
Se você quiser fazer logon em sua instalação local da CLI, primeiro verifique se você tem a versão mais recente e
execute o comando de logon:
az login

Para criar um novo grupo de recursos com a CLI do Azure, use o comando az group create.
az group create `
--name files-howto-resource-group `
--location westus2

Para criar uma conta de armazenamento do FileStorage a partir da CLI do Azure, use o comando AZ Storage
Account Create .
az storage account create `

--name fileshowto `
--resource-group files-howto-resource-group `
--location westus `
--sku Premium_LRS `
--kind FileStorage
Obter a chave da conta de armazenamento

As chaves da conta de armazenamento controlam o acesso a recursos em uma conta de armazenamento, neste
artigo, usamos a chave para criar um compartilhamento de arquivos premium. As chaves são criadas
automaticamente quando você cria uma conta de armazenamento. Você pode obter as chaves da conta de
armazenamento usando o comando az storage account keys list:
STORAGEKEY=$(az storage account keys list \

--resource-group "myResourceGroup" \
--account-name $STORAGEACCT \

Agora que você tem uma conta de armazenamento de arquivo, é possível criar um compartilhamento de arquivos
premium. Use o comando AZ Storage share Create para criar um.
NOTE

--account-name $STORAGEACCT \
--account-key $STORAGEKEY \
--name "myshare"
Limpar os recursos
Para remover o grupo de recursos e seus recursos associados, incluindo a nova conta de armazenamento, use o
comando az group delete.
az group delete --name myResourceGroup
Próximas etapas
Neste artigo, você criou um compartilhamento de arquivos premium. Para saber mais sobre o desempenho
oferecido por essa conta, continue na seção nível de desempenho do guia de planejamento.
Camadas de compartilhamento de arquivos
Como implantar Arquivos do Azure
O Arquivos do Azure oferece compartilhamentos de arquivos totalmente gerenciados na nuvem, acessíveis por
meio do protocolo SMB padrão no setor. Este artigo mostra como implantar Arquivos do Azure de maneira
prática dentro de sua organização.
É altamente recomendável ler Planejando uma implantação de Arquivos do Azure antes de seguir as etapas neste
artigo.
Pré-requisitos
Este artigo pressupõe que você tenha completado as seguintes etapas:
Criado uma conta de Armazenamento do Azure com as opções de resiliência e de criptografia desejadas, na
região desejada. Para orientações passo a passo sobre como criar uma conta de armazenamento, consulte
Criar uma conta de armazenamento.
Criado um compartilhamento de arquivos do Azure com sua cota desejada na sua conta de armazenamento.
Consulte Criar um compartilhamento de arquivos para obter instruções passo a passo sobre como criar um
Transferir dados para Arquivos do Azure

Talvez você queira migrar compartilhamentos de arquivos existentes, tais como aqueles armazenados localmente,
para o novo compartilhamento de Arquivos do Azure. Esta seção mostrará como mover dados para um
compartilhamento de arquivos do Azure por meio de vários métodos populares detalhados no Guia de
planejamento
A Sincronização de Arquivos do Azure permite que você centralize os compartilhamentos de arquivos da sua
organização em Arquivos do Azure sem abrir mão da flexibilidade, do desempenho e da compatibilidade de um
servidor de arquivos local. Ele faz isso transformando Windows Servers em um cache rápido do seu
compartilhamento de Arquivos do Azure. Você pode usar qualquer protocolo disponível no Windows Server para
acessar seus dados localmente (incluindo SMB, NFS e FTPS) e pode ter todos os caches de que precisar ao redor
do mundo.
A Sincronização de Arquivos do Azure pode ser usada para migrar dados para um compartilhamento de Arquivos
do Azure, mesmo que o mecanismo de sincronização não seja desejável para uso de longo prazo. Mais
informações sobre como usar a Sincronização de Arquivos do Azure para transferir dados em um
compartilhamento de arquivos do Azure podem ser encontradas em Planejando uma implantação da
Sincronização de Arquivos do Azure e Como implantar a Sincronização de Arquivos do Azure.
Importação/Exportação do Azure
O serviço de importação/exportação do Azure permite a transferência de grandes quantidades de dados com
segurança em um compartilhamento de arquivos do Azure pelo envio de discos rígidos para um datacenter do
Azure. Consulte Usar o serviço de Importação/Exportação do Microsoft Azure para transferir dados para o
Armazenamento do Azure para obter uma visão geral mais detalhada do serviço.
NOTE
O serviço de Importação/Exportação do Azure não dá suporte à exportação de arquivos de um compartilhamento de
Arquivos do Azure no momento.
As etapas a seguir importarão dados de uma localização local para o compartilhamento de Arquivos do Azure.
1. Adquira o número necessário de discos rígidos para email no Azure. Os discos rígidos podem ter qualquer
capacidade, mas devem ser um SSD ou HD de 2,5" ou 3,5", com suporte ao padrão SATA II ou SATA III.
2. Conecte-se e monte cada disco no servidor/PC realizando a transferência de dados. Para otimizar o
desempenho, é recomendável que o trabalho de exportação local seja executado localmente no servidor
que contém os dados. Em alguns casos, assim como quando o servidor de arquivos que serve os dados é
um dispositivo NAS, isso pode não ser possível. Nesse caso, é perfeitamente aceitável montar cada disco
em um computador.
3. Verifique se cada unidade está online, inicializada e com uma letra da unidade atribuída a ela. Para colocar
uma unidade online, inicializá-la e atribuir uma letra da unidade a ela, abra o snap-in do MMC de
gerenciamento de disco (diskmgmt.msc).
Para colocar um disco online (se ainda não estiver online), clique com o botão direito do mouse no
disco no painel inferior do MMC de Gerenciamento de Disco e selecione "Online".
Para inicializar um disco, clique com o botão direito do mouse no disco no painel inferior (depois
que o disco estiver online) e selecione "Inicializar". Quando solicitado, verifique se a opção "GPT" foi
selecionada.
Para atribuir uma letra da unidade ao disco, clique com o botão direito do mouse no espaço "não
alocado" do disco online e inicializado e clique em "Novo Volume Simples". Isso permitirá que você
atribua a letra da unidade. Observe que não é necessário formatar o volume, já que isso será feito
mais tarde.
4. Crie o arquivo CSV de conjunto de dados. O arquivo CSV de conjunto de dados é um mapeamento entre o
caminho para os dados locais e o compartilhamento de Arquivos do Azure desejado para o qual os dados
devem ser copiados. Por exemplo, o arquivo CSV de conjunto de dados a seguir mapeia um
compartilhamento de arquivos local ("F:\shares\scratch") para um compartilhamento de Arquivos do
Azure ("MyAzureFileShare"):
BasePath,DstItemPathOrPrefix,ItemType,Disposition,MetadataFile,PropertiesFile
"F:\shares\scratch\","MyAzureFileShare/",file,rename,"None",None
Vários compartilhamentos com uma conta de armazenamento podem ser especificados. Consulte Preparar
o arquivo CSV de conjunto de dados para obter mais informações.
5. Crie o arquivo CSV de conjunto de unidades. O arquivo CSV de conjunto de unidades lista os discos
disponíveis para o agente de exportação local. Por exemplo, o arquivo CSV de conjunto de unidades a
seguir lista as unidades X: , Y: e Z: para serem usadas no trabalho de exportação local:
DriveLetter,FormatOption,SilentOrPromptOnFormat,Encryption,ExistingBitLockerKey
X,Format,SilentMode,Encrypt,
Y,Format,SilentMode,Encrypt,
Z,Format,SilentMode,Encrypt,
Consulte Preparar o arquivo CSV de conjunto de unidades para obter mais informações.
6. Use a ferramenta WAImportExport para copiar seus dados para um ou mais discos rígidos.
WAImportExport.exe PrepImport /j:<JournalFile> /id:<SessionId> [/logdir:<LogDirectory>] [/sk:

<StorageAccountKey>] [/silentmode] [/InitialDriveSet:<driveset.csv>] DataSet:<dataset.csv>
WARNING
Não modifique os dados em unidades de disco rígido ou o arquivo de diário depois de concluir a preparação do
disco.
7. Crie um trabalho de importação.

Robocopy
Robocopy é uma ferramenta de cópia bem conhecida que é fornecida com o Windows e o Windows Server.
Robocopy pode ser usado para transferir dados para arquivos do Azure montando o compartilhamento de
arquivos localmente e, em seguida, usando a localização montada como o destino no comando Robocopy. Usar o
Robocopy é bastante simples:
1. Monte o compartilhamento de arquivos do Azure. Para otimizar o desempenho, é recomendável a
montagem do compartilhamento de arquivos do Azure localmente no servidor que contém os dados. Em
alguns casos, assim como quando o servidor de arquivos que serve os dados é um dispositivo NAS, isso
pode não ser possível. Nesse caso, é perfeitamente aceitável para montar o compartilhamento de arquivos
do Azure em um PC. Neste exemplo, net use é usado na linha de comando para montar o
compartilhamento de arquivos:
net use <desired-drive-letter>: \\<storage-account-name>.file.core.windows.net\<share-name> <storage-

account-key> /user:Azure\<storage-account-name>
2. Use robocopy na linha de comando para mover dados para o Azure file Sync - Sincronização de arquivos
do Azure:
robocopy <path-to-local-share> <path-to-azure-file-share> /E /Z /MT:32
O Robocopy tem um número significativo de opções para modificar o comportamento de cópia conforme
desejado. Para obter mais informações, exiba a página de manual do Robocopy.
AzCopy
O AzCopy é um utilitário de linha de comando projetado para copiar dados de e para os Arquivos do Azure e o
Armazenamento de Blobs do Azure, usando comandos simples com o desempenho ideal. É fácil usar o AzCopy:
1. Baixe a versão mais recente do AzCopy no Windows ou Linux.
2. Use azcopy na linha de comando para mover dados para o compartilhamento de Arquivos do Azure. A
sintaxe no Windows é conforme a seguir:
azcopy /Source:<path-to-local-share> /Dest:https://<storage-account>.file.core.windows.net/<file-

share>/ /DestKey:<storage-account-key> /S
No Linux, a sintaxe do comando é um pouco diferente:
azcopy --source <path-to-local-share> --destination https://<storage-

account>.file.core.windows.net/<file-share>/ --dest-key <storage-account-key> --recursive
O AzCopy tem um número significativo de opções para modificar o comportamento de cópia conforme
desejado. Para obter mais informações, exiba AzCopy no Windows e AzCopy no Linux.
Montar automaticamente em computadores/servidores necessários

Para substituir um compartilhamento de arquivos local, vale a pena montar previamente os compartilhamentos
nos computadores em que ele será usado. Isso pode ser feito automaticamente em uma lista de computadores.
NOTE
Montar um compartilhamento de Arquivos do Azure requer o uso da chave de conta de armazenamento como a senha,
portanto, recomendamos a montagem apenas em ambientes confiáveis.
Windows
O PowerShell pode ser usado para executar o comando de montagem em vários computadores. No exemplo a
seguir, $computers é populado manualmente, mas você pode gerar a lista de computadores para montagem
automática. Por exemplo, você pode popular essa variável com resultados do Active Directory.
$computer = "MyComputer1", "MyComputer2", "MyComputer3", "MyComputer4"

$computer | ForEach-Object { Invoke-Command -ComputerName $_ -ScriptBlock { net use <desired-drive-letter>:
\\<storage-account-name>.file.core.windows.net\<share-name> <storage-account-key> /user:Azure\<storage-
account-name> /PERSISTENT:YES } }
Linux
Um script do bash simples combinado com SSH pode gerar o mesmo resultado no exemplo a seguir. A variável
$computer é similarmente deixada para ser populada pelo usuário:
computer = ("MyComputer1" "MyComputer2" "MyComputer3" "MyComputer4")

for item in "${computer[@]}"
do
ssh $item "sudo bash -c 'echo \"//<storage-account-name>.file.core.windows.net/<share-name> /mymountpoint
cifs vers=3.0,username=<storage-account-name>,password=<storage-account-
key>,dir_mode=0777,file_mode=0777,serverino\" >> /etc/fstab'", "sudo mount -a"
done
Próximas etapas
Planejar uma implantação da Sincronização de Arquivos do Azure
Solucionar Problemas dos Arquivos do Azure no Windows
Solucionar Problemas dos Arquivos do Azure no Linux
Use a Sincronização de Arquivos do Azure para centralizar os compartilhamentos de arquivos da sua

organização em Arquivos do Azure enquanto mantém a flexibilidade, o desempenho e a compatibilidade
de um servidor de arquivos local. A Sincronização de arquivos do Azure transforma o Windows Server em
um cache rápido do compartilhamento de arquivos do Azure. Use qualquer protocolo disponível no
Windows Server para acessar seus dados localmente, incluindo SMB, NFS e FTPS. Você pode ter tantos
caches quantos precisar em todo o mundo.
É altamente recomendável que você leia Planejando uma implantação de Arquivos do Azure e Planejando
uma implantação de Sincronização de arquivos do Azure antes de completar as etapas descritas neste
artigo.
Pré-requisitos
Um compartilhamento de arquivos do Azure na mesma região que você deseja implantar
Sincronização de Arquivos do Azure. Para obter mais informações, consulte:
Disponibilidade de região para Sincronização de arquivos do Azure.
Para orientações passo a passo sobre como criar uma conta de compartilhamento, consulte
Criar uma conta de compartilhamento.
Pelo menos uma instância do Windows Server ou cluster do Windows Server com suporte para
sincronização com o Sincronização de Arquivos do Azure. Para obter mais informações sobre as
versões com suporte do Windows Server, consulte interoperabilidade com o Windows Server.
O módulo AZ PowerShell pode ser usado com o PowerShell 5,1 ou o PowerShell 6 +. Você pode
usar o módulo AZ PowerShell para Sincronização de Arquivos do Azure em qualquer sistema com
suporte, incluindo sistemas não Windows, no entanto, o cmdlet de registro do servidor sempre
deve ser executado na instância do Windows Server que você está registrando (isso pode ser feito
diretamente ou por meio de comunicação remota do PowerShell). No Windows Server 2012 R2,
você pode verificar se está executando pelo menos o PowerShell 5,1. * examinando o valor da
propriedade PSVersion do objeto $psversiontable :
$PSVersionTable.PSVersion
Se o valor de PSVersion for menor que 5.1. *, como será o caso com a maioria das novas instalações
do Windows Server 2012 R2, será possível facilmente fazer upgrade, baixando e instalando o
Windows Management Framework (WMF) 5.1. O pacote apropriado para baixar e instalar o
Windows Server 2012 R2 é win 8.1 andw2k12r2-KB*******-x64. msu .
O PowerShell 6 + pode ser usado com qualquer sistema com suporte e pode ser baixado por meio
de sua página do GitHub.
IMPORTANT
Se você planeja usar a interface do usuário de registro do servidor, em vez de registrá-la diretamente do
PowerShell, você deve usar o PowerShell 5,1.
Se você tiver optado por usar o PowerShell 5,1, verifique se pelo menos o .NET 4.7.2 está instalado.
Saiba mais sobre as versões do .NET Framework e as dependências em seu sistema.
IMPORTANT
Se você estiver instalando o .NET 4.7.2 + no Windows Server Core, será necessário instalar quiet o
norestart com os sinalizadores e ou a instalação falhará. Por exemplo, se estiver instalando o .NET 4,8, o
comando seria semelhante ao seguinte:
Start-Process -FilePath "ndp48-x86-x64-allos-enu.exe" -ArgumentList "/q /norestart" -Wait
O módulo AZ PowerShell, que pode ser instalado seguindo as instruções aqui: instalar e configurar
o Azure PowerShell.
NOTE
O módulo AZ. StorageSync agora é instalado automaticamente quando você instala o módulo AZ
PowerShell.
Preparar Servidores Windows para uso com Sincronização de

arquivos do Azure
Para cada servidor que você pretende usar com a Sincronização de Arquivos do Azure, incluindo cada nó
de servidor em um Cluster de Failover, desabilite a Configuração de Segurança Reforçada do
Internet Explorer . Isso é necessário apenas para o registro inicial do servidor. Você pode habilitá-la
novamente depois que o servidor foi registrado.
Portal
PowerShell
NOTE
Você pode ignorar esta etapa se estiver implantando Sincronização de Arquivos do Azure no Windows Server Core.
1. Abra o Gerenciador de Servidor.

2. Clique em Ser vidor Local :
3. No subpainel Propriedades , selecione o link de Configuração de Segurança Reforçada do IE .

4. Na caixa de diálogo Configuração de Segurança Reforçada do Internet Explorer , selecione
Desativado para Administradores e Usuários :
Implantar o Serviço de Sincronização de Armazenamento

A implantação da Sincronização de Arquivos do Azure começa com a colocação de um recurso do Ser viço
de Sincronização de Armazenamento em um grupo de recursos da assinatura selecionada. É
recomendável provisionar alguns desse, conforme necessário. Você criará uma relação de confiança entre
os servidores e esse recurso e um servidor somente poderá ser registrado em um Serviço de
Sincronização de Armazenamento. Como resultado, é recomendável implantar quantos serviços de
sincronização de armazenamento forem necessários para separar grupos de servidores. Tenha em mente
que os servidores de diferentes serviços de sincronização de armazenamento não podem sincronizar
entre si.
NOTE
O serviço de sincronização de armazenamento herda as permissões de acesso da assinatura e do grupo de recursos
em que foi implantado. É recomendável verificar cuidadosamente quem tem acesso a ele. Entidades com acesso de
gravação podem começar a sincronizar novos conjuntos de arquivos de servidores registrados nesse serviço de
sincronização de armazenamento e fazer com que os dados fluam para o armazenamento do Azure que está
acessível para elas.
Portal
PowerShell
Para implantar um serviço de sincronização de armazenamento, vá para o portal do Azure, clique em criar
um recurso e procure por sincronização de arquivos do Azure. Nos resultados da pesquisa, selecione
sincronização de arquivos do Azure e, em seguida, selecione criar para abrir a guia implantar
sincronização de armazenamento .
No novo painel que será aberta, insira as seguintes informações:
Nome : um nome exclusivo (por assinatura) para o Serviço de Sincronização de Armazenamento.
Assinatura : A assinatura na qual você quer criar o Serviço de Sincronização de Armazenamento.
Dependendo da estratégia de configuração da sua empresa, você pode ter acesso a uma ou mais
assinaturas. Uma Assinatura do Azure é o contêiner mais básico de cobrança para cada serviço de
nuvem (como Arquivos do Azure).
Grupo de recursos : um grupo de recursos é um grupo lógico de recursos do Azure, como uma conta
de armazenamento ou um Serviço de Sincronização de Armazenamento. Você pode criar um novo
grupo de recursos ou usar um grupo de recursos existente para Sincronização de Arquivos do Azure. (É
recomendável usar grupos de recursos como contêineres para isolar recursos logicamente para sua
organização, como agrupamento de recursos ou recursos de RH para um projeto específico.)
Local : a região na qual você deseja implantar sincronização de arquivos do Azure. Somente regiões
com suporte estão disponíveis nesta lista.
Quando terminar, selecione Criar para implantar o Serviço De Sincronização De Armazenamento.

O agente de Sincronização de arquivos do Azure é um pacote baixável que permite que o Windows Server
seja sincronizado com um compartilhamento de arquivos do Azure.
Portal
PowerShell
Você pode baixar o agente do Centro de Download da Microsoft. Após fazer o download, clique duas vezes
no pacote MSI para iniciar a instalação do agente de Sincronização de arquivos do Azure.
IMPORTANT
Se você pretende usar a Sincronização de arquivos do Azure com um Cluster de Failover, o agente de Sincronização
de Arquivo do Azure precisa ser instalado em cada nó no cluster. Cada nó do cluster deve ser registrado para
trabalhar com Sincronização de Arquivos do Azure.
Recomendamos que você faça o seguinte:

Deixe o caminho de instalação padrão (C:\Program Files\Azure\StorageSyncAgent), para simplificar a
manutenção do servidor e solução de problemas.
Habilite o Microsoft Update para manter a Sincronização de arquivos do Azure atualizada. Todas as
atualizações, incluindo hotfixes e atualizações de recursos, para o agente de Sincronização de arquivos
do Azure, ocorrerão por meio do Microsoft Update. É recomendável instalar a atualização mais recente
para Sincronização de Arquivos do Azure. Para obter mais informações, consulte sincronização de
arquivos do Azure Update Policy.
Quando a instalação do agente de Sincronização de arquivos do Azure tiver acabado, a interface do
usuário de Registro do Servidor abrirá automaticamente. Para fazer o registro é necessário que haja um
Serviço de Sincronização de Armazenamento. Veja como criar um Serviço de Sincronização de
Armazenamento na próxima seção.
Registrar o Windows Server com o Serviço de Sincronização de

Armazenamento
Registrar o Windows Server com um Serviço de Sincronização de Armazenamento estabelece uma relação
de confiança entre o servidor (ou cluster) e o Serviço de Sincronização de Armazenamento. Um servidor
somente pode ser registrado em um Serviço de Sincronização de Armazenamento e sincronizar com
outros servidores e compartilhamentos de arquivos do Azure associados ao mesmo Serviço de
NOTE
O registro do servidor usa suas credenciais do Azure para criar uma relação de confiança entre o Serviço de
Sincronização de Armazenamento e o Windows Server, mas o servidor cria e usa sua própria identidade, desde que
o servidor permaneça registrado e o token de assinatura de acesso compartilhado (Armazenamento SAS) é válido.
Um novo token de SAS não poderá ser emitido para o servidor depois que o servidor for cancelado, removendo,
assim, a capacidade do servidor de acessar os compartilhamentos de arquivos do Azure, interrompendo qualquer
sincronização.
Portal
PowerShell
A interface do usuário de Registro do Servidor deve abrir automaticamente após a instalação do agente de
Sincronização de arquivos do Azure. Se não estiver, você pode abri-lo manualmente de seu local de
arquivo: C:\Program Files\Azure\StorageSyncAgent\ServerRegistration.exe. Quando a interface do usuário
de Registro do Servidor abrir, clique em Entrar para começar.
Depois de entrar, você deverá fornecer as seguintes informações:
Assinatura do Azure : a assinatura que contém o Serviço de Sincronização de Armazenamento

(consulte Implantar o Serviço de Sincronização de Armazenamento).
Grupo de recursos : o grupo de recursos que contém o Serviço de Sincronização de Armazenamento.
Ser viço de Sincronização de Armazenamento : o nome do Serviço de Sincronização de
Armazenamento com o qual você deseja registrar.
Depois de selecionar as informações apropriadas nos menus suspensos, clique em Registrar para
concluir o registro do servidor. Como parte do processo de registro, você será solicitado a realizar uma
entrada adicional.
Criar um grupo de sincronização e um ponto de extremidade de

nuvem
Um grupo de sincronização define a topologia de sincronização para um conjunto de arquivos. Os pontos
de extremidade em um grupo de sincronização são mantidos em sincronização entre si. Um grupo de
sincronização precisa conter um ponto de extremidade de nuvem que represente um compartilhamento
de arquivos do Azure e um ou mais pontos de extremidade do servidor. Um ponto de extremidade do
servidor representa um caminho em um servidor registrado. Um servidor pode ter pontos de extremidade
do servidor em vários grupos de sincronização. É necessário criar tantos grupos de sincronização quantos
você precisar para descrever adequadamente sua topologia de sincronização desejada.
Um ponto de extremidade de nuvem é um ponteiro para um compartilhamento de arquivos do Azure.
Todos os pontos de extremidade do servidor serão sincronizados com um ponto de extremidade de
nuvem, tornando o ponto de extremidade de nuvem o hub. A conta de armazenamento do
compartilhamento de arquivos do Azure deve estar localizada na mesma região que o Serviço de
Sincronização de Armazenamento. A totalidade do compartilhamento de arquivos do Azure será
sincronizada, com uma exceção: uma pasta especial, comparável à pasta "Informações de Volume do
Sistema" oculta em um volume NTFS, será provisionada. Este diretório é chamado
".SystemShareInformation". Ele contém importantes metadados de sincronização que não serão
sincronizados com outros pontos de extremidade. Não utilize nem exclua-o!
IMPORTANT
Você pode fazer alterações a qualquer Ponto de extremidade de Nuvem ou de Servidor no Grupo de sincronização
e ter seus arquivos sincronizados com os outros pontos de extremidade no Grupo de sincronização. Se você fizer
uma alteração diretamente no Ponto de extremidade de nuvem (compartilhamento de Arquivos do Azure), observe
que as alterações devem primeiro ser descobertas por um trabalho de detecção de alteração de sincronização de
arquivos do Azure. Um trabalho de detecção de alteração é iniciado para um ponto de extremidade da nuvem
apenas uma vez a cada 24 horas. Para obter mais informações, consulte Perguntas frequentes sobre os Arquivos do
Azure.
Portal
PowerShell
Para criar um grupo de sincronização, na portal do Azure, vá para o serviço de sincronização de
armazenamento e, em seguida, selecione + grupo de sincronização :
No painel que abrir, insira as informações a seguir para criar um Grupo de Sincronização com um ponto
de extremidade de nuvem:
Nome do grupo de sincronização : o nome do grupo de sincronização a ser criado. Esse nome deve
ser exclusivo dentro do Serviço de Sincronização de Armazenamento, mas pode ser qualquer nome
lógico para você.
Assinatura : a assinatura na qual você implantou o Serviço de Sincronização de Armazenamento em
Implantar o Serviço de Sincronização de Armazenamento.
Conta de armazenamento : se você selecionar Selecionar conta de armazenamento , outro painel
aparece no qual você pode selecionar a conta de armazenamento que tenha o compartilhamento de
arquivos do Azure que você deseja fazer a sincronização.
Compar tilhamento de Arquivo do Azure : o nome do Compartilhamento de Arquivo do Azure com
o qual você deseja sincronizar.
Criar um ponto de extremidade do servidor

Um ponto de extremidade do servidor representa um local específico em um servidor registrado, como
uma pasta em um volume do servidor. Um ponto de extremidade do servidor deve ser um caminho em
um servidor registrado (em vez de um compartilhamento montado) e, para usar a classificação em
camadas de nuvem, o caminho deve estar em um volume que não seja do sistema. Não há suporte para
Armazenamento NAS (Network Attached Storage).
Portal
PowerShell
Para adicionar um ponto de extremidade do servidor, vá até o grupo de sincronização recém-criado e
selecione Adicionar ponto de extremidade do ser vidor .
No painel Adicionar ponto de extremidade do ser vidor , insira as informações a seguir para criar um
ponto de extremidade do servidor:
Ser vidor registrado : o nome do servidor ou cluster em que você deseja criar o ponto de extremidade
do servidor.
Caminho : o caminho do Windows Server a ser sincronizado como parte do grupo de sincronização.
Nuvem em camadas : uma opção para habilitar ou desabilitar a nuvem camadas. Com nuvem em
camadas, arquivos raramente usados ou acessados de nuvem podem ter várias camada para arquivos
do Azure.
Espaço livre no volume : a quantidade de espaço livre a ser reservada no volume no qual o ponto de
extremidade do servidor está localizado. Por exemplo, se o espaço livre do volume estiver definido
como 50% em um volume com um único ponto de extremidade do servidor, aproximadamente metade
da quantidade de dados será disposta em camadas para os Arquivos do Azure. Independentemente de
as camadas na nuvem estarem habilitadas, o Compartilhamento de Arquivos do Azure sempre terá
uma cópia completa dos dados no Grupo de Sincronização.
Para adicionar o ponto de extremidade do servidor, selecione criar . Os arquivos agora serão mantidos em
sincronia entre o Compartilhamento de Arquivos do Azure e o Windows Server.
Definir configurações de rede virtual e de firewall
Portal
Se você quiser configurar a sincronização de arquivos do Azure para trabalhar com as configurações de
firewall e rede virtual, faça o seguinte:
1. No portal do Azure, navegue até a conta de armazenamento que você deseja proteger.
2. Selecione o botão firewalls e redes vir tuais no menu à esquerda.
3. Selecione redes selecionadas em permitir acesso de .
4. Verifique se os servidores IP ou rede virtual estão listados na seção apropriada.
5. Certifique-se de que permitir que ser viços da Microsoft confiáveis acessem esta conta de
armazenamento esteja marcado.
6. Selecione salvar para salvar as configurações.
Integração com a Sincronização de arquivos do Azure

As etapas recomendadas para se integrar à Sincronização de arquivos do Azure pela primeira vez com
zero tempo de inatividade e ainda preservar a fidelidade do arquivo completo e a lista de controle de
acesso (ACL) são as seguintes:
1. Implantar um Serviço de sincronização de armazenamento.
2. Criar um grupo de sincronização.
3. Instalar o agente de Sincronização de arquivos do Azure no servidor com o conjunto de dados
completo.
4. Registrar esse servidor e criar um ponto de extremidade do servidor no compartilhamento.
5. Permitir que a sincronização faça o upload completo ao compartilhamento de arquivos do Azure
(ponto de extremidade de nuvem).
6. Após a conclusão do upload inicial, instalar o agente de Sincronização de arquivos do Azure em cada
um dos servidores restantes.
7. Criar novos compartilhamentos de arquivo em cada um dos servidores restantes.
8. Criar pontos de extremidade do servidor em novos compartilhamentos de arquivo com a política de
camadas de nuvem, se desejado. (Essa etapa requer que haja armazenamento adicional disponível para
a configuração inicial.)
9. Permitir que o Sincronização de Arquivos do Azure Agent faça uma restauração rápida do namespace
completo sem a transferência de dados real. Após a sincronização completa de namespace, o
mecanismo de sincronização preencherá o espaço de disco local com base na política de camadas de
nuvem do ponto de extremidade do servidor.
10. Certifique-se de que a sincronização seja concluída e teste a sua topologia conforme desejado.
11. Redirecionar usuários e aplicativos para esse novo compartilhamento.
12. Outra opção é excluir compartilhamentos duplicados nos servidores.
Caso não tenha armazenamento extra para a integração inicial e gostaria de anexar aos
compartilhamentos existentes, você pode pré-propagar os dados nos compartilhamentos de arquivos do
Azure. Essa abordagem é sugerida se e somente se você puder aceitar o tempo de inatividade e não
garante absolutamente nenhuma alteração de dados em compartilhamentos do servidor durante o
processo de migração inicial.
1. Verifique se os dados em qualquer um dos servidores não podem ser alterados durante o processo de
integração.
2. Pré-propagar compartilhamentos de arquivos do Azure com os dados do servidor usando qualquer
ferramenta de transferência de dados no SMB, por exemplo, Robocopy, Direct SMB Copy. Como o
AzCopy não baixa dados pelo SMB, ele não pode ser usado para pré-propagação.
3. Crie a topologia da Sincronização de arquivos do Azure com os pontos de extremidade desejados do
servidor apontando para os compartilhamentos existentes.
4. Deixe a sincronização concluir o processo de reconciliação em todos os pontos de extremidade.
5. Assim que a reconciliação for concluída, você pode abrir compartilhamentos para alterações.
Atualmente, a abordagem de pré-propagação tem algumas limitações –
A fidelidade total nos arquivos não é preservada. Por exemplo, arquivos perdem ACLs e carimbo de
data/hora.
Alterações de dados no servidor antes de a topologia de sincronização estar totalmente ativa e em
execução podem causar conflitos nos pontos de extremidade do servidor.
Depois que o ponto de extremidade de nuvem é criado, o Sincronização de Arquivos do Azure executa
um processo para detectar os arquivos na nuvem antes de iniciar a sincronização inicial. O tempo
necessário para concluir esse processo varia de acordo com os vários fatores, como velocidade de rede,
largura de banda disponível e número de arquivos e pastas. Para obter uma estimativa aproximada na
versão prévia, o processo de detecção é executado a aproximadamente 10 arquivos por segundo.
Portanto, mesmo se a pré-propagação for executada rapidamente, o tempo geral para obter um
sistema totalmente em execução pode ser significativamente maior quando os dados forem pré-
propagados na nuvem.
Restauração de autoatendimento por meio de versões anteriores

e VSS (Serviço de Cópias de Sombra de Volume)
IMPORTANT
As informações a seguir só podem ser usadas com a versão 9 (ou superior) do agente de sincronização de
armazenamento. As versões inferiores a 9 não terão os cmdlets StorageSyncSelfService.
As versões anteriores são um recurso do Windows que permite que você utilize instantâneos VSS do lado
do servidor de um volume para apresentar versões restauráveis de um arquivo a um cliente SMB. Isso
permite um cenário poderoso, comumente conhecido como restauração de autoatendimento, diretamente
para operadores de informações, em vez de depender da restauração de um administrador de ti.
Os instantâneos do VSS e as versões anteriores funcionam independentemente do Sincronização de
Arquivos do Azure. No entanto, a camada da nuvem deve ser definida como um modo compatível. Muitos
pontos de extremidade do Sincronização de Arquivos do Azure Server podem existir no mesmo volume.
Você precisa fazer a seguinte chamada do PowerShell por volume que tenha até mesmo um ponto de
extremidade do servidor no qual você planeja ou está usando camadas de nuvem.
Import-Module '<SyncAgentInstallPath>\StorageSync.Management.ServerCmdlets.dll'
Enable-StorageSyncSelfServiceRestore [-DriveLetter] <string> [[-Force]]
Os instantâneos do VSS são tirados de um volume inteiro. Por padrão, até 64 instantâneos podem existir
para um determinado volume, contanto que haja espaço suficiente para armazenar os instantâneos. O VSS
trata isso automaticamente. A agenda de instantâneo padrão usa dois instantâneos por dia, de segunda-
feira a sexta-feira. Essa agenda pode ser configurada por meio de uma tarefa agendada do Windows. O
cmdlet do PowerShell acima faz duas coisas:
1. Ele configura as sincronizações de arquivos do Azure em camadas de nuvem no volume especificado
para serem compatíveis com as versões anteriores e garante que um arquivo possa ser restaurado de
uma versão anterior, mesmo que ele tenha sido em camadas para a nuvem no servidor.
2. Ele habilita a agenda padrão do VSS. Em seguida, você pode decidir modificá-lo mais tarde.
NOTE
Há dois aspectos importantes a serem observados:
Se você usar o parâmetro-Force e o VSS estiver habilitado no momento, ele substituirá o agendamento atual do
instantâneo do VSS e o substituirá pelo agendamento padrão. Certifique-se de salvar sua configuração
personalizada antes de executar o cmdlet.
Se você estiver usando esse cmdlet em um nó de cluster, também deverá executá-lo em todos os outros nós no
cluster!
Para ver se a compatibilidade de restauração de autoatendimento está habilitada, você pode executar o
cmdlet a seguir.
Get-StorageSyncSelfServiceRestore [[-Driveletter] <string>]
Ele listará todos os volumes no servidor, bem como o número de dias compatíveis em camadas de nuvem
para cada um. Esse número é calculado automaticamente com base no máximo de instantâneos possíveis
por volume e no agendamento de instantâneo padrão. Portanto, por padrão, todas as versões anteriores
apresentadas a um operador de informações podem ser usadas para restaurar do. O mesmo será
verdadeiro se você alterar o agendamento padrão para obter mais instantâneos. No entanto, se você
alterar o agendamento de uma maneira que resultará em um instantâneo disponível no volume que seja
mais antigo que o valor de dias compatíveis, os usuários não poderão usar esse instantâneo mais antigo
(versão anterior) para restaurar.
NOTE
Habilitar a restauração de autoatendimento pode afetar o consumo e a fatura do armazenamento do Azure. Esse
impacto é limitado aos arquivos atualmente em camadas no servidor. Habilitar esse recurso garante que haja uma
versão de arquivo disponível na nuvem que pode ser referenciada por meio de uma entrada de versões anteriores
(instantâneo do VSS).
Se você desabilitar o recurso, o consumo de armazenamento do Azure diminuirá lentamente até que a janela de
dias compatíveis tenha passado. Não há como acelerar isso.
O número máximo padrão de instantâneos VSS por volume (64), bem como o agendamento padrão para
levá-los, resulta em um máximo de 45 dias de versões anteriores que um operador de informações pode
restaurar, dependendo de quantos instantâneos VSS você pode armazenar em seu volume.
Se for Max. 64 os instantâneos do VSS por volume não são a configuração correta para você, você pode
alterar esse valor por meio de uma chave do registro. Para que o novo limite entre em vigor, você precisa
executar novamente o cmdlet para habilitar a compatibilidade de versão anterior em cada volume que foi
habilitado anteriormente, com o sinalizador-Force para obter o novo número máximo de instantâneos do
VSS por volume em conta. Isso resultará em um número calculado recentemente de dias compatíveis.
Observe que essa alteração só entrará em vigor em arquivos em camadas recentemente e substituirá as
personalizações na agenda do VSS que você tenha feito.
Migrar uma implantação de replicação do DFS (DFS-R) para

sincronização de arquivos do Azure
Para migrar uma implantação de DFS-R para sincronização de arquivos do Azure:
1. Crie um grupo de sincronização para representar a topologia de DFS-R que você estiver substituindo.
2. Inicialize no servidor que tiver o conjunto completo de dados em sua topologia de DFS-R para migrar.
Instale a sincronização de arquivos do Azure nesse servidor.
3. Registre o servidor e crie um ponto de extremidade do servidor para o primeiro servidor a ser
migrado. Não habilite a camada de nuvem.
4. Permita que todos os dados se sincronizem ao seu compartilhamento de arquivos do Azure (ponto de
extremidade de nuvem).
5. Instale e registre o agente de sincronização de arquivos do Azure em cada um dos servidores restantes
do DFS-R.
6. Desabilite o DFS-R.
7. Crie um ponto de extremidade do servidor em cada um dos servidores do DFS-R. Não habilite a
camada de nuvem.
8. Certifique-se de que a sincronização seja concluída e teste a sua topologia conforme desejado.
9. Desative o DFS-R.
10. Agora, a camada de nuvem pode ser ativada em qualquer ponto de extremidade do servidor, conforme
desejado.
Para obter mais informações, consulte Interoperabilidade de sincronização de arquivos do Azure com o
sistema de arquivos distribuído (DFS).
Próximas etapas
Adicionar/remover um ponto de extremidade do Servidor de Sincronização de arquivos do Azure
Registrar/cancelar o registro de um servidor com a Sincronização de arquivos do Azure
Configurações de proxy e firewall da Sincronização
de arquivos do Azure
A Sincronização de arquivos do Azure se conecta seus servidores locais para arquivos do Azure, permitindo
camadas de recursos de nuvem e sincronização de vários locais. Como tal, um servidor local deve estar
conectado à internet. Um administrador de TI precisa decidir o melhor caminho para o servidor acessar os
serviços de nuvem do Azure.
Este artigo fornecerá informações sobre requisitos específicos e as opções disponíveis para conectar com êxito
e segurança o servidor de Sincronização de Arquivos do Azure.
Visão geral
A Sincronização de Arquivos do Azure atua como um serviço de coordenação entre o Windows Server, seu
compartilhamento de arquivos do Azure e vários outros serviços do Azure para sincronizar os dados conforme
descrito em seu grupo de sincronização. Para que a Sincronização de Arquivos do Azure funcione corretamente,
você precisará configurar seus servidores para se comunicar com os seguintes serviços do Azure:
Armazenamento do Azure
Azure Resource Manager
Serviços de Autenticação
NOTE
O agente de Sincronização de Arquivos do Azure no Windows Server inicia todas as solicitações para serviços que
resultam em apenas ter que considerar o tráfego de saída de uma perspectiva de firewall de nuvem.
Nenhum serviço do Azure inicia uma conexão com o agente de sincronização de arquivos do Azure.
Portas
A Sincronização de Arquivos do Azure move metadados e dados de arquivos exclusivamente via HTTPS e exige
que a porta 443 tenha a saída aberta. Como resultado, todo o tráfego é criptografado.
Redes e conexões especiais para o Azure

O agente de Sincronização de Arquivos do Azure não tem requisitos sobre canais especiais como ExpressRoute,
etc. para o Azure.
A Sincronização de Arquivos do Azure funcionará por meios disponíveis que permitem o alcance no Azure,
automaticamente se adaptando a várias características de rede com largura de banda, latência, bem como
oferecendo controle de administração para ajustar. Alguns recursos não estão disponíveis neste momento. Se
você quiser configurar o comportamento específico, fale por meio do Azure Files UserVoice.
Proxy
A Sincronização de Arquivos do Azure oferece suporte a configurações de proxy específicas do aplicativo e de
todo o computador.
As configurações de proxy específicas do aplicativo permitirão a configuração de um proxy
especificamente para o tráfego da Sincronização de Arquivos do Azure. As configurações de proxy específicas
do aplicativo são suportadas no agente versão 4.0.1.0 ou mais recente e podem ser configuradas durante a
instalação do agente ou usando o cmdlet do PowerShell Set-StorageSyncProxyConfiguration.
Comandos do PowerShell para definir as configurações de proxy específicas do aplicativo:

Set-StorageSyncProxyConfiguration -Address <url> -Port <port number> -ProxyCredential <credentials>
As configurações de proxy amplas do computador são transparentes para o agente de Sincronização de

Arquivos do Azure, pois o tráfego inteiro do servidor é roteado através do proxy.
Para definir as configurações de proxy amplas do computador, siga as etapas abaixo:
1. Definir configurações de proxy para aplicativos .NET
Edite esses dois arquivos:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
Adicione a seção <system.net> nos arquivos machine.config (abaixo da seção
<system.serviceModel>). Altere 127.0.01: 8888 para o endereço IP e porta para o servidor proxy.
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888"
usesystemdefault="false" />
</defaultProxy>
</system.net>
2. Definir as configurações de proxy do WinHTTP

Execute o comando a seguir em um prompt de comandos com privilégios elevados ou no
PowerShell para ver a configuração de proxy existente:
netsh winhttp show proxy
Execute o comando a seguir em um prompt de comandos com privilégios elevados ou no
PowerShell para definir a configuração de proxy (altere 127.0.01: 8888 para o endereço IP e porta
para o servidor proxy):
netsh winhttp set proxy 127.0.0.1:8888
3. Reinicie o serviço do Agente de Sincronização de Armazenamento executando o comando a seguir em
um prompt de comandos com privilégios elevados ou no PowerShell:
net stop filesyncsvc
Observação: o serviço do Agente de Sincronização de Armazenamento (filesyncsvc) será iniciado
automaticamente quando interrompido.
Firewall
Conforme mencionado em uma seção anterior, a porta 443 precisa estar com a saída aberta. Com base em
políticas em seu banco de dados, a ramificação ou a região, restringir ainda mais o tráfego por essa porta a
domínios específicos pode ser desejado ou necessário.
A tabela a seguir descreve os domínios necessários para a comunicação:
P O N TO DE EXT REM IDA DE

P O N TO DE EXT REM IDA DE DO A Z URE
SERVIÇ O DE N UVEM P ÚB L IC A GO VERN A M EN TA L USO
Azure Resource https://management.azure.comhttps://management.usgovc Qualquer chamada de

Manager loudapi.net usuário (como o PowerShell)
passa por essa URL,
incluindo a chamada de
registro inicial do servidor.
Azure Active Director y https://login.windows.net https://login.microsoftonline As chamadas do Azure

.us
https://login.microsoftonline.com Resource Manager devem
ser feitas por um usuário
autenticado. Para ter êxito,
essa URL é usada para
autenticação do usuário.
Azure Active Director y https://graph.microsoft.com https://graph.microsoft.com Como parte da implantação

/ / de Sincronização de
Arquivos do Azure, será
criado um objeto de serviço
do Azure Active Directory
da assinatura. Essa URL é
usada para fazer isso. Essa
entidade de segurança é
usada para a delegação de
um conjunto mínimo de
direitos para o Serviço de
Sincronização de Arquivos
do Azure. O usuário que
estiver executando a
configuração inicial de
do Azure deve ser um
usuário autenticado com
privilégios de proprietário
da assinatura.
Azure Active Director y https://secure.aadcdn.micro Use a URL do ponto de Essa URL é acessada pelo
softonline-p.com extremidade público. Active Directory biblioteca
de autenticação que a
interface do usuário de
registro do Sincronização de
Arquivos do Azure Server
usa para fazer logon no
administrador.
P O N TO DE EXT REM IDA DE
P O N TO DE EXT REM IDA DE DO A Z URE
SERVIÇ O DE N UVEM P ÚB L IC A GO VERN A M EN TA L USO
Armazenamento do *.core.windows.net *. core.usgovcloudapi.net Quando o servidor baixa

Azure um arquivo, o servidor
executa essa movimentação
de dados com mais
eficiência quando se
comunicando diretamente
com o compartilhamento
de arquivos do Azure na
O servidor tem uma chave
SAS que só permite o
acesso de
compartilhamento do
arquivo de destino.
Sincronização de *. one.microsoft.com *. afs.azure.us Após o registro do servidor

Arquivos do Azure *. afs.azure.net inicial, o servidor recebe
uma URL regional para a
instância do serviço de
do Azure nessa região. O
servidor pode usar a URL
para se comunicar de forma
direta e eficiente com a
instância de tratando sua
sincronização.
Microsoft PKI https://www.microsoft.com/ https://www.microsoft.com/ Depois de instalar o agente

pki/mscorp/cps pki/mscorp/cps da Sincronização de
http://ocsp.msocsp.com http://ocsp.msocsp.com Arquivos do Azure, a URL
do PKI é usada para baixar
os certificados
intermediários necessários
para se comunicar com o
serviço de Sincronização de
Arquivos do Azure e do
compartilhamento de
arquivos do Azure. A URL
do OCSP é usada para
verificar o status de um
certificado.
IMPORTANT
Ao permitir o tráfego para o *. one.microsoft.com, o tráfego para mais do que apenas o serviço de sincronização é
possível a partir do servidor. Há muitos mais serviços da Microsoft nos subdomínios.
Se o *. one.microsoft.com for muito amplo, você poderá limitar a comunicação do servidor permitindo a
comunicação apenas com instâncias regionais explícitas do serviço Sincronização de Arquivos do Azure. Qual
instância escolher depende da região do serviço de sincronização de armazenamento em que o servidor está
implantado e registrado. Essa região é chamada de "URL do ponto de extremidade primário" na tabela abaixo.
Por motivos de BCDR (continuidade dos negócios e recuperação de desastres), você pode ter especificado os
compartilhamentos de arquivos do Azure em uma conta de GRS (armazenamento com redundância global). Se
esse for o caso, os compartilhamentos de arquivos do Azure farão failover na região emparelhada se ocorrer
uma interrupção regional duradoura. A Sincronização de Arquivos do Azure usa os mesmos emparelhamentos
regionais do armazenamento. Portanto, se você usar contas de armazenamento GRS, será necessário habilitar
URLs adicionais para permitir que o servidor se comunique com a região emparelhada para Sincronização de
Arquivos do Azure. A tabela a seguir chama essa "região emparelhada". Adicionalmente, há uma URL do perfil
do gerenciador de tráfego que também precisa ser habilitada. Isso garantirá que o tráfego possa ser roteado
novamente diretamente para a região emparelhada no caso de um failover e é chamado de "URL de
Descoberta" na tabela abaixo.
URL DO P O N TO DE
EXT REM IDA DE REGIÃ O
N UVEM REGIÃ O P RIM Á RIO EM PA REL H A DA URL DE DESC O B ERTA
Público Leste da Austrália https://Kailani- Sudeste da Austrália https://TM-Kailani-

Aue.One.Microsoft.co Aue.One.Microsoft.co
m m
Público Sudeste da Austrália https://Kailani- Leste da Austrália https://TM-Kailani-

aus.One.Microsoft.co aus.One.Microsoft.co
m m
Público Sul do Brasil https://brazilsouth01. Centro-Sul dos https://TM-

AFS.Azure.net Estados Unidos brazilsouth01.AFS.Az
ure.net
Público Canadá Central https://Kailani- Leste do Canadá https://TM-Kailani-

CAC.One.Microsoft.c CAC.One.Microsoft.c
om om
Público Leste do Canadá https://Kailani- Canadá Central https://TM-

CAE.One.Microsoft.co Kailani.CAE.One.Micr
m osoft.com
Público Índia Central https://Kailani- Sul da Índia https://TM-Kailani-

CIN.One.Microsoft.co CIN.One.Microsoft.co
m m
Público Centro dos EUA https://Kailani- Leste dos EUA 2 https://TM-Kailani-

cus.One.Microsoft.co cus.One.Microsoft.co
m m
Público Leste da Ásia https://kailani11.One. Sudeste Asiático https://TM-

Microsoft.com kailani11.One.Micros
oft.com
Público Leste dos EUA https://kailani1.One. Oeste dos EUA https://TM-

Microsoft.com kailani1.One.Microsof
t.com
Público Leste dos EUA 2 https://Kailani- Centro dos EUA https://TM-Kailani-

ESS.One.Microsoft.co ESS.One.Microsoft.co
m m
Público Leste do Japão https://japaneast01.A Oeste do Japão https://TM-

FS.Azure.net japaneast01.AFS.Azur
e.net
Público Oeste do Japão https://japanwest01. Leste do Japão https://TM-

AFS.Azure.net japanwest01.AFS.Azu
re.net
URL DO P O N TO DE
Público Coreia Central https://koreacentral0 Sul da Coreia https://TM-

1.AFS.Azure.net/ koreacentral01.AFS.A
zure.net/
Público Sul da Coreia https://koreasouth01 Coreia Central https://TM-

.AFS.Azure.net/ koreasouth01.AFS.Az
ure.net/
Público Centro-Norte dos https://northcentralu Centro-Sul dos https://TM-

EUA s01.AFS.Azure.net Estados Unidos northcentralus01.AFS
.Azure.net
Público Norte da Europa https://kailani7.One. Europa Ocidental https://TM-

t.com
Público Centro-Sul dos https://southcentralu Centro-Norte dos https://TM-

Estados Unidos s01.AFS.Azure.net EUA southcentralus01.AFS
.Azure.net
Público Sul da Índia https://Kailani- Índia Central https://TM-Kailani-

Sin.One.Microsoft.co Sin.One.Microsoft.co
m m
Público Sudeste Asiático https://kailani10.One. Leste da Ásia https://TM-

Microsoft.com kailani10.One.Micros
oft.com
Público Sul do Reino Unido https://Kailani- Oeste do Reino https://TM-Kailani-

UKs.One.Microsoft.co Unido UKs.One.Microsoft.co
m m
Público Oeste do Reino https://Kailani- Sul do Reino Unido https://TM-Kailani-

Unido UKW.One.Microsoft.c UKW.One.Microsoft.c
om om
Público Centro-Oeste dos https://westcentralus Oeste dos EUA 2 https://TM-

EUA 01.AFS.Azure.net westcentralus01.AFS.
Azure.net
Público Europa Ocidental https://kailani6.One. Norte da Europa https://TM-

t.com
Público Oeste dos EUA https://Kailani.One.Mi Leste dos EUA https://TM-

crosoft.com Kailani.One.Microsoft.
com
Público Oeste dos EUA 2 https://westus201.AF Centro-Oeste dos https://TM-

S.Azure.net EUA westus201.AFS.Azure
.net
URL DO P O N TO DE
Governamental Governo dos EUA do https://usgovarizona Governo dos EUA do https://TM-

Arizona 01.AFS.Azure.us Texas usgovarizona01.AFS.
Azure.us
Governamental Governo dos EUA do https://usgovtexas01. Governo dos EUA do https://TM-

Texas AFS.Azure.us Arizona usgovtexas01.AFS.Az
ure.us
Se estiver utilizando contas de LRS (armazenamento com redundância local) ou ZRS (com redundância
de zona), será necessário somente habilitar a URL listada em "URL do ponto de extremidade primário".
Se estiver utilizando contas de GRS (armazenamento com redundância global), habilite três URLs.
Exemplo: você implanta um serviço de sincronização de armazenamento em "West US" e registra o servidor
com ele. As URLs para permitir que o servidor comunique-se para esse caso são:
https://Kailani.One.Microsoft.com (ponto de extremidade primário: oeste dos EUA)

https://kailani1.One.Microsoft.com (região de failover emparelhada: leste dos EUA)
https://TM-KAILANI.One.Microsoft.com (URL de descoberta da região primária)
Lista de permissões para endereços IP de Sincronização de Arquivos do Azure

Sincronização de Arquivos do Azure dá suporte ao uso de marcas de serviço, que representam um grupo de
prefixos de endereço IP para um determinado serviço do Azure. Você pode usar marcas de serviço para criar
regras de firewall que permitem a comunicação com o serviço de Sincronização de Arquivos do Azure. A marca
de serviço para Sincronização de Arquivos do Azure StorageSyncService é.
Se você estiver usando Sincronização de Arquivos do Azure no Azure, poderá usar o nome da marca de serviço
diretamente em seu grupo de segurança de rede para permitir o tráfego. Para saber mais sobre como fazer isso,
consulte grupos de segurança de rede.
Se você estiver usando Sincronização de Arquivos do Azure local, poderá usar a API de marca de serviço para
obter intervalos de endereços IP específicos para a lista de permissões do firewall. Há dois métodos para obter
essas informações:
A lista atual de intervalos de endereços IP para todos os serviços do Azure que dão suporte a marcas de
serviço são publicadas semanalmente no centro de download da Microsoft, na forma de um documento
JSON. Cada nuvem do Azure tem seu próprio documento JSON com os intervalos de endereços IP
relevantes para essa nuvem:
Público do Azure
Governo dos EUA do Azure
Azure China
Azure Alemanha
A API de descoberta de marca de serviço (versão prévia) permite a recuperação programática da lista atual
de marcas de serviço. Na visualização, a API de descoberta de marca de serviço pode retornar informações
que são menos atuais do que as informações retornadas dos documentos JSON publicados no centro de
download da Microsoft. Você pode usar a superfície da API com base na sua preferência de automação:
REST API
PowerShell do Azure
CLI do Azure
Como a API de descoberta de marca de serviço não é atualizada com a frequência dos documentos JSON
publicados no centro de download da Microsoft, é recomendável usar o documento JSON para atualizar a lista
de permissões do firewall local. Isso pode ser feito da seguinte maneira:
# The specific region to get the IP address ranges for. Replace westus2 with the desired region code
# from Get-AzLocation.
$region = "westus2"
# The service tag for Azure File Sync. Do not change unless you're adapting this
# script for another service.
$serviceTag = "StorageSyncService"
# Download date is the string matching the JSON document on the Download Center.
$possibleDownloadDates = 0..7 | `
ForEach-Object { [System.DateTime]::Now.AddDays($_ * -1).ToString("yyyyMMdd") }
# Verify the provided region

$validRegions = Get-AzLocation | `
Where-Object { $_.Providers -contains "Microsoft.StorageSync" } | `
Select-Object -ExpandProperty Location
if ($validRegions -notcontains $region) {

Write-Error `
-Message "The specified region $region is not available. Either Azure File Sync is not deployed
there or the region does not exist." `
-ErrorAction Stop
}
# Get the Azure cloud. This should automatically based on the context of
# your Az PowerShell login, however if you manually need to populate, you can find
# the correct values using Get-AzEnvironment.
$azureCloud = Get-AzContext | `
Select-Object -ExpandProperty Environment | `
Select-Object -ExpandProperty Name
# Build the download URI

$downloadUris = @()
switch($azureCloud) {
"AzureCloud" {
$downloadUris = $possibleDownloadDates | ForEach-Object {
"https://download.microsoft.com/download/7/1/D/71D86715-5596-4529-9B13-
DA13A5DE5B63/ServiceTags_Public_$_.json"
}
}
"AzureUSGovernment" {
"https://download.microsoft.com/download/6/4/D/64DB03BF-895B-4173-A8B1-
BA4AD5D4DF22/ServiceTags_AzureGovernment_$_.json"
}
}
"AzureChinaCloud" {
"https://download.microsoft.com/download/9/D/0/9D03B7E2-4B80-4BF3-9B91-
DA8C7D3EE9F9/ServiceTags_China_$_.json"
}
}
"AzureGermanCloud" {
"https://download.microsoft.com/download/0/7/6/076274AB-4B0B-4246-A422-
4BAF1E03F974/ServiceTags_AzureGermany_$_.json"
}
}
default {
Write-Error -Message "Unrecognized Azure Cloud: $_" -ErrorAction Stop
}
}
# Find most recent file

$found = $false
foreach($downloadUri in $downloadUris) {
try { $response = Invoke-WebRequest -Uri $downloadUri -UseBasicParsing } catch { }
if ($response.StatusCode -eq 200) {
$found = $true
break
}
}
if ($found) {
# Get the raw JSON
$content = [System.Text.Encoding]::UTF8.GetString($response.Content)
# Parse the JSON

$serviceTags = ConvertFrom-Json -InputObject $content -Depth 100
# Get the specific $ipAddressRanges

$ipAddressRanges = $serviceTags | `
Select-Object -ExpandProperty values | `
Where-Object { $_.id -eq "$serviceTag.$region" } | `
Select-Object -ExpandProperty properties | `
Select-Object -ExpandProperty addressPrefixes
} else {
# If the file cannot be found, that means there hasn't been an update in
# more than a week. Please verify the download URIs are still accurate
# by checking https://docs.microsoft.com/azure/virtual-network/service-tags-overview
Write-Verbose -Message "JSON service tag file not found."
return
}
Você pode usar os intervalos de endereços IP no $ipAddressRanges para atualizar o firewall. Verifique o site do
seu firewall/dispositivo de rede para obter informações sobre como atualizar seu firewall.
Testar a conectividade de rede para pontos de extremidade de serviço

Depois que um servidor é registrado com o serviço de Sincronização de Arquivos do Azure, o cmdlet Test-
StorageSyncNetworkConnectivity e o ServerRegistration. exe podem ser usados para testar as comunicações
com todos os pontos de extremidade (URLs) específicos desse servidor. Esse cmdlet pode ajudar a solucionar
problemas quando a comunicação incompleta impede que o servidor trabalhe totalmente com o Sincronização
de Arquivos do Azure e ele pode ser usado para ajustar as configurações de proxy e firewall.
Para executar o teste de conectividade de rede, instale Sincronização de Arquivos do Azure Agent versão 9,1 ou
posterior e execute os seguintes comandos do PowerShell:

Test-StorageSyncNetworkConnectivity
Resumo e limitação de risco

As listas no início deste documento contém as URLs de Sincronização de Arquivos do Azure com que está se
comunicando. Os firewalls devem permitir o tráfego de saída para esses domínios. A Microsoft se esforça para
manter essa lista atualizada.
A configuração das regras de firewall de restrição de domínio pode ser uma medida para melhorar a segurança.
Se essas configurações de firewall são utilizadas, é necessário ter em mente que URLs serão adicionadas e
poderão até mesmo ser alteradas ao longo do tempo. Consulte este artigo periodicamente.
Próximas etapas
Usar um compartilhamento de arquivos do Azure
com o Windows

arquivos do Azure podem ser usados perfeitamente no Windows e no Windows Server. Este artigo aborda
as considerações para usar um compartilhamento de arquivos do Azure com Windows e Windows Server.
Para usar um compartilhamento de Arquivos do Azure fora da região na qual o Azure está hospedado, por
exemplo, localmente ou em uma região diferente do Azure, o sistema operacional deverá dar suporte a SMB
3.0.
Você pode usar compartilhamentos de arquivos do Azure em uma instalação do Windows que esteja em
execução em uma VM do Azure ou localmente. A tabela abaixo mostra quais versões do sistema operacional
dão suporte ao acesso de compartilhamentos de arquivos em quais ambientes:
M O N TÁVEL N A VM DO
VERSÃ O DO W IN DO W S VERSÃ O DO SM B A Z URE M O N TÁVEL LO C A L
Windows Server 2019 SMB 3.0 Sim Sim
Windows 101 SMB 3.0 Sim Sim
Canal semestral do SMB 3.0 Sim Sim

Windows Server2
Windows 8.1 SMB 3.0 Sim Sim
Windows Server 2012 R2 SMB 3.0 Sim Sim
Windows 73 SMB 2.1 Sim Não
Windows Server 2008 R23 SMB 2.1 Sim Não
1 Windows 10, versões 1507, 1607, 1709, 1803, 1809, 1903 e 1909.
2 Windows Server, versões 1809, 1903 e 1909.
3 O suporte regular da Microsoft para o Windows 7 e o Windows Server 2008 R2 terminou. É possível
adquirir suporte adicional para atualizações de segurança somente por meio do programa ESU (atualização
de segurança estendida). É altamente recomendável migrar desses sistemas operacionais.
NOTE
É sempre recomendável obter o KB mais recente para a sua versão do Windows.
Pré-requisitos
Nome da conta de armazenamento : para montar um compartilhamento de arquivos do Azure,
será necessário o nome da conta de armazenamento.
Chave de conta de armazenamento : Para montar um compartilhamento de arquivos do Azure,
você precisará da chave de armazenamento primária (ou secundária). Atualmente, as chaves SAS não
têm suporte para montagem.
Verifique se a por ta 445 está aber ta : o protocolo SMB requer a porta TCP 445 aberta; haverá
falha de conexão se a porta 445 estiver bloqueada. Você pode verificar se o firewall está bloqueando
a porta 445 com o cmdlet Test-NetConnection . Você pode aprender sobre várias maneiras de
solucionar a porta de solução de bloqueio 445 aqui.
O código do PowerShell a seguir pressupõe que você tenha o módulo Azure PowerShell instalado,
consulte instalar Azure PowerShell módulo para obter mais informações. Lembre-se de substituir
<your-storage-account-name> e <your-resource-group-name> pelos nomes referentes a sua conta de
armazenamento.
$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"
# This command requires you to be logged into your Azure account, run Login-AzAccount if you
haven't
# already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name
$storageAccountName
# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.

# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as
sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage
resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -
Port 445
Se a conexão foi bem-sucedida, você verá a seguinte saída:
ComputerName : <storage-account-host-name>
RemoteAddress : <storage-account-ip-address>
RemotePort : 445
InterfaceAlias : <your-network-interface>
SourceAddress : <your-ip-address>
TcpTestSucceeded : True
NOTE
O comando acima retorna o endereço IP atual da conta de armazenamento. Não há garantia de que esse
endereço IP será sempre o mesmo; ele pode mudar a qualquer momento. Não codifique esse endereço IP em
um script ou em uma configuração de firewall.
Usando um compartilhamento de arquivos do Azure com o

Windows
Para usar um compartilhamento de arquivos do Azure com o Windows, você deve montá-lo, ou seja,
atribuir uma letra da unidade ou um caminho de ponto de montagem, ou acessá-lo por meio do caminho
UNC.
Ao contrário de outros compartilhamentos de SMB com os quais você possa ter interagido, como aqueles
hospedados em um Windows Server, em um servidor Linux Samba ou em um dispositivo NAS, os
compartilhamentos de arquivos do Azure atualmente não dão suporte à autenticação Kerberos no Azure AD
(Active Directory) ou à identidade do AAD (Azure Active Directory), embora estejamos trabalhando nisso.
Sendo assim, você deve acessar o compartilhamento de arquivos do Azure com a chave da conta de
armazenamento que contém o compartilhamento de arquivos do Azure. Uma chave de conta de
armazenamento é uma chave de administrador para uma conta de armazenamento, incluindo permissões
de administrador para todos os arquivos e pastas no compartilhamento de arquivos que você está
acessando e para todos os compartilhamentos de arquivos e outros recursos de armazenamento (BLOBs,
filas, tabelas, etc.) contidos em sua conta de armazenamento. Se isso não é suficiente para sua carga de
trabalho, a Sincronização de Arquivos do Azure pode lidar com a falta de autenticação Kerberos e suporte a
ACL nesse meio-tempo até que o suporte a ACL e a autenticação Kerberos com base em AAD fiquem
disponíveis publicamente.
Um padrão comum para o lift and shift de aplicativos de LOB (linha de negócios) que esperam um
compartilhamento de arquivos SMB para o Azure é usar um compartilhamento de arquivos do Azure como
uma alternativa para a execução de um servidor de arquivos dedicado do Windows em uma VM do Azure.
Uma consideração importante para a migração com êxito de um aplicativo de linha de negócios a fim de
usar um compartilhamento de arquivos do Azure é que muitos aplicativos de linha de negócios são
executados no contexto de uma conta de serviço dedicada com permissões do sistema limitadas em vez de
usar a conta administrativa da VM. Portanto, você deve montar/salvar as credenciais do compartilhamento
de arquivos do Azure a partir do contexto da conta de serviço em vez da conta administrativa.
Persistindo as credenciais de compartilhamento de arquivos do Azure no Windows
O utilitário cmdkey permite que você armazene suas credenciais da conta de armazenamento no Windows.
Isso significa que você não precisa especificar as credenciais quando tenta acessar um compartilhamento de
arquivos do Azure por meio do caminho UNC ou montar o compartilhamento de arquivos do Azure. Para
salvar as credenciais da conta de armazenamento, execute os seguintes comandos do PowerShell,
substituindo <your-storage-account-name> e <your-resource-group-name> quando apropriado.
# These commands require you to be logged into your Azure account, run Login-AzAccount if you haven't
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName
$storageAccountKeys = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name
$storageAccountName
# The cmdkey utility is a command-line (rather than PowerShell) tool. We use Invoke-Expression to allow
us to
# consume the appropriate values from the storage account variables. The value given to the add
parameter of the
# cmdkey utility is the host address for the storage account, <storage-account>.file.core.windows.net
for Azure
# Public Regions. $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as
sovereign
# clouds or Azure Stack deployments, will have different hosts for Azure file shares (and other storage
resources).
Invoke-Expression -Command ("cmdkey /add:$([System.Uri]::new($storageAccount.Context.FileEndPoint).Host)
" + `
"/user:AZURE\$($storageAccount.StorageAccountName) /pass:$($storageAccountKeys[0].Value)")
Você pode verificar que o utilitário cmdkey armazenou a credencial da conta de armazenamento usando o
parâmetro de lista:
cmdkey /list
Se as credenciais do compartilhamento de arquivos do Azure forem armazenadas com êxito, a saída
esperada será semelhante à seguinte (pode haver outras chaves armazenadas na lista):
Currently stored credentials:
Target: Domain:target=<storage-account-host-name>
Type: Domain Password
User: AZURE\<your-storage-account-name>
Agora você deve conseguir montar ou acessar o compartilhamento sem ter que fornecer outras credenciais.
Cenários cmdkey avançados
Há dois cenários adicionais a serem considerados com cmdkey: armazenar credenciais de outro usuário na
máquina, por exemplo, uma conta de serviço, e armazenar credenciais em um computador remoto com a
comunicação remota do PowerShell.
É fácil armazenar as credenciais para outro usuário no computador: quando conectado à sua conta, basta
executar o seguinte comando do PowerShell:
$password = ConvertTo-SecureString -String "<service-account-password>" -AsPlainText -Force

$credential = New-Object System.Management.Automation.PSCredential -ArgumentList "<service-account-
username>", $password
Start-Process -FilePath PowerShell.exe -Credential $credential -LoadUserProfile
Isso abrirá uma nova janela do PowerShell no contexto do usuário de sua conta de serviço (ou conta de
usuário). Você pode usar o utilitário cmdkey conforme descrito acima.
No entanto, não é possível armazenar as credenciais em um computador remoto usando a comunicação
remota do PowerShell, já que cmdkey não permite o acesso ao repositório de credenciais, mesmo para
adições, quando o usuário está conectado por meio da comunicação remota do PowerShell. Recomendamos
fazer logon no computador com a Área de Trabalho Remota.
Como montar o compartilhamento de arquivos do Azure com o PowerShell
Execute os seguintes comandos de uma sessão do PowerShell regular (não elevada) para montar o
compartilhamento de arquivos do Azure. Lembre-se de substituir <your-resource-group-name> ,
<your-storage-account-name> , <your-file-share-name> , e <desired-drive-letter> pelas informações
apropriadas.
$fileShareName = "<your-file-share-name>"
# These commands require you to be logged into your Azure account, run Login-AzAccount if you haven't
$storageAccountKeys = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name
$storageAccountName
$fileShare = Get-AzStorageShare -Context $storageAccount.Context | Where-Object {
$_.Name -eq $fileShareName -and $_.IsSnapshot -eq $false
}
if ($fileShare -eq $null) {

throw [System.Exception]::new("Azure file share not found")
}
# The value given to the root parameter of the New-PSDrive cmdlet is the host address for the storage
account,
# <storage-account>.file.core.windows.net for Azure Public Regions.
$fileShare.StorageUri.PrimaryUri.Host is
# used because non-Public Azure regions, such as sovereign clouds or Azure Stack deployments, will have
different
# hosts for Azure file shares (and other storage resources).
$password = ConvertTo-SecureString -String $storageAccountKeys[0].Value -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential -ArgumentList
"AZURE\$($storageAccount.StorageAccountName)", $password
New-PSDrive -Name <desired-drive-letter> -PSProvider FileSystem -Root
"\\$($fileShare.StorageUri.PrimaryUri.Host)\$($fileShare.Name)" -Credential $credential -Persist
NOTE
O uso da opção -Persist no cmdlet New-PSDrive só permitirá que o compartilhamento de arquivos seja
remontado na inicialização se as credenciais tiverem sido salvas. Você pode salvar as credenciais usando o cmdkey
como descrito anteriormente.
Se desejar, você pode desmontar o compartilhamento de arquivos do Azure usando o cmdlet do PowerShell
a seguir.
Remove-PSDrive -Name <desired-drive-letter>
Como montar o compartilhamento de arquivos do Azure com o Explorador de Arquivos
NOTE
Observe que as instruções a seguir são mostradas no Windows 10 e podem diferir ligeiramente em versões mais
antigas.
1. Abra o Explorador de Arquivos. Isso pode ser feito abrindo o Menu Iniciar ou pressionando o atalho
Win + E.
2. Navegue até o item este computador no lado esquerdo da janela. Isso alterará os menus
disponíveis na faixa de opções. No menu do computador, selecione Mapear unidade de rede .
3. Selecione a letra da unidade e insira o caminho UNC, o formato do caminho
<storageAccountName>.file.core.windows.net/<fileShareName> UNC é. Por exemplo:
anexampleaccountname.file.core.windows.net/example-share-name .
4. Use o nome da conta de armazenamento anexado com AZURE\ como o nome de usuário e uma
chave de conta de armazenamento como a senha.
5. Use o compartilhamento de arquivos do Azure como quiser.
6. Quando quiser desmontar o compartilhamento de arquivos do Azure, clique com o botão direito do
mouse na entrada do compartilhamento em Locais de rede no Explorador de Arquivos e selecione
Desconectar .
Acessar instantâneos de compartilhamento no Windows
Se você tirou um instantâneo de compartilhamento, manual ou automaticamente por meio de um script ou
serviço como o Backup do Azure, veja as versões anteriores de um compartilhamento, um diretório ou um
arquivo específico do compartilhamento de arquivos no Windows. Você pode tirar um instantâneo de
compartilhamento do portal do Azure, Azure PowerShelle CLI do Azure.
Listar versões anteriores
Navegue até o item ou o item pai que precisa ser restaurado. Clique duas vezes para ir até o diretório
desejado. Clique com o botão direito do mouse e selecione Propriedades no menu.
Selecione Versões Anteriores para ver a lista de instantâneos de compartilhamento para esse diretório. A
lista pode levar alguns segundos para carregar, dependendo da velocidade da rede e do número de
instantâneos de compartilhamento no diretório.
Você pode selecionar Abrir para abrir um instantâneo específico.
Restaurar de uma versão anterior

Selecione Restaurar para copiar o conteúdo do diretório inteiro recursivamente no momento da criação do
instantâneo de compartilhamento para o local original.
Protegendo o Windows/Windows Server
Para montar um compartilhamento de arquivos do Azure no Windows, a porta 445 deve estar acessível.
Muitas organizações bloqueiam a porta 445 devido aos riscos de segurança inerentes ao protocolo SMB 1.
SMB 1, também conhecido como CIFS (Common Internet File System), é um protocolo de sistema de
arquivos herdados incluído no Windows e no Windows Server. O SMB 1 é um protocolo desatualizado,
ineficiente e, o mais importante, não seguro. A boa notícia é que os arquivos do Azure não dão suporte a
SMB 1 e todas as versões com suporte do Windows e do Windows Server possibilitam a remoção ou
desabilitação do SMB 1. Recomendamos sempre remover ou desabilitar o cliente e o servidor SMB 1 no
Windows antes de usar os compartilhamentos de arquivos do Azure na produção.
A tabela a seguir fornece informações detalhadas sobre o status do SMB 1 em cada versão do Windows:
STAT US PA DRÃ O DE P ROTO C O LO S

VERSÃ O DO W IN DO W S SM B 1 DESA B IL ITA R/ REM O VER M ÉTO DO
Windows Server 2019 Desabilitado Remover com recurso do Windows
Windows Server, versões 1709 e Desabilitado Remover com recurso do Windows

posteriores
Windows 10, versões 1709 ou Desabilitado Remover com recurso do Windows

posterior
Windows Server 2016 habilitado Remover com recurso do Windows
Windows 10 versões 1507, 1607 e habilitado Remover com recurso do Windows

1703
Windows Server 2012 R2 habilitado Remover com recurso do Windows
Windows 8.1 habilitado Remover com recurso do Windows
Windows Server 2012 habilitado Desabilitar no Registro
Windows Server 2008 R2 habilitado Desabilitar no Registro
Windows 7 habilitado Desabilitar no Registro
Auditando o uso de protocolos SMB 1

Aplica-se ao Windows Server 2019, canal semestral do Windows Server (versões 1709 e 1803),
Windows Server 2016, Windows 10 (versões 1507, 1607, 1703, 1709 e 1803), Windows Server 2012
R2 e Windows 8.1
Antes de remover o protocolo SMB 1 de seu ambiente, audite o uso de SMB 1 para ver se algum cliente será
interrompido pela alteração. Se alguma solicitação for feita em relação a compartilhamentos SMB com
protocolos SMB 1, um evento de auditoria será registrado no log de eventos em
Applications and Services Logs > Microsoft > Windows > SMBServer > Audit .
NOTE
Para habilitar o suporte a auditoria no Windows Server 2012 R2 e no Windows 8.1, instale pelo menos o KB4022720.
Para habilitar a auditoria, execute o seguinte cmdlet em uma sessão do PowerShell com privilégios elevados:
Set-SmbServerConfiguration –AuditSmb1Access $true
Removendo SMB 1 do Windows Server

Aplica-se ao Windows Server 2019, canal semestral do Windows Server (versões 1709 e 1803),
Windows Server 2016, Windows Server 2012 R2
Para remover o SMB 1 de uma instância do Windows Server, execute o seguinte cmdlet em uma sessão do
PowerShell com privilégios elevados:
Remove-WindowsFeature -Name FS-SMB1
Para concluir o processo de remoção, reinicie o servidor.
NOTE
A partir do Windows 10 e do Windows Server versão 1709, o SMB 1 não está instalado por padrão e tem recursos
do Windows diferentes para o servidor SMB 1 e o cliente SMB 1. Recomendamos sempre deixar o servidor SMB 1 (
FS-SMB1-SERVER ) e o cliente SMB 1 ( FS-SMB1-CLIENT ) desinstalados.
Removendo SMB 1 do cliente do Windows

Aplica-se a Windows 10 (versões 1507, 1607, 1703, 1709 e 1803) e Windows 8.1
Para remover o SMB 1 do seu cliente Windows, execute o seguinte cmdlet em uma sessão do PowerShell
com privilégios elevados:
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
Para concluir o processo de remoção, reinicie o computador.

Desabilitando SMB 1 em versões herdadas do Windows/Windows Server
Aplica-se a Windows Server 2012, Windows Server 2008 R2 e Windows 7
O SMB 1 não pode ser completamente removidos em versões herdadas do Windows ou do Windows
Server, mas pode ser desabilitado no Registro. Para desabilitar o SMB 1, crie uma nova chave do registro
SMB1 do tipo DWORD com um valor de 0 em
HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > LanmanServer > Parameters .
Você pode fazer isso facilmente usando também o seguinte cmdlet do PowerShell:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type

DWORD -Value 0 –Force
Depois de criar essa chave do registro, você deverá reiniciar o servidor para desabilitar o SMB 1.
Recursos de SMB
Parar de usar protocolos SMB 1
Produto SMB 1 Clearinghouse
Descobrir SMB 1 em seu ambiente com DSCEA
Desabilitando o SMB 1 com Política de Grupo
Próximas etapas
Veja estes links para obter mais informações sobre o Arquivos do Azure:
Solução de problemas no Windows
Arquivos do Azure é o sistema de arquivos de nuvem de fácil acesso da Microsoft. Os compartilhamentos de

arquivos do Azure podem ser montados em distribuições do Linux usando o cliente de kernel SMB. Este
artigo mostra duas maneiras de montar um compartilhamento de arquivos do Azure: sob demanda com o
comando mount e na inicialização criando uma entrada em /etc/fstab .
A maneira recomendada para montar um compartilhamento de arquivos do Azure no Linux é usando SMB
3,0. Por padrão, os arquivos do Azure exigem criptografia em trânsito, que tem suporte apenas no SMB 3,0.
Os arquivos do Azure também dão suporte ao SMB 2,1, que não dá suporte à criptografia em trânsito, mas
você não pode montar compartilhamentos de arquivos do Azure com o SMB 2,1 de outra região do Azure ou
local por motivos de segurança. A menos que seu aplicativo exija especificamente o SMB 2,1, há pouco motivo
para usá-lo desde que as distribuições do Linux mais populares, lançadas recentemente, dão suporte ao SMB
3,0:
SM B 2. 1 SM B 3. 0
( M O N TA GEN S EM VM S N A M ESM A ( M O N TA GEN S DE REGIÃ O C RUZ A DA E
REGIÃ O DO A Z URE) LO C A IS)
Ubuntu 14.04+ 16.04+
Red Hat Enterprise Linux (RHEL) 7+ 7.5+
CentOS 7+ 7.5+
Debian Mais de 8 Mais de 10
openSUSE 13.2+ 42.3+
SUSE Linux Enterprise Server 12+ 12 SP3+
Se você estiver usando uma distribuição do Linux não listada na tabela acima, poderá verificar se sua
distribuição do Linux dá suporte ao SMB 3,0 com criptografia verificando a versão do kernel do Linux. O SMB
3,0 com criptografia foi adicionado ao kernel do Linux versão 4,11. O uname comando retornará a versão do
kernel do Linux em uso:
uname -r
Pré-requisitos
Verifique se o pacote CIFS-utils está instalado.
O pacote cifs-utils pode ser instalado usando o gerenciador de pacotes na distribuição do Linux
escolhida.
Em distribuições Ubuntu e Debian , use o gerenciador de pacotes do apt :
sudo apt update

sudo apt install cifs-utils
Em Fedora , Red Hat Enterprise Linux 8 + e CentOS 8 + , use o Gerenciador dnf de pacotes:
sudo dnf install cifs-utils
Em versões mais antigas do Red Hat Enterprise Linux e do CentOS , yum use o Gerenciador de
pacotes:
sudo yum install cifs-utils
No openSUSE , use o gerenciador de pacotes do zypper :
sudo zypper install cifs-utils
Em outras distribuições, use o gerenciador de pacotes apropriado ou compile do código-fonte

A versão mais recente da CLI (interface de linha de comando) do Azure. Para obter mais
informações sobre como instalar o CLI do Azure, consulte instalar o CLI do Azure e selecionar o sistema
operacional. Se preferir usar o módulo Azure PowerShell no PowerShell 6 +, você pode, no entanto, as
instruções a seguir são apresentadas para o CLI do Azure.
Verifique se a por ta 445 está aber ta : o SMB se comunica pela porta TCP 445, por isso confira se o
firewall não está bloqueando as portas TCP 445 do computador cliente. Substitua de grupo de
recursos e
resourceGroupName="<your-resource-group>"
storageAccountName="<your-storage-account>"
# This command assumes you have logged in with az login

httpEndpoint=$(az storage account show \
smbPath=$(echo $httpEndpoint | cut -c7-$(expr length $httpEndpoint))
fileHost=$(echo $smbPath | tr -d "/")
nc -zvw3 $fileHost 445
Se a conexão tiver sido bem-sucedida, você verá algo semelhante à seguinte saída:
Connection to <your-storage-account> 445 port [tcp/microsoft-ds] succeeded!
Se não for possível abrir a porta 445 em sua rede corporativa ou se estiver impedido de fazer isso por
um ISP, você poderá usar uma conexão VPN ou o ExpressRoute para contornar a porta 445. Para obter
mais informações, consulte considerações de rede para acesso direto ao compartilhamento de
arquivos do Azure.
Montando o compartilhamento de arquivos do Azure

Para usar um compartilhamento de arquivos do Azure com sua distribuição do Linux, você deve criar um
diretório para servir como o ponto de montagem para o compartilhamento de arquivos do Azure. Um ponto
de montagem pode ser criado em qualquer lugar no seu sistema Linux, mas é uma convenção comum criar
isso em/mnt. Após o ponto de montagem, use o mount comando para acessar o compartilhamento de
arquivos do Azure.
Você pode montar o mesmo compartilhamento de arquivos do Azure para vários pontos de montagem, se
desejar.
Montar o compartilhamento de arquivos do Azure sob demanda com mount
1. Crie uma pasta para o ponto de montagem : <your-resource-group> substitua

<your-storage-account> , e <your-file-share> com as informações apropriadas para seu ambiente:
fileShareName="<your-file-share>"
mntPath="/mnt/$storageAccountName/$fileShareName"
sudo mkdir -p $mntPath
2. Use o comando mount para montar o compar tilhamento de arquivos do Azure . No exemplo
abaixo, as permissões locais do arquivo e da pasta do Linux padrão são 0755, o que significa ler, gravar
e executar para o proprietário (com base no proprietário do Linux de arquivo/diretório), ler e executar
para usuários no grupo proprietário e ler e executar para outras pessoas no sistema. Você pode usar as
uid opções gid de montagem e para definir a ID de usuário e a ID de grupo para a montagem. Você
também pode usar dir_mode e file_mode para definir permissões personalizadas conforme desejado.
Para obter mais informações sobre como definir permissões, consulte notação numérica do UNIX na
Wikipédia.

smbPath=$(echo $httpEndpoint | cut -c7-$(expr length $httpEndpoint))$fileShareName
storageAccountKey=$(az storage account keys list \

sudo mount -t cifs $smbPath $mntPath -o

vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino
NOTE
O comando de montagem acima é montado com SMB 3,0. Se sua distribuição do Linux não oferecer suporte a
SMB 3,0 com criptografia ou se ela der suporte apenas ao SMB 2,1, você só poderá montar de uma VM do
Azure na mesma região que a conta de armazenamento. Para montar o compartilhamento de arquivos do
Azure em uma distribuição do Linux que não dá suporte a SMB 3,0 com criptografia, você precisará desabilitar a
criptografia em trânsito para a conta de armazenamento.
Quando tiver terminado de usar o compartilhamento de arquivos do Azure, você pode usar
sudo umount $mntPath para desmontar o compartilhamento.
Criar um ponto de montagem persistente para o compartilhamento de arquivos do Azure com /etc/fstab
1. Criar uma pasta para o ponto de montagem : uma pasta para um ponto de montagem pode ser
criada em qualquer lugar no sistema de arquivos, mas é uma convenção comum criá-la em/mnt. Por
exemplo, o comando a seguir cria um novo diretório, <your-resource-group> substitui
<your-storage-account> , e <your-file-share> com as informações apropriadas para seu ambiente:
fileShareName="<your-file-share>"
2. Crie um arquivo de credencial para armazenar o nome de usuário (o nome de conta de

armazenamento) e a senha (a chave de conta de armazenamento) para o
compar tilhamento de arquivos.
if [ ! -d "/etc/smbcredentials" ]; then
sudo mkdir "/etc/smbcredentials"
fi

smbCredentialFile="/etc/smbcredentials/$storageAccountName.cred"
if [ ! -f $smbCredentialFile ]; then
echo "username=$storageAccountName" | sudo tee $smbCredentialFile > /dev/null
echo "password=$storageAccountKey" | sudo tee -a $smbCredentialFile > /dev/null
else
echo "The credential file $smbCredentialFile already exists, and was not modified."
fi
3. Alterar as permissões no arquivo de credenciais para que raiz possa ler ou modificar o
arquivo de senha. Como a chave da conta de armazenamento é essencialmente uma senha de super
administrador para a conta de armazenamento, é importante definir as permissões no arquivo de
modo que somente o usuário root possa acessar, para que usuários com privilégios mais baixos não
possam recuperar a chave da conta de armazenamento.
sudo chmod 600 $smbCredentialFile
4. **Use o comando a seguir para acrescentar a seguinte linha /etc/fstab a **: no exemplo abaixo, as
permissões de pasta e arquivo Linux local padrão 0755, que significa leitura, gravação e execução para
o proprietário (com base no proprietário do Linux de arquivo/diretório), leitura e execução para
usuários no grupo proprietário e leitura e execução para outras pessoas no sistema. Você pode usar as
uid opções gid de montagem e para definir a ID de usuário e a ID de grupo para a montagem. Você
também pode usar dir_mode e file_mode para definir permissões personalizadas conforme desejado.
Para obter mais informações sobre como definir permissões, consulte notação numérica do UNIX na
Wikipédia.
smbPath=$(echo $httpEndpoint | cut -c7-$(expr length $httpEndpoint))$fileShareName
if [ -z "$(grep $smbPath\ $mntPath /etc/fstab)" ]; then

echo "$smbPath $mntPath cifs nofail,vers=3.0,credentials=$smbCredentialFile,serverino" | sudo
tee -a /etc/fstab > /dev/null
else
echo "/etc/fstab was not modified to avoid conflicting entries as this Azure file share was
already present. You may want to double check /etc/fstab to ensure the configuration is as
desired."
fi
sudo mount -a
NOTE
O comando de montagem acima é montado com SMB 3,0. Se sua distribuição do Linux não oferecer suporte a
SMB 3,0 com criptografia ou se ela der suporte apenas ao SMB 2,1, você só poderá montar de uma VM do
Azure na mesma região que a conta de armazenamento. Para montar o compartilhamento de arquivos do
Azure em uma distribuição do Linux que não dá suporte a SMB 3,0 com criptografia, você precisará desabilitar a
criptografia em trânsito para a conta de armazenamento.
Usando o autofs para montar automaticamente os compartilhamento (s) de arquivos do Azure

1. Verifique se o pacote do autofs está instalado.
O pacote do autofs pode ser instalado usando o Gerenciador de pacotes na distribuição do Linux de
sua escolha.
Em distribuições Ubuntu e Debian , use o gerenciador de pacotes do apt :
sudo apt update

sudo apt install autofs
Em Fedora , Red Hat Enterprise Linux 8 + e CentOS 8 + , use o Gerenciador dnf de pacotes:
sudo dnf install autofs
Em versões mais antigas do Red Hat Enterprise Linux e do CentOS , yum use o Gerenciador de
pacotes:
sudo yum install autofs
No openSUSE , use o gerenciador de pacotes do zypper :
sudo zypper install autofs
2. Crie um ponto de montagem para os compar tilhamentos :
sudo mkdir /fileshares

3. Criar um novo arquivo de configuração do autofs personalizado
sudo vi /etc/auto.fileshares
4. Adicione as seguintes entradas a/etc/auto.fileshares
echo "$fileShareName -fstype=cifs,credentials=$smbCredentialFile :$smbPath"" > /etc/auto.fileshares
5. Adicione a seguinte entrada a/etc/auto.Master
/fileshares /etc/auto.fileshares --timeout=60
6. Reiniciar o autofs
sudo systemctl restart autofs
7. Acessar a pasta designada para o compar tilhamento
cd /fileshares/$filesharename
Como proteger o Linux

Para montar um compartilhamento de arquivos do Azure no Linux, a porta 445 deve estar acessível. Muitas
organizações bloqueiam a porta 445 devido aos riscos de segurança inerentes ao protocolo SMB 1. O SMB 1,
também conhecido como CIFS (Common Internet File System), é um protocolo de sistema de arquivos
herdado incluído com muitas distribuições do Linux. O SMB 1 é um protocolo desatualizado, ineficiente e, o
mais importante, não seguro. A boa notícia é que os arquivos do Azure não oferecem suporte a SMB 1 e, a
partir do Linux kernel versão 4,18, o Linux possibilita a desabilitação do SMB 1. Sempre é altamente
recomendável desabilitar o SMB 1 em seus clientes Linux antes de usar compartilhamentos de arquivos SMB
em produção.
A partir do kernel do Linux 4,18, o módulo kernel SMB cifs , chamado por motivos herdados, expõe um
novo parâmetro de módulo (muitas vezes conhecido como Parm por várias documentações
disable_legacy_dialects externas), chamado. Embora introduzido no kernel do Linux 4,18, alguns
fornecedores têm reportado essa alteração para os kernels mais antigos aos quais dão suporte. Para sua
conveniência, a tabela a seguir detalha a disponibilidade desse parâmetro de módulo em distribuições
comuns do Linux.
DIST RIB UIÇ Ã O P O DE DESA B IL ITA R O SM B 1
Ubuntu 14.04 – 16.04 Não
Ubuntu 18.04 Sim
Ubuntu 19.04 + Sim
Debian 8-9 Não
Debian 10 + Sim
DIST RIB UIÇ Ã O P O DE DESA B IL ITA R O SM B 1
Fedora 29 + Sim
CentOS 7 Não
CentOS 8 + Sim
Red Hat Enterprise Linux 6. x-7. x Não
Red Hat Enterprise Linux 8 + Sim
openSUSE Leap 15,0 Não
openSUSE Leap 15.1 + Sim
openSUSE Tumbleweed Sim
SUSE Linux Enterprise 11. x-12. x Não
SUSE Linux Enterprise 15 Não
SUSE Linux Enterprise 15,1 Não
Você pode verificar se sua distribuição do Linux dá suporte ao disable_legacy_dialects parâmetro de módulo
por meio do comando a seguir.
sudo modinfo -p cifs | grep disable_legacy_dialects
Esse comando deve gerar a seguinte mensagem:
disable_legacy_dialects: To improve security it may be helpful to restrict the ability to override the
default dialects (SMB2.1, SMB3 and SMB3.02) on mount with old dialects (CIFS/SMB1 and SMB2) since
vers=1.0 (CIFS/SMB1) and vers=2.0 are weaker and less secure. Default: n/N/0 (bool)
Antes de desabilitar o SMB 1, você deve verificar se o módulo SMB não está carregado atualmente no seu
sistema (isso ocorre automaticamente se você tiver montado um compartilhamento SMB). Você pode fazer
isso com o comando a seguir, que não deverá gerar nada se o SMB não for carregado:
lsmod | grep cifs
Para descarregar o módulo, primeiro Desmonte todos os compartilhamentos SMB umount (usando o
comando, conforme descrito acima). Você pode identificar todos os compartilhamentos SMB montados em
seu sistema com o seguinte comando:
mount | grep cifs
Depois de desmontar todos os compartilhamentos de arquivos SMB, é seguro descarregar o módulo. Você
pode fazer isso com o comando modprobe :
sudo modprobe -r cifs
Você pode carregar manualmente o módulo com o SMB 1 descarregado modprobe usando o comando:
sudo modprobe cifs disable_legacy_dialects=Y
Por fim, você pode verificar se o módulo SMB foi carregado com o parâmetro examinando os parâmetros
carregados em /sys/module/cifs/parameters :
cat /sys/module/cifs/parameters/disable_legacy_dialects
Para desabilitar o SMB 1 de forma persistente em distribuições baseadas em Ubuntu e Debian, você deve criar
um novo arquivo (se você ainda não tiver opções personalizadas para outros módulos
/etc/modprobe.d/local.conf ) chamado com a configuração. Você pode fazer isso com o seguinte comando:
echo "options cifs disable_legacy_dialects=Y" | sudo tee -a /etc/modprobe.d/local.conf > /dev/null
Você pode verificar se isso funcionou carregando o módulo SMB:
sudo modprobe cifs

cat /sys/module/cifs/parameters/disable_legacy_dialects
Próximas etapas
Veja estes links para obter mais informações sobre o Arquivos do Azure:
Solução de problemas
Montagem do compartilhamento de arquivos do
Azure no SMB com macOS

arquivos do Azure podem ser montados com o protocolo SMB 3 padrão do setor do macOS El Capitan 10.11 e
versões posteriores. Este artigo mostra duas maneiras diferentes para montar um compartilhamento de
arquivos do Azure no macOS: com a interface do usuário do Finder e usando o Terminal.
NOTE
Antes de montar um compartilhamento de arquivos do Azure no SMB, é recomendável desabilitar a assinatura de
pacote SMB. Isso pode resultar em baixo desempenho ao acessar o compartilhamento de arquivos do Azure no macOS.
Sua conexão SMB será criptografada para que isso não afete a segurança de sua conexão. No terminal, os comandos a
seguir desabilitarão a assinatura de pacotes SMB, conforme descrito por este Artigo do suporte da Apple sobre como
desabilitar a assinatura de pacote SMB:
sudo -s
echo "[default]" >> /etc/nsmb.conf
echo "signing_required=no" >> /etc/nsmb.conf
exit
Pré-requisitos para montar um compartilhamento de arquivos do

Azure no macOS
Nome da conta de armazenamento : para montar um compartilhamento de arquivos do Azure, será
necessário o nome da conta de armazenamento.
Chave de conta de armazenamento : Para montar um compartilhamento de arquivos do Azure, você
precisará da chave de armazenamento primária (ou secundária). Atualmente, as chaves SAS não têm
suporte para montagem.
Cer tifique-se de que a por ta 445 está aber ta : SMB se comunica pela porta TCP 445. No
computador cliente (Mac), verifique se o firewall não está bloqueando a porta TCP 445.
Montar um compartilhamento de arquivos do Azure por meio do

Localizador
1. Abrir o Localizador : o Localizador é aberto no macOS por padrão, mas você pode garantir que ele é o
aplicativo selecionado clicando no "ícone de rosto do macOS" no encaixe:
2. Selecione "conectar ao ser vidor" no menu "ir" \\ : usando o caminho UNC dos pré-requisitos,
converta a barra invertida dupla inicial () para smb:// e todas as barras invertidas ( \ ) para
encaminhar barras ( / ). O link deve ser semelhante ao seguinte:
3. Use o nome da conta de armazenamento e a chave da conta de armazenamento quando
solicitado a fornecer um nome de usuário e senha : ao clicar em "Conectar" na caixa de diálogo
"Conectar ao servidor", você será solicitado a fornecer o nome de usuário e senha (Isso será preenchido
automaticamente com seu nome de usuário macOS). Você tem a opção de colocar a chave da conta de
armazenamento/nome da conta de armazenamento em seu conjunto de chaves do macOS.
4. Use o compar tilhamento de arquivos do Azure conforme desejado : depois de substituir o
nome do compartilhamento e a chave da conta de armazenamento em para o nome de usuário e a
senha, o compartilhamento será montado. Você pode usar isso como você normalmente usa um
compartilhamento de arquivo/pasta local, incluindo a opção de arrastar e soltar arquivos no
compartilhamento de arquivos:
Montar um compartilhamento de arquivos do Azure por meio do

Terminal
1. Substitua <storage-account-name> pelo nome de sua conta de armazenamento. Quando solicitado,
forneça a chave da conta de armazenamento como a senha.
mount_smbfs //<storage-account-name>@<storage-account-name>.file.core.windows.net/<share-name>
<desired-mount-point>
2. Use o compar tilhamento de arquivos do Azure conforme desejado : o compartilhamento de

arquivos do Azure será montado no ponto de montagem especificado pelo comando anterior.
Próximas etapas
Veja estes links para obter mais informações sobre o Arquivos do Azure.
Artigo de suporte da Apple - Como conectar-se com o compartilhamento de arquivos em seu Mac
Solução de problemas no Windows
Solução de problemas no Linux
Configurar pontos de extremidade de rede dos
Arquivos do Azure
Os Arquivos do Azure fornecem dois tipos principais de pontos de extremidade para acessar compartilhamentos
de arquivos do Azure:
Pontos de extremidade públicos, que têm um endereço IP público e podem ser acessados de qualquer lugar do
mundo.
Pontos de extremidade privados, que existem em uma rede virtual e têm um endereço IP privado dentro do
espaço de endereço dessa rede virtual.
Pontos de extremidade públicos e privados existem na conta de armazenamento do Azure. Uma conta de
armazenamento é um constructo de gerenciamento que representa um pool compartilhado de armazenamento
no qual você pode implantar vários compartilhamentos de arquivos bem como outros recursos de
armazenamento, como filas ou contêineres de blob.
Este artigo se concentra em como configurar os pontos de extremidade de uma conta de armazenamento para
acessar o compartilhamento de arquivos do Azure diretamente. A maior parte dos detalhes fornecidos neste
documento também se aplica a como a Sincronização de Arquivos do Azure interopera com pontos de
extremidade públicos e privados para a conta de armazenamento. No entanto, para saber mais sobre as
considerações de rede para uma implantação da Sincronização de Arquivos do Azure, confira Configurações de
proxy e firewall da Sincronização de Arquivos do Azure.
É recomendável ler as Considerações de rede dos Arquivos do Azure antes de ler este guia de instruções.
Pré-requisitos
Este artigo pressupõe que você já tenha criado uma assinatura do Azure. Se você ainda não tiver uma
assinatura, crie uma conta gratuita antes de começar.
Este artigo pressupõe que você já tenha criado um compartilhamento de arquivo do Azure em uma conta de
armazenamento à qual deseja se conectar do local. Para saber como criar um compartilhamento de arquivo do
Azure, confira Criar um compartilhamento de arquivo do Azure.
Se pretende usar o Azure PowerShell, instale a versão mais recente.
Se pretende usar a CLI do Azure, instale a versão mais recente.
Criar um ponto de extremidade privado

A criação de um ponto de extremidade privado para sua conta de armazenamento resultará na implantação dos
seguintes recursos do Azure:
Um ponto de extremidade privado : um recurso do Azure que representa o ponto de extremidade privado
da conta de armazenamento. Considere-o como um recurso que conecta uma conta de armazenamento e uma
interface de rede.
Uma NIC (adaptador de rede) : o adaptador de rede que mantém um endereço IP privado dentro da rede
virtual/sub-rede especificada. É exatamente o mesmo recurso que é implantado quando você implanta uma
máquina virtual. No entanto, em vez de ser atribuído a uma VM, ele pertence ao ponto de extremidade
privado.
Uma zona DNS privada : se você nunca tiver implantado um ponto de extremidade privado para essa rede
virtual, uma nova zona DNS privada será implantada em sua rede virtual. Um registro DNS A também será
criado para a conta de armazenamento nesta zona DNS. Se você já tiver implantado um ponto de extremidade
privado nessa rede virtual, um novo registro A para a conta de armazenamento será adicionado à zona DNS
existente. A implantação da zona DNS é opcional, mas altamente recomendada e necessária se você estiver
montando os compartilhamentos de arquivo do Azure com uma entidade de serviço do AD ou usando a API
FileREST.
NOTE
Este artigo usa o sufixo DNS da conta de armazenamento para as regiões Públicas do Azure, core.windows.net . Esse
comentário também se aplica a nuvens soberanas do Azure, como a nuvem do Governo dos EUA para Azure e a nuvem do
Azure China – só substitua os sufixos apropriados para seu ambiente.
Portal
PowerShell
CLI do Azure
Navegue até a conta de armazenamento para a qual gostaria de criar o ponto de extremidade privado. Na
sumário da conta de armazenamento, selecione Conexões de ponto de extremidade privado e, em seguida,
+ Ponto de extremidade privado para criar um ponto de extremidade privado.
O assistente resultante tem várias páginas a serem preenchidas.

Na folha Básico , selecione o grupo de recursos, o nome e a região desejados para o ponto de extremidade
privado. Essas configurações podem ter o valor que você quiser, elas não precisam corresponder à conta de
armazenamento, embora seja necessário criar o ponto de extremidade privado na mesma região que a rede
virtual na qual você deseja criá-lo.
Na folha Recurso , selecione o botão de opção para Conectar-se a um recurso do Azure em meu diretório .
Em Tipo de recurso , selecione Microsoft.Storage/storageAccounts . O campo Recurso é a conta de
armazenamento com o compartilhamento de arquivo do Azure ao qual você deseja se conectar. O sub-recurso de
destino é arquivo , uma vez que se trata dos Arquivos do Azure.
A folha Configuração permite que você selecione a rede virtual específica e a sub-rede à qual deseja adicionar o
ponto de extremidade privado. Selecione a rede virtual criada acima. Você precisa selecionar uma sub-rede
diferente daquela à qual adicionou o ponto de extremidade de serviço acima. A folha Configuração também
contém as informações para criar/atualizar a zona DNS privada. Recomendamos usar a zona
privatelink.file.core.windows.net padrão.
Clique em Examinar + Criar para criar o ponto de extremidade privado.

Se tiver uma máquina virtual dentro de sua rede virtual ou se tiver configurado o encaminhamento de DNS
conforme descrito aqui, você poderá testar se o ponto de extremidade privado foi instalado corretamente
executando os seguintes comandos do PowerShell, na linha de comando ou no terminal (funciona para Windows,
Linux e macOS). Substitua <storage-account-name> pelo nome da conta de armazenamento apropriada:
nslookup <storage-account-name>.file.core.windows.net
Se tudo tiver funcionado corretamente, você deverá ver a seguinte saída, em que 192.168.0.5 é o endereço IP
privado do ponto de extremidade privado em sua rede virtual (saída mostrada para o Windows):
Server: UnKnown
Address: 10.2.4.4
Non-authoritative answer:
Name: storageaccount.privatelink.file.core.windows.net
Address: 192.168.0.5
Aliases: storageaccount.file.core.windows.net
Restringir o acesso ao ponto de extremidade público

Você pode restringir o acesso ao ponto de extremidade público usando as configurações de firewall da conta de
armazenamento. Em geral, a maioria das políticas de firewall para uma conta de armazenamento restringirá o
acesso de rede a uma ou mais redes virtuais. Há duas abordagens para a restrição do acesso a uma conta de
armazenamento a uma rede virtual:
Criar um ou mais pontos de extremidade privados para a conta de armazenamento e restringir todo o acesso
ao ponto de extremidade público. Com isso, apenas o tráfego proveniente de dentro das redes virtuais
desejadas poderá acessar os compartilhamentos de arquivo do Azure dentro da conta de armazenamento.
Restrinja o ponto de extremidade público a uma ou mais redes virtuais. Isso funciona usando uma
funcionalidade da rede virtual denominada pontos de extremidade de serviço. Quando você restringir o
tráfego a uma conta de armazenamento por meio de um ponto de extremidade de serviço, você ainda
acessará a conta de armazenamento por meio do endereço IP público.
Restringir todo o acesso ao ponto de extremidade público
Quando todo o acesso ao ponto de extremidade público está restrito, a conta de armazenamento ainda pode ser
acessada por meio de seus pontos de extremidade privados. Caso contrário, as solicitações válidas para o ponto
de extremidade público da conta de armazenamento serão rejeitadas.
Portal
PowerShell
CLI do Azure
Navegue até a conta de armazenamento para a qual gostaria de restringir todo o acesso ao ponto de extremidade
público. No sumário da conta de armazenamento, selecione Firewalls e redes vir tuais .
Na parte superior da página, selecione o botão de opção Redes selecionadas . Isso exibirá várias configurações
para controlar a restrição do ponto de extremidade público. Marque Permitir que ser viços Microsoft
confiáveis acessem esta conta de ser viço para permitir que serviços Microsoft confiáveis, como a
Sincronização de Arquivos do Azure, acessem a conta de armazenamento.
Restringir o acesso ao ponto de extremidade público para redes virtuais específicas
Ao restringir a conta de armazenamento para redes virtuais específicas, você permite solicitações ao ponto de
extremidade público de dentro das redes virtuais especificadas. Isso funciona usando uma funcionalidade da rede
virtual denominada pontos de extremidade de serviço. Isso pode ser usado com ou sem pontos de extremidade
privados.
Portal
PowerShell
CLI do Azure
Navegue até a conta de armazenamento para a qual gostaria de restringir o ponto de extremidade público para
redes virtuais específicas. No sumário da conta de armazenamento, selecione Firewalls e redes vir tuais .
Na parte superior da página, selecione o botão de opção Redes selecionadas . Isso exibirá várias configurações
para controlar a restrição do ponto de extremidade público. Clique em + Adicionar rede vir tual existente para
selecionar a rede virtual específica que deve ter permissão para acessar a conta de armazenamento por meio do
ponto de extremidade público. Para isso, será necessário selecionar uma rede virtual e uma sub-rede para essa
rede virtual.
Marque Permitir que ser viços Microsoft confiáveis acessem esta conta de ser viço para permitir que
serviços Microsoft confiáveis, como a Sincronização de Arquivos do Azure, acessem a conta de armazenamento.
Confira também
Como configurar o encaminhamento de DNS para Arquivos do Azure
Configurando a VPN S2S para os Arquivos do Azure
Como configurar o encaminhamento de DNS para
Arquivos do Azure
Os Arquivos do Azure permitem que você crie pontos de extremidade privados para as contas de
armazenamento que contêm seus compartilhamentos de arquivos. Embora sejam úteis para muitas finalidades
diferentes, os pontos de extremidade privados são especialmente úteis para se conectar aos compartilhamentos
de arquivos do Azure da rede local usando uma conexão VPN ou do ExpressRoute com emparelhamento
privado.
Para que as conexões com a conta de armazenamento passem pelo seu túnel de rede, o FQDN (nome de
domínio totalmente qualificado) da conta de armazenamento precisa ser resolvido para o endereço IP privado
do ponto de extremidade privado. Para fazer isso, você precisa encaminhar o sufixo do ponto de extremidade de
armazenamento ( core.windows.net para regiões de nuvem pública) para o serviço de DNS privado do Azure
acessível de dentro de sua rede virtual. Este guia mostrará como configurar encaminhamento de DNS para que
ele seja resolvido corretamente para o endereço IP do ponto de extremidade privado de sua conta de
armazenamento.
É altamente recomendável que você leia Planejando uma implantação dos Arquivos do Azure e Considerações
de rede dos Arquivos do Azure antes de seguir as etapas descritas neste artigo.
Visão geral
Os Arquivos do Azure fornecem dois tipos principais de pontos de extremidade para acessar compartilhamentos
de arquivos do Azure:
Pontos de extremidade públicos, que têm um endereço IP público e podem ser acessados de qualquer lugar
do mundo.
Pontos de extremidade privados, que existem em uma rede virtual e têm um endereço IP privado dentro do
espaço de endereço dessa rede virtual.
Pontos de extremidade públicos e privados existem na conta de armazenamento do Azure. Uma conta de
armazenamento é um constructo de gerenciamento que representa um pool compartilhado de armazenamento
no qual você pode implantar vários compartilhamentos de arquivos bem como outros recursos de
armazenamento, como filas ou contêineres de blob.
Toda conta de armazenamento tem um FQDN (nome de domínio totalmente qualificado). Para as regiões de
nuvem pública, esse FQDN segue o padrão storageaccount.file.core.windows.net , em que storageaccount é o
nome da conta de armazenamento. Quando você faz solicitações para esse nome, como ao montar o
compartilhamento em sua estação de trabalho usando SMB, o sistema operacional executa uma pesquisa de
DNS para resolver o nome de domínio totalmente qualificado para um endereço IP que pode ser usado para
envio das solicitações SMB.
Por padrão, storageaccount.file.core.windows.net é resolvido para o endereço IP do ponto de extremidade
público. O ponto de extremidade público de uma conta de armazenamento é hospedado em um cluster de
armazenamento do Azure que hospeda os pontos de extremidade públicos de muitas outras contas de
armazenamento. Quando você cria um ponto de extremidade privado, uma zona DNS privada é vinculada à rede
virtual à qual ele foi adicionado, com um registro CNAME que mapeia storageaccount.file.core.windows.net
para uma entrada de registro A para o endereço IP privado do ponto de extremidade privado de sua conta de
armazenamento. Isso permite que você use o FQDN storageaccount.file.core.windows.net na rede virtual e faça
com que ele seja resolvido para o endereço IP do ponto de extremidade privado.
Como nosso objetivo final é acessar os compartilhamentos de arquivos do Azure hospedados na conta de
armazenamento do local usando um túnel de rede, como uma conexão VPN ou do ExpressRoute, você precisa
configurar seus servidores DNS locais para encaminhar solicitações feitas ao serviço do Arquivos do Azure para
o serviço de DNS privado do Azure. Para fazer isso, você precisa configurar o encaminhamento condicional de
*.core.windows.net (ou o sufixo de ponto de extremidade de armazenamento apropriado para as nuvens
nacionais da China, da Alemanha ou do Governo dos EUA) para um servidor DNS hospedado em sua rede
virtual do Azure. Esse servidor DNS, em seguida, encaminhará recursivamente a solicitação para o serviço DNS
privado do Azure, que resolverá o nome de domínio totalmente qualificado da conta de armazenamento para o
endereço IP privado apropriado.
Para configurar o encaminhamento de DNS para os Arquivos do Azure, será necessário executar uma máquina
virtual para hospedar um servidor DNS para encaminhar as solicitações. No entanto, essa etapa é realizada
apenas uma vez para todos os compartilhamentos de arquivos do Azure hospedados em sua rede virtual. Além
disso, esse requisito não é exclusivo dos Arquivos do Azure – qualquer serviço do Azure com suporte para
pontos de extremidade privados que você desejar acessar do local poderá usar o encaminhamento de DNS que
você vai configurar neste guia: Armazenamento de Blobs do Azure, SQL do Azure, Cosmos DB etc.
Este guia mostra as etapas para configurar o encaminhamento de DNS para o ponto de extremidade de
armazenamento do Azure, sendo assim, além dos Arquivos do Azure, as solicitações de resolução de nomes DNS
para todos os outros serviços de Armazenamento do Azure (Armazenamento de Blobs do Azure,
Armazenamento de Tabelas do Azure, Armazenamento de Filas do Azure etc.) serão encaminhados para o
serviço DNS privado do Azure. Pontos de extremidade adicionais para outros serviços do Azure também
poderão ser adicionados, se desejado. O encaminhamento de DNS de volta para seus servidores DNS locais
também será configurado, permitindo que os recursos de nuvem em sua rede virtual (como um servidor DFS-N)
resolvam nomes de computadores locais.
Pré-requisitos
Antes de configurar o encaminhamento de DNS para os Arquivos do Azure, você precisa concluir as seguintes
etapas:
Uma conta de armazenamento contendo um compartilhamento de arquivo do Azure que você gostaria de
montar. Para saber como criar uma conta de armazenamento e um compartilhamento de arquivo do Azure,
confira Criar um compartilhamento de arquivos do Azure.
Um ponto de extremidade privado para a conta de armazenamento. Para saber como criar um ponto de
extremidade privado para os Arquivos do Azure, confira Criar um ponto de extremidade privado.
A versão mais recente do módulo do Azure PowerShell.
IMPORTANT
Este guia pressupõe que você esteja usando o servidor DNS no Windows Server em seu ambiente local. Todas as etapas
descritas neste guia são possíveis com qualquer servidor DNS, não apenas com o servidor DNS do Windows.
Configurando manualmente o encaminhamento de DNS

Se já tem servidores DNS em funcionamento em sua rede virtual do Azure, ou se simplesmente prefere
implantar suas próprias máquinas virtuais para os servidores DNS seguindo qualquer metodologia adotada por
sua organização, você pode configurar o DNS manualmente com os cmdlets do PowerShell do servidor DNS
interno.
Nos servidores DNS locais, crie um encaminhador condicional usando Add-DnsServerConditionalForwarderZone .
Esse encaminhador condicional precisa ser implantado em todos os servidores DNS locais para que seja capaz
de encaminhar corretamente o tráfego para o Azure. Lembre-se de substituir <azure-dns-server-ip> pelos
endereços IP adequados para seu ambiente.
$vnetDnsServers = "<azure-dns-server-ip>", "<azure-dns-server-ip>"
$storageAccountEndpoint = Get-AzContext | `
Select-Object -ExpandProperty Environment | `
Select-Object -ExpandProperty StorageEndpointSuffix
Add-DnsServerConditionalForwarderZone `
-Name $storageAccountEndpoint `
-MasterServers $vnetDnsServers
Nos servidores DNS de sua rede virtual do Azure, você também precisará configurar um encaminhador de
modo que as solicitações para a zona DNS da conta de armazenamento sejam direcionadas para o serviço DNS
privado do Azure, que usa o endereço IP reservado 168.63.129.16 . (Lembre-se de popular
$storageAccountEndpoint se estiver executando os comandos em uma sessão diferente do PowerShell.)
Add-DnsServerConditionalForwarderZone `
-Name $storageAccountEndpoint `
-MasterServers "168.63.129.16"
Usando o módulo Híbrido dos Arquivos do Azure para configurar o

encaminhamento de DNS
Para facilitar ao máximo a configuração do encaminhamento de DNS, fornecemos automação no módulo
Híbrido dos Arquivos do Azure. Os cmdlets fornecidos para manipular o DNS neste módulo ajudarão você a
implantar servidores DNS em sua rede virtual do Azure e a atualizar seus servidores DNS locais para
encaminhá-los.
Se nunca usou o módulo Híbrido dos Arquivos do Azure, você precisa instalá-lo em sua estação de trabalho.
Baixe a versão mais recente do módulo Híbrido do PowerShell dos Arquivos do Azure:
# Unzip the downloaded file

Expand-Archive -Path AzFilesHybrid.zip
# Change the execution policy to unblock importing AzFilesHybrid.psm1 module

Set-ExecutionPolicy -ExecutionPolicy Unrestricted
# Navigate to where AzFilesHybrid is unzipped and stored and run to copy the files into your path
.\AzFilesHybrid\CopyToPSPath.ps1
# Import AzFilesHybrid module

Import-Module -Name AzFilesHybrid
A implantação da solução de encaminhamento de DNS tem duas etapas, criar um conjunto de regras de
encaminhamento de DNS, que define a quais serviços do Azure você deseja encaminhar solicitações, e a
implantação de fato dos encaminhadores de DNS.
O exemplo a seguir encaminha as solicitações para a conta de armazenamento, inclusive solicitações para os
Arquivos do Azure, o Armazenamento de Blobs do Azure, o Armazenamento de Tabelas do Azure e o
Armazenamento de Filas do Azure. Se desejar, você pode adicionar o encaminhamento para serviços adicionais
do Azure por meio do parâmetro -AzureEndpoints do cmdlet New-AzDnsForwardingRuleSet . Lembre-se de
substituir <virtual-network-resource-group> , <virtual-network-name> , e <subnet-name> pelos valores adequados
para seu ambiente.
# Create a rule set, which defines the forwarding rules
$ruleSet = New-AzDnsForwardingRuleSet -AzureEndpoints StorageAccountEndpoint
# Deploy and configure DNS forwarders

New-AzDnsForwarder `
-DnsForwardingRuleSet $ruleSet `
-VirtualNetworkResourceGroupName "<virtual-network-resource-group>" `
-VirtualNetworkName "<virtual-network-name>" `
-VirtualNetworkSubnetName "<subnet-name>"
Além disso, você pode achar útil/necessário fornecer vários parâmetros adicionais:
N O M E DO PA RÂ M ET RO TYPE DESC RIÇ Ã O
DnsServerResourceGroupName string Por padrão, os servidores DNS serão

implantados no mesmo grupo de
recursos que a rede virtual. Se isso não
for desejado, esse parâmetro permitirá
que você escolha um grupo de
recursos alternativo no qual eles serão
implantados.
DnsForwarderRootName string Por padrão, os servidores DNS

implantados no Azure têm os nomes
DnsFwder-* , em que o asterisco é
populado por um iterador. Esse
parâmetro altera a raiz do nome (ou
seja, DnsFwder ).
VmTemporaryPassword SecureString Por padrão, uma senha aleatória é

escolhida para a conta padrão
temporária que uma VM tem antes de
ser ingressada no domínio. Após o
ingresso no domínio, a conta padrão é
desabilitada.
DomainToJoin string O domínio no qual ingressar as VMs

deo DNS. Por padrão, esse domínio é
escolhido com base no domínio do
computador em que você está
executando os cmdlets.
DnsForwarderRedundancyCount int O número de VMs de DNS a serem

implantadas em sua rede virtual. Por
padrão, New-AzDnsForwarder
implanta dois servidores DNS em sua
rede virtual do Azure, em um conjunto
de disponibilidade, para garantir a
redundância. Esse número pode ser
modificado conforme desejado.
OnPremDnsHostNames HashSet<string> Uma lista especificada manualmente de

nomes de host DNS locais nos quais
criar encaminhadores. Esse parâmetro
é útil quando você não deseja aplicar
encaminhadores em todos os
servidores DNS locais, por exemplo,
quando você tem um intervalo de
clientes com nomes DNS especificados
manualmente.
N O M E DO PA RÂ M ET RO TYPE DESC RIÇ Ã O
Credential PSCredential Uma credencial a ser usada ao atualizar

os servidores DNS. Isso é útil quando a
conta de usuário com a qual você fez
logon não tem permissões para
modificar as configurações de DNS.
SkipParentDomain SwitchParameter Por padrão, os encaminhadores de

DNS são aplicados ao domínio de nível
mais alto que existe no ambiente. Por
exemplo, se
northamerica.corp.contoso.com for
um domínio filho de
corp.contoso.com , o encaminhador
será criado para os servidores DNS
associados a corp.contoso.com . Esse
parâmetro fará com que os
encaminhadores sejam criados em
northamerica.corp.contoso.com .
Confirmar encaminhadores de DNS

Antes de testar se os encaminhadores de DNS foram aplicados com êxito, é recomendável limpar o cache DNS
da estação de trabalho local usando Clear-DnsClientCache . Para testar se você pode resolver com êxito o nome
de domínio totalmente qualificado de sua conta de armazenamento, use Resolve-DnsName ou nslookup .
# Replace storageaccount.file.core.windows.net with the appropriate FQDN for your storage account.
# Note the proper suffix (core.windows.net) depends on the cloud your deployed in.
Resolve-DnsName -Name storageaccount.file.core.windows.net
Se a resolução de nomes for bem-sucedida, você verá que o endereço IP resolvido corresponde ao endereço IP
de sua conta de armazenamento.

---- ---- --- ------- --------
storageaccount.file.core.windows. CNAME 29 Answer csostoracct.privatelink.file.core.windows.net
net
Name : storageaccount.privatelink.file.core.windows.net
QueryType : A
TTL : 1769
Section : Answer
IP4Address : 192.168.0.4
Se já tiver configurado uma conexão VPN ou do ExpressRoute, você também poderá usar Test-NetConnection
para ver que uma conexão TCP pode ser estabelecida com êxito em sua conta de armazenamento.
Test-NetConnection -ComputerName storageaccount.file.core.windows.net -CommonTCPPort SMB
Confira também
Configurar pontos de extremidade de rede dos Arquivos do Azure
Configurar uma VPN Site a Site para uso com os
Arquivos do Azure
Você pode usar uma conexão de VPN S2S (Site a Site) para montar compartilhamentos de arquivo do Azure de
sua rede local, sem precisar abrir a porta 445. Você pode configurar uma VPN Site a Site usando o Gateway de
VPN do Azure, que é um recurso do Azure que oferece serviços de VPN e é implantado em um grupo de recursos
em conjunto com contas de armazenamento ou outros recursos do Azure.
Recomendamos que você leia Visão geral da rede nos Arquivos do Azure antes de continuar este tutorial para ver
uma discussão completa a respeito das opções de rede disponíveis para os Arquivos do Azure.
O artigo detalha as etapas de configuração de uma VPN Site a Site para montar compartilhamentos de arquivo
do Azure diretamente no local. Se você deseja encaminhar o tráfego de sincronização para a Sincronização de
Arquivos do Azure usando uma VPN Site a Site, confira Definir configurações de proxy e firewall da Sincronização
de Arquivos do Azure.
Pré-requisitos
Um compartilhamento de arquivos do Azure que você gostaria de montar no local. Os compartilhamentos
de arquivo do Azure são implantados em contas de armazenamento, que são constructos de
gerenciamento que representam um pool compartilhado de armazenamento no qual você pode implantar
vários compartilhamentos de arquivo bem como outros recursos de armazenamento, como filas ou
contêineres de blobs. Você pode aprender mais sobre como implantar compartilhamentos de arquivo do
Azure e contas de armazenamento em Criar um compartilhamento de arquivo do Azure.
Um ponto de extremidade privado para a conta de armazenamento contendo o compartilhamento de
arquivo do Azure que você deseja montar localmente. Para saber mais sobre como criar um ponto de
extremidade privado, consulte Configuração de pontos de extremidades de rede do serviço Arquivos do
Azure.
Um dispositivo de rede ou servidor em seu datacenter local compatível com o Gateway de VPN do Azure.
Os Arquivos do Azure são independentes do dispositivo de rede local escolhido, mas o Gateway de VPN do
Azure mantém uma lista de dispositivos testados. Dispositivos de rede diferentes oferecem recursos,
características de desempenho e funcionalidades de gerenciamento diferentes, portanto, considere isso ao
selecionar um dispositivo de rede.
Se você não tiver um dispositivo de rede, o Windows Server tem uma Função de Servidor interna, o RRAS
(Roteamento e Acesso Remoto), que poderá ser usada como o dispositivo de rede local. Para saber mais
sobre como configurar o Roteamento e Acesso Remoto no Windows Server, consulte Gateway de RAS.
Adicionar conta de armazenamento à VNet

Na portal do Azure, navegue até a conta de armazenamento que contém o compartilhamento de arquivo do
Azure que você deseja montar no local. No sumário da conta de armazenamento, selecione a entrada Firewalls e
redes vir tuais . A menos que você tenha adicionado uma rede virtual à sua conta de armazenamento quando ela
foi criada, o painel resultante deverá ter o botão de opção Permitir acesso de para Todas as redes
selecionado.
Para adicionar sua conta de armazenamento à rede virtual desejada, selecione Redes selecionadas . No subtítulo
Redes vir tuais , clique em + Adicionar rede vir tual existente ou + Adicionar nova rede vir tual ,
dependendo do estado desejado. A criação de uma nova rede virtual resultará na criação de um novo recurso do
Azure. O recurso de VNet novo ou existente não precisa estar no mesmo grupo de recursos ou assinatura que a
conta de armazenamento. No entanto, ele precisa estar na mesma região que a conta de armazenamento, e o
grupo de recursos e a assinatura em que você implantar a VNet deverão corresponder àqueles em que você
implantará o Gateway de VPN.
Se você adicionar uma rede virtual existente, será solicitado que selecione uma ou mais sub-redes da rede virtual
à qual a conta de armazenamento deverá ser adicionada. Se selecionar uma nova rede virtual, você criará uma
sub-rede como parte da criação da rede virtual e posteriormente poderá adicionar mais usando o recurso do
Azure resultante para a rede virtual.
Se você não tiver adicionado uma conta de armazenamento à sua assinatura, o ponto de extremidade do serviço
Microsoft.Storage precisará ser adicionado à rede virtual. Isso pode levar algum tempo, e até que a operação seja
concluída, você não poderá acessar os compartilhamentos de arquivos do Azure dentro dessa conta de
armazenamento, nem mesmo usando a conexão VPN.
Implantar um Gateway de VPN do Azure

No sumário do portal do Azure, selecione Criar um novo recurso e pesquise Gateway de rede virtual. O
gateway de rede virtual deve estar na mesma assinatura, região do Azure e grupo de recursos que a rede virtual
implantada na etapa anterior (observe que o grupo de recursos é selecionado automaticamente quando a rede
virtual é escolhida).
Para implantação de um Gateway de VPN do Azure, você deve preencher os seguintes campos:
Name : o nome do recurso do Azure para o Gateway de VPN. Esse nome pode ser qualquer nome que você
acha útil para seu gerenciamento.
Região : a região na qual o Gateway de VPN será implantado.
Tipo de gateway : para implantar uma VPN Site a Site, você precisa selecionar VPN .
Tipo de VPN : você pode escolher Baseado em Rota* ou Baseado em Política , dependendo de seu
dispositivo VPN. VPNs baseadas em rota dão suporte a IKEv2, enquanto VPNs baseadas em política dão
suporte apenas a IKEv1. Para saber mais sobre os dois tipos de gateways de VPN, confira Sobre gateways VPN
com base em políticas e rotas
SKU : a SKU controla o número de túneis de Site a Site permitidos e o desempenho desejado da VPN. Para
selecionar o SKU apropriado para seu caso de uso, consulte a lista SKU do Gateway. A SKU do Gateway de
VPN pode ser alterada posteriormente se necessário.
Rede vir tual : a rede virtual que você criou na etapa anterior.
Endereço IP público : o endereço IP do Gateway de VPN que será exposto à Internet. Provavelmente, você
precisará criar um novo endereço IP. No entanto, você também poderá usar um endereço IP não utilizado
existente se isso for apropriado. Se você optar por Criar novo , um novo recurso do Azure de endereço IP será
criado no mesmo grupo de recursos que o Gateway de VPN, e o nome do endereço IP público será o
nome do endereço IP recém-criado. Se selecionar Usar existente , você deverá selecionar o endereço IP não
utilizado existente.
Habilitar o modo ativo-ativo : selecione Habilitado apenas se você estiver criando uma configuração de
gateway ativa-ativa; caso contrário, deixe Desabilitado selecionado. Para saber mais sobre o modo ativo-
ativo, confira Conectividade Altamente Disponível entre os Locais e VNet com VNet.
Configurar BGP ASN : selecione Habilitado apenas se sua configuração exigir essa configuração
especificamente. Para saber mais sobre essa configuração, confira Sobre o BGP com o Gateway de VPN do
Azure.
Selecione Examinar + criar para criar o Gateway de VPN. Um Gateway de VPN pode levar até 45 minutos para
ser criado e implantado totalmente.
Criar um gateway de rede local para seu gateway local
Um gateway de rede local é um recurso do Azure que representa seu dispositivo de rede local. No sumário do
portal do Azure, selecione Criar um novo recurso e pesquise Gateway de rede local. O gateway de rede local é
um recurso do Azure que será implantado em conjunto com sua conta de armazenamento, rede virtual e
Gateway de VPN, mas não precisa estar no mesmo grupo de recursos ou assinatura que a conta de
armazenamento.
Para implantação do recurso de gateway de rede local, você deve preencher os seguintes campos:
Name : o nome do recurso do Azure para o gateway de rede local. Esse nome pode ser qualquer nome que
você acha útil para seu gerenciamento.
Endereço IP : o endereço IP público do seu gateway local.
Espaço de endereço : os intervalos de endereços para a rede que é representada por esse gateway de rede
local. Você pode adicionar vários intervalos de endereços, mas verifique se os intervalos que você especificar
aqui não se sobrepõem aos intervalos de outras redes com que você deseja se conectar.
Configurar as definições de BGP ASN : defina configurações de BGP somente se sua configuração exigir.
Para saber mais sobre essa configuração, confira Sobre o BGP com o Gateway de VPN do Azure.
Assinatura : a assinatura desejada. Ela não precisa corresponder à assinatura usada para o Gateway de VPN
ou a conta de armazenamento.
Grupo de recursos : o grupo de recursos desejado. Ele não precisa corresponder ao grupo de recursos usado
para o Gateway de VPN ou a conta de armazenamento.
Localização : a região do Azure em que o recurso de gateway de rede local deve ser criado. Ela deve
corresponder à região que você selecionou para o Gateway de VPN e a conta de armazenamento.
Selecione Criar para criar o gateway de rede local.
Configurar um dispositivo de rede local

As etapas específicas para configurar seu dispositivo de rede local dependem do dispositivo de rede selecionado
pela sua organização. Dependendo do dispositivo que sua organização escolheu, a lista de dispositivos testados
pode ter um link para as instruções do fornecedor do dispositivo para configuração com o Gateway de VPN do
Azure.
Criar a conexão Site a Site

Para concluir a implantação de uma VPN S2S, você precisa criar uma conexão entre o dispositivo de rede local
(representado pelo recurso de gateway de rede local) e o Gateway de VPN. Para fazer isso, navegue até o Gateway
de VPN que você criou acima. No sumário do Gateway de VPN, selecione Conexões e clique em Adicionar . O
painel Adicionar conexão resultante exige os seguintes campos:
Name : o nome da conexão. Um Gateway de VPN pode hospedar várias conexões, portanto, escolha um nome
útil para seu gerenciamento, que diferenciará essa conexão específica.
Tipo de conexão : como essa é uma conexão site a site, selecione Site a Site (IPSec) na lista suspensa.
Gateway de rede vir tual : este campo é selecionado automaticamente para o Gateway de VPN com que
você está fazendo a conexão e não pode ser alterado.
Gateway de rede local : é o gateway de rede local que você deseja conectar ao seu Gateway de VPN. O
painel de seleção resultante deve ter o nome do gateway de rede local que você criou acima.
Chave compar tilhada (PSK) : uma mistura de letras e números, usada para estabelecer a criptografia para a
conexão. A mesma chave compartilhada deve ser usada tanto na rede virtual quanto nos gateways de rede
local. Se o seu dispositivo de gateway não fornecer um, você poderá criar um aqui e fornecê-lo ao seu
dispositivo.
Selecione OK para criar a conexão. Você pode verificar se a conexão foi criada com êxito na página Conexões .
Montar o compartilhamento de arquivo do Azure

A etapa final da configuração de uma VPN S2S é verificar se ela funciona para os Arquivos do Azure. Você pode
fazer isso montando o compartilhamento de arquivo do Azure localmente com o sistema operacional de sua
preferência. Consulte as instruções de montagem segundo o sistema operacional aqui:
Windows
macOS
Linux
Confira também
Visão geral da rede dos Arquivos do Azure
Configurar uma VPN P2S (ponto a site) no Windows para uso com os Arquivos do Azure
Configurar uma VPN P2S (Ponto a Site) no Linux para usar com os Arquivos do Azure
Configurar uma VPN P2S (ponto a site) no Windows
para uso com os Arquivos do Azure
Você pode usar uma conexão de VPN P2S (ponto a site) para montar compartilhamentos de arquivo do Azure no
SMB de fora do Azure, sem precisar abrir a porta 445. Uma conexão VPN Ponto a Site é uma conexão VPN entre o
Azure e um cliente individual. Para usar uma conexão VPN P2S com os Arquivos do Azure, será preciso configurar
uma conexão VPN P2S para cada cliente que desejar se conectar. Se muitos clientes precisarem se conectar aos
seus compartilhamentos de arquivo do Azure de suas redes locais, você poderá usar uma VPN S2S (Site a Site)
em vez de uma conexão ponto a site para cada um deles. Para saber mais, confira Configurar uma VPN Site a Site
para usar com os Arquivos do Azure.
Recomendamos que você leia Considerações de rede para acesso direto ao compartilhamento de arquivos do
Azure antes de continuar este tutorial para ver uma discussão completa a respeito das opções de rede disponíveis
para os Arquivos do Azure.
O artigo detalha as etapas de configuração de uma VPN Ponto a Site no Windows (cliente Windows e Windows
Server) para criar compartilhamentos de arquivo do Azure diretamente no local. Se você deseja encaminhar o
tráfego da Sincronização de Arquivos do Azure por uma VPN, confira Definir configurações de proxy e firewall da
Pré-requisitos
A versão mais recente do módulo do Azure PowerShell. Para obter mais informações sobre como instalar o
Azure PowerShell, confira Instalar e configurar o módulo do Azure PowerShell e escolha seu sistema
operacional. Se preferir, você poderá usar a CLI do Azure no Windows. No entanto, as instruções a seguir
são apresentadas para o Azure PowerShell.
Azure.
Implantar uma rede virtual

Para acessar o compartilhamento de arquivo do Azure e outros recursos do Azure do local por meio de uma VPN
ponto a site, você precisa criar uma rede virtual ou VNet. A conexão VPN P2S que você criará automaticamente é
uma ponte entre seu computador Windows local e essa rede virtual do Azure.
O PowerShell a seguir criará uma rede virtual do Azure com três sub-redes: uma para o ponto de extremidade de
serviços de sua conta de armazenamento, uma para o ponto de extremidade privado de sua conta de
armazenamento – que é necessária para acessar a conta de armazenamento local sem criar um roteamento
personalizado para o IP público dessa conta de armazenamento que pode ser alterada – e outra para o gateway
de rede virtual que fornece o serviço de VPN.
Lembre-se de substituir <region> , <resource-group> ,e <desired-vnet-name> pelos valores adequados para seu
ambiente.
$region = "<region>"
$resourceGroupName = "<resource-group>"
$virtualNetworkName = "<desired-vnet-name>"
$virtualNetwork = New-AzVirtualNetwork `
-Name $virtualNetworkName `
-Location $region `
-AddressPrefix "192.168.0.0/16"
Add-AzVirtualNetworkSubnetConfig `
-Name "ServiceEndpointSubnet" `
-AddressPrefix "192.168.0.0/24" `
-VirtualNetwork $virtualNetwork `
-ServiceEndpoint "Microsoft.Storage" `
-WarningAction SilentlyContinue | Out-Null
-Name "PrivateEndpointSubnet" `
-AddressPrefix "192.168.1.0/24" `
-Name "GatewaySubnet" `
-AddressPrefix "192.168.2.0/24" `
$virtualNetwork | Set-AzVirtualNetwork | Out-Null

$virtualNetwork = Get-AzVirtualNetwork `
-Name $virtualNetworkName
$serviceEndpointSubnet = $virtualNetwork.Subnets | `
Where-Object { $_.Name -eq "ServiceEndpointSubnet" }
$privateEndpointSubnet = $virtualNetwork.Subnets | `
Where-Object { $_.Name -eq "PrivateEndpointSubnet" }
$gatewaySubnet = $virtualNetwork.Subnets | `
Where-Object { $_.Name -eq "GatewaySubnet" }
Criar um certificado raiz para autenticação da VPN

Para que as conexões VPN de seus computadores Windows locais sejam autenticadas e acessem sua rede virtual,
você precisa criar dois certificados: um certificado raiz, que será fornecido para o gateway da máquina virtual, e
um certificado do cliente, que será assinado com o certificado raiz. O PowerShell a seguir cria o certificado raiz; já
o certificado do cliente será criado depois que o gateway de rede virtual do Azure for criado com informações do
gateway.
$rootcertname = "CN=P2SRootCert"
$certLocation = "Cert:\CurrentUser\My"
$vpnTemp = "C:\vpn-temp\"
$exportedencodedrootcertpath = $vpnTemp + "P2SRootCertencoded.cer"
$exportedrootcertpath = $vpnTemp + "P2SRootCert.cer"
if (-Not (Test-Path $vpnTemp)) {

New-Item -ItemType Directory -Force -Path $vpnTemp | Out-Null
}
if ($PSVersionTable.PSVersion -ge [System.Version]::new(6, 0)) {

Install-Module WindowsCompatibility
Import-WinModule PKI
}
$rootcert = New-SelfSignedCertificate `
-Type Custom `
-KeySpec Signature `
-Subject $rootcertname `
-KeyExportPolicy Exportable `
-HashAlgorithm sha256 `
-KeyLength 2048 `
-CertStoreLocation $certLocation `
-KeyUsageProperty Sign `
-KeyUsage CertSign
Export-Certificate `
-Cert $rootcert `
-FilePath $exportedencodedrootcertpath `
-NoClobber | Out-Null
certutil -encode $exportedencodedrootcertpath $exportedrootcertpath | Out-Null
$rawRootCertificate = Get-Content -Path $exportedrootcertpath
[System.String]$rootCertificate = ""
foreach($line in $rawRootCertificate) {
if ($line -notlike "*Certificate*") {
$rootCertificate += $line
}
}
Implantar o gateway de rede virtual

O gateway de rede virtual do Azure é o serviço ao qual os computadores Windows locais serão conectados.
Implantar esse serviço requer dois componentes básicos: um IP público que identificará o gateway para seus
clientes em qualquer lugar do mundo e um certificado raiz criado previamente que será usado para autenticar
seus clientes.
Lembre-se de substituir <desired-vpn-name-here> pelo nome que você deseja para esses recursos.
NOTE
Implantar o gateway de rede virtual do Azure pode levar até 45 minutos. Para que o processo seja concluído, este script do
PowerShell será bloqueado durante a implantação do recurso. Isso é esperado.
$vpnName = "<desired-vpn-name-here>"
$publicIpAddressName = "$vpnName-PublicIP"
$publicIPAddress = New-AzPublicIpAddress `
-Name $publicIpAddressName `
-Location $region `
-Sku Basic `
-AllocationMethod Dynamic
$gatewayIpConfig = New-AzVirtualNetworkGatewayIpConfig `
-Name "vnetGatewayConfig" `
-SubnetId $gatewaySubnet.Id `
-PublicIpAddressId $publicIPAddress.Id
$azRootCertificate = New-AzVpnClientRootCertificate `
-Name "P2SRootCert" `
-PublicCertData $rootCertificate
$vpn = New-AzVirtualNetworkGateway `
-Name $vpnName `
-Location $region `
-GatewaySku VpnGw1 `
-GatewayType Vpn `
-VpnType RouteBased `
-IpConfigurations $gatewayIpConfig `
-VpnClientAddressPool "172.16.201.0/24" `
-VpnClientProtocol IkeV2 `
-VpnClientRootCertificates $azRootCertificate
Criar o certificado do cliente

O certificado do cliente é criado com o URI do gateway de rede virtual. Esse certificado é assinado com o
certificado raiz que você criou anteriormente.
$clientcertpassword = "1234"
$vpnClientConfiguration = New-AzVpnClientConfiguration `
-Name $vpnName `
-AuthenticationMethod EAPTLS
Invoke-WebRequest `
-Uri $vpnClientConfiguration.VpnProfileSASUrl `
-OutFile "$vpnTemp\vpnclientconfiguration.zip"
Expand-Archive `
-Path "$vpnTemp\vpnclientconfiguration.zip" `
-DestinationPath "$vpnTemp\vpnclientconfiguration"
$vpnGeneric = "$vpnTemp\vpnclientconfiguration\Generic"
$vpnProfile = ([xml](Get-Content -Path "$vpnGeneric\VpnSettings.xml")).VpnProfile
$exportedclientcertpath = $vpnTemp + "P2SClientCert.pfx"

$clientcertname = "CN=" + $vpnProfile.VpnServer
$clientcert = New-SelfSignedCertificate `
-Type Custom `
-DnsName $vpnProfile.VpnServer `
-KeySpec Signature `
-Subject $clientcertname `
-KeyExportPolicy Exportable `
-HashAlgorithm sha256 `
-KeyLength 2048 `
-CertStoreLocation $certLocation `
-Signer $rootcert `
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")
$mypwd = ConvertTo-SecureString -String $clientcertpassword -Force -AsPlainText
Export-PfxCertificate `
-FilePath $exportedclientcertpath `
-Password $mypwd `
-Cert $clientcert | Out-Null
Configurar o cliente VPN

O gateway de rede virtual do Azure criará um pacote que poderá ser baixado contendo os arquivos de
configuração necessários para iniciar a conexão VPN em seu computador Windows local. Configuraremos a
conexão VPN usando o recurso VPN Always On do Windows 10/Windows Server 2016+. Este pacote também
contém pacotes executáveis para configurar o cliente VPN do Windows herdado, caso seja desejado. Este guia usa
a VPN Always On em vez do cliente VPN do Windows herdado, pois o cliente VPN Always On permite que os
usuários finais se conectem/desconectem da VPN do Azure sem ter permissões de administrador em seus
computadores.
O script a seguir instalará o certificado do cliente necessário para autenticação no gateway de rede virtual, além
de baixar e instalar o pacote da VPN. Lembre-se de substituir <computer1> e <computer2> pelos computadores
desejados. Você pode executar este script em quantos computadores desejar adicionando mais sessões do
PowerShell à matriz $sessions . Sua conta de usuário deve ser de administrador em todos esses computadores.
Se um desses computadores for o computador virtual de onde você está rodando o script, você precisará executar
o script em uma sessão do PowerShell elevada.
$sessions = [System.Management.Automation.Runspaces.PSSession[]]@()
$sessions += New-PSSession -ComputerName "<computer1>"
$sessions += New-PSSession -ComputerName "<computer2>"
foreach ($session in $sessions) {

foreach ($session in $sessions) {
Invoke-Command -Session $session -ArgumentList $vpnTemp -ScriptBlock {
$vpnTemp = $args[0]
if (-Not (Test-Path $vpnTemp)) {
New-Item `
-ItemType Directory `
-Force `
-Path "C:\vpn-temp" | Out-Null
}
}
Copy-Item `
-Path $exportedclientcertpath, $exportedrootcertpath, "$vpnTemp\vpnclientconfiguration.zip" `
-Destination $vpnTemp `
-ToSession $session
Invoke-Command `
-Session $session `
-ArgumentList `
$mypwd, `
$vpnTemp, `
$virtualNetworkName `
-ScriptBlock {
$mypwd = $args[0]
$vpnTemp = $args[1]
$virtualNetworkName = $args[2]
Import-PfxCertificate `
-Exportable `
-Password $mypwd `
-CertStoreLocation "Cert:\LocalMachine\My" `
-FilePath "$vpnTemp\P2SClientCert.pfx" | Out-Null
Import-Certificate `
-FilePath "$vpnTemp\P2SRootCert.cer" `
-CertStoreLocation "Cert:\LocalMachine\Root" | Out-Null
Expand-Archive `
-Path "$vpnTemp\vpnclientconfiguration.zip" `
-DestinationPath "$vpnTemp\vpnclientconfiguration"
$vpnGeneric = "$vpnTemp\vpnclientconfiguration\Generic"
$vpnProfile = ([xml](Get-Content -Path "$vpnGeneric\VpnSettings.xml")).VpnProfile
Add-VpnConnection `
-ServerAddress $vpnProfile.VpnServer `
-TunnelType Ikev2 `
-EncryptionLevel Required `
-AuthenticationMethod MachineCertificate `
-SplitTunneling `
-AllUserConnection
Add-VpnConnectionRoute `
-DestinationPrefix $vpnProfile.Routes `
-AllUserConnection
Add-VpnConnectionRoute `
-DestinationPrefix $vpnProfile.VpnClientAddressPool `
-AllUserConnection
rasdial $virtualNetworkName
}
}
Remove-Item -Path $vpnTemp -Recurse

Agora que configurou sua VPN Ponto a Site, você pode usá-la para criar o compartilhamento de arquivo do Azure
nos computadores que configurou usando o PowerShell. O exemplo a seguir montará o compartilhamento, listará
o diretório raiz do compartilhamento para provar que ele foi montado e, em seguida, desmontará o
compartilhamento. Não é possível montar o compartilhamento de forma persistente na comunicação remota do
PowerShell. Para fazer isso, confira Usar um compartilhamento de arquivo do Azure com o Windows.
$myShareToMount = "<file-share>"
$storageAccountKeys = Get-AzStorageAccountKey `
-Name $storageAccountName
$storageAccountKey = ConvertTo-SecureString `
-String $storageAccountKeys[0].Value `
-AsPlainText `
-Force
$nic = Get-AzNetworkInterface -ResourceId $privateEndpoint.NetworkInterfaces[0].Id

$storageAccountPrivateIP = $nic.IpConfigurations[0].PrivateIpAddress
Invoke-Command `
-Session $sessions `
-ArgumentList `
$storageAccountName, `
$storageAccountKey, `
$storageAccountPrivateIP, `
$myShareToMount `
-ScriptBlock {
$storageAccountName = $args[0]
$storageAccountKey = $args[1]
$storageAccountPrivateIP = $args[2]
$myShareToMount = $args[3]
$credential = [System.Management.Automation.PSCredential]::new(
"AZURE\$storageAccountName",
$storageAccountKey)
New-PSDrive `
-Name Z `
-PSProvider FileSystem `
-Root "\\$storageAccountPrivateIP\$myShareToMount" `
-Credential $credential `
-Persist | Out-Null
Get-ChildItem -Path Z:\
Remove-PSDrive -Name Z
}
Confira também
Considerações de rede para acesso direto ao compartilhamento de arquivos do Azure
Configurar uma VPN P2S (Ponto a Site) no Linux para usar com os Arquivos do Azure
Configurar uma VPN S2S (Site a Site) para uso com os Arquivos do Azure
Configurar uma VPN P2S (Ponto a Site) no Linux
para usar com os Arquivos do Azure
Você pode usar uma conexão de VPN P2S (ponto a site) para montar compartilhamentos de arquivo do Azure no
SMB de fora do Azure, sem precisar abrir a porta 445. Uma conexão VPN Ponto a Site é uma conexão VPN entre o
Azure e um cliente individual. Para usar uma conexão VPN P2S com os Arquivos do Azure, será preciso configurar
uma conexão VPN P2S para cada cliente que desejar se conectar. Se muitos clientes precisarem se conectar aos
seus compartilhamentos de arquivo do Azure de suas redes locais, você poderá usar uma VPN S2S (Site a Site)
em vez de uma conexão ponto a site para cada um deles. Para saber mais, confira Configurar uma VPN Site a Site
para usar com os Arquivos do Azure.
Recomendamos que você leia Visão geral da rede nos Arquivos do Azure antes de continuar este tutorial para ver
uma discussão completa a respeito das opções de rede disponíveis para os Arquivos do Azure.
O artigo detalha as etapas de configuração de uma VPN Ponto a Site no Linux para montar compartilhamentos de
arquivo do Azure diretamente no local. Se você deseja encaminhar o tráfego da Sincronização de Arquivos do
Azure por uma VPN, confira Definir configurações de proxy e firewall da Sincronização de Arquivos do Azure.
Pré-requisitos
A versão mais recente da CLI do Azure. Para obter mais informações sobre como instalar a CLI do Azure,
confira Instalar a CLI do Azure PowerShell e escolha seu sistema operacional. Se preferir, você poderá usar o
módulo do Azure PowerShell no Linux. No entanto, as instruções a seguir são apresentadas para a CLI do
Azure.
Azure.
Instalar o software necessário

O gateway de rede virtual do Azure pode fornecer conexões VPN usando vários protocolos VPN, incluindo IPsec e
OpenVPN. Este guia mostra como usar o IPsec e usa o pacote strongSwan para dar suporte no Linux.
Verificado com o Ubuntu 18.10.
sudo apt install strongswan strongswan-pki libstrongswan-extra-plugins curl libxml2-utils cifs-utils
installDir="/etc/"
Implantar uma rede virtual
Para acessar o compartilhamento de arquivo do Azure e outros recursos do Azure do local por meio de uma VPN
ponto a site, você precisa criar uma rede virtual ou VNet. A conexão VPN P2S que você criará automaticamente é
uma ponte entre seu computador Linux local e essa rede virtual do Azure.
O script a seguir criará uma rede virtual do Azure com três sub-redes: uma para o ponto de extremidade de
serviços de sua conta de armazenamento, uma para o ponto de extremidade privado de sua conta de
armazenamento – que é necessária para acessar a conta de armazenamento local sem criar um roteamento
personalizado para o IP público dessa conta de armazenamento que pode ser alterada – e outra para o gateway de
rede virtual que fornece o serviço de VPN.
Lembre-se de substituir <region> , <resource-group> ,e <desired-vnet-name> pelos valores adequados para seu
ambiente.
region="<region>"
resourceGroupName="<resource-group>"
virtualNetworkName="<desired-vnet-name>"
virtualNetwork=$(az network vnet create \

--name $virtualNetworkName \
--address-prefixes "192.168.0.0/16" \
--query "newVNet.id" | tr -d '"')
serviceEndpointSubnet=$(az network vnet subnet create \

--vnet-name $virtualNetworkName \
--name "ServiceEndpointSubnet" \
--service-endpoints "Microsoft.Storage" \
--query "id" | tr -d '"')
privateEndpointSubnet=$(az network vnet subnet create \

--name "PrivateEndpointSubnet" \
gatewaySubnet=$(az network vnet subnet create \

--name "GatewaySubnet" \
Criar certificados para autenticação da VPN

Para que as conexões VPN de seus computadores Linux locais sejam autenticadas e acessem sua rede virtual, você
precisa criar dois certificados: um certificado raiz, que será fornecido para o gateway da máquina virtual, e um
certificado do cliente, que será assinado com o certificado raiz. O script a seguir cria os certificados necessários.
rootCertName="P2SRootCert"
username="client"
password="1234"
mkdir temp
cd temp
sudo ipsec pki --gen --outform pem > rootKey.pem

sudo ipsec pki --self --in rootKey.pem --dn "CN=$rootCertName" --ca --outform pem > rootCert.pem
rootCertificate=$(openssl x509 -in rootCert.pem -outform der | base64 -w0 ; echo)
sudo ipsec pki --gen --size 4096 --outform pem > "clientKey.pem"
sudo ipsec pki --pub --in "clientKey.pem" | \
sudo ipsec pki \
--issue \
--cacert rootCert.pem \
--cakey rootKey.pem \
--dn "CN=$username" \
--san $username \
--flag clientAuth \
--outform pem > "clientCert.pem"
openssl pkcs12 -in "clientCert.pem" -inkey "clientKey.pem" -certfile rootCert.pem -export -out "client.p12" -
password "pass:$password"
Implantar o gateway de rede virtual

O gateway de rede virtual do Azure é o serviço ao qual os computadores Linux locais serão conectados. Implantar
esse serviço requer dois componentes básicos: um IP público que identificará o gateway para seus clientes em
qualquer lugar do mundo e um certificado raiz criado previamente que será usado para autenticar seus clientes.
Lembre-se de substituir <desired-vpn-name-here> pelo nome que você deseja para esses recursos.
NOTE
Implantar o gateway de rede virtual do Azure pode levar até 45 minutos. Para que a implantação seja concluída, este script
de bash será bloqueado durante a implantação do recurso. Isso é esperado.
vpnName="<desired-vpn-name-here>"
publicIpAddressName="$vpnName-PublicIP"
publicIpAddress=$(az network public-ip create \

--name $publicIpAddressName \
--sku "Basic" \
--allocation-method "Dynamic" \
--query "publicIp.id" | tr -d '"')
az network vnet-gateway create \

--name $vpnName \
--vnet $virtualNetworkName \
--public-ip-addresses $publicIpAddress \
--sku "VpnGw1" \
--gateway-typ "Vpn" \
--vpn-type "RouteBased" \
--client-protocol "IkeV2" > /dev/null
az network vnet-gateway root-cert create \

--gateway-name $vpnName \
--name $rootCertName \
--public-cert-data $rootCertificate \
--output none
Configurar o cliente VPN

O gateway de rede virtual do Azure criará um pacote que poderá ser baixado contendo os arquivos de
configuração necessários para iniciar a conexão VPN em seu computador Linux local. O script a seguir coloca os
certificados que você criou no local correto e configura o arquivo ipsec.conf com os valores corretos do arquivo
de configuração no pacote baixável.
vpnClient=$(az network vnet-gateway vpn-client generate \
--name $vpnName \
--authentication-method EAPTLS | tr -d '"')
curl $vpnClient --output vpnClient.zip

unzip vpnClient.zip
vpnServer=$(xmllint --xpath "string(/VpnProfile/VpnServer)" Generic/VpnSettings.xml)

vpnType=$(xmllint --xpath "string(/VpnProfile/VpnType)" Generic/VpnSettings.xml | tr '[:upper:]' '[:lower:]')
routes=$(xmllint --xpath "string(/VpnProfile/Routes)" Generic/VpnSettings.xml)
sudo cp "${installDir}ipsec.conf" "${installDir}ipsec.conf.backup"

sudo cp "Generic/VpnServerRoot.cer" "${installDir}ipsec.d/cacerts"
sudo cp "${username}.p12" "${installDir}ipsec.d/private"
echo -e "\nconn $virtualNetworkName" | sudo tee -a "${installDir}ipsec.conf" > /dev/null

echo -e "\tkeyexchange=$vpnType" | sudo tee -a "${installDir}ipsec.conf" > /dev/null
echo -e "\ttype=tunnel" | sudo tee -a "${installDir}ipsec.conf" > /dev/null
echo -e "\tleftfirewall=yes" | sudo tee -a "${installDir}ipsec.conf" > /dev/null
echo -e "\tleft=%any" | sudo tee -a "${installDir}ipsec.conf" > /dev/null
echo -e "\tleftauth=eap-tls" | sudo tee -a "${installDir}ipsec.conf" > /dev/null
echo -e "\tleftid=%client" | sudo tee -a "${installDir}ipsec.conf" > /dev/null
echo -e "\tright=$vpnServer" | sudo tee -a "${installDir}ipsec.conf" > /dev/null
echo -e "\trightid=%$vpnServer" | sudo tee -a "${installDir}ipsec.conf" > /dev/null
echo -e "\trightsubnet=$routes" | sudo tee -a "${installDir}ipsec.conf" > /dev/null
echo -e "\tleftsourceip=%config" | sudo tee -a "${installDir}ipsec.conf" > /dev/null
echo -e "\tauto=add" | sudo tee -a "${installDir}ipsec.conf" > /dev/null
echo ": P12 client.p12 '$password'" | sudo tee -a "${installDir}ipsec.secrets" > /dev/null
sudo ipsec restart

sudo ipsec up $virtualNetworkName

Agora que configurou sua VPN Ponto a Site, você pode montar o compartilhamento de arquivo do Azure. O
exemplo a seguir montará o compartilhamento de forma não persistente. Para fazer isso, confira Usar um
compartilhamento de arquivo do Azure com o Linux.
fileShareName="myshare"

smbPath="//$storageAccountPrivateIP/$fileShareName"
sudo mount -t cifs $smbPath $mntPath -o
vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino
Confira também
Visão geral da rede dos Arquivos do Azure
Configurar uma VPN P2S (ponto a site) no Windows para uso com os Arquivos do Azure
Configurar uma VPN S2S (Site a Site) para uso com os Arquivos do Azure
Gerenciar servidores registrados com a Sincronização
de Arquivos do Azure
acessar seus dados localmente (incluindo SMB, NFS e FTPS) e pode ter todos os caches de que precisar ao redor
do mundo.
O artigo a seguir ilustra como registrar e gerenciar um servidor com um Serviço de Sincronização de
Armazenamento. Consulte Como implantar a Sincronização de Arquivos do Azure para obter informações sobre
como implantar a Sincronização de Arquivos do Azure de ponta a ponta.
Registrar/cancelar o registro de um servidor no Serviço de

Registrar um servidor na Sincronização de arquivos do Azure estabelece uma relação de confiança entre o
Windows Server e o Azure. Essa relação pode ser usada para criar pontos de extremidade do servidor no servidor,
que representam as pastas específicas que devem ser sincronizadas com um compartilhamento de arquivos do
Azure (também conhecidas como pontos de extremidade de nuvem).
Pré -requisitos
Para registrar um servidor em um Serviço de Sincronização de Armazenamento, primeiro você deve preparar o
servidor com os pré-requisitos necessários:
O servidor deve estar executando uma versão do Windows Server compatível. Para obter mais
informações, veja Requisitos de sistema da Sincronização de Arquivos do Azure e interoperabilidade.
Certifique-se de que um Serviço de Sincronização de Armazenamento foi implantado. Para obter mais
informações sobre como implantar um Serviço de Sincronização de Armazenamento, consulte Como
implantar a Sincronização de Arquivos do Azure.
Certifique-se de que o servidor está conectado à Internet e que o Azure está acessível.
Desabilite a Configuração de Segurança Reforçada do IE para administradores com a interface do usuário
do Gerenciador do Servidor.
Certifique-se de que o módulo Azure PowerShell está instalado no servidor. Se o servidor for um membro
de um Cluster de Failover, todos os nós no cluster precisarão do módulo Az. É possível encontrar mais
detalhes sobre como instalar o módulo Az em Instalar e configurar o Azure PowerShell.
NOTE
É recomendável usar a versão mais recente do módulo Az PowerShell para registrar/cancelar o registro de um
servidor. Se o pacote do Az tiver sido instalado anteriormente nesse servidor (e a versão do PowerShell nesse
servidor for 5.* ou maior), você poderá usar o cmdlet Update-Module para atualizar esse pacote.
Se você utilizar um servidor de proxy de rede em seu ambiente, configure as definições de proxy no seu
servidor para que o agente de sincronização use.
1. Determine o número da porta e o endereço IP do proxy
2. Edite esses dois arquivos:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
3. Adicione as linhas na Figura 1 (abaixo desta seção) em /System.ServiceModel nos dois arquivos acima
alterando 127.0.0.1:8888 para o endereço IP correto (substituir 127.0.0.1) e o número de porta correto
(substituir 8888):
4. Defina as configurações de proxy do WinHTTP por meio da linha de comando:
Mostre o proxy: netsh winhttp mostra o proxy
Defina o proxy: netsh winhttp define o proxy 127.0.0.1:8888
Reinicie o proxy: netsh winhttp reiniciar o proxy
se isso for definido após o agente ser instalado, reinicie o nosso agente de sincronização: net stop
filesyncsvc
Figure 1:
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888"
usesystemdefault="false" />
</defaultProxy>
</system.net>
Registrar um servidor com o Serviço de Sincronização de Armazenamento

Para que um servidor possa ser usado como um ponto de extremidade do servidor em um grupo de
sincronização da Sincronização de arquivos do Azure, ele deve ser registrado em um Serviço de Sincronização de
Armazenamento. Um servidor apenas pode ser registrado em um único Serviço de Sincronização de
Armazenamento de cada vez.
1. Baixe o agente de Sincronização de Arquivo do Azure.
2. Inicie o instalador do agente de Sincronização de Arquivo do Azure.
3. Certifique-se de habilitar as atualizações para o agente de Sincronização de Arquivo do Azure usando o
Microsoft Update. É importante porque correções de segurança críticas e aprimoramentos de recursos para
o pacote do servidor são enviadas por meio do Microsoft Update.
4. Se o servidor não tiver sido registrado anteriormente, a interface do usuário de registro do servidor será
aberta imediatamente após a conclusão da instalação.
IMPORTANT
Se o servidor for um membro de um Cluster de Failover, o agente de Sincronização de Arquivo do Azure precisará ser
instalado em cada nó no cluster.
Registrar o servidor usando a interface do usuário de registro do servidor
IMPORTANT
As assinaturas CSP (Provedor de Soluções na Nuvem) não podem usar a interface do usuário de registro de servidor. Em vez
disso, use o PowerShell (abaixo desta seção).
1. Se a interface do usuário de registro do servidor não for iniciada imediatamente após a conclusão da
instalação do agente de Sincronização de Arquivo do Azure, ela poderá ser iniciada manualmente
executando C:\Program Files\Azure\StorageSyncAgent\ServerRegistration.exe .
2. Clique em Entrar para acessar sua assinatura do Azure.
3. Selecione a assinatura, o grupo de recursos e o Serviço de Sincronização de Armazenamento na caixa de

diálogo.
4. Na versão prévia, é necessário entrar mais uma vez para concluir o processo.
IMPORTANT
Se o servidor for um membro de um Cluster de Failover, cada servidor precisará executar o Registro do Servidor. Quando
você exibe os servidores registrados no Portal do Azure, a Sincronização de arquivos do Azure reconhece automaticamente
cada nó como um membro do mesmo Cluster de Failover e agrupa-os corretamente.
Registrar o servidor com o PowerShell

Você também pode executar o registro do servidor por meio do PowerShell. Essa é a única maneira permitida para
o registro do servidor em assinaturas de CSP (Provedor de Soluções na Nuvem):
Register-AzStorageSyncServer -ResourceGroupName "<your-resource-group-name>" -StorageSyncServiceName "<your-

storage-sync-service-name>"
Cancelar o registro de um servidor com o Serviço de Sincronização de Armazenamento

Há várias etapas que são necessárias para cancelar o registro de um servidor com um Serviço de Sincronização de
Armazenamento. Vamos analisar como cancelar o registro de um servidor corretamente.
WARNING
Não tente solucionar problemas com sincronização, hierarquização em nuvem ou qualquer outro aspecto do Azure File Sync
- Sincronização de Arquivos do Azure cancelando o registro e o registro de um servidor ou removendo e recriando os
pontos de extremidade do servidor, a menos que instruído explicitamente por um engenheiro da Microsoft. Cancelar o
registro de um servidor e remover os terminais do servidor é uma operação destrutiva e os arquivos em camadas nos
volumes com terminais do servidor não serão "reconectados" a seus locais no compartilhamento de arquivos do Azure
depois que os pontos de extremidade do servidor e do servidor registrados forem recriados, o que resultará em
sincronização erros. Observe também que os arquivos em camadas que existem fora de um namespace do terminal do
servidor podem ser permanentemente perdidos. Os arquivos em camadas podem existir nos terminais do servidor, mesmo
que a camada em nuvem nunca tenha sido ativada.
(Opcional) Realizar o recall de todos os dados em camadas

Se você gostaria que os arquivos que estão atualmente em camadas para estar disponível após a remoção do
Azure File Sync - Sincronização de Arquivos do Azure (ou seja, esse é um de produção, não um teste, o ambiente),
lembre-se todos os arquivos em cada volume que contém os pontos de extremidade do servidor. Desabilitar
nuvem camadas para todos os pontos de extremidade do servidor e, em seguida, execute o seguinte cmdlet do
PowerShell:

Invoke-StorageSyncFileRecall -Path <a-volume-with-server-endpoints-on-it>
WARNING
Se o volume local que hospeda o ponto de extremidade do servidor não tiver espaço livre suficiente para recuperar todos os
dados em camadas, o cmdlet Invoke-StorageSyncFileRecall falhará.
Remover o servidor de todos os grupos de sincronização

Antes de cancelar o registro do servidor no Serviço de Sincronização de Armazenamento, todos os pontos de
extremidade do servidor nesse servidor devem ser removidos. Isso pode ser feito no portal do Azure:
1. Navegue até o Serviço de Sincronização do Armazenamento no qual o servidor está registrado.
2. Remova todos os pontos de extremidade do servidor deste servidor em cada grupo de sincronização no
Serviço de Sincronização de Armazenamento. Isso pode ser feito clicando com o botão direito do mouse no
ponto de extremidade do servidor relevante no painel Grupo de sincronização.
Isso também pode ser feito com um script simples do PowerShell:

Connect-AzAccount
$storageSyncServiceName = "<your-storage-sync-service>"
$resourceGroup = "<your-resource-group>"
Get-AzStorageSyncGroup -ResourceGroupName $resourceGroup -StorageSyncServiceName $storageSyncServiceName |

ForEach-Object {
$syncGroup = $_;
Get-AzStorageSyncServerEndpoint -ParentObject $syncGroup | Where-Object { $_.ServerEndpointName -eq
$env:ComputerName } | ForEach-Object {
Remove-AzStorageSyncServerEndpoint -InputObject $_
}
}
Cancelar o registro do servidor

Agora que todos os dados foram recuperados e o servidor foi removido de todos os grupos de sincronização, é
possível cancelar o registro do servidor.
1. Na portal do Azure, navegue até a seção servidores registrados do serviço de sincronização de
armazenamento.
2. Clique com botão direito do mouse no servidor do qual deseja cancelar o registro e clique em “Cancelar
Registro do Servidor”.
Garantindo que a Sincronização de arquivos do Azure seja uma boa

vizinha no seu data center
Como a Sincronização de arquivos do Azure raramente será o único serviço em execução em seu data center, é
interessante limitar o uso de rede e de armazenamento da Sincronização de arquivos do Azure.
IMPORTANT
Definir limites muito baixos afetará o desempenho de sincronização e de recuperação da Sincronização de arquivos do Azure.
Definir limites de rede da Sincronização de arquivos do Azure

Você pode limitar a utilização de rede da Sincronização de arquivos do Azure usando os cmdlets
StorageSyncNetworkLimit .
NOTE
Limites de rede não se aplicam quando um arquivo em camadas é acessado ou o cmdlet Invoke-StorageSyncFileRecall é
usado.
Por exemplo, você pode criar uma nova limitação para garantir que a Sincronização de arquivos do Azure não use
mais de 10 Mbps entre 9h e 17h de segunda a sexta-feira:

New-StorageSyncNetworkLimit -Day Monday, Tuesday, Wednesday, Thursday, Friday -StartHour 9 -EndHour 17 -
LimitKbps 10000
Você pode ver o seu limite usando o seguinte cmdlet:
Get-StorageSyncNetworkLimit # assumes StorageSync.Management.ServerCmdlets.dll is imported
Para remover os limites de rede, use Remove-StorageSyncNetworkLimit . Por exemplo, o comando a seguir remove
todos os limites de rede:
Get-StorageSyncNetworkLimit | ForEach-Object { Remove-StorageSyncNetworkLimit -Id $_.Id } # assumes

StorageSync.Management.ServerCmdlets.dll is imported
Usar a QoS de armazenamento do Windows Server

Quando a Sincronização de arquivos do Azure estiver hospedada em uma máquina virtual em execução em um
host de virtualização do Windows Server, você poderá usar a QoS de armazenamento (qualidade de serviço de
armazenamento) para regular o consumo de E/S do armazenamento. A política de QoS de armazenamento pode
ser definida como um nível máximo (ou um limite, da mesma forma em que o limite de StorageSyncNetwork é
imposto acima) ou como um nível mínimo (ou uma reserva). Definir um nível mínimo em vez de um máximo
permite que a Sincronização de arquivos do Azure seja disparada para usar a largura de banda de armazenamento
disponível se outras cargas de trabalho não a estiverem usando. Para obter mais informações, consulte Qualidade
de serviço do armazenamento.
Confira também
Adicionar/remover um ponto de extremidade do
servidor de Sincronização de Arquivos do Azure
acessar seus dados localmente (incluindo SMB, NFS e FTPS) e pode ter todos os caches de que precisar ao redor do
mundo.
Um ponto de extremidade do servidor representa uma localização específica em um servidor registrado, como
uma pasta em um volume do servidor ou a raiz do volume. Pode haver vários pontos de extremidade do servidor
no mesmo volume se seus namespaces não forem sobrepostos (por exemplo, F:\sync1 e F:\sync2). Você pode
configurar políticas de disposição em camada de nuvem individualmente para cada ponto de extremidade de
servidor. Se você adicionar uma localização de servidor com um conjunto existente de arquivos como um ponto de
extremidade de servidor a um Grupo de Sincronização, esses arquivos serão mesclados com quaisquer outros
arquivos que já estiverem em outros pontos de extremidade no Grupo de Sincronização.
Consulte Como implantar a Sincronização de Arquivos do Azure para obter informações sobre como implantar a
Sincronização de Arquivos do Azure de ponta a ponta.
Pré-requisitos
Para criar um ponto de extremidade do servidor, primeiro você deve garantir que os seguintes critérios sejam
atendidos:
O servidor tem o agente de Sincronização de Arquivo do Azure instalado e foi registrado. As instruções para
instalar o Agente de Sincronização de Arquivos do Azure podem ser encontradas no artigo Registrar/cancelar o
registro de um servidor com a Sincronização de Arquivos do Azure.
Certifique-se de que um Serviço de Sincronização de Armazenamento foi implantado. Consulte Como
implantar a Sincronização de Arquivos do Azure para obter detalhes sobre como implantar um Serviço de
Certifique-se de que um Grupo de Sincronização tenha sido implantado. Saiba como [Criar um Grupo de
Sincronização](storage-sync-files-deployment-guide.md#create-a sync-group-and-a-cloud-endpoint).
Certifique-se de que o servidor está conectado à Internet e que o Azure está acessível. Usamos a porta 443 para
toda a comunicação entre o servidor e o nosso serviço.
Adicionar um ponto de extremidade do servidor

Para adicionar um ponto de extremidade do servidor, navegue até o Grupo de Sincronização desejado e selecione
“Adicionar ponto de extremidade do servidor”.
As informações a seguir são necessárias em Adicionar ponto de extremidade do ser vidor :
Ser vidor Registrado : o nome do servidor ou cluster no qual criar o ponto de extremidade do servidor.
Caminho : o caminho no Windows Server a ser sincronizado como parte do grupo de sincronização.
Nuvem em camadas : uma opção para habilitar ou desabilitar a nuvem camadas. Quando habilitada, será
camada na nuvem camada arquivos para os compartilhamentos de arquivos do Azure. Isso converte os
compartilhamentos de arquivos local em um cache, em vez de uma cópia completa do conjunto de dados, para
ajudá-lo a gerenciar a eficiência de espaço em seu servidor.
Espaço Livre no Volume : a quantidade de espaço livre para reservar no volume no qual reside o ponto de
extremidade do servidor. Por exemplo, se o espaço livre do volume estiver definido como 50% em um volume
com um único ponto de extremidade do servidor, aproximadamente metade da quantidade de dados será
disposta em camadas para os Arquivos do Azure. Independentemente de as camadas na nuvem estarem
habilitadas, o Compartilhamento de Arquivos do Azure sempre terá uma cópia completa dos dados no Grupo
de Sincronização.
Selecione Criar para adicionar o ponto de extremidade do servidor. Agora, os arquivos dentro de um namespace
de um Grupo de Sincronização serão mantidos sincronizados.
Remover um ponto de extremidade do servidor

Se você quiser interromper o uso da Azure File Sync - Sincronização de arquivos do Azure para um determinado
servidor de ponto de extremidade, você pode remover o ponto de extremidade do servidor.
WARNING
Não tente solucionar problemas com a sincronização, camadas de nuvem ou qualquer outro aspecto da Azure File Sync -
Sincronização de arquivos do Azure removendo e recriando o ponto de extremidade do servidor, a menos que explicitamente
instruído pelo engenheiro de Microsoft. Remover um ponto de extremidade do servidor é uma operação destrutiva e
arquivos em camadas em que o ponto de extremidade do servidor não "retornará" em seus locais no compartilhamento de
arquivos do Azure após o ponto de extremidade do servidor é recriado, o que resultará em erros em sincronia. Observe
também, arquivos em camadas que existem fora do namespace de ponto de extremidade do servidor poderão ser perdidos
permanentemente. Arquivos em camadas podem existir em seu se até mesmo de ponto de extremidade do servidor nuvem
camadas nunca foi habilitada.
Para garantir que todos os arquivos em camadas são recuperados antes de remover o ponto de extremidade do
servidor, desabilitar nuvem camadas no ponto de extremidade do servidor e, em seguida, execute o seguinte
cmdlet do PowerShell para recuperar todos os arquivos em camadas no seu namespace de ponto de extremidade
do servidor:

Invoke-StorageSyncFileRecall -Path <path-to-to-your-server-endpoint> -Order CloudTieringPolicy
Se -Order CloudTieringPolicy você especificar, os arquivos modificados mais recentemente serão relembrados
primeiro. Outros parâmetros opcionais, mas úteis a serem considerados, são:
-ThreadCount determina a quantidade de arquivos que podem ser recuperados em paralelo.
-PerFileRetryCount determina com que frequência uma recall será tentada de um arquivo bloqueado no
momento.
-PerFileRetryDelaySeconds determina o tempo em segundos entre tentativas de recuperação e sempre deve ser
usado em combinação com o parâmetro anterior.
NOTE
Se o volume local que hospeda o servidor não tiver espaço livre suficiente para realizar o recall de todos os dados em
camadas, o cmdlet Invoke-StorageSyncFileRecall falha.
Para remover o ponto de extremidade do servidor:

1. Navegue até o Serviço de Sincronização do Armazenamento no qual o servidor está registrado.
2. Navegue até o Grupo de Sincronização desejado.
3. Remova o ponto de extremidade do servidor que você desejar no Grupo de Sincronização no Serviço de
Sincronização de Armazenamento. Isso pode ser feito clicando com o botão direito do mouse no ponto de
extremidade do servidor relevante no painel Grupo de sincronização.
Próximas etapas
Registrar/cancelar o registro de um servidor com a Sincronização de Arquivos do Azure
Gerenciamento do Armazenamento nas nuvens
independentes do Azure usando o PowerShell
A maioria das pessoas usa a Nuvem Pública do Azure em suas implantações globais do Azure. Há também algumas
implantações independentes do Microsoft Azure por motivos de soberania e assim por diante. Essas implantações
independentes são chamadas de “ambientes”. A lista a seguir fornece detalhes sobre as nuvens independentes
disponíveis no momento.
Nuvem do Azure Governamental
Nuvem do Azure China 21Vianet operada pela 21Vianet na China
Nuvem Alemã do Azure
NOTE
Utilização de uma nuvem independente

Para utilizar o Armazenamento do Azure em uma das nuvens independentes, você deve se conectar àquela nuvem
em vez de se conectar à nuvem pública do Azure. Para usar uma das nuvens independentes em vez da nuvem
pública do Azure:
Especifique o ambiente com o qual deseja se conectar.
Determine e use as regiões disponíveis.
Use o sufixo do ponto de extremidade correto, que é diferente do da nuvem pública do Azure.
Estes exemplos exigem a versão 0.7 ou posterior do módulo do Azure PowerShell. Em uma janela do PowerShell,
execute Get-Module -ListAvailable Az para localizar a versão. Se nada for listado ou você precisar atualizar,
consulte Instalar o módulo do Azure PowerShell.
Fazer logon no Azure

Execute o cmdlet Get-AzEnvironment para ver os ambientes do Azure disponíveis:
Get-AzEnvironment
Entre em sua conta que tem acesso à nuvem com a qual você deseja se conectar e defina o ambiente. Este exemplo
mostra como entrar em uma conta que usa a Nuvem do Azure Governamental.
Connect-AzAccount –Environment AzureUSGovernment
Para acessar a Nuvem da China, use o ambiente AzureChinaCloud . Para acessar a Nuvem alemã, use
AzureGermanCloud .
Neste ponto, se precisar da lista de locais para criar uma conta de armazenamento ou outro recurso, você poderá
consultar os locais disponíveis para a nuvem selecionada usando Get-AzLocation.
Get-AzLocation | select Location, DisplayName
A tabela a seguir mostra os locais retornados para a Nuvem alemã.
LO C A L N O M E DE EXIB IÇ Ã O
germanycentral Alemanha Central
germanynortheast Nordeste da Alemanha
Sufixo de ponto de extremidade

O sufixo de ponto de extremidade para cada um desses ambientes é diferente do ponto de extremidade da nuvem
pública do Azure. Por exemplo, o sufixo de ponto de extremidade do blob da nuvem pública do Azure é
blob.core.windows.net . Para a nuvem do governo, o sufixo de ponto de extremidade do blob é
blob.core.usgovcloudapi.net .
Obter o ponto de extremidade usando Get-AzEnvironment
Recupere o sufixo de ponto de extremidade usando Get-AzEnvironment. O ponto de extremidade é a propriedade
StorageEndpointSuffix do ambiente.
Os trechos de código a seguir mostram como recuperar o sufixo do ponto de extremidade. Todos esses comandos
retornam algo como "core.cloudapp.net" ou "core.cloudapi.de", etc. Acrescente o sufixo ao serviço de
armazenamento para acessar esse serviço. Por exemplo, “queue.core.cloudapi.de” acessará o serviço Fila na nuvem
alemã.
Este snippet de código recupera todos os ambientes e o sufixo do ponto de extremidade para cada um.
Get-AzEnvironment | select Name, StorageEndpointSuffix
Esse comando retorna os seguintes resultados.
NOME STO RA GEEN DP O IN T SUF F IX
AzureChinaCloud core.chinacloudapi.cn
AzureCloud core.windows.net
AzureGermanCloud core.cloudapi.de
AzureUSGovernment core.usgovcloudapi.net
Para recuperar todas as propriedades para o ambiente especificado, chame Get-AzEnvironment e especifique o
nome da nuvem. Este snippet de código retorna uma lista de propriedades. Procure por StorageEndpointSuffix
na lista. O exemplo a seguir é para a nuvem alemã.
Get-AzEnvironment -Name AzureGermanCloud
Os resultados são semelhantes aos seguintes valores:

|Nome da propriedade|Valor| |----|----| | Nome | AzureGermanCloud | | EnableAdfsAuthentication | False | |
ActiveDirectoryServiceEndpointResourceI | http://management.core.cloudapi.de/ | | GalleryURL |
https://gallery.cloudapi.de/ | | ManagementPortalUrl | https://portal.microsoftazure.de/ | |
ServiceManagementUrl | https://manage.core.cloudapi.de/ | | PublishSettingsFileUrl|
https://manage.microsoftazure.de/publishsettings/index | | ResourceManagerUrl |
http://management.microsoftazure.de/ | | SqlDatabaseDnsSuffix | .database.cloudapi.de | |
StorageEndpointSuffix | core.cloudapi.de | | ... | ... | Para recuperar apenas a propriedade de sufixo de ponto de
extremidade do armazenamento, recupere a nuvem específica e solicite somente aquela propriedade.
$environment = Get-AzEnvironment -Name AzureGermanCloud

Write-Host "Storage EndPoint Suffix = " $environment.StorageEndpointSuffix
Esse comando retorna as informações a seguir:

Storage Endpoint Suffix = core.cloudapi.de
Obter o ponto de extremidade de uma conta de armazenamento

Você também pode examinar as propriedades de uma conta de armazenamento para recuperar os pontos de
extremidade:
# Get a reference to the storage account.

$resourceGroup = "myexistingresourcegroup"
$storageAccountName = "myexistingstorageaccount"
$storageAccount = Get-AzStorageAccount `
-ResourceGroupName $resourceGroup `
-Name $storageAccountName
# Output the endpoints.
Write-Host "blob endpoint = " $storageAccount.PrimaryEndPoints.Blob
Write-Host "file endpoint = " $storageAccount.PrimaryEndPoints.File
Write-Host "queue endpoint = " $storageAccount.PrimaryEndPoints.Queue
Write-Host "table endpoint = " $storageAccount.PrimaryEndPoints.Table
Para uma conta de armazenamento na nuvem governamental, esse comando retorna a seguinte saída:
blob endpoint = http://myexistingstorageaccount.blob.core.usgovcloudapi.net/

file endpoint = http://myexistingstorageaccount.file.core.usgovcloudapi.net/
queue endpoint = http://myexistingstorageaccount.queue.core.usgovcloudapi.net/
table endpoint = http://myexistingstorageaccount.table.core.usgovcloudapi.net/
Após configurar o ambiente

Agora você pode usar o PowerShell para gerenciar suas contas de armazenamento e acessar dados de BLOB, fila,
arquivo e tabela. Para obter mais informações, consulte AZ. Storage.
Limpar os recursos
Se você criou um novo grupo de recursos e uma conta de armazenamento para este exercício, você pode remover
ambos os ativos excluindo o grupo de recursos. A exclusão do grupo de recursos exclui todos os recursos contidos
nele.
Remove-AzResourceGroup -Name $resourceGroup
Próximas etapas
Persistência de logons de usuário nas sessões do PowerShell
Armazenamento do Azure governamental
Guia do Desenvolvedor do Microsoft Azure Government
Notas do desenvolvedor para aplicativos da 21Vianet do Azure na China
Documentação do Azure Alemanha
Alterar como uma conta de armazenamento é
replicada
O armazenamento do Azure sempre armazena várias cópias de seus dados para que eles sejam protegidos contra
eventos planejados e não planejados, incluindo falhas transitórias de hardware, interrupções de rede ou energia e
desastres naturais em massa. A redundância garante que sua conta de armazenamento atenda ao SLA (contrato de
nível de serviço) do armazenamento do Azure , mesmo diante de falhas.
O armazenamento do Azure oferece os seguintes tipos de replicação:
Armazenamento com redundância local (LRS)
Armazenamento com redundância de zona (ZRS)
Armazenamento com redundância geográfica (GRS) ou armazenamento com redundância geográfica com
acesso de leitura (RA-GRS)
Armazenamento com redundância de zona geográfica (GZRS) ou armazenamento com redundância de acesso
de leitura (RA-GZRS)
Para obter uma visão geral de cada uma dessas opções, consulte redundância de armazenamento do Azure.
Alternar entre tipos de replicação

Você pode alternar uma conta de armazenamento de um tipo de replicação para qualquer outro tipo, mas alguns
cenários são mais diretos do que outros. Se você quiser adicionar ou remover a replicação geográfica ou o acesso
de leitura para a região secundária, poderá usar o portal do Azure, o PowerShell ou o CLI do Azure para atualizar a
configuração de replicação. No entanto, se você quiser alterar a forma como os dados são replicados na região
primária, movendo de LRS para ZRS ou vice-versa, você deve executar uma migração manual.
A tabela a seguir fornece uma visão geral de como alternar de cada tipo de replicação para outro:
. . . PA RA GZ RS/ RA -
IN DEP EN DEN T E . . . PA RA L RS . . . PA RA GRS/ RA - GRS . . . PA RA Z RS GZ RS
... de LRS N/D Usar portal do Azure, Executar uma Executar uma
PowerShell ou CLI migração manual migração manual
para alterar a
configuração de Solicitar uma OU
replicação1 migração ao vivo
Alterne para GRS/RA-
GRS primeiro e, em
seguida, solicite uma
migração ao vivo1
... de GRS/RA-GRS Usar portal do Azure, N/D Executar uma Executar uma
PowerShell ou CLI migração manual migração manual
para alterar a
configuração de OU Solicitar uma
replicação migração ao vivo
Alterne para o LRS
primeiro e, em
seguida, solicite uma
migração ao vivo
. . . PA RA GZ RS/ RA -
IN DEP EN DEN T E . . . PA RA L RS . . . PA RA GRS/ RA - GRS . . . PA RA Z RS GZ RS
... de ZRS Executar uma Executar uma N/D Use portal do Azure,
migração manual migração manual PowerShell ou CLI
para alterar a
configuração de
replicação1, 2
... de GZRS/RA- Executar uma Executar uma Usar portal do Azure, N/D
GZRS migração manual migração manual PowerShell ou CLI
para alterar a
configuração de
replicação
1 gera uma cobrança de egresso única.

2 não há suporte para a conversão de ZRS em GZRS/ra-GZRS ou vice-versa nas seguintes regiões: leste dos EUA 2,
leste dos EUA, oeste da Europa.
Cau t i on
Se você executou um failover de conta para sua conta do (ra-) grs ou (ra-) GZRS, a conta será localmente
redundante na nova região primária após o failover. Não há suporte para a migração dinâmica para ZRS ou GZRS
para uma conta LRS resultante de um failover. Você precisará executar uma migração manual para ZRS ou GZRS.
Alterar a configuração de replicação

Você pode usar o portal do Azure, o PowerShell ou o CLI do Azure para alterar a configuração de replicação de
uma conta de armazenamento, desde que não esteja alterando a forma como os dados são replicados na região
primária. Se você estiver migrando de LRS na região primária para ZRS na região primária ou vice-versa, você
deverá executar uma migração manual ou uma migração dinâmica.
Alterar a forma como sua conta de armazenamento é replicada não resulta em tempo de inatividade para seus
aplicativos.
Portal
PowerShell
CLI do Azure
Para alterar a opção de redundância para sua conta de armazenamento no portal do Azure, siga estas etapas:
1. Navegue até sua conta de armazenamento no portal do Azure.
2. Selecione a definição de configuração .
3. Atualize a configuração de replicação .
Executar uma migração manual para o ZRS
Se você quiser alterar a forma como os dados em sua conta de armazenamento são replicados na região primária,
movendo de LRS para ZRS ou vice-versa, você pode optar por executar uma migração manual. Uma migração
manual fornece mais flexibilidade do que uma migração ao vivo. Você controla o tempo de uma migração manual,
portanto, use essa opção se precisar que a migração seja concluída em uma determinada data.
Quando você executa uma migração manual de LRS para ZRS na região primária ou vice-versa, a conta de
armazenamento de destino pode ser com redundância geográfica e também pode ser configurada para acesso de
leitura à região secundária. Por exemplo, você pode migrar uma conta LRS para uma conta GZRS ou RA-GZRS em
uma única etapa.
Uma migração manual pode resultar em tempo de inatividade do aplicativo. Se o seu aplicativo exigir alta
disponibilidade, a Microsoft também oferece uma opção de migração ao vivo. Uma migração ao vivo é uma
migração no local sem tempo de inatividade.
Com uma migração manual, você copia os dados de sua conta de armazenamento existente para uma nova conta
de armazenamento que usa ZRS na região primária. Para executar uma migração manual, você pode usar uma das
seguintes opções:
Copie dados usando uma ferramenta existente, como AzCopy, uma das bibliotecas de cliente de
armazenamento do Azure ou uma ferramenta de terceiros confiável.
Se você estiver familiarizado com o Hadoop ou o HDInsight, poderá anexar a conta de armazenamento de
origem e a conta de conta de armazenamento de destino ao cluster. Em seguida, paralelize o processo de cópia
de dados com uma ferramenta como DistCp.
Solicitar uma migração ao vivo para o ZRS

Se você precisar migrar sua conta de armazenamento de LRS ou GRS para ZRS na região primária sem tempo de
inatividade do aplicativo, você pode solicitar uma migração ao vivo da Microsoft. Durante uma migração ao vivo,
você pode acessar dados em sua conta de armazenamento e sem perda de durabilidade ou disponibilidade. O SLA
do armazenamento do Azure é mantido durante o processo de migração. Não há perda de dados associada a uma
migração dinâmica. Pontos de extremidade de serviço, chaves de acesso, assinaturas de acesso compartilhado e
outras opções de conta permanecem inalterados após a migração.
O ZRS dá suporte apenas a contas v2 de uso geral, portanto, atualize sua conta de armazenamento antes de enviar
uma solicitação para uma migração ao vivo para o ZRS. Para obter mais informações, consulte atualizar para uma
conta de armazenamento v2 de uso geral. Uma conta de armazenamento deve conter dados a serem migrados por
meio da migração dinâmica.
A migração ao vivo é suportada apenas para contas de armazenamento que usam a replicação de LRS ou GRS. Se
sua conta usa o RA-GRS, você precisa primeiro alterar o tipo de replicação da sua conta para LRS ou GRS antes de
prosseguir. Essa etapa intermediária remove o terminal secundário somente leitura fornecido pelo RA-GRS antes
da migração.
Enquanto a Microsoft lida com seu pedido de migração ao vivo prontamente, não há garantia de quando uma
migração ao vivo será concluída. Se você precisar que seus dados sejam migrados para o ZRS até uma
determinada data, a Microsoft recomenda que você execute uma migração manual. Geralmente, quanto mais
dados você tiver em sua conta, mais tempo levará para migrar esses dados.
Você deve executar uma migração manual se:
Você deseja migrar seus dados para uma conta de armazenamento ZRS que esteja localizada em uma região
diferente da conta de origem.
Sua conta de armazenamento é um blob de páginas Premium ou uma conta de blob de blocos.
Você deseja migrar dados de ZRS para LRS, GRS ou RA-GRS.
Sua conta de armazenamento inclui dados na camada de arquivo morto.
Você pode solicitar a migração ao vivo por meio do Portal de Suporte do Azure. No portal, selecione a conta de
armazenamento que você deseja converter em ZRS.
1. Selecionar nova solicitação de supor te
2. Preencha o Básico com base nas informações da sua conta. Na seção Ser viço , selecione Gerenciamento de
Contas de Armazenamento e o recurso que você deseja converter em ZRS.
3. Selecione Avançar .
4. Especifique os seguintes valores na seção Problema :
Severidade : deixe o valor padrão como-está.
Tipo de problema : selecione migração de dados .
Categoria : selecione migrar para ZRS .
Título : Tipo de titúlo descritivo, por exemplo, migração de conta do ZRS .
Detalhes : digite detalhes adicionais na caixa de detalhes , por exemplo, eu gostaria de migrar para ZRS
de [lRS, grs] na _ _ região.
5. Selecione Avançar .
6. Verifique se as informações de contato estão corretas na informações de contato folha.
Uma pessoa de suporte entrará em contato com você e fornecerá toda a assistência necessária.
NOTE
Atualmente, a migração ao vivo não tem suporte para compartilhamentos de arquivos premium. No momento, só há
suporte para copiar ou mover dados manualmente.
Atualmente, as contas de armazenamento GZRS não dão suporte à camada de arquivo morto. Consulte armazenamento de
BLOBs do Azure: camadas de acesso quentes, frias e de arquivo para obter mais detalhes.
Os discos gerenciados estão disponíveis somente para LRS e não podem ser migrados para o ZRS. Você pode armazenar
instantâneos e imagens para discos gerenciados de SSD padrão no armazenamento de HDD padrão e escolher entre as
opções LRS e ZRS. Para obter informações sobre a integração com conjuntos de disponibilidade, consulte introdução aos
Azure Managed disks.
Alternar do ZRS clássico

IMPORTANT
A Microsoft irá substituir e migrar as contas do ZRS clássico em 31 de março de 2021. Mais detalhes serão fornecidos aos
clientes do ZRS Classic antes da reprovação.
Depois que o ZRS se tornar disponível em uma determinada região, os clientes não poderão mais criar contas ZRS clássicas
do portal do Azure nessa região. O uso do Microsoft PowerShell e do Azure CLI para criar contas do ZRS Classic é uma opção
até que o ZRS Classic seja descontinuado. Para obter informações sobre onde o ZRS está disponível, consulte redundância de
O ZRS Clássico replica os dados de forma assíncrona em datacenters em uma ou duas regiões. Os dados
replicados podem não estar disponíveis, a menos que a Microsoft inicie o failover para o secundário. Uma conta do
ZRS Classic não pode ser convertida para ou de LRS, GRS ou RA-GRS. As contas do ZRS Classic também não
suportam métricas ou registros.
As contas do ZRS Clássico estão disponíveis somente para blobs de blocos em contas de armazenamento V1
(GPv1) de uso geral. Para saber mais sobre as contas de armazenamento, confira Visão geral da conta de
Para migrar manualmente os dados da conta do ZRS para ou de uma conta LRS, GRS, RA-GRS ou ZRS clássico, use
uma das seguintes ferramentas: AzCopy, Gerenciador de Armazenamento do Azure, PowerShell ou CLI do Azure.
Você também pode criar sua própria solução de migração com uma das bibliotecas de cliente do Armazenamento
do Microsoft Azure.
Você também pode atualizar sua conta de armazenamento ZRS clássico para ZRS usando o portal do Azure, o
PowerShell ou o CLI do Azure em regiões em que o ZRS está disponível.
Portal
PowerShell
CLI do Azure
Para atualizar para o ZRS no portal do Azure, navegue até as definições de configuração da conta e escolha
Atualizar :
Custos associados à alteração de como os dados são replicados
Os custos associados à alteração de como os dados são replicados dependem do seu caminho de conversão.
Ordenar as ofertas de redundância de armazenamento do Azure mais dispendiosas, incluindo LRS, ZRS, GRS, RA-
GRS, GZRS e RA-GZRS.
Por exemplo, passar de LRS para qualquer outro tipo de replicação incorrerá em encargos adicionais, pois você
está mudando para um nível de redundância mais sofisticado. Migrar para grs ou ra-grs incorrerá em um encargo
de largura de banda de saída, pois seus dados (em sua região primária) estão sendo replicados para sua região
secundária remota. Essa cobrança é um custo único na configuração inicial. Depois que os dados são copiados, não
há nenhuma cobrança adicional de migração. Para obter detalhes sobre encargos de largura de banda, visite a
página Preços do Armazenamento do Azure.
Se você migrar sua conta de armazenamento de GRS para LRS, não haverá nenhum custo adicional, mas os dados
replicados serão excluídos do local secundário.
IMPORTANT
Se você migrar sua conta de armazenamento de RA-GRS para GRS ou LRS, essa conta será cobrada como RA-GRS por um
adicional 30 dias além da data em que foi convertida.
Consulte também
Redundância de armazenamento do Azure
Verificar a propriedade hora da última sincronização de uma conta de armazenamento
Use a redundância geográfica para criar aplicativos
altamente disponíveis
Um recurso comum de infraestruturas baseadas em nuvem como o armazenamento do Azure é que eles
fornecem uma plataforma altamente disponível e durável para hospedar dados e aplicativos. Os
desenvolvedores de aplicativos baseados em nuvem devem considerar cuidadosamente como aproveitar essa
plataforma para maximizar essas vantagens para seus usuários. O armazenamento do Azure oferece
armazenamento com redundância geográfica para garantir a alta disponibilidade, mesmo no caso de uma
interrupção regional. As contas de armazenamento configuradas para replicação com redundância geográfica
são replicadas de forma síncrona na região primária e, em seguida, replicadas assincronamente para uma região
secundária que está a centenas de quilômetros de distância.
O armazenamento do Azure oferece duas opções de replicação com redundância geográfica. A única diferença
entre essas duas opções é como os dados são replicados na região primária:
Armazenamento com redundância de zona geográfica (GZRS): os dados são replicados de forma síncrona
em três zonas de disponibilidade do Azure na região primária usando o armazenamento com redundância
de zona (ZRS) e, em seguida, replicados assincronamente para a região secundária. Para acesso de leitura
aos dados na região secundária, habilite o armazenamento com redundância de zona geográfica com
acesso de leitura (RA-GZRS).
A Microsoft recomenda o uso de GZRS/RA-GZRS para cenários que exigem disponibilidade e durabilidade
máximas.
Armazenamento com redundância geográfica (GRS): os dados são replicados de forma síncrona três vezes
na região primária usando o LRS (armazenamento com redundância local) e, em seguida, replicados
assincronamente para a região secundária. Para acesso de leitura aos dados na região secundária, habilite
o armazenamento com redundância geográfica com acesso de leitura (RA-GRS).
Este artigo mostra como projetar seu aplicativo para lidar com uma interrupção na região primária. Se a região
primária ficar indisponível, seu aplicativo poderá se adaptar para executar operações de leitura em vez da região
secundária. Verifique se sua conta de armazenamento está configurada para RA-GRS ou RA-GZRS antes de
começar.
Considerações de design de aplicativo ao ler do secundário

A finalidade deste artigo é mostrar como criar um aplicativo que continuará funcionando (embora com
capacidade limitada) mesmo que ocorra um grande desastre no data center primário. Você pode projetar seu
aplicativo para resolver problemas transitórios ou de execução longa com a leitura da região secundária quando
há um problema que interfere na leitura da região primária. Quando a região primária estiver disponível
novamente, o aplicativo poderá retornar com a leitura da região primária.
Tenha em mente estes pontos-chave ao projetar seu aplicativo para RA-GRS ou RA-GZRS:
O Armazenamento do Azure mantém uma cópia somente leitura dos dados armazenados na região
primária em uma região secundária. Conforme observado acima, o serviço de armazenamento determina
o local da região secundária.
A cópia somente leitura é eventualmente consistente com os dados na região primária.
Para blobs, tabelas e filas, você pode consultar a região secundária para obter um valor de Hora da Última
Sincronização que informa quando ocorreu a última replicação da região primária para a secundária. (Não
há suporte para isso nos Arquivos do Azure, que, no momento, não têm redundância RA-GRS.)
Você pode usar a biblioteca de cliente de armazenamento para ler e gravar dados na região primária ou
secundária. Você também poderá redirecionar as solicitações de leitura automaticamente para a região
secundária se uma solicitação de leitura para a região primária atingir o tempo limite.
Se a região primária ficar indisponível, você pode iniciar um failover de conta. Quando você executa o
failover para a região secundária, as entradas DNS que apontam para a região primária são alteradas para
apontar para a região secundária. Após o failover estar concluído, o acesso de gravação é restaurado para
as contas GRS e RA-GRS. Para obter mais informações, consulte recuperação de desastre e failover da
Usando dados eventualmente consistentes
A solução proposta pressupõe que é aceitável retornar dados potencialmente obsoletos ao aplicativo de
chamada. Como os dados na região secundária são finalmente consistentes, é possível que a região primária se
torne inacessível antes que uma atualização para a região secundária tenha concluído a replicação.
Por exemplo, suponha que o cliente envie uma atualização com êxito, mas a região primária falhe antes que a
atualização seja propagada para a região secundária. Quando o cliente pede para ler os dados de volta, eles
recebem os dados obsoletos da região secundária em vez dos dados atualizados. Ao projetar seu aplicativo, você
deve decidir se isso é aceitável e, nesse caso, como você enviará uma mensagem ao cliente.
Neste artigo, mostramos como verificar a Hora da Última Sincronização para os dados secundários para verificar
se o secundário está atualizado.
Tratamento de serviços separadamente ou em conjunto
Embora não seja provável, é possível que um serviço não fique disponível enquanto os outros serviços ainda
estão totalmente funcionais. Você pode lidar com as repetições e o modo somente leitura para cada serviço
separadamente (blobs, filas, tabelas) ou pode lidar com as repetições de forma genérica para todos os serviços
de armazenamento em conjunto.
Por exemplo, se usar filas e blobs no aplicativo, você poderá optar por incluir código separado para lidar com
erros com nova tentativa para cada um desses itens. Em seguida, se você receber uma repetição do serviço blob,
mas o serviço fila ainda estiver funcionando, somente a parte do aplicativo que lida com os blobs será afetada.
Se você decidir lidar com todas as tentativas de serviço de armazenamento de forma genérica e uma chamada
ao serviço blob retornar um erros com nova tentativa, as solicitações para o serviço blob e o serviço fila serão
afetadas.
Em última análise, isso depende da complexidade do aplicativo. Você pode optar por não lidar com as falhas de
serviço, mas, em vez disso, redirecionar as solicitações de leitura a todos os serviços de armazenamento para a
região secundária e executar o aplicativo no modo somente leitura ao detectar um problema em qualquer
serviço de armazenamento na região primária.
Outras considerações
Essas são as outras considerações que discutiremos no restante deste artigo.
Lidar com repetições de solicitações de leitura usando o padrão de Disjuntor
Dados eventualmente consistentes e a Hora da Última Sincronização
Testando
Executando o aplicativo no modo somente leitura

Para se preparar efetivamente para uma interrupção na região primária, você deve ser capaz de lidar com
solicitações de leitura com falha e solicitações de atualização com falha (com Update neste caso, significa
inserções, atualizações e exclusões). Se a região primária falhar, as solicitações de leitura poderão ser
redirecionadas para a região secundária. No entanto, as solicitações de atualização não podem ser redirecionadas
para o secundário porque o secundário é somente leitura. Por esse motivo, você precisa projetar o aplicativo para
ser executado no modo somente leitura.
Por exemplo, você pode definir um sinalizador que é verificado antes que todas as solicitações de atualização
sejam enviadas ao Armazenamento do Azure. Quando uma das solicitações de atualização chega, você pode
ignorá-la e retornar uma resposta apropriada para o cliente. Talvez você até ainda queira desabilitar totalmente
determinados recursos até que o problema seja resolvido e notificar os usuários de que esses recursos estão
temporariamente indisponíveis.
Se optar por lidar com os erros em cada serviço separadamente, você também precisará lidar com a capacidade
de executar o aplicativo no modo somente leitura pelo serviço. Por exemplo, você pode ter sinalizadores somente
leitura para cada serviço que pode ser habilitado e desabilitado. Em seguida, você pode manipular o sinalizador
nos lugares apropriados do código.
Ser capaz de executar o aplicativo no modo somente leitura tem outro benefício: a capacidade de garantir
funcionalidade limitada durante uma atualização importante do aplicativo. Você pode disparar o aplicativo para
ser executado no modo somente leitura e apontar para o data center secundário, garantindo que ninguém acessa
os dados na região primária enquanto você faz atualizações.
Tratamento de atualizações ao executar no modo somente leitura

Há várias maneiras de lidar com solicitações de atualização durante a execução no modo somente leitura. Não
abordaremos isso de forma abrangente, mas, em geral, há alguns padrões a serem considerados.
1. Você pode responder ao usuário e informar que não está aceitando atualizações. Por exemplo, um sistema
de gerenciamento de contatos pode habilitar os clientes a acessar informações de contato, mas não fazer
atualizações.
2. Você pode enfileirar as atualizações em outra região. Nesse caso, você gravaria as solicitações de
atualização pendentes em uma fila em uma região diferente e teria uma maneira de processar essas
solicitações depois que o data center primário ficasse online novamente. Nesse cenário, você deve
informar ao cliente que a atualização solicitada está na fila para processamento posterior.
3. Você pode gravar as atualizações em uma conta de armazenamento em outra região. Em seguida, quando
o data center primário ficar online novamente, você poderá ter uma maneira de mesclar essas
atualizações nos dados principais, dependendo da estrutura dos dados. Por exemplo, se estiver criando
arquivos separados com um carimbo de data/hora no nome, você poderá copiar esses arquivos de volta
para a região primária. Isso funciona para algumas cargas de trabalho, como dados de log e iOT.
Lidar com repetições

A biblioteca de cliente de armazenamento do Azure ajuda a determinar quais erros podem ser repetidos. Por
exemplo, um erro 404 (recurso não encontrado) não seria repetido porque tentar novamente provavelmente não
resultará em sucesso. Por outro lado, um erro 500 pode ser repetido porque é um erro de servidor e o problema
pode ser simplesmente um problema transitório. Para obter mais detalhes, confira abrir o código-fonte para a
classe ExponentialRetry na biblioteca de cliente de armazenamento do .NET. (Procure o método ShouldRetry.)
Solicitações de leitura
Solicitações de leitura poderão ser redirecionadas para o armazenamento secundário, se houver um problema
no armazenamento primário. Conforme observado acima em Usando dados eventualmente consistentes, deve
ser aceitável que o aplicativo potencialmente leia dados obsoletos. Se você estiver usando a biblioteca de cliente
de armazenamento para acessar dados do secundário, poderá especificar o comportamento de repetição de uma
solicitação de leitura definindo um valor para a propriedade locationmode como um dos seguintes:
Primar yOnly (o padrão)
Primar yThenSecondar y
Secondar yOnly
Secondar yThenPrimar y
Quando você define o locationmode como Primar yThenSecondar y , se a solicitação de leitura inicial para o
ponto de extremidade primário falhar com um erro que pode ser repetido, o cliente fará automaticamente outra
solicitação de leitura para o ponto de extremidade secundário. Se o erro for um tempo limite do servidor, o
cliente terá que aguardar até que o tempo limite expire antes de receber um erro com nova tentativa do serviço.
Existem basicamente dois cenários a serem considerados ao decidir como reagir a um erro com nova tentativa:
Esse é um problema isolado, e solicitações subsequentes para o ponto de extremidade primário não
retornarão um erro com nova tentativa. Um exemplo é quando há um erro de rede temporário.
Nesse cenário, não há uma redução de desempenho significativa quando LocationMode é definido como
Primar yThenSecondar y , pois isso ocorre apenas raramente.
Esse é um problema pelo menos para um dos serviços de armazenamento na região primária, e todas as
solicitações subsequentes desse serviço na região primária provavelmente retornarão erros com nova
tentativa por um período de tempo. Um exemplo disso é se a região primária está totalmente inacessível.
Nesse cenário, há uma redução de desempenho porque todas as solicitações de leitura tentarão primeiro
o ponto de extremidade primário, aguardarão até que o tempo limite expire e alternarão para o ponto de
extremidade secundário.
Nesses cenários, você deve identificar que há um problema contínuo no ponto de extremidade primário e enviar
todas as solicitações de leitura diretamente para o ponto de extremidade secundário, definindo a propriedade
LocationMode como Secondar yOnly . Nesse momento, você também deve alterar o aplicativo para que seja
executado no modo somente leitura. Essa abordagem é conhecida como Padrão de Disjuntor.
Solicitações de atualização
O padrão de Disjuntor também pode ser aplicado a solicitações de atualização. No entanto, as solicitações de
atualização não poderão ser redirecionadas para o armazenamento secundário, que é somente leitura. Para essas
solicitações, você deve deixar a propriedade LocationMode definida como Primar yOnly (o padrão). Para lidar
com esses erros, você pode aplicar uma métrica para essas solicitações (por exemplo, 10 falhas contínuas) e,
quando o limite for atingido, alternar o aplicativo para o modo somente leitura. Você pode usar os mesmos
métodos para retornar para o modo de atualização que são descritos abaixo na seção seguinte sobre o padrão de
Disjuntor.
Padrão de Disjuntor
Usar o padrão de Disjuntor no aplicativo pode impedi-lo de repetir uma operação que provavelmente falhará
repetidas vezes. Ele permite que o aplicativo continue a ser executado em vez de gastar tempo enquanto a
operação é repetida exponencialmente. Ele também detecta quando a falha é corrigida e, nesse momento, o
aplicativo pode tentar a operação novamente.
Como implementar o padrão de disjuntor
Para identificar um problema contínuo em um ponto de extremidade primário, você pode monitorar com que
frequência o cliente encontra erros com nova tentativa. Como cada caso é diferente, você precisa decidir sobre o
limite que deseja usar para a decisão de alternar para o ponto de extremidade secundário e executar o aplicativo
no modo somente leitura. Por exemplo, você poderá decidir executar a mudança se houver 10 falhas contínuas
sem sucesso. Outro exemplo é alternar se 90% das solicitações em um período de dois minutos falharem.
Para o primeiro cenário, você pode simplesmente manter uma contagem de falhas e, se houver êxito antes de
atingir o máximo, definir a contagem como zero. Para o segundo cenário, uma maneira de implementá-lo é usar
o objeto MemoryCache (no .NET). Para cada solicitação, adicione um CacheItem no cache, defina o valor para
sucesso (1) ou falha (0) e defina o tempo de expiração de dois minutos a partir de agora (ou a restrição de tempo
que desejar). Quando o tempo de expiração de uma entrada for atingido, a entrada será removida
automaticamente. Isso lhe dará uma janela de dois minutos sem interrupção. Sempre que faz uma solicitação ao
serviço de armazenamento, primeiro você usa uma consulta Linq no objeto MemoryCache para calcular a
porcentagem de êxitos somando os valores e dividindo pela contagem. Quando a porcentagem de êxitos ficar
abaixo de determinado limite (como 10%), defina a propriedade LocationMode para solicitações de leitura
como Secondar yOnly e alterne o aplicativo para o modo somente leitura antes de continuar.
O limite de erros usado para determinar quando alternar pode variar dependendo do serviço no aplicativo.
Portanto, você deve considerar torná-los parâmetros configuráveis. Esse também é o momento para decidir se
erros com nova tentativa de cada serviço devem ser tratados separadamente ou em conjunto, conforme
discutido anteriormente.
Outra consideração é como lidar com várias instâncias de um aplicativo e o que fazer ao detectar erros com nova
tentativa em cada instância. Por exemplo, você pode ter 20 VMs em execução com o mesmo aplicativo carregado.
Você lida com cada instância separadamente? Se uma instância começar a apresentar problemas, você deseja
limitar a resposta para apenas se uma instância ou deseja tentar fazer com que todas as instâncias respondam da
mesma forma quando uma instância tiver um problema? Tratar as instâncias separadamente é muito mais
simples do que tentar coordenar a resposta entre elas, mas a maneira de fazer isso depende da arquitetura do
aplicativo.
Opções de monitoramento da frequência de erros
Você tem três opções principais para monitorar a frequência de novas tentativas na região primária para
determinar quando passar para a região secundária e alterar o aplicativo para que seja executado no modo
somente leitura.
Adicionar um manipulador para o evento Retr ying do objeto OperationContext que você passa para
solicitações de armazenamento. Esse é o método apresentado neste artigo e usado no exemplo que o
acompanha. Esses eventos são acionados sempre que o cliente tenta novamente uma solicitação,
permitindo que você controle com que frequência o cliente encontra erros com nova tentativa em um
ponto de extremidade primário.
operationContext.Retrying += (sender, arguments) =>

{
// Retrying in the primary region
if (arguments.Request.Host == primaryhostname)
...
};
No método Evaluate em uma política de repetição personalizada, você pode executar código
personalizado sempre que uma repetição ocorre. Além de gravação quando uma repetição ocorre, isso
também lhe dá a oportunidade de modificar o comportamento de repetição.
public RetryInfo Evaluate(RetryContext retryContext,
OperationContext operationContext)
{
var statusCode = retryContext.LastRequestResult.HttpStatusCode;
if (retryContext.CurrentRetryCount >= this.maximumAttempts
|| ((statusCode >= 300 && statusCode < 500 && statusCode != 408)
|| statusCode == 501 // Not Implemented
|| statusCode == 505 // Version Not Supported
))
{
// Do not retry
return null;
}
// Monitor retries in the primary location

...
// Determine RetryInterval and TargetLocation

RetryInfo info =
CreateRetryInfo(retryContext.CurrentRetryCount);
return info;
}
A terceira abordagem é implementar um componente de monitoramento personalizado no aplicativo que

continuamente executa ping no ponto de extremidade de armazenamento primário com solicitações de
leitura fictícias (como ler um blob pequeno) para determinar sua integridade. Isso deve exigir alguns
recursos, mas não uma quantidade significativa. Quando é descoberto um problema que atinge o limite
você executa a mudança para Secondar yOnly e o modo somente leitura.
Em algum momento, convém alternar de volta para o ponto de extremidade primário e permitir atualizações. Se
usar um dos dois primeiros métodos listados acima, você poderá simplesmente alternar de novo para o ponto de
extremidade primário e habilitar o modo de atualização após um período arbitrariamente selecionado ou a
execução de determinado número de operações. Você pode permitir que ele percorra a lógica de repetição
novamente. Se o problema tiver sido corrigido, ele continuará a usar o ponto de extremidade primário e a
permitir atualizações. Se ainda houver um problema, ele alternará mais uma vez para o ponto de extremidade
secundário e o modo somente leitura depois de ser reprovado nos critérios que você definiu.
Para o terceiro cenário, quando a execução de ping no ponto de extremidade de armazenamento primário tiver
êxito novamente, você poderá alternar de volta para Primar yOnly e continuar permitindo atualizações.
Manipulação de dados eventualmente consistentes

O armazenamento com redundância geográfica funciona replicando as transações da região primária para a
secundária. Esse processo de replicação garante que os dados na região secundária sejam eventualmente
consistentes. Isso significa que todas as transações na região primária eventualmente aparecerão na região
secundária, mas pode haver um atraso antes de aparecerem e não há garantia de que as transações chegarão na
região secundária na mesma ordem que em que foram aplicadas originalmente na região primária. Se as
transações chegarem na região secundária fora de ordem, você poderá considerar que os dados na região
secundária estão em um estado inconsistente até que o serviço restabeleça a ordem.
A tabela a seguir mostra um exemplo do que pode acontecer quando você atualiza os detalhes de um
funcionário para torná-los membros da função Administradores . Para este exemplo, isso requer que você
atualize a entidade funcionário e atualize uma entidade função de administrador com uma contagem do
número total de administradores. Observe como as atualizações são aplicadas fora de ordem na região
secundária.
H O RÁ RIO DA ÚLT IM A
H O RA A C IO N A REP L IC A Ç Ã O SIN C RO N IZ A Ç Ã O DISSO
T0 Transação A: Transação A inserida

Inserir funcionário no primário,
entidade no principal ainda não replicada.
T1 Transação A T1 A transação A foi

replicada para replicada para o
secundário secundário.
Hora da Última
Sincronização
atualizada.
T2 Transação B: T1 Transação B gravada

Atualizar no principal,
entidade de ainda não replicada.
funcionário
no principal
T3 Transação C: T1 Transação C gravada

Atualizar no principal,
administrator ainda não replicada.
entidade de função
em
primary
T4 Transação C T1 Transação C replicada

replicada para para o secundário.
secundário LastSyncTime não
atualizado porque
a transação B ainda
não foi replicada.
T5 Ler entidades T1 Você obtém o valor

de secundário obsoleto para a
entidade de
funcionário
porque a transação B
não foi
replicada ainda. Você
obtém o novo valor
para
a entidade de função
de administrador
porque C foi
replicada. A Hora da
Última Sincronização
ainda não
foi atualizada porque
a transação B
não foi replicada.
Você pode ver que a
entidade da função
de administrador está
inconsistente
porque a data/hora
da entidade é
posterior
à Hora da Última
Sincronização.
H O RÁ RIO DA ÚLT IM A
H O RA A C IO N A REP L IC A Ç Ã O SIN C RO N IZ A Ç Ã O DISSO
T6 Transação B T6 T6 – todas as
replicada para transações até C
secundário foram replicadas; a
Hora da Última
Sincronização
foi atualizada.
Neste exemplo, suponha que o cliente alterne para leitura da região secundária em T5. Ele pode ler com êxito a
entidade de função de administrador nesse momento, mas a entidade contém um valor para a contagem de
administradores que não é consistente com o número de entidades funcionário que são marcadas como
administradores na região secundária nesse momento. O cliente simplesmente pode exibir esse valor, com o
risco de que se trata de informações inconsistentes. Como alternativa, o cliente pode tentar determinar que a
função de administrador está em um estado potencialmente inconsistente porque as atualizações ocorreram
fora de ordem e informar esse fato ao usuário.
Para reconhecer que ele tem dados potencialmente inconsistentes, o cliente pode usar o valor da Hora da Última
Sincronização, que você pode obter a qualquer momento consultando um serviço de armazenamento. Isso indica
a hora em que os dados na região secundária estiveram consistentes pela última vez e quando o serviço aplicou
todas as transações antes desse ponto no tempo. No exemplo mostrado acima, após o serviço inserir a entidade
funcionário na região secundária, a Hora da Última Sincronização é definida como T1. Ela permanece em T1 até
que as atualizações de serviço da entidade funcionário na região secundária, quando ela é definida como T6. Se
o cliente recupera a hora da última sincronização ao ler a entidade em T5, pode compará-la ao carimbo de
data/hora na entidade. Se o carimbo de data/hora na entidade é posterior à hora da última sincronização, a
entidade está em um estado potencialmente inconsistente, e você pode tomar a ação apropriada para o
aplicativo. Usar esse campo requer que você saiba quando a última atualização do primário foi concluída.
Para saber como verificar a hora da última sincronização, consulte verificar a propriedade hora da última
sincronização de uma conta de armazenamento.
Testando
É importante testar se o aplicativo se comporta conforme o esperado ao encontra erros com nova tentativa. Por
exemplo, você precisa testar se o aplicativo alterna para o secundário e o modo somente leitura ao detectar um
problema e alterna de volta quando a região primária fica disponível novamente. Para fazer isso, você precisa de
uma maneira de simular erros com nova tentativa e controlar com que frequência eles ocorrem.
Você pode usar o Fiddler para interceptar e modificar respostas HTTP em um script. Esse script pode identificar as
respostas que vêm do ponto de extremidade primário e alterar o código de status HTTP de forma que a
Biblioteca de Cliente de Armazenamento o reconheça como um erros com nova tentativa. Este snippet de código
mostra um exemplo simples de um script do Fiddler que intercepta as respostas para ler as solicitações em
relação à tabela employeedata para retornar um status 502:
static function OnBeforeResponse(oSession: Session) {

...
if ((oSession.hostname == "\[yourstorageaccount\].table.core.windows.net")
&& (oSession.PathAndQuery.StartsWith("/employeedata?$filter"))) {
oSession.responseCode = 502;
}
}
Você pode estender esse exemplo para interceptar uma maior gama de solicitações e alterar apenas o
responseCode em alguns deles para simular melhor um cenário do mundo real. Para obter mais informações
sobre como personalizar os scripts do Fiddler, confira Modificando uma solicitação ou resposta na documentação
do Fiddler.
Se você tiver tornado configuráveis os limites para alternar o aplicativo para o modo somente leitura, será mais
fácil testar o comportamento com volumes de transações de não produção.
Próximas etapas
Para obter um exemplo completo mostrando como fazer a alternância entre os pontos de extremidade primário e
secundário, consulte exemplos do Azure – usando o padrão de disjuntor com o armazenamento ra-grs.
Verificar a propriedade hora da última sincronização
de uma conta de armazenamento
Ao configurar uma conta de armazenamento, você pode especificar que seus dados sejam copiados para uma
região secundária que seja de centenas de milhas da região primária. A replicação geográfica oferece
durabilidade para seus dados em caso de uma interrupção significativa na região primária, como um desastre
natural. Se você também habilitar o acesso de leitura para a região secundária, seus dados permanecerão
disponíveis para operações de leitura se a região primária ficar indisponível. Você pode projetar seu aplicativo
para alternar diretamente para a leitura da região secundária se a região primária não estiver respondendo.
O GRS (armazenamento com redundância geográfica) e o GZRS (armazenamento com redundância de zona
geográfica) replicam seus dados de forma assíncrona para uma região secundária. Para acesso de leitura à região
secundária, habilite o armazenamento com redundância geográfica com acesso de leitura (RA-GRS) ou o
armazenamento com redundância de acesso de leitura (RA-GZRS). Para obter mais informações sobre as várias
opções de redundância oferecidas pelo armazenamento do Azure, consulte redundância de armazenamento do
Azure.
Este artigo descreve como verificar a propriedade hora da última sincronização de sua conta de
armazenamento para que você possa avaliar qualquer discrepância entre as regiões primárias e secundárias.
Sobre a propriedade hora da última sincronização

Como a replicação geográfica é assíncrona, é possível que os dados gravados na região primária ainda não
tenham sido gravados na região secundária no momento em que ocorrer uma interrupção. A propriedade hora
da última sincronização indica a última vez que os dados da região primária foram gravados com êxito na
região secundária. Todas as gravações feitas na região primária antes da hora da última sincronização estão
disponíveis para serem lidas a partir do local secundário. As gravações feitas na região primária após a última
propriedade de hora de sincronização podem ou não estar disponíveis para leituras ainda.
A propriedade hora da última sincronização é um valor de data/hora GMT.
Obter a propriedade hora da última sincronização

Você pode usar o PowerShell ou CLI do Azure para recuperar o valor da última propriedade de hora de
sincronização.
PowerShell
CLI do Azure
Para obter a hora da última sincronização para a conta de armazenamento com o PowerShell, instale uma versão
do módulo AZ. Storage que dá suporte à obtenção de estatísticas de replicação geográfica. Por exemplo:
Install-Module Az.Storage –Repository PSGallery -RequiredVersion ??? –AllowPrerelease –AllowClobber –Force
Em seguida, verifique a propriedade GeoReplicationStats. LastSyncTime da conta de armazenamento.

Lembre-se de substituir os valores de espaço reservado pelos seus próprios valores:
$lastSyncTime = $(Get-AzStorageAccount -ResourceGroupName <resource-group> `
-Name <storage-account> `
-IncludeGeoReplicationStats).GeoReplicationStats.LastSyncTime
Confira também
Redundância de armazenamento do Azure
Alterar a opção de redundância para uma conta de armazenamento
Iniciar um failover de conta de armazenamento
Se o ponto de extremidade primário para sua conta de armazenamento com redundância geográfica ficar
indisponível por algum motivo, você poderá iniciar um failover de conta. Um failover de conta atualiza o ponto de
extremidade secundário para torná-lo um ponto de extremidade primário de sua conta de armazenamento.
Quando o failover estiver concluído, os clientes poderão começar a gravar na nova região primária. O failover
forçado permite manter uma alta disponibilidade para seus aplicativos.
Este artigo mostra como iniciar um failover de conta para sua conta de armazenamento usando o portal do Azure,
o PowerShell ou a CLI do Azure. Para saber mais sobre o failover de conta, consulte recuperação de desastre e
failover da conta de armazenamento.
WARNING
Um failover de conta normalmente resulta em alguma perda de dados. Para entender as implicações de um failover de
conta e para preparar a perda de dados, examine Entendendo o processo de failover da conta.
NOTE
Pré-requisitos
Para poder executar um failover de conta em sua conta de armazenamento, verifique se sua conta de
armazenamento está configurada para replicação geográfica. Sua conta de armazenamento pode usar qualquer
uma das seguintes opções de redundância:
Armazenamento com redundância geográfica (GRS) ou armazenamento com redundância geográfica com
acesso de leitura (RA-GRS)
Armazenamento com redundância de zona geográfica (GZRS) ou armazenamento com redundância de acesso
de leitura (RA-GZRS)
Para obter mais informações sobre a redundância de armazenamento do Azure, consulte redundância de
Iniciar o failover
Portal
PowerShell
CLI do Azure
Para iniciar um failover da conta do portal do Azure, siga estas etapas:
2. Em Configurações , selecione Replicação geográfica . A imagem a seguir mostra o status de replicação
geográfica e de failover de uma conta de armazenamento.
3. Verifique se a conta de armazenamento está configurada para GRS (armazenamento com redundância
geográfica) ou RA-GRS (armazenamento com redundância geográfica com acesso de leitura). Se não
estiver, selecione Configuração em Configurações para atualizar sua conta, acrescentando redundância
geográfica a ela.
4. A propriedade Hora da Última Sincronização indica o atraso do secundário em relação ao primário. A
Hora da Última Sincronização fornece uma estimativa da extensão da perda de dados que você
experimentará após a conclusão do failover.
5. Selecione preparar para failover .
6. Revise a caixa de diálogo de confirmação. Quando você estiver pronto, insira Sim para confirmar e iniciar o
failover.
Implicações importantes de failover da conta
Quando você inicia um failover de conta para sua conta de armazenamento, os registros DNS para o ponto de
extremidade secundário são atualizados para que o ponto de extremidade secundário se torne o ponto de
extremidade primário. Verifique se você compreende o impacto potencial para sua conta de armazenamento
antes de iniciar um failover.
Para estimar a extensão da provável perda de dados antes de iniciar um failover, verifique a propriedade Hora da
Última Sincronização usando o cmdlet Get-AzStorageAccount do PowerShell e inclua o parâmetro
-IncludeGeoReplicationStats . Em seguida, verifique a propriedade GeoReplicationStats para sua conta.
Após o failover, o tipo de conta de armazenamento é automaticamente convertido em LRS (Armazenamento com
Redundância Local) na nova região primária. Você pode reabilitar o GRS (armazenamento com redundância
geográfica) ou o RA-GRS (armazenamento com redundância geográfica com acesso de leitura) para a conta.
Observe que a conversão de LRS em GRS ou RA-GRS acarreta um custo adicional. Para obter informações
adicionais, veja Detalhes de preço de largura de banda.
Depois de habilitar novamente o GRS para sua conta de armazenamento, a Microsoft começa a replicar os dados
em sua conta para a nova região secundária. O tempo de replicação depende da quantidade de dados sendo
replicados.
Próximas etapas
Recuperação de desastres e failover de conta de armazenamento
Tutorial: criar um aplicativo altamente disponível com o armazenamento de BLOBs
Use a Sincronização de Arquivos do Azure para centralizar os compartilhamentos de arquivos da sua organização
em Arquivos do Azure enquanto mantém a flexibilidade, o desempenho e a compatibilidade de um servidor de
arquivos local. A Sincronização de arquivos do Azure transforma o Windows Server em um cache rápido do
compartilhamento de arquivos do Azure. Use qualquer protocolo disponível no Windows Server para acessar
seus dados localmente, incluindo SMB, NFS e FTPS. Você pode ter tantos caches quantos precisar em todo o
mundo.
Este artigo descreve como monitorar sua implantação do Sincronização de Arquivos do Azure usando Azure
Monitor, o serviço de sincronização de armazenamento e o Windows Server.
As opções de monitoramento a seguir estão disponíveis no momento.
Azure Monitor
Use Azure monitor para exibir as métricas e configurar alertas para sincronização, camadas de nuvem e
conectividade de servidor.
Métricas
As métricas para a Sincronização de Arquivos do Azure são habilitadas por padrão e são enviadas para o Azure
Monitor a cada 15 minutos.
Para exibir Sincronização de Arquivos do Azure métricas em Azure Monitor, selecione o tipo de recurso ser viços
de sincronização de armazenamento .
As métricas a seguir para a Sincronização de Arquivos do Azure estão disponíveis no Azure Monitor:
N O M E DA M ÉT RIC A DESC RIÇ Ã O
Bytes sincronizados Tamanho dos dados transferidos (upload e download).
Unidade: Bytes
Tipo de agregação: Sum
Dimensões aplicáveis: nome do ponto de extremidade do
servidor, direção de sincronização, nome do grupo de
sincronização
Recall da camada de nuvem Tamanho dos dados em recall.
Obser vação : essa métrica será removida no futuro. Use a

métrica de tamanho de recuperação de camadas de nuvem
para monitorar o tamanho dos dados recuperados.
Unidade: Bytes
Dimensão aplicável: nome do servidor
N O M E DA M ÉT RIC A DESC RIÇ Ã O
Tamanho de recall em camadas de nuvem Tamanho dos dados em recall.
Unidade: Bytes
Dimensão aplicável: nome do servidor, nome do grupo de
sincronização
Tamanho de recall de camadas de nuvem por aplicativo Tamanho dos dados recuperados pelo aplicativo.
Unidade: Bytes
Dimensão aplicável: nome do aplicativo, nome do servidor,
nome do grupo de sincronização
Taxa de transferência de recall em camadas de nuvem Tamanho da taxa de transferência de recall de dados.
Unidade: Bytes
Dimensão aplicável: nome do servidor, nome do grupo de
sincronização
Arquivos não sincronizando Contagem de arquivos que estão falhando em sincronizar.
Unidade: Contagem
sincronização
Arquivos sincronizados Contagem dos arquivos transferidos (upload e download).
Unidade: Contagem
sincronização
Status online do servidor Contagem de pulsações recebidas do servidor.
Unidade: Contagem
Tipo de agregação: Máximo
Dimensão aplicável: nome do servidor
Resultado da sessão de sincronização Resultado da sessão de sincronização (1 = sessão de

sincronização bem-sucedida; 0 = sessão de sincronização com
falha)
Unidade: Contagem
Tipos de agregação: máximo
sincronização
Alertas
Para configurar alertas no Azure Monitor, selecione o serviço de sincronização de armazenamento e, em seguida,
selecione a métrica de sincronização de arquivos do Azure a ser usada para o alerta.
A tabela a seguir lista alguns cenários de exemplo para monitorar e a métrica apropriada a ser usada para o
alerta:
C EN Á RIO M ÉT RIC A A SER USA DA PA RA A L ERTA
Integridade do ponto de extremidade do servidor no portal = Resultado da sessão de sincronização

erro
Os arquivos estão falhando ao sincronizar com um ponto de Arquivos não sincronizando

extremidade de servidor ou de nuvem
O servidor registrado não está conseguindo se comunicar Status online do servidor

com o serviço de sincronização de armazenamento
O tamanho de recall em camadas de nuvem excedeu 500GiB Tamanho de recall em camadas de nuvem
em um dia
Para saber mais sobre como configurar alertas no Azure Monitor, consulte visão geral de alertas no Microsoft
Azure.
Serviço de Sincronização de Armazenamento

Para exibir a integridade do servidor registrado, a integridade do ponto de extremidade do servidor e as métricas,
vá para o serviço de sincronização de armazenamento no portal do Azure. Você pode exibir a integridade do
servidor registrado na folha ser vidores registrados e a integridade do ponto de extremidade do servidor na
folha grupos de sincronização .
Integridade do servidor registrado
Se o estado do ser vidor registrado estiver online , o servidor estará se comunicando com êxito com o
serviço.
Se o estado do ser vidor registrado for exibido offline , verifique se o processo do monitor de
sincronização de armazenamento (AzureStorageSyncMonitor. exe) no servidor está em execução. Se o servidor
estiver protegido por um firewall ou proxy, consulte Este artigo para configurar o firewall e o proxy.
Integridade do ponto de extremidade do servidor
A integridade do ponto de extremidade do servidor no portal baseia-se nos eventos de sincronização
registrados no log de eventos de telemetria no servidor (ID 9102 e 9302). Se uma sessão de sincronização
falhar devido a um erro transitório, como erro cancelado, a sincronização ainda poderá aparecer íntegra no
portal, desde que a sessão de sincronização atual esteja progredindo. A ID de evento 9302 é usada para
determinar se os arquivos estão sendo aplicados. Para obter mais informações, consulte sincronizar
integridade e sincronizar andamento.
Se o portal mostrar um erro de sincronização porque a sincronização não está progredindo, consulte a
documentação de solução de problemas para obter diretrizes.
Gráficos de métricas
Os gráficos de métrica a seguir são visíveis no portal do serviço de sincronização de armazenamento:
N O M E DA M ÉT RIC A DESC RIÇ Ã O N O M E DA F O L H A
Bytes sincronizados Tamanho dos dados transferidos Grupo de sincronização, ponto de

(upload e download) extremidade do servidor
Recall da camada de nuvem Tamanho dos dados em recall Servidores registrados

N O M E DA M ÉT RIC A DESC RIÇ Ã O N O M E DA F O L H A
Arquivos não sincronizando Contagem de arquivos que estão Ponto de extremidade do servidor
falhando ao sincronizar
Arquivos sincronizados Contagem dos arquivos transferidos Grupo de sincronização, ponto de

(upload e download) extremidade do servidor
Status online do servidor Contagem de pulsações recebidas do Servidores registrados

servidor
Para saber mais, consulte Azure monitor.
NOTE
Os gráficos no portal do Serviço de Sincronização de Armazenamento possuem um intervalo de tempo de 24 horas.
Para exibir os diferentes intervalos de tempo ou dimensões, use o Azure Monitor.
Windows Server
No Windows Server, você pode exibir a camada de nuvem, o servidor registrado e a integridade da sincronização.
Logs de eventos
Use o log de eventos de telemetria no servidor para monitorar a integridade do servidor registrado, da
sincronização e das camadas de nuvem. O log de eventos de telemetria está localizado em Visualizador de
Eventos em Applications e Services\Microsoft\FileSync\Agent.
Integridade da sincronização:
A ID de evento 9102 é registrada após a conclusão de uma sessão de sincronização. Use esse evento para
determinar se as sessões de sincronização são bem-sucedidas (HRESULT = 0 ) e se há erros de
sincronização por item. Para obter mais informações, consulte a documentação sincronizar integridade e
erros por item .
NOTE
Às vezes, as sessões de sincronização falham em geral ou têm um PerItemErrorCount diferente de zero. No entanto,
eles ainda encaminham o progresso e alguns arquivos são sincronizados com êxito. Você pode ver isso nos campos
aplicados, como AppliedFileCount, AppliedDirCount, AppliedTombstoneCount e AppliedSizeBytes. Esses campos
informam quanto da sessão foi bem-sucedida. Se você vir a falha de várias sessões de sincronização em uma linha e
elas tiverem uma contagem aplicada crescente, forneça o tempo de sincronização para tentar novamente antes de
abrir um tíquete de suporte.
A ID do evento 9302 é registrada a cada 5 a 10 minutos, se há uma sessão de sincronização ativa. Use esse
evento para determinar se a sessão de sincronização atual está fazendo o andamento (AppliedItemCount
> 0 ). Se a sincronização não estiver progredindo, a sessão de sincronização deverá eventualmente falhar e
uma ID de evento 9102 será registrada com o erro. Para obter mais informações, consulte a documentação
progresso da sincronização.
Integridade do servidor registrado:
A ID do evento 9301 é registrada a cada 30 segundos quando um servidor consulta o serviço em busca de
trabalhos. Se GetNextJob for concluído com status = 0 , o servidor será capaz de se comunicar com o serviço.
Se GetNextJob for concluído com um erro, consulte a documentação de solução de problemas para obter
diretrizes.
Integridade de camadas de nuvem:
Para monitorar a atividade de camadas em um servidor, use a ID de evento 9003, 9016 e 9029 no log de
eventos de telemetria, que está localizado em Visualizador de Eventos em Applications e
Services\Microsoft\FileSync\Agent.
A identificação de evento 9003 fornece distribuição de erro para um terminal do servidor. Por exemplo:
contagem de erros total e ErrorCode. Um evento é registrado por código de erro.
A identificação de evento 9016 fornece resultados de fantasma para um volume. Por exemplo: a
porcentagem de espaço livre é, o número de arquivos fantasmas na sessão e o número de arquivos
com falha no fantasma.
A ID do evento 9029 fornece informações de sessão de conversão em fantasma para um ponto de
extremidade de servidor. Por exemplo: o número de arquivos tentados na sessão, o número de arquivos
em camadas na sessão e o número de arquivos já em camadas.
Para monitorar a atividade de recuperação em um servidor, use a ID de evento 9005, 9006, 9009 e 9059 no
log de eventos de telemetria, localizado em Visualizador de Eventos em Applications e
Services\Microsoft\FileSync\Agent.
A ID de evento 9005 fornece confiabilidade de recall para um ponto de extremidade do servidor. Por
exemplo: total de arquivos exclusivos acessados e total de arquivos exclusivos com falha de acesso.
ID do evento 9006 fornece Lembre-se a distribuição de erro para um ponto de extremidade do servidor.
Por exemplo: total de solicitações com falha e ErrorCode. Um evento é registrado por código de erro.
A ID do evento 9009 fornece informações de sessão de recall para um ponto de extremidade de
servidor. Por exemplo: DurationSeconds, CountFilesRecallSucceeded e CountFilesRecallFailed.
A ID do evento 9059 fornece distribuição de recall do aplicativo para um ponto de extremidade de
servidor. Por exemplo: Shareid, nome do aplicativo e TotalEgressNetworkBytes.
Contadores de desempenho
Use os contadores de desempenho da Sincronização de Arquivos do Azure no servidor para monitorar a
atividade de sincronização.
Para exibir Sincronização de Arquivos do Azure contadores de desempenho no servidor, abra o monitor de
desempenho (Perfmon. exe). Você pode encontrar os contadores nos objetos de operações de sincronização
de AFS bytes transferidos e AFS.
Os seguintes contadores de desempenho para a Sincronização de Arquivos do Azure estão disponíveis no
Monitor de Desempenho:
O B JETO DE DESEM P EN H O \ N O M E DO C O N TA DO R DESC RIÇ Ã O
Bytes de AFS Transferidos\Bytes Baixados/s Número de bytes baixados por segundo.
Bytes de AFS Transferidos\Bytes Carregados/s Número de bytes carregados por segundo.
Bytes de AFS Transferidos\Total de Bytes/s Total de bytes por segundo (upload e download).
Operações de Sincronização de AFS\Arquivos de Número de arquivos baixados por segundo.

Sincronização Baixados/s
Operações de Sincronização de AFS\Arquivos de Número de arquivos carregados por segundo.

Sincronização Carregados/s
O B JETO DE DESEM P EN H O \ N O M E DO C O N TA DO R DESC RIÇ Ã O
Operações de Sincronização de AFS\Total de Operações de Número total de arquivos sincronizados (upload e download).
Arquivo de Sincronização/s
Próximas etapas
Considere as configurações de firewall e proxy
Perguntas frequentes da Arquivos do Azure
Migrar para compartilhamentos de Arquivos do
Azure
Este artigo aborda os aspectos básicos de uma migração para compartilhamentos de arquivos do Azure.
Este artigo contém noções básicas de migração e uma tabela de guias de migração. Esses guias ajudam você a
mover seus arquivos para compartilhamentos de arquivos do Azure. Os guias são organizados com base em onde
estão os dados e em qual modelo de implantação (somente em nuvem ou híbrido) você está migrando.
Noções básicas de migração

O Azure tem vários tipos de armazenamento em nuvem disponíveis. Um aspecto fundamental das migrações de
arquivos para o Azure é determinar qual opção de armazenamento do Azure é adequada para seus dados.
Os compartilhamentos de arquivos do Azure são adequados para dados de arquivo de uso geral. Esses dados
incluem tudo o que você usa em um compartilhamento SMB ou NFS local para o. Com o sincronização de
arquivos do Azure, você pode armazenar em cache o conteúdo de vários compartilhamentos de arquivos do Azure
em servidores que executam o Windows Server local.
Para um aplicativo que é executado atualmente em um servidor local, o armazenamento de arquivos em um
compartilhamento de arquivos do Azure pode ser uma boa opção. Você pode mover o aplicativo para o Azure e
usar compartilhamentos de arquivos do Azure como armazenamento compartilhado. Você também pode
considerar os discos do Azure para esse cenário.
Alguns aplicativos de nuvem não dependem de SMB ou de acesso a dados locais de computador ou acesso
compartilhado. Para esses aplicativos, o armazenamento de objeto como BLOBs do Azure geralmente é a melhor
opção.
A chave em qualquer migração é capturar toda a fidelidade do arquivo aplicável ao mover os arquivos de seu local
de armazenamento atual para o Azure. A quantidade de fidelidade que a opção de armazenamento do Azure dá
suporte e o quanto seu cenário exige também ajuda a escolher o armazenamento do Azure correto. Os dados de
arquivo de uso geral dependem tradicionalmente dos metadados do arquivo. Os dados do aplicativo podem não.
Estes são os dois componentes básicos de um arquivo:
Fluxo de dados : o fluxo de dados de um arquivo armazena o conteúdo do arquivo.
Metadados de arquivo : os metadados de arquivo têm estes subcomponentes:
Atributos de arquivo como somente leitura
Permissões de arquivo, que podem ser referenciadas como permissões NTFS ou ACLs de arquivo e pasta
Carimbos de data/hora, principalmente os carimbos de data/hora da criação e da última modificação
Um fluxo de dados alternativo, que é um espaço para armazenar grandes quantidades de propriedades
não padrão
A fidelidade do arquivo em uma migração pode ser definida como a capacidade de:
Armazene todas as informações de arquivo aplicáveis na origem.
Transfira arquivos com a ferramenta de migração.
Armazene arquivos no armazenamento de destino da migração.
Para garantir que a migração continue sem problemas, identifique a melhor ferramenta de cópia para suas
necessidades e faça a correspondência de um destino de armazenamento com sua fonte.
Levando em conta as informações anteriores, você pode ver que o armazenamento de destino para arquivos de
uso geral no Azure é compartilhamentos de arquivos do Azure.
Ao contrário do armazenamento de objetos em BLOBs do Azure, um compartilhamento de arquivos do Azure
pode armazenar os metadados de arquivo nativamente. Os compartilhamentos de arquivos do Azure também
preservam a hierarquia de arquivos e pastas, atributos e permissões. As permissões NTFS podem ser armazenadas
em arquivos e pastas porque são locais.
Um usuário de Active Directory, que é o controlador de domínio local, pode acessar nativamente um
compartilhamento de arquivos do Azure. Portanto, um usuário de Azure Active Directory Domain Services (AD DS
do Azure). Cada uma usa sua identidade atual para obter acesso com base nas permissões de compartilhamento e
nas ACLs de arquivo e pasta. Esse comportamento é semelhante a um usuário que se conecta a um
compartilhamento de arquivos local.
O fluxo de dados alternativo é o aspecto principal da fidelidade do arquivo que atualmente não pode ser
armazenado em um arquivo em um compartilhamento de arquivos do Azure. Ele é preservado localmente quando
Sincronização de Arquivos do Azure é usado.
Saiba mais sobre a autenticação do Azure ad e a autenticação de AD DS do Azure para compartilhamentos de
arquivos do Azure.
Guias de migração
A tabela a seguir lista os guias de migração detalhados.
Como usar a tabela:
1. Localize a linha do sistema de origem em que os arquivos estão armazenados no momento.
2. Escolha um destes destinos:
Uma implantação híbrida usando Sincronização de Arquivos do Azure para armazenar em cache o
conteúdo dos compartilhamentos de arquivos do Azure no local
Compartilhamentos de arquivos do Azure na nuvem
Selecione a coluna de destino que corresponde à sua escolha.
3. Dentro da interseção de origem e destino, uma célula de tabela lista os cenários de migração disponíveis.
Selecione uma para vincular diretamente ao guia de migração detalhado.
Um cenário sem um link ainda não tem um guia de migração publicado. Marque esta tabela ocasionalmente para
obter atualizações. Novos guias serão publicados quando estiverem disponíveis.
DEST IN O : DEST IN O :
FONT E IM P L A N TA Ç Ã O H ÍB RIDA IM P L A N TA Ç Ã O SO M EN T E EM N UVEM
Combinação de ferramentas: Combinação de ferramentas:
Windows Server 2012 R2 e posterior Sincronização de Arquivos do Sincronização de Arquivos do

Azure Azure
Sincronização de Arquivos do Sincronização de Arquivos do
Azure e Azure Data Box Azure e Data Box
Serviço de migração de Serviço de migração de
Sincronização de Arquivos do Sincronização de Arquivos do
Azure e armazenamento Azure e armazenamento
RoboCopy
DEST IN O : DEST IN O :
FONT E IM P L A N TA Ç Ã O H ÍB RIDA IM P L A N TA Ç Ã O SO M EN T E EM N UVEM
Windows Server 2012 e anterior Sincronização de Arquivos do Serviço de migração de

Azure e Data Box Sincronização de Arquivos do
Serviço de migração de Azure e armazenamento
Sincronização de Arquivos do RoboCopy
Azure e armazenamento
NAS (armazenamento conectado à Sincronização de Arquivos do RoboCopy

rede) Azure e RoboCopy
Linux ou samba Sincronização de Arquivos do RoboCopy

Azure e RoboCopy
Microsoft Azure StorSimple Cloud Sincronização de Arquivos do

Appliance 8100 ou dispositivo de Azure e dispositivo de nuvem
nuvem StorSimple 8600 StorSimple 8020
Dispositivo de nuvem StorSimple 1200 Sincronização de Arquivos do

Azure
Caixa de ferramentas de migração

Ferramentas de cópia de arquivos
Há várias ferramentas de cópia de arquivos disponíveis da Microsoft e de outras. Para selecionar a ferramenta
certa para seu cenário de migração, você deve considerar estas perguntas fundamentais:
A ferramenta dá suporte aos locais de origem e de destino para sua cópia de arquivo?
A ferramenta dá suporte ao seu caminho de rede ou protocolos disponíveis (como REST, SMB ou NFS) entre
os locais de armazenamento de origem e de destino?
A ferramenta preserva a fidelidade de arquivo necessária com suporte nos locais de origem e de destino?
Em alguns casos, o armazenamento de destino não dá suporte à mesma fidelidade que sua fonte. Se o
armazenamento de destino for suficiente para suas necessidades, a ferramenta deverá corresponder apenas
aos recursos de fidelidade de arquivo do destino.
A ferramenta tem recursos que permitem que ele se ajuste à sua estratégia de migração?
Por exemplo, considere se a ferramenta permite minimizar o tempo de inatividade.
Quando uma ferramenta dá suporte a uma opção para espelhar uma origem em um destino, você
geralmente pode executá-la várias vezes na mesma origem e no mesmo destino, enquanto a origem
permanece acessível.
Na primeira vez que você executar a ferramenta, ela copiará a massa dos dados. Essa execução inicial pode
durar um pouco. Ele geralmente dura mais do que você deseja colocar a fonte de dados offline para seus
processos de negócios.
Ao espelhar uma origem para um destino (como com o Robocopy/Mir ), você pode executar a ferramenta
novamente na mesma origem e no mesmo destino. A execução é muito mais rápida porque precisa
transportar somente as alterações de origem que ocorrem após a execução anterior. Executar novamente
uma ferramenta de cópia dessa maneira pode reduzir significativamente o tempo de inatividade.
A tabela a seguir classifica as ferramentas da Microsoft e sua adequação atual para compartilhamentos de
arquivos do Azure:
SUP O RT E PA RA
C O M PA RT IL H A M EN TO S DE P RESERVA Ç Ã O DA
REC O M EN DA DA S F ERRA M EN TA A RQ UIVO S DO A Z URE F IDEL IDA DE DO A RQ UIVO
RoboCopy Com suporte. Os Fidelidade total. *

compartilhamentos de
arquivos do Azure podem
ser montados como
unidades de rede.
Sincronização de Arquivos Integrado nativamente aos Fidelidade total. *

do Azure compartilhamentos de
arquivos do Azure.
Serviço de Migração de Com suporte indiretamente. Fidelidade total. *

Armazenamento Os compartilhamentos de
arquivos do Azure podem
ser montados como
unidades de rede em
servidores de destino do
SMS.
Data Box Com suporte. Não copia metadados. Data

box pode ser usado com
sincronização de arquivos do
Azure.
AzCopy Com suporte. Não copia metadados.
Gerenciador de Com suporte. Não copia metadados.

Armazenamento do Azure
Fábrica de dados do Azure Com suporte. Não copia metadados.
*Fidelidade total: atende ou excede os recursos de compartilhamento de arquivos do Azure.

Ferramentas auxiliares de migração
Esta seção descreve as ferramentas que ajudam a planejar e executar migrações.
RoboCopy da Microsoft Corporation
O RoboCopy é uma das ferramentas mais aplicáveis às migrações de arquivos. Ele é fornecido como parte do
Windows. A principal documentação do Robocopy é um recurso útil para as várias opções dessa ferramenta.
Árvores de EMPERRAmento da Software GmbH
Sincronização de Arquivos do Azure é dimensionado principalmente com o número de itens (arquivos e pastas) e
não com a quantidade total de armazenamento. A ferramenta Treeize permite que você determine o número de
itens nos volumes do Windows Server.
Você pode usar a ferramenta para criar uma perspectiva antes de uma implantação de sincronização de arquivos
do Azure. Você também pode usá-lo quando a camada de nuvem estiver envolvida após a implantação. Nesse
cenário, você vê o número de itens e quais diretórios usam o cache do servidor mais.
A versão testada da ferramenta é a versão 4.4.1. Ele é compatível com arquivos em camadas de nuvem. A
ferramenta não causará a recall de arquivos em camadas durante sua operação normal.
Próximas etapas
1. Crie um plano para o qual implantação de compartilhamentos de arquivos do Azure (somente em nuvem ou
híbrido) você deseja.
2. Examine a lista de guias de migração disponíveis para encontrar o guia detalhado que corresponde à sua
origem e implantação de compartilhamentos de arquivos do Azure.
Aqui estão mais informações sobre as tecnologias de arquivos do Azure mencionadas neste artigo:
Visão geral do compartilhamento de arquivos do Azure
Sincronização de Arquivos do Azure: camadas de nuvem
Migrar dados em massa para Sincronização de
Arquivos do Azure com o Azure Data Box
Você pode migrar dados em massa para Sincronização de Arquivos do Azure de duas maneiras:
Carregue seus arquivos usando sincronização de arquivos do Azure. Esse é o método mais simples.
Mova os arquivos localmente para o Windows Server 2012 R2 ou posterior e instale o agente de
Sincronização de Arquivos do Azure. Depois de configurar a sincronização, os arquivos serão carregados do
servidor. (Atualmente, nossos clientes enfrentam uma velocidade de upload média de 1 TiB a cada dois dias.)
Para garantir que o servidor não use muita largura de banda para seu datacenter, talvez você queira configurar
um agendamento de limitação de largura de banda.
Transfira os arquivos offline. Se você não tiver largura de banda suficiente, talvez não consiga carregar
arquivos no Azure em um período de tempo razoável. O desafio é a sincronização inicial de todo o conjunto de
arquivos. Para superar esse desafio, use ferramentas de migração em massa offline, como a família de Azure
data Box.
Este artigo explica como migrar arquivos offline de forma que seja compatível com Sincronização de Arquivos do
Azure. Siga estas instruções para evitar conflitos de arquivo e preservar as listas de controle de acesso (ACLs) de
arquivo e pasta e os carimbos de data/hora depois de habilitar a sincronização.
Ferramentas de migração
O processo que descrevemos neste artigo funciona não apenas para Data Box, mas também para outras
ferramentas de migração offline. Ele também funciona para ferramentas como AzCopy, Robocopy ou ferramentas
de parceiros e serviços que funcionam diretamente pela Internet. No entanto, para superar o desafio de upload
inicial, siga as etapas neste artigo para usar essas ferramentas de forma que seja compatível com Sincronização
Em alguns casos, você precisa passar de um Windows Server para outro Windows Server antes de adotar
Sincronização de Arquivos do Azure. O serviço de migração de armazenamento (SMS) pode ajudar com isso.
Independentemente de você precisar migrar para uma versão do sistema operacional com suporte pelo
Sincronização de Arquivos do Azure (Windows Server 2012R2 e up) ou simplesmente precisar migrar porque
você está comprando um novo sistema para Sincronização de Arquivos do Azure, o SMS tem vários recursos e
vantagens que ajudarão a fazer com que sua migração seja feita sem problemas.
Benefícios de usar uma ferramenta para transferir dados offline

Aqui estão os principais benefícios do uso de uma ferramenta de transferência como Data Box para a migração
offline:
Você não precisa carregar todos os seus arquivos pela rede. Para namespaces grandes, essa ferramenta pode
economizar tempo e largura de banda de rede significativa.
Quando você usa Sincronização de Arquivos do Azure, não importa qual ferramenta de transferência usa (Data
Box, serviço de importação/exportação do Azure e assim por diante), o servidor ao vivo carrega somente os
arquivos que são alterados depois que você move os dados para o Azure.
O Sincronização de Arquivos do Azure sincroniza as ACLs de arquivo e pasta mesmo se a ferramenta de
migração em massa offline não transportar ACLs.
Data Box e Sincronização de Arquivos do Azure não exigem nenhum tempo de inatividade. Ao usar Data Box
para transferir dados para o Azure, você usa a largura de banda de rede com eficiência e preserva a fidelidade
do arquivo. Você também mantém seu namespace atualizado carregando apenas os arquivos que são
alterados depois de mover os dados para o Azure.
Pré-requisitos para a transferência de dados offline

Você não deve habilitar a sincronização no servidor que está migrando antes de concluir a transferência de dados
offline. Outras coisas a serem consideradas antes de começar são as seguintes:
Se você planeja usar Data Box para sua migração em massa: examine os pré-requisitos de implantação para
data Box.
Planejar a topologia de Sincronização de Arquivos do Azure final: planejar uma implantação de sincronização
Escolha a conta de armazenamento do Azure que conterá os compartilhamentos de arquivos com os quais
você deseja sincronizar. Assegure-se de que sua migração em massa ocorra nos compartilhamentos de
preparo temporários da mesma Conta de Armazenamento. A migração em massa só poderá ser ativada
utilizando um compartilhamento final e um compartilhamento de preparo que residem na mesma conta de
armazenamento.
Uma migração em massa só pode ser utilizada quando você cria uma nova relação de sincronização com um
local do servidor. Você não pode habilitar uma migração em massa com uma relação de sincronização
existente.
Processo para transferência de dados offline

Veja como configurar Sincronização de Arquivos do Azure de forma que seja compatível com ferramentas de
migração em massa, como Azure Data Box:
ETA PA DETA L H ES
ETA PA DETA L H ES
Solicite o Data Box. A família de Data Box oferece vários

produtos para atender às suas necessidades. Ao receber sua
data Box, siga sua documentação para copiar os dados para
esse caminho UNC no data Box: * \<><DeviceIPAddres
StorageAccountName_AzFile><ShareName>*. Aqui,
ShareName é o nome do compartilhamento de preparo. Envie
o Data Box para o Azure.
Aguarde até que os arquivos apareçam nos

compartilhamentos de arquivos do Azure que você escolheu
como compartilhamentos temporários de preparo. Não
habilite a sincronização para esses compartilhamentos.
Crie um novo compartilhamento vazio para cada

compartilhamento de arquivos que Data Box criado
para você. Esse novo compartilhamento deve estar na
mesma conta de armazenamento que o
compartilhamento de Data Box. Como criar um novo
Crie um grupo de sincronização em um serviço de
sincronização de armazenamento. Referencie o
compartilhamento vazio como um ponto de
extremidade de nuvem. Repita essa etapa para cada
compartilhamento de arquivos do Data Box.
Configurar sincronização de arquivos do Azure.
Adicione seu diretório do servidor ao vivo como um ponto de

extremidade do servidor. No processo, especifique que você
moveu os arquivos para o Azure e faça referência aos
compartilhamentos de preparo. Você pode habilitar ou
desabilitar a disposição em camadas de nuvem conforme
necessário. Ao criar um ponto de extremidade do servidor em
seu servidor dinâmico, faça referência ao compartilhamento
de preparo. Na folha Adicionar ponto de extremidade do
ser vidor , em transferência de dados offline , selecione
habilitado e, em seguida, selecione o compartilhamento de
preparo que deve estar na mesma conta de armazenamento
que o ponto de extremidade da nuvem. Aqui, a lista de
compartilhamentos disponíveis é filtrada por conta de
armazenamento e compartilhamentos que ainda não estão
sincronizando. A captura de tela após esta tabela mostra
como referenciar o compartilhamento data box durante a
criação do ponto de extremidade do servidor no portal do
Azure.
Depois de adicionar o ponto de extremidade do servidor na

etapa anterior, os dados começam a fluir automaticamente da
origem correta. A seção sincronizando o compartilhamento
explica quando os dados fluem do compartilhamento data
Box ou do Windows Server
Sincronização do compartilhamento
Depois de criar o ponto de extremidade do servidor, a sincronização será iniciada. O processo de sincronização
determina se cada arquivo no servidor também existe no compartilhamento de preparo em que Data Box
deposita os arquivos. Se o arquivo existir lá, o processo de sincronização copiará o arquivo do compartilhamento
de preparo em vez de carregá-lo do servidor. Se o arquivo não existir no compartilhamento de preparo ou se uma
versão mais recente estiver disponível no servidor local, o processo de sincronização carregará o arquivo do
servidor local.
Ao sincronizar o compartilhamento, a sincronização mesclará quaisquer atributos de arquivo ausentes,
permissões ou carimbos de data/hora das variantes de arquivo no servidor local, combinando-os com suas
contrapartes de arquivo do compartilhamento data box. Isso garante que cada arquivo e pasta cheguem com toda
a fidelidade de arquivo possível no compartilhamento de arquivos do Azure.
IMPORTANT
Você pode habilitar o modo de migração em massa somente enquanto estiver criando um ponto de extremidade do
servidor. Depois de estabelecer um ponto de extremidade do servidor, você não pode integrar dados de migração em massa
de um servidor já sincronizado no namespace.
ACLs e carimbos de data/hora em arquivos e pastas

Sincronização de Arquivos do Azure garante que as ACLs de arquivo e pasta sejam sincronizadas a partir do
servidor ativo, mesmo que a ferramenta de migração em massa que você usou não tenha transportado
inicialmente as ACLs. Por isso, o compartilhamento de preparo não precisa conter nenhuma ACL para arquivos e
pastas. Quando você habilita o recurso de migração de dados offline ao criar um novo ponto de extremidade do
servidor, todas as ACLs de arquivo são sincronizadas no servidor. Os carimbos de data/hora recém-criados e
modificados também são sincronizados.
Forma do namespace
Quando você habilita a sincronização, o conteúdo do servidor determina a forma do namespace. Se os arquivos
forem excluídos do servidor local após a conclusão do instantâneo de Data Box e da migração, esses arquivos não
serão movidos para o namespace de sincronização ao vivo. Eles permanecem no compartilhamento de preparo,
mas não são copiados. Isso é necessário porque a sincronização mantém o namespace de acordo com o servidor
dinâmico. O instantâneo de data Box é apenas um aterramento de preparo para uma cópia de arquivo eficiente.
Não é a autoridade para a forma do namespace ao vivo.
Limpando após a migração em massa

Conforme o servidor conclui sua sincronização inicial do namespace, o Data Box arquivos migrados em massa
usam o compartilhamento de arquivos de preparo. Na folha de propriedades de ponto de extremidade do
ser vidor no portal do Azure, na seção transferência de dados offline , o status muda de em andamento
para concluído .
Agora você pode limpar o compartilhamento de preparo para economizar custos:

1. Na folha Propriedades do ponto de extremidade do ser vidor , quando o status for concluído , selecione
desabilitar transferência de dados offline .
2. Considere excluir o compartilhamento de preparo para economizar custos. O compartilhamento de preparo
provavelmente não contém ACLs de arquivo e pasta, portanto, é improvável que seja útil. Para fins de backup
de ponto no tempo, crie um instantâneo real da sincronização do compartilhamento de arquivos do Azure.
Você pode Configurar o backup do Azure para tirar instantâneos de uma agenda.
Desabilite o modo de transferência de dados offline somente quando o estado for concluído ou quando desejar
cancelar devido a uma configuração incorreta. Se você desabilitar o modo durante uma implantação, os arquivos
começarão a ser carregados do servidor, mesmo que o compartilhamento de preparo ainda esteja disponível.
IMPORTANT
Depois de desabilitar o modo de transferência de dados offline, você não poderá habilitá-lo novamente, mesmo que o
compartilhamento de preparo da migração em massa ainda esteja disponível.
Próximas etapas
Planejar uma implantação da Sincronização de Arquivos do Azure
Migre do Linux para uma implantação de nuvem
híbrida com Sincronização de Arquivos do Azure
Sincronização de Arquivos do Azure funciona em instâncias do Windows Server com DAS (armazenamento com
conexão direta). Ele não dá suporte à sincronização de e para o Linux ou a um compartilhamento remoto de
protocolo SMB.
Como resultado, transformar os serviços de arquivo em uma implantação híbrida faz uma migração para o
Windows Server necessária. Este artigo orienta você pelo planejamento e pela execução de tal migração.
Metas de migração
O objetivo é mover os compartilhamentos que você tem em seu servidor Samba do Linux para uma instância do
Windows Server. Em seguida, use Sincronização de Arquivos do Azure para uma implantação de nuvem híbrida.
Essa migração precisa ser feita de forma a garantir a integridade dos dados de produção, bem como a
disponibilidade durante a migração. O segundo requer um mínimo de tempo de inatividade, para que ele possa se
ajustar ou ter apenas um pouco mais de uma janela de manutenção regular.
Visão geral da migração

Conforme mencionado no artigo Visão geral da migraçãode arquivos do Azure, é importante usar a ferramenta de
cópia correta e a abordagem. Seu servidor do Linux Samba está expondo compartilhamentos SMB diretamente em
sua rede local. O Robocopy, criado no Windows Server, é a melhor maneira de mover seus arquivos nesse cenário
de migração.
Se você não estiver executando o samba em seu servidor Linux e, em vez disso, quiser migrar pastas para uma
implantação híbrida no Windows Server, poderá usar as ferramentas de cópia do Linux em vez do Robocopy. Se
você fizer isso, lembre-se dos recursos de fidelidade em sua ferramenta de cópia de arquivos. Examine a seção
noções básicas de migração no artigo Visão geral da migração para saber o que procurar em uma ferramenta de
cópia.
Fase 1: identificar Quantos compartilhamentos de arquivos do Azure

você precisa
Nesta etapa, você está avaliando Quantos compartilhamentos de arquivos do Azure são necessários. Uma única
instância do Windows Server (ou cluster) pode sincronizar até 30 compartilhamentos de arquivos do Azure.
Você pode ter mais pastas em seus volumes que estão sendo compartilhados localmente como
compartilhamentos SMB para seus usuários e aplicativos. A maneira mais fácil é desconceber um
compartilhamento local que mapeia 1:1 para um compartilhamento de arquivos do Azure. Se você tiver um
número pequeno o suficiente, abaixo de 30 para uma única instância do Windows Server, recomendamos um
mapeamento 1:1.
Se você tiver mais compartilhamentos do que 30, muitas vezes é desnecessário mapear um compartilhamento
local 1:1 para um compartilhamento de arquivos do Azure. Considere as opções a seguir.
Agrupamento de compartilhamento
Se o seu departamento de RH (por exemplo) tiver um total de 15 compartilhamentos, você poderá considerar
armazenar todos os dados de RH em um único compartilhamento de arquivos do Azure. O armazenamento de
vários compartilhamentos locais em um compartilhamento de arquivos do Azure não impede que você crie os 15
compartilhamentos SMB usuais em sua instância local do Windows Server. Isso significa apenas que você organiza
as pastas raiz desses 15 compartilhamentos como subpastas em uma pasta comum. Em seguida, sincronize essa
pasta comum com um compartilhamento de arquivos do Azure. Dessa forma, apenas um único compartilhamento
de arquivos do Azure na nuvem é necessário para esse grupo de compartilhamentos locais.
Sincronização de volume
O Sincronização de Arquivos do Azure dá suporte à sincronização da raiz de um volume para um
compartilhamento de arquivos do Azure. Se você sincronizar a pasta raiz, todas as subpastas e arquivos vão para o
mesmo compartilhamento de arquivos do Azure.
A sincronização da raiz do volume nem sempre é a melhor resposta. Há benefícios na sincronização de vários
locais. Por exemplo, isso ajuda a manter o número de itens menores por escopo de sincronização. Configurar
Sincronização de Arquivos do Azure com um número menor de itens não é apenas benéfico para a sincronização
de arquivos. Um número menor de itens também beneficia cenários como estes:
A restauração do lado da nuvem de um instantâneo de compartilhamento de arquivos do Azure pode ser
realizada como um backup.
A recuperação de desastres de um servidor local pode acelerar significativamente.
As alterações feitas diretamente em um compartilhamento de arquivos do Azure (fora da sincronização) podem
ser detectadas e sincronizadas mais rapidamente.
Uma abordagem estruturada para um mapa de implantação
Antes de implantar o armazenamento em nuvem em uma etapa posterior, é importante criar um mapa entre
pastas locais e compartilhamentos de arquivos do Azure. Esse mapeamento informará quantas e quais
Sincronização de Arquivos do Azure os recursos do grupo de sincronização que você provisionar. Um grupo de
sincronização vincula o compartilhamento de arquivos do Azure e a pasta em seu servidor em conjunto e
estabelece uma conexão de sincronização.
Para tomar a decisão sobre quantos compartilhamentos de arquivos do Azure você precisa, examine os limites e as
melhores práticas a seguir. Isso ajudará você a otimizar seu mapa.
Um servidor com o agente de Sincronização de Arquivos do Azure instalado pode sincronizar com até 30
Um compartilhamento de arquivos do Azure é implantado dentro de uma conta de armazenamento. Isso
torna a conta de armazenamento um destino de escala para números de desempenho, como IOPS e taxa de
transferência.
Dois compartilhamentos de arquivos do Azure padrão (não Premium) podem, teoricamente, saturar o
desempenho máximo que uma conta de armazenamento pode fornecer. Se você planeja anexar apenas
Sincronização de Arquivos do Azure a esses compartilhamentos de arquivos, o agrupamento de vários
compartilhamentos de arquivos do Azure na mesma conta de armazenamento não criará um problema.
Examine os destinos de desempenho do compartilhamento de arquivos do Azure para obter informações
mais aprofundadas sobre as métricas relevantes a serem consideradas.
Se você planeja levantar um aplicativo para o Azure que usará o compartilhamento de arquivos do Azure
nativamente, talvez precise de mais desempenho do compartilhamento de arquivos do Azure. Se essa for
uma possibilidade, mesmo no futuro, o mapeamento de um compartilhamento de arquivos do Azure para
sua própria conta de armazenamento é o melhor.
Há um limite de 250 contas de armazenamento por assinatura em uma única região do Azure.
TIP
Com essas informações em mente, geralmente é necessário agrupar várias pastas de nível superior em seus volumes em um
diretório raiz comum e novo. Em seguida, você sincroniza esse novo diretório raiz e todas as pastas que você agrupau para
ele para um único compartilhamento de arquivos do Azure. Essa técnica permite que você permaneça dentro do limite de 30
sincronizações de compartilhamento de arquivos do Azure por servidor.
Esse agrupamento sob uma raiz comum não tem impacto sobre o acesso aos seus dados. Suas ACLs permanecem como
estão. Você precisaria apenas ajustar os caminhos de compartilhamento (como compartilhamentos SMB ou NFS) que você
pode ter nas pastas de servidor que você alterou em uma raiz comum. Nada mais muda.
Outro aspecto importante do Sincronização de Arquivos do Azure e de um desempenho e experiência balanceada

é compreender os fatores de escala para o desempenho de Sincronização de Arquivos do Azure. Obviamente,
quando os arquivos são sincronizados pela Internet, os arquivos maiores levam mais tempo e largura de banda
para sincronização.
IMPORTANT
O vetor de escala mais importante para Sincronização de Arquivos do Azure é o número de itens (arquivos e pastas) que
precisam ser sincronizados.
O Sincronização de Arquivos do Azure dá suporte à sincronização de até 100.000 itens para um único
compartilhamento de arquivos do Azure. Esse limite pode ser excedido e mostra apenas o que a equipe de
Sincronização de Arquivos do Azure testa regularmente.
É uma prática recomendada manter o número de itens por escopo de sincronização baixo. Esse é um fator
importante a ser considerado no mapeamento de pastas para compartilhamentos de arquivos do Azure.
Em sua situação, é possível que um conjunto de pastas possa ser sincronizado logicamente com o mesmo
compartilhamento de arquivos do Azure (usando a nova abordagem de pasta raiz comum mencionada
anteriormente). Mas talvez ainda seja melhor reagrupar pastas de forma que elas sincronizem com duas, em vez
de um compartilhamento de arquivos do Azure. Você pode usar essa abordagem para manter o número de
arquivos e pastas por compartilhamento de arquivos balanceados pelo servidor.
Criar uma tabela de mapeamento
Use uma combinação dos conceitos anteriores para ajudar a determinar quantos compartilhamentos de arquivos
do Azure são necessários e quais partes dos dados existentes acabarão com o compartilhamento de arquivos do
Azure.
Crie uma tabela que registra suas ideias, para que você possa consultá-las na próxima etapa. Manter-se organizado
é importante, pois pode ser fácil perder detalhes do seu plano de mapeamento quando você estiver Provisionando
muitos recursos do Azure de uma vez. Para ajudá-lo a criar um mapeamento completo, você pode baixar um
arquivo do Microsoft Excel como um modelo.
Baixe um modelo de mapeamento de namespace.
Fase 2: provisionar uma instância do Windows Server local adequada

Crie uma instância do Windows Server 2019 como uma máquina virtual ou um servidor físico. O Windows
Server 2012 R2 é o requisito mínimo. Também há suporte para um cluster de failover do Windows Server.
Provisione ou adicione o DAS (armazenamento anexado direto). Não há suporte para Armazenamento NAS
(Network Attached Storage).
A quantidade de armazenamento que você provisiona pode ser menor do que o que você está usando
atualmente em seu servidor do Linux Samba, se você usar o recurso de camadas de nuvem sincronização de
arquivos do Azure. No entanto, ao copiar os arquivos do espaço do servidor Samba do Linux maior para o
volume menor do Windows Server em uma fase posterior, você precisará trabalhar em lotes:
1. Mova um conjunto de arquivos que caibam no disco.
2. Permita que a sincronização de arquivos e a camada de nuvem se envolvam.
3. Quando mais espaço livre for criado no volume, prossiga com o próximo lote de arquivos.
Você pode evitar essa abordagem de envio em lote Provisionando o espaço equivalente na instância do
Windows Server que os arquivos ocupam no servidor do Linux Samba. Considere habilitar a eliminação de
duplicação no Windows. Se você não quiser confirmar permanentemente essa grande quantidade de
armazenamento para sua instância do Windows Server, poderá reduzir o tamanho do volume após a
migração e antes de ajustar as políticas de camadas de nuvem. Isso cria um cache local menor de seus
A configuração de recurso (computação e RAM) da instância do Windows Server que você implanta depende
principalmente do número de itens (arquivos e pastas) que você estará sincronizando. É recomendável usar uma
configuração de alto desempenho se você tiver alguma preocupação.
Saiba como dimensionar uma instância do Windows Server com base no número de itens (arquivos e pastas) que
você precisa sincronizar.
NOTE
O artigo vinculado anteriormente apresenta uma tabela com um intervalo para a memória do servidor (RAM). Você pode
orientar em direção ao número menor para o servidor, mas esperar que a sincronização inicial possa levar muito mais tempo.
Fase 3: implantar o Sincronização de Arquivos do Azure recurso de

nuvem
Nesta etapa, você precisa de suas credenciais de assinatura do Azure.
O recurso principal a ser configurado para Sincronização de Arquivos do Azure é chamado de serviço de
sincronização de armazenamento. Recomendamos que você implante apenas um para todos os servidores que
estão sincronizando o mesmo conjunto de arquivos agora ou no futuro. Crie vários serviços de sincronização de
armazenamento somente se você tiver conjuntos distintos de servidores que nunca devem trocar dados (por
exemplo: sincronizar o mesmo compartilhamento de arquivos do Azure). Caso contrário, um único serviço de
sincronização de armazenamento é a melhor prática.
Escolha uma região do Azure para o serviço de sincronização de armazenamento que está perto de seu local.
Todos os outros recursos de nuvem devem ser implantados na mesma região. Para simplificar o gerenciamento,
crie um novo grupo de recursos em sua assinatura que abriga os recursos de sincronização e armazenamento.
Para obter mais informações, consulte a seção sobre como implantar o serviço de sincronização de
armazenamento no artigo sobre como implantar sincronização de arquivos do Azure. Siga apenas esta parte do
artigo. Haverá links para outras seções do artigo em etapas posteriores.
Fase 4: implantar recursos de armazenamento do Azure

Nesta fase, consulte a tabela de mapeamento da fase 1 e use-a para provisionar o número correto de contas de
armazenamento do Azure e compartilhamentos de arquivos dentro deles.
Um compartilhamento de arquivos do Azure é armazenado na nuvem em uma conta de armazenamento do Azure.
Há outro nível de considerações de desempenho aqui.
Se você tiver compartilhamentos altamente ativos (compartilhamentos usados por muitos usuários e/ou
aplicativos), dois compartilhamentos de arquivos do Azure poderão alcançar o limite de desempenho de uma
Uma prática recomendada é implantar contas de armazenamento com um compartilhamento de arquivos cada.
Você pode agrupar vários compartilhamentos de arquivos do Azure na mesma conta de armazenamento, caso
você tenha compartilhamentos de arquivamento ou você espera uma atividade de baixa diária neles.
Essas considerações se aplicam mais ao acesso direto à nuvem (por meio de uma VM do Azure) do que para
Sincronização de Arquivos do Azure. Se você planeja usar Sincronização de Arquivos do Azure apenas nesses
compartilhamentos, o agrupamento de vários em uma única conta de armazenamento do Azure é bom.
Se você tiver feito uma lista de seus compartilhamentos, deverá mapear cada compartilhamento para a conta de
armazenamento na qual ele residirá.
Na fase anterior, você determinou o número apropriado de compartilhamentos. Nesta etapa, você criou um
mapeamento de contas de armazenamento para compartilhamentos de arquivos. Agora, implante o número
apropriado de contas de armazenamento do Azure com o número apropriado de compartilhamentos de arquivos
do Azure neles.
Verifique se a região de cada uma de suas contas de armazenamento é a mesma e corresponde à região do
recurso de serviço de sincronização de armazenamento que você já implantou.
Cau t i on
Se você criar um compartilhamento de arquivos do Azure que tenha um limite de 100 a TiB, esse
compartilhamento só poderá usar opções de redundância de armazenamento com redundância local ou
armazenamento com redundância de zona. Considere suas necessidades de redundância de armazenamento antes
de usar os compartilhamentos de arquivos 100-TiB.
Os compartilhamentos de arquivos do Azure ainda são criados com um limite de 5 TiB por padrão. Como você está
criando novas contas de armazenamento, certifique-se de seguir as diretrizes para criar contas de armazenamento
que permitem compartilhamentos de arquivos do Azure com limites 100-Tib.
Outra consideração quando você está implantando uma conta de armazenamento é a redundância do
armazenamento do Azure. Consulte Opções de redundância do armazenamento do Azure.
Os nomes de seus recursos também são importantes. Por exemplo, se você agrupar vários compartilhamentos
para o departamento de RH em uma conta de armazenamento do Azure, deverá nomear a conta de
armazenamento adequadamente. Da mesma forma, ao nomear seus compartilhamentos de arquivos do Azure,
você deve usar nomes semelhantes àqueles usados para suas contrapartes locais.
Fase 5: implantar o agente de Sincronização de Arquivos do Azure

Nesta seção, você instalará o agente de Sincronização de Arquivos do Azure em sua instância do Windows Server.
O Guia de implantação ilustra que você precisa desativar a configuração de segurança reforçada do Internet
Explorer . Essa medida de segurança não é aplicável com Sincronização de Arquivos do Azure. Desativá-lo permite
que você se autentique no Azure sem problemas.
Abra o PowerShell e instale os módulos do PowerShell necessários usando os comandos a seguir. Certifique-se de
instalar o módulo completo e o provedor do NuGet quando for solicitado.
Install-Module -Name Az -AllowClobber

Install-Module -Name Az.StorageSync
Se você tiver problemas para acessar a Internet do seu servidor, agora é o momento de solucioná-los.
Sincronização de Arquivos do Azure usa qualquer conexão de rede disponível com a Internet. Também há suporte
para exigir um servidor proxy para acessar a Internet. Você pode configurar um proxy de todo o computador agora
ou especificar um proxy que apenas Sincronização de Arquivos do Azure será usado durante a instalação do
agente.
Se configurar um proxy significa que você precisa abrir seus firewalls para esse servidor, isso pode ser uma
abordagem aceitável para você. No final da instalação do servidor, depois de concluir o registro do servidor, um
relatório de conectividade de rede mostrará as URLs exatas do ponto de extremidade no Azure que Sincronização
de Arquivos do Azure precisa se comunicar com a região que você selecionou. O relatório também informa o
motivo pelo qual a comunicação é necessária. Você pode usar o relatório para bloquear os firewalls em todo esse
servidor para URLs específicas.
Você também pode seguir uma abordagem mais conservadora na qual não abre os firewalls, mas sim limitar o
servidor para se comunicar com namespaces DNS de nível superior. Para obter mais informações, consulte
sincronização de arquivos do Azure configurações de proxy e firewall. Siga suas próprias práticas recomendadas
de rede.
No final do assistente de instalação do servidor, um assistente de registro do servidor será aberto. Registre o
servidor no recurso do Azure do serviço de sincronização de armazenamento anteriormente.
Essas etapas são descritas mais detalhadamente no guia de implantação, incluindo os módulos do PowerShell que
você deve instalar primeiro: sincronização de arquivos do Azure instalação do agente.
Use o agente mais recente. Você pode baixá-lo no centro de download da Microsoft: agente de sincronização de
arquivos do Azure.
Após uma instalação bem-sucedida e um registro de servidor, você pode verificar se concluiu com êxito esta etapa.
Vá para o recurso serviço de sincronização de armazenamento no portal do Azure e, em seguida, siga o menu à
esquerda para ser vidores registrados . Você verá o servidor listado lá.
Fase 6: Configurar Sincronização de Arquivos do Azure na implantação

do Windows Server
Sua instância do Windows Server local registrada deve estar pronta e conectada à Internet para esse processo.
Esta etapa reúne todos os recursos e pastas que você configurou na instância do Windows Server durante as
etapas anteriores.
2. Localize o recurso do serviço de sincronização de armazenamento.
3. Crie um novo grupo de sincronização dentro do recurso de serviço de sincronização de armazenamento para
cada compartilhamento de arquivos do Azure. Na terminologia Sincronização de Arquivos do Azure, o
compartilhamento de arquivos do Azure se tornará um ponto de extremidade de nuvem na topologia de
sincronização que você está descrevendo com a criação de um grupo de sincronização. Como você está criando
o grupo de sincronização, dê a ele um nome familiar para que você reconheça qual conjunto de arquivos é
sincronizado aqui. Certifique-se de fazer referência ao compartilhamento de arquivos do Azure com um nome
correspondente.
4. Depois que o grupo de sincronização for criado, uma linha para ele aparecerá na lista de grupos de
sincronização. Selecione o nome (um link) para exibir o conteúdo do grupo de sincronização. Você verá o
compartilhamento de arquivos do Azure em pontos de extremidade de nuvem .
5. Localize o botão + Adicionar ponto de extremidade do ser vidor . A pasta no servidor local que você
provisionar se tornará o caminho para esse ponto de extremidade do servidor.
IMPORTANT
A camada de nuvem é o recurso Sincronização de Arquivos do Azure que permite que o servidor local tenha menos
capacidade de armazenamento do que o armazenado na nuvem, mas que tenha o namespace completo disponível. Dados
interessantes localmente também são armazenados em cache localmente para desempenho rápido de acesso. A camada de
nuvem é um recurso opcional para cada ponto de extremidade do Sincronização de Arquivos do Azure Server.
WARNING
Se você provisionou menos armazenamento em volumes do Windows Server do que os dados usados no servidor do Linux
Samba, a disposição em camadas da nuvem é obrigatória. Se você não ativar a disposição em camadas de nuvem, o servidor
não liberará espaço para armazenar todos os arquivos. Defina a política de camadas, temporariamente para a migração, para
99% de espaço livre para um volume. Certifique-se de retornar às configurações de camadas de nuvem após a conclusão da
migração e defina a política para um nível mais útil para o longo prazo.
Repita as etapas de criação do grupo de sincronização e a adição da pasta de servidor correspondente como um
ponto de extremidade do servidor para todos os compartilhamentos de arquivos do Azure e locais de servidor que
precisam ser configurados para sincronização.
Após a criação de todos os pontos de extremidade do servidor, a sincronização está funcionando. Você pode criar
um arquivo de teste e vê-lo sincronizar do local do servidor com o compartilhamento de arquivos do Azure
conectado (conforme descrito pelo ponto de extremidade de nuvem no grupo de sincronização).
Os dois locais, as pastas de servidor e os compartilhamentos de arquivos do Azure, estão vazios e aguardando
dados. Na próxima etapa, você começará a copiar arquivos na instância do Windows Server para Sincronização de
Arquivos do Azure para movê-los para a nuvem. Se você habilitou a camada de nuvem, o servidor começará a
hierarquizar os arquivos se você ficar sem capacidade nos volumes locais.
Fase 7: Robocopy
A abordagem de migração básica é usar o Robocopy para copiar arquivos e usar Sincronização de Arquivos do
Azure para fazer a sincronização.
Execute a primeira cópia local em sua pasta de destino do Windows Server:
1. Identifique o primeiro local em seu servidor do Linux Samba.
2. Identifique a pasta correspondente na instância do Windows Server que já tem Sincronização de Arquivos do
Azure configurada.
3. Inicie a cópia usando o Robocopy.
O comando Robocopy a seguir copiará arquivos do armazenamento do servidor do Linux Samba para a pasta de
destino do Windows Server. O Windows Server irá sincronizá-lo para os compartilhamentos de arquivos do Azure.
Se você provisionou menos armazenamento em sua instância do Windows Server do que seus arquivos ocupam
no servidor do Linux Samba, você configurou a camada de nuvem. Como o volume do Windows Server local fica
cheio, a disposição em camadas da nuvem será iniciada e os arquivos de camada que já foram sincronizados com
êxito. A disposição em camadas da nuvem gerará espaço suficiente para continuar a cópia do servidor do Linux
Samba. As verificações de camadas de nuvem uma vez por hora para ver o que foi sincronizado e liberar espaço
em disco para alcançar a política de 99% de espaço livre para um volume.
É possível que o Robocopy mova arquivos mais rápido do que você pode sincronizar com a nuvem e a camada
localmente, fazendo com que você fique sem espaço em disco local. O Robocopy então falhará. Recomendamos
que você trabalhe nos compartilhamentos em uma sequência que impede o problema. Por exemplo, considere não
iniciar trabalhos de Robocopy para todos os compartilhamentos ao mesmo tempo. Ou considere mover
compartilhamentos que caibam na quantidade atual de espaço livre na instância do Windows Server. Se o trabalho
do Robocopy falhar, você sempre poderá executar novamente o comando, desde que use a seguinte opção de
espelhamento/limpeza:
Robocopy /MT:32 /UNILOG:<file name> /TEE /B /MIR /COPYALL /DCOPY:DAT <SourcePath> <Dest.Path>
Plano de fundo:
/MT
Permite que o Robocopy seja executado em vários threads. O padrão é 8, o máximo é 128.
/UNILOG:<nome do arquivo>
Gera o status para um arquivo de log como Unicode (Substitui o log existente).
/TEE
Saídas para uma janela de console. Usado em conjunto com a saída para um arquivo de log.
/B
Executa o Robocopy no mesmo modo que um aplicativo de backup usaria. Ele permite que o Robocopy mova
arquivos aos quais o usuário atual não tem permissões.
/MIR
Permite executar esse comando Robocopy várias vezes, sequencialmente, no mesmo destino/destino. Ele identifica
e omite o que foi copiado antes. Somente alterações, adições e exclusões ocorridas desde a última execução são
processadas. Se o comando não for executado antes, nada será omitido. O sinalizador /Mir é uma excelente opção
para locais de origem que ainda são usados e alterados ativamente.
/COPY: copyflag [s]
Fidelidade da cópia de arquivo (o padrão é/COPY: DAT). Os sinalizadores de cópia são: D = data, A = atributos, T =
carimbos de data/hora, S = segurança = ACLs de NTFS, O = proprietário informações, U = informações de
auditoria.
/COPYALL
Copie todas as informações do arquivo (equivalente a/COPY: DATSOU).
/DCOPY: copyflag [s]
Fidelidade para a cópia de diretórios (o padrão é/DCOPY: DA). Sinalizadores de cópia são: D = dados, A = atributos,
T = carimbos de data/hora.
Fase 8: recortar o usuário

Quando você executa o comando Robocopy pela primeira vez, seus usuários e aplicativos ainda estão acessando
arquivos no servidor Linux Samba e potencialmente alterá-los. É possível que o Robocopy tenha processado um
diretório e passe para o próximo e, em seguida, um usuário no local de origem (Linux) adicione, altere ou exclua
um arquivo que agora não será processado nesta execução atual do Robocopy. O comportamento é esperado.
A primeira execução é sobre a movimentação da massa dos dados para a instância do Windows Server e para a
nuvem via Sincronização de Arquivos do Azure. Essa primeira cópia pode levar muito tempo, dependendo de:
Sua largura de banda de download.
A largura de banda de upload.
A velocidade da rede local e o número de quão otimizado o número de threads Robocopy corresponde a ele.
O número de itens (arquivos e pastas) que o Robocopy e o Sincronização de Arquivos do Azure precisam
processar.
Depois que a execução inicial for concluída, execute o comando novamente.
Ele termina mais rapidamente na segunda vez, porque precisa transportar somente as alterações ocorridas desde a
última execução. Durante esse segundo, executar novas alterações ainda poderá ser acumulado.
Repita esse processo até estar convencido de que o tempo necessário para concluir uma operação Robocopy para
um local específico está dentro de uma janela aceitável para tempo de inatividade.
Quando você considera o tempo de inatividade aceitável e está preparado para colocar o local do Linux offline,
pode alterar as ACLs na raiz do compartilhamento, de modo que os usuários não possam mais acessar o local. Ou
você pode executar qualquer outra etapa apropriada que impeça o conteúdo de ser alterado nessa pasta no
servidor Linux.
Executar uma última rodada do Robocopy. Ele escolherá todas as alterações que possam ter sido perdidas. O
quanto tempo leva essa etapa final depende da velocidade da verificação do Robocopy. Você pode estimar o tempo
(que é igual ao seu tempo de inatividade) medindo quanto tempo a execução anterior levou.
Crie um compartilhamento na pasta do Windows Server e, possivelmente, ajuste sua implantação do DFS-N para
apontar para ele. Certifique-se de definir as mesmas permissões de nível de compartilhamento que em seus
compartilhamentos SMB do servidor do Linux Samba. Se você tiver usado usuários locais em seu servidor do
Linux Samba, precisará recriar esses usuários como usuários locais do Windows Server. Você também precisa
mapear os SIDs existentes que o Robocopy moveu para sua instância do Windows Server para os SIDs de seus
novos usuários locais do Windows Server. Se você usou Active Directory contas e ACLs, o Robocopy as moverá
como está, e nenhuma ação adicional será necessária.
Você concluiu a migração de um compartilhamento ou de um grupo de compartilhamentos em um volume ou raiz
comum (dependendo do mapeamento da fase 1).
Você pode tentar executar algumas dessas cópias em paralelo. É recomendável processar o escopo de um
compartilhamento de arquivos do Azure por vez.
WARNING
Depois de mover todos os dados do seu servidor do Linux Samba para a instância do Windows Server e a migração estiver
concluída, retorne a todos os grupos de sincronização na portal do Azure. Ajuste a porcentagem de espaço livre para o
volume de camadas de nuvem para algo mais adequado para a utilização de cache, como 20%.
A política de espaço livre no volume de camadas de nuvem atua em um nível de volume com potencialmente
vários pontos de extremidade de servidor sincronizando a partir dele. Se você se esquecer de ajustar o espaço livre
em um ponto de extremidade de servidor, a sincronização continuará a aplicar a regra mais restritiva e tentará
manter o espaço livre em disco em 99%. O cache local pode não ser executado conforme o esperado. O
desempenho poderá ser aceitável se o objetivo for ter o namespace para um volume que contenha apenas dados
de arquivamento acessados raramente, e você estiver reservando o restante do espaço de armazenamento para
outro cenário.
O problema mais comum é que o comando Robocopy falha com volume cheio no lado do Windows Server. A
camada de nuvem age uma vez a cada hora para evacuar o conteúdo do disco do Windows Server local que foi
sincronizado. Seu objetivo é atingir o espaço livre de 99 por cento no volume.
Deixe o progresso da sincronização e a camada da nuvem liberar espaço em disco. Você pode observar isso no
explorador de arquivos no Windows Server.
Quando a instância do Windows Server tiver capacidade disponível suficiente, a reexecução do comando resolverá
o problema. Nada é interrompido quando você entra nessa situação, e você pode avançar com confiança. O
inconveniente da execução do comando novamente é a única consequência.
Verifique o link na seção a seguir para solucionar problemas de Sincronização de Arquivos do Azure.
Próximas etapas
Há mais a descobrir sobre compartilhamentos de arquivos do Azure e Sincronização de Arquivos do Azure. Os
artigos a seguir contêm opções avançadas, práticas recomendadas e ajuda para solução de problemas. Estes
artigos se vinculam à documentação do compartilhamento de arquivos do Azure , conforme apropriado.
Visão geral de Sincronização de Arquivos do Azure
Guia de implantação do Sincronização de Arquivos do Azure
Solução de problemas da Sincronização de Arquivos do Azure
Migre do NAS (armazenamento anexado à rede)
para uma implantação de nuvem híbrida com
Sincronização de Arquivos do Azure funciona em locais DAS (armazenamento anexado direto) e não oferece
suporte à sincronização para os locais de NAS (armazenamento anexado à rede). Esse fato faz uma migração dos
arquivos necessários e este artigo o orienta durante o planejamento e a execução de tal migração.
Metas de migração
O objetivo é mover os compartilhamentos que você tem em seu dispositivo NAS para um Windows Server. Em
seguida, utilize Sincronização de Arquivos do Azure para uma implantação de nuvem híbrida. Essa migração
precisa ser feita de forma a garantir a integridade dos dados de produção, bem como a disponibilidade durante a
migração. O segundo requer um mínimo de tempo de inatividade, para que ele possa se ajustar ou ter apenas um
pouco mais de uma janela de manutenção regular.
Visão geral da migração

Conforme mencionado no artigo Visão geral da migraçãode arquivos do Azure, é importante usar a ferramenta de
cópia correta e a abordagem. Seu dispositivo NAS está expondo compartilhamentos SMB diretamente em sua rede
local. O RoboCopy, interno do Windows Server, é a melhor maneira de mover seus arquivos nesse cenário de
migração.
Fase 1: identificar Quantos compartilhamentos de arquivos do Azure você precisa
Fase 2: provisionar um Windows Server local adequado
Fase 3: implantar o sincronização de arquivos do Azure recurso de nuvem
Fase 5: implantar o agente de sincronização de arquivos do Azure
Fase 6: configurar sincronização de arquivos do Azure no Windows Server
Fase 7: Robocopy
Fase 1: identificar Quantos compartilhamentos de arquivos do Azure

você precisa
mapeamento 1:1.
transferência.
TIP

IMPORTANT
Azure.
Fase 2: provisionar um Windows Server local adequado

Crie um Windows Server 2019 – no mínimo 2012R2-como uma máquina virtual ou um servidor físico.
Também há suporte para um cluster de failover do Windows Server.
Provisione ou adicione armazenamento de conexão direta (DAS em comparação com o NAS, para o qual
não há suporte).
A quantidade de armazenamento que você provisiona pode ser menor do que o que você está usando
atualmente em seu dispositivo NAS, se você usar o recurso de camadas de nuvem de sincronizações de
arquivos do Azure. No entanto, quando você copiar os arquivos do espaço de NAS maior para o volume
menor do Windows Server em uma fase posterior, será necessário trabalhar em lotes:
1. Mover um conjunto de arquivos que se ajustam ao disco
2. permitir que a sincronização de arquivos e a camada de nuvem se envolvam
3. Quando mais espaço livre for criado no volume, prossiga com o próximo lote de arquivos.
Você pode evitar essa abordagem de envio em lote Provisionando o espaço equivalente no Windows Server
que os arquivos ocupam no dispositivo NAS. Considere a eliminação de duplicação no NAS/Windows. Se
você não quiser confirmar permanentemente essa grande quantidade de armazenamento para o Windows
Server, poderá reduzir o tamanho do volume após a migração e antes de ajustar as políticas de camadas de
nuvem. Isso cria um cache local menor de seus compartilhamentos de arquivos do Azure.
A configuração de recurso (computação e RAM) do Windows Server que você implanta depende principalmente
do número de itens (arquivos e pastas) que serão sincronizados. É recomendável usar uma configuração de
desempenho maior se você tiver alguma preocupação.
Saiba como dimensionar um Windows Server com base no número de itens (arquivos e pastas) que você precisa
sincronizar.
NOTE
O artigo vinculado anteriormente apresenta uma tabela com um intervalo para a memória do servidor (RAM). Você pode
orientar em direção ao número menor para o servidor, mas esperar que a sincronização inicial possa levar muito mais tempo.
Fase 3: implantar o Sincronização de Arquivos do Azure recurso de

nuvem

Nesta fase, consulte a tabela de mapeamento da fase 1 e use-a para provisionar o número correto de contas de
armazenamento do Azure e compartilhamentos de arquivos dentro deles.
do Azure neles.
Cau t i on
Fase 5: implantar o agente de Sincronização de Arquivos do Azure


agente.
de rede.
arquivos do Azure.
Fase 6: Configurar Sincronização de Arquivos do Azure no Windows

Server
Seu Windows Server local registrado deve estar pronto e conectado à Internet para esse processo.
etapas anteriores.
correspondente.
IMPORTANT
A camada de nuvem é o recurso AFS que permite que o servidor local tenha menos capacidade de armazenamento do que o
armazenado na nuvem, mas que tenha o namespace completo disponível. Dados interessantes localmente também são
armazenados em cache localmente para desempenho rápido de acesso. A camada de nuvem é um recurso opcional por
Sincronização de Arquivos do Azure "ponto de extremidade do servidor".
WARNING
Se você provisionou menos armazenamento em seus volumes do Windows Server do que os dados usados no dispositivo
NAS, a camada de nuvem é obrigatória. Se você não ativar a disposição em camadas de nuvem, o servidor não liberará
espaço para armazenar todos os arquivos. Defina a política de camadas, temporariamente para a migração, para 99% de
espaço livre no volume. Certifique-se de retornar às configurações de camadas de nuvem após a conclusão da migração e
defina-a para um nível útil de mais longo prazo.
Repita as etapas da criação do grupo de sincronização e adição da pasta de servidor correspondente como um
ponto de extremidade do servidor para todos os compartilhamentos de arquivos/locais de servidor do Azure que
Após a criação de todos os pontos de extremidade do servidor, a sincronização está funcionando. Você pode criar
um arquivo de teste e vê-lo sincronizar do local do servidor com o compartilhamento de arquivos do Azure
conectado (conforme descrito pelo ponto de extremidade de nuvem no grupo de sincronização).
Ambos os locais, as pastas de servidor e os compartilhamentos de arquivos do Azure estão vazios e aguardando
dados em qualquer local. Na próxima etapa, você começará a copiar arquivos no Windows Server para
Sincronização de Arquivos do Azure para movê-los para a nuvem. Caso você tenha habilitado camadas de nuvem,
o servidor começará a hierarquizar os arquivos, caso você fique sem capacidade no volume (s) local (es).
Fase 7: RoboCopy
A abordagem de migração básica é um RoboCopy de seu dispositivo NAS para o Windows Server e Sincronização
de Arquivos do Azure aos compartilhamentos de arquivos do Azure.
Identifique o primeiro local em seu dispositivo NAS.
Identifique a pasta correspondente no Windows Server, que já tem Sincronização de Arquivos do Azure
configurada nela.
Iniciar a cópia usando o RoboCopy
O comando RoboCopy a seguir copiará os arquivos do armazenamento NAS para a pasta de destino do Windows
Server. O Windows Server irá sincronizá-lo para os compartilhamentos de arquivos do Azure.
Se você provisionou menos armazenamento no Windows Server do que seus arquivos ocupam no dispositivo
NAS, você configurou a camada de nuvem. Como o volume do Windows Server local fica cheio, a disposição em
camadas da nuvem será iniciada e os arquivos de camada que já foram sincronizados com êxito. A disposição em
camadas da nuvem gerará espaço suficiente para continuar a cópia do dispositivo NAS. As verificações de camadas
de nuvem uma vez por hora para ver o que foi sincronizado e liberar espaço em disco para alcançar o espaço livre
do volume de 99%. É possível que o RoboCopy mova arquivos mais rápido do que você pode sincronizar com a
nuvem e a camada localmente, ficando sem espaço em disco local. O RoboCopy falhará. É recomendável que você
trabalhe nos compartilhamentos em uma sequência que impede isso. Por exemplo, não iniciar trabalhos do
RoboCopy para todos os compartilhamentos ao mesmo tempo ou mover somente compartilhamentos que caibam
na quantidade atual de espaço livre no Windows Server, para mencionar alguns.
Plano de fundo:
/MT
Permite que o RoboCopy seja executado em vários threads. O padrão é 8, o máximo é 128.
/UNILOG:<nome do arquivo>
Gera o status do arquivo de LOG como UNICODE (Substitui o log existente).
/TEE
Saídas para a janela do console. Usado em conjunto com a saída para um arquivo de log.
/B
Executa o RoboCopy no mesmo modo que um aplicativo de backup usaria. Ele permite que o RoboCopy mova
/MIR
Permite executar esse comando RoboCopy várias vezes, sequencialmente no mesmo destino/destino. Ele identifica
o que foi copiado antes e o omite. Somente as alterações, adições e "exclusões" serão processadas, ocorridas desde
a última execução. Se o comando não for executado antes, nada será omitido. O sinalizador /Mir é uma excelente
opção para locais de origem que ainda são usados e alterados ativamente.
/COPY: copyflag [s]
fidelidade da cópia de arquivo (o padrão é/COPY: DAT), sinalizadores de cópia: D = dados, A = atributos, T =
carimbos de data/hora, S = segurança = ACLs de NTFS, O = informações de proprietário, U = informações de
auditoria
/COPYALL
Copie todas as informações do arquivo (equivalente a/COPY: DATSOU)
fidelidade para a cópia de diretórios (o padrão é/DCOPY: DA), sinalizadores de cópia: D = data, A = atributos, T =
carimbos de hora
Quando você executa o comando RoboCopy pela primeira vez, seus usuários e aplicativos ainda estão acessando
arquivos no NAS e potencialmente os alteram. É possível que o RoboCopy tenha processado um diretório, passe
para o próximo e, em seguida, um usuário no local de origem (NAS) adicione, altere ou exclua um arquivo que
agora não será processado nesta execução atual do RoboCopy. O comportamento é esperado.
A primeira execução é sobre a movimentação da massa dos dados para o Windows Server e para a nuvem por
meio de Sincronização de Arquivos do Azure. Essa primeira cópia pode levar muito tempo, dependendo de:
sua largura de banda de download
a largura de banda de upload
a velocidade da rede local e o número de quão otimizado o número de threads RoboCopy corresponde a ele
o número de itens (arquivos e pastas) que precisam ser processados pelo RoboCopy e Sincronização de
Arquivos do Azure
A segunda vez que terminará mais rapidamente, porque ele só precisa transportar alterações ocorridas desde a
última execução. Durante essa segunda execução, ainda assim, novas alterações podem ser acumuladas.
Repita esse processo até estar convencido de que o tempo necessário para concluir um RoboCopy para um local
específico está dentro de uma janela aceitável para tempo de inatividade.
Quando você considera o tempo de inatividade aceitável e está preparado para colocar o local NAS offline: para
que o usuário tenha acesso offline, você tem a opção de alterar ACLs na raiz do compartilhamento, de modo que
os usuários não possam mais acessar o local ou executar qualquer outra etapa apropriada que impeça o conteúdo
seja alterado nessa pasta em seu NAS.
Executar uma última rodada do RoboCopy. Ele escolherá todas as alterações, que podem ter sido perdidas. Quanto
tempo leva essa etapa final, depende da velocidade da verificação do RoboCopy. Você pode estimar o tempo (que é
igual ao seu tempo de inatividade) medindo quanto tempo a execução anterior levou.
apontar para ele. Certifique-se de definir as mesmas permissões de nível de compartilhamento que em seu
compartilhamento SMB de NAS. Se você tivesse um NAS de classe empresarial ingressado no domínio, os SIDs do
usuário corresponderão automaticamente à medida que os usuários existirem em Active Directory e o RoboCopy
copia arquivos e metadados com total fidelidade. Se você tiver usado usuários locais em seu NAS, precisará recriar
esses usuários como usuários locais do Windows Server e mapear os SIDs RoboCopy existentes movidos para o
Windows Server para os SIDs dos novos usuários locais do Windows Server.
Você concluiu a migração de um compartilhamento/grupo de compartilhamentos em um volume ou raiz comum.
(Dependendo do mapeamento da fase 1)
WARNING
Depois de mover todos os dados do NAS para o Windows Server e sua migração estiver concluída: retorne a todos os
grupos de sincronização na portal do Azure e ajuste o valor de porcentagem de espaço livre do volume de camadas da
nuvem para algo mais adequado para a utilização do cache, digamos 20%.
A política de espaço livre do volume de camadas de nuvem age em um nível de volume com potencialmente vários
pontos de extremidade de servidor sincronizando a partir dele. Se você se esquecer de ajustar o espaço livre em
um ponto de extremidade de servidor, a sincronização continuará a aplicar a regra mais restritiva e tentará manter
99% de espaço livre em disco, tornando o cache local não funcionando como você poderia esperar. A menos que
seja o objetivo de ter apenas o namespace para um volume que contenha apenas dados de arquivamento
raramente acessados e você esteja reservando o restante do espaço de armazenamento para outro cenário.
O problema mais provável que você pode encontrar é que o comando RoboCopy falha com "volume cheio" no
lado do Windows Server. A camada de nuvem age uma vez a cada hora para evacuar o conteúdo do disco local do
Windows Server, que foi sincronizado. Seu objetivo é atingir o espaço livre de 99% no volume.
explorador de arquivos no seu Windows Server.
Quando o seu Windows Server tiver capacidade disponível suficiente, a reexecução do comando resolverá o
problema. Nada é interrompido quando você entra nessa situação e pode avançar com confiança. A inconveniência
de executar o comando novamente é a única consequência.
Verifique o link na seção a seguir para solucionar problemas de Sincronização de Arquivos do Azure.
Próximas etapas
Há mais a descobrir sobre compartilhamentos de arquivos do Azure e Sincronização de Arquivos do Azure. Os
artigos a seguir ajudam a entender opções avançadas, práticas recomendadas e também contêm ajuda para
solução de problemas. Estes artigos se vinculam à documentação do compartilhamento de arquivos do Azure ,
conforme apropriado.
Visão geral de AFS
Guia de implantação AFS
Solução de problemas AFS
Migração do StorSimple 8100 e 8600 para
A série StorSimple 8000 é representada pelo 8100 ou pelo 8600 dispositivos físicos, locais e seus componentes de
serviço de nuvem. É possível migrar os dados de qualquer um desses dispositivos para um ambiente
Sincronização de Arquivos do Azure. Sincronização de Arquivos do Azure é o serviço do Azure de longo prazo
padrão e estratégico para o qual os dispositivos StorSimple podem ser migrados.
A série StorSimple 8000 atingirá o fim da vida útil em 2022 de dezembro. É importante começar a planejar sua
migração assim que possível. Este artigo fornece as etapas de conhecimento e migrações em segundo plano
necessárias para uma migração bem-sucedida para o Sincronização de Arquivos do Azure.

IMPORTANT
A Microsoft está comprometida em auxiliar os clientes em sua migração. Envie AzureFiles@microsoft.com um email para um
plano de migração personalizado, bem como assistência durante a migração.
Sincronização de Arquivos do Azure é um serviço de nuvem da Microsoft, com base em dois componentes
principais:
Sincronização de arquivos e camadas de nuvem.
Compartilhamentos de arquivos como armazenamento nativo no Azure, que podem ser acessados por meio de
vários protocolos, como SMB e REST de arquivo. Um compartilhamento de arquivos do Azure é comparável a
um compartilhamento de arquivos em um Windows Server, que você pode montar nativamente como uma
unidade de rede. Ele dá suporte a aspectos de fidelidade de arquivo importantes, como atributos, permissões e
carimbos de data/hora. Com compartilhamentos de arquivos do Azure, não há mais necessidade de um
aplicativo ou serviço para interpretar os arquivos e as pastas armazenados na nuvem. Você pode acessá-los
nativamente por meio de protocolos e clientes familiares, como o explorador de arquivos do Windows. Isso faz
com que o arquivo do Azure compartilhe a abordagem ideal e mais flexível para armazenar dados de servidor
de arquivos de uso geral, bem como alguns dados de aplicativo, na nuvem.
Este artigo se concentra nas etapas de migração. Se antes de migrar você gostaria de saber mais sobre
Sincronização de Arquivos do Azure, recomendamos os seguintes artigos:
Sincronização de Arquivos do Azure-visão geral
Sincronização de Arquivos do Azure-guia de implantação
Metas de migração
O objetivo é garantir a integridade dos dados de produção, bem como garantir a disponibilidade. O segundo
requer um mínimo de tempo de inatividade, para que ele possa se ajustar ou ter apenas um pouco mais de uma
janela de manutenção regular.
Caminho de migração da série StorSimple 8000 para Sincronização de

Arquivos do Azure
Um servidor Windows local é necessário para executar um agente de Sincronização de Arquivos do Azure. O
Windows Server pode ser, no mínimo, um servidor 2012R2, mas o ideal é o Windows Server 2019.
Há inúmeros caminhos de migração alternativos e criaria um artigo muito longo para documentar todos eles e
ilustrar por que eles têm risco ou desvantagens na rota que recomendamos como prática recomendada neste
artigo.
A imagem anterior descreve as fases que correspondem às seções neste artigo. Usamos uma migração no lado da
nuvem para evitar a RECALL desnecessária de arquivos para seu dispositivo StorSimple local. Essa abordagem
evita o impacto no comportamento do cache local ou na utilização da largura de banda da rede, ou seja, pode
afetar suas cargas de trabalho de produção. Uma migração no lado da nuvem está operando em um instantâneo
(um clone de volume) de seus dados. Portanto, seus dados de produção são isolados desse processo-até o fim da
migração. Ao trabalhar com o que é essencialmente um backup, o torna a migração segura e facilmente
reproduzível, caso você tenha dificuldades.
Considerações sobre backups do StorSimple existentes

O StorSimple permite que você faça backups na forma de clones de volume. Este artigo usa um novo clone de
volume para migrar seus arquivos dinâmicos. Se você precisar migrar backups além de seus dados dinâmicos,
todas as diretrizes neste artigo ainda se aplicarão. A única diferença é que, em vez de começar com um novo clone
de volume, você começará com o clone de volume de backup mais antigo que precisará migrar.
Esta é a sequência:
Determine o conjunto mínimo de clones de volume que você deve migrar. É recomendável manter essa lista
com um mínimo, se possível, porque quanto mais backups você migrar, mais tempo o processo de migração
geral levará.
Ao passar pelo processo de migração, comece com o clone de volume mais antigo que você pretende migrar e,
em cada migração subsequente, use o próximo mais antigo.
Quando cada migração de clone de volume for concluída, você deverá usar um instantâneo de
compartilhamento de arquivos do Azure. Os instantâneos de compartilhamento de arquivos do Azure são
como você mantém backups pontuais dos arquivos e da estrutura de pastas para seus compartilhamentos de
arquivos do Azure. Você precisará desses instantâneos após a conclusão da migração, para garantir que você
tenha preservado as versões de cada um dos clones de volume à medida que avança pela migração.
Certifique-se de fazer instantâneos de compartilhamento de arquivos do Azure para todos os
compartilhamentos de arquivos do Azure, que são servidos pelo mesmo volume do StorSimple. Os clones de
volume estão no nível de volume, os instantâneos de compartilhamento de arquivos do Azure estão no nível de
compartilhamento. Você deve usar um instantâneo de compartilhamento (em cada compartilhamento de
arquivos do Azure) depois que a migração de um clone de volume for concluída.
Repita o processo de migração para um clone de volume e tirando instantâneos de compartilhamento após
cada clone de volume até obter um instantâneo dos dados dinâmicos. O processo de migração de um clone de
volume é descrito nas fases abaixo.
Se você não precisar mover backups e iniciar uma nova cadeia de backups no lado do compartilhamento de
arquivos do Azure depois que a migração de apenas os dados dinâmicos for feita, isso será benéfico para reduzir a
complexidade na migração e o tempo que a migração levará. Você pode tomar a decisão se deseja ou não mover
backups e quantos de cada volume (não cada compartilhamento) você tem no StorSimple.
Fase 1: preparar-se
A base para a migração é um clone de volume e um dispositivo de nuvem virtual, chamado de StorSimple 8020.
Esta fase se concentra na implantação desses recursos no Azure.
Implantar um dispositivo virtual StorSimple 8020
A implantação de um dispositivo de nuvem é um processo que exige segurança, rede e algumas outras
considerações.
IMPORTANT
O guia a seguir contém algumas seções desnecessárias. Leia e siga o artigo desde o início até a "etapa 3". Em seguida,
retorne a este artigo. No momento, não é necessário concluir a "etapa 3" ou nada além dele neste guia.
Implantação de um dispositivo virtual StorSimple 8020

Determinar um clone de volume a ser usado
Quando você estiver pronto para iniciar a migração, a primeira etapa será fazer um novo clone de volume,
exatamente como você faria para o backup, que captura o estado atual de seu armazenamento em nuvem do
StorSimple. Faça um clone para cada um dos volumes do StorSimple que você tem. Se você precisar mover
backups, o primeiro clone de volume usado não é um clone recém-criado, mas o clone de volume mais antigo
(backup mais antigo) que você precisa migrar. Consulte a seção "considerações sobre backups do StorSimple
existentes" para obter orientações detalhadas.
IMPORTANT
O guia a seguir contém algumas seções desnecessárias. Leia e siga apenas as etapas descritas na seção vinculada a. Em
seguida, retorne a este artigo. Você não precisa seguir a seção "próximas etapas".
Criar clone de um volume

Usar o clone de volume
A última fase da fase 1 é fazer o clone do volume escolhido, disponível no dispositivo virtual 8020 no Azure.
IMPORTANT
O guia a seguir contém as etapas necessárias, mas também-no final, uma instrução para formatar o volume. Não Formatar
o volume Leia e siga a "seção 7" vinculada a partir da instrução inicial até: "10. Para formatar um volume simples,... " Pare
antes de seguir esta etapa e retorne a este artigo.
Montar um clone de volume no dispositivo virtual 8020 no Azure

Resumo da fase 1
Agora que você concluiu a fase 1, terá feito o seguinte:
Implantou um dispositivo virtual StorSimple 8020 no Azure.
Determinado qual clone de volume você começará a migração.
Montados seus clones de volume (um para cada volume ativo) para o dispositivo virtual StorSimple no Azure,
com seus dados disponíveis para uso posterior.
Fase 2: VM de nuvem
Depois que o clone inicial estiver disponível no dispositivo virtual StorSimple 8020 no Azure, agora é hora de
provisionar uma VM e expor o clone do volume (ou vários) para essa VM por iSCSI.
Implantar uma VM do Azure
A máquina virtual do Windows Server no Azure é exatamente como o StorSimple 8020, uma parte temporária da
infraestrutura que é necessária apenas durante a migração. A configuração da VM que você implanta depende
principalmente do número de itens (arquivos e pastas) que você estará sincronizando. É recomendável usar uma
configuração de desempenho maior se você tiver alguma preocupação.
Um único Windows Server pode sincronizar até 30 compartilhamentos de arquivos do Azure. As especificações
que você decide precisam abranger cada compartilhamento/caminho ou a raiz do volume do StorSimple e contar
os itens (arquivos e pastas).
O tamanho geral dos dados é menor do que um afunilamento – é o número de itens que você precisa para
personalizar as especificações do computador.
Saiba como dimensionar um Windows Server com base no número de itens (arquivos e pastas) que você
precisa sincronizar.
Obser vação: O artigo vinculado anteriormente apresenta uma tabela com um intervalo para a memória
do servidor (RAM). Orientar em direção ao número grande para a VM do Azure. Você pode orientar em
direção ao número menor para seu computador local.
Saiba como implantar uma VM do Windows Server.
IMPORTANT
Verifique se a VM está implantada na mesma região do Azure que o dispositivo virtual StorSimple 8020. Se como parte
dessa migração, você também precisa alterar a região dos dados da nuvem da região em que ela está armazenada hoje. você
pode fazer isso em uma etapa posterior, ao provisionar compartilhamentos de arquivos do Azure.
IMPORTANT
Muitas vezes, um Windows Server local é usado para front-end do seu dispositivo StorSimple local. Nessa configuração, é
possível habilitar o recurso "eliminação de duplicação de dados" no Windows Server. Se você usou a eliminação de
duplicação de dados com seus dados do StorSimple, cer tifique-se de habilitar a eliminação de duplicação de
dados nesta VM do Azure também. Não confunda essa eliminação de duplicação em nível de arquivo com a eliminação
de duplicação de nível de bloco interna StorSimples, para a qual nenhuma ação é necessária.
IMPORTANT
Para otimizar o desempenho, implante um disco do sistema operacional rápido para sua VM de nuvem. Você
armazenará o banco de dados de sincronização no disco do sistema operacional para todos os seus volumes de dado. Além
disso, certifique-se de criar um grande disco do sistema operacional. Dependendo do número de itens (arquivos e
pastas) em seus volumes do StorSimple, o disco do sistema operacional pode precisar de várias centenas de Gib de
espaço para acomodar o banco de dados de sincronização.
Expor os volumes do StorSimple 8020 para a VM do Azure

Nesta fase, você está conectando um ou vários volumes do StorSimple do dispositivo virtual 8020 sobre iSCSI à
VM do Windows Server que você provisionou.
IMPORTANT
Para os artigos a seguir, conclua apenas as seções obter IP privado para o dispositivo de nuvem e conectar-se por
meio de iSCSI e retorne a este artigo.
1. Obter IP privado para o dispositivo de nuvem

2. Conectar-se via iSCSI
Resumo da fase 2
Agora que você concluiu a fase 2, você tem:
Provisionado uma VM do Windows Server na mesma região que o dispositivo virtual StorSimple 8020
Expor todos os volumes aplicáveis do 8020 para a VM do Windows Server sobre iSCSI.
Agora você deve ver o conteúdo do arquivo e da pasta, ao usar o explorador de arquivos na VM do servidor
nos volumes montados.
Vá para a fase 3 somente quando tiver concluído essas etapas para todos os volumes que precisam de migração.
Fase 3: configurar compartilhamentos de arquivos do Azure e preparar-
se para Sincronização de Arquivos do Azure
Nesta fase, você determinará e provisionar vários compartilhamentos de arquivos do Azure, criando um Windows
Server local como uma substituição do dispositivo StorSimple e configurará esse servidor para Sincronização de
Arquivos do Azure.
Mapear seus namespaces existentes para compartilhamentos de arquivos do Azure
mapeamento 1:1.
transferência.
TIP

IMPORTANT
Azure.
Implantar compartilhamentos de arquivos do Azure

do Azure neles.
Cau t i on
Os compartilhamentos de arquivos do Azure ainda são criados com um limite de 5 TiB por padrão. Como você
está criando novas contas de armazenamento, certifique-se de seguir as diretrizes para criar contas de
armazenamento que permitem compartilhamentos de arquivos do Azure com limites 100-Tib.
TIP
Se você precisar alterar a região do Azure da região atual em que os dados do StorSimple residem, provisione os
compartilhamentos de arquivos do Azure na nova região que você deseja usar. Você determina a região selecionando-a ao
provisionar as contas de armazenamento que mantêm os compartilhamentos de arquivos do Azure. Certifique-se de que
também o recurso de Sincronização de Arquivos do Azure que você provisionar abaixo está na mesma região, nova.
Implantar o Sincronização de Arquivos do Azure recurso de nuvem

TIP
Se você precisar alterar a região do Azure da região atual em que os dados do StorSimple residem, você provisionou as
contas de armazenamento para seus compartilhamentos de arquivos do Azure na nova região. Certifique-se de ter
selecionado essa mesma região ao implantar esse serviço de sincronização de armazenamento.
Implantar um Windows Server local

Crie um Windows Server 2019 – no mínimo 2012R2-como uma máquina virtual ou um servidor físico.
Também há suporte para um cluster de failover do Windows Server. Não reutilize o servidor que você pode ter
ao lado do StorSimple 8100 ou 8600.
Provisione ou adicione armazenamento de conexão direta (DAS em comparação com o NAS, para o qual não há
suporte).
É recomendável dar ao seu novo Windows Server uma quantidade igual ou maior de armazenamento do que o
dispositivo StorSimple 8100 ou 8600 está disponível localmente para cache. Você usará o Windows Server da
mesma maneira que usou o dispositivo StorSimple, se ele tiver a mesma quantidade de armazenamento que o
dispositivo, então a experiência de cache deverá ser semelhante, se não for a mesma. Você pode adicionar ou
remover o armazenamento do seu Windows Server no. Isso permite que você dimensione o tamanho do volume
local e a quantidade de armazenamento local disponível para cache.
Preparar o Windows Server para sincronização de arquivos

agente.
de rede.
arquivos do Azure.
Configurar Sincronização de Arquivos do Azure no Windows Server
Seu Windows Server local registrado deve estar pronto e conectado à Internet para esse processo.
etapas anteriores.
correspondente.
WARNING
Cer tifique-se de ativar a disposição em camadas de nuvem! A camada de nuvem é o recurso AFS que permite que
o servidor local tenha menos capacidade de armazenamento do que o armazenado na nuvem, mas que tenha o namespace
completo disponível. Os dados interessantes localmente também são armazenados em cache localmente para um
desempenho rápido e local de acesso. Outro motivo para ativar a camada de nuvem nesta etapa é que não queremos
sincronizar o conteúdo do arquivo neste estágio, somente o namespace deve ser movido no momento.
Fase 4: configurar a VM do Azure para sincronização

Esta fase se preocupa com a VM do Azure com os clones do primeiro volume e do iSCSI montados. Durante essa
fase, você obterá a VM conectada por meio de Sincronização de Arquivos do Azure e iniciará uma primeira rodada
de mover arquivos do clone (s) do volume do StorSimple.
Você já configurou seu servidor local que substituirá seu dispositivo StorSimple 8100 ou 8600, por Sincronização
Configurar a VM do Azure é um processo quase idêntico, com uma etapa adicional. As etapas a seguir irão guiá-lo
pelo processo.
IMPORTANT
É importante que a VM do Azure não esteja configurada com a camada de nuvem habilitada! Você vai trocar o
volume desse servidor com clones de volume mais recentes durante a migração. A camada de nuvem não tem nenhum
benefício e sobrecarga sobre o uso da CPU que você deve evitar.
1. Implante o agente AFS. (consulte a seção anterior)

2. Preparando a VM para Sincronização de Arquivos do Azure.
3. Configurar sincronização
Prepare a VM para Sincronização de Arquivos do Azure
Sincronização de Arquivos do Azure é usado para mover os arquivos dos volumes iSCSI StorSimple montados
para os compartilhamentos de arquivos de destino do Azure. Durante esse processo de migração, você montará
vários clones de volume em sua VM, sob a mesma letra de unidade. Sincronização de Arquivos do Azure deve ser
configurado para ver o próximo clone de volume que você montou como uma versão mais recente dos arquivos e
pastas e atualizar os compartilhamentos de arquivos do Azure conectados via Sincronização de Arquivos do Azure.
IMPORTANT
Para que isso funcione, uma chave do registro deve ser definida no servidor antes que o Sincronização de Arquivos do Azure
seja configurado.
1. Crie um novo diretório na unidade do sistema da VM. Sincronização de Arquivos do Azure informações
precisarão ser persistidas em vez de nos clones do volume montado. Por exemplo: "C:\syncmetadata"
2. Abra regedit e localize o seguinte hive do registro: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure\StorageSync
3. Crie uma nova chave do tipo cadeia de caracteres chamada: MetadataRootPath
4. Defina o caminho completo para o diretório que você criou no volume do sistema, por exemplo:
C:\syncmetadata"
Configurar Sincronização de Arquivos do Azure na VM do Azure

Esta etapa é semelhante à seção anterior, que discute como você configura o AFS no servidor local.
A diferença é que você não deve habilitar a camada de nuvem nesse servidor e que precisa certificar-se de que as
pastas certas estejam conectadas aos compartilhamentos de arquivos do Azure corretos. Caso contrário, o seu
nome de compartilhamentos de arquivos do Azure e conteúdo de dados não corresponderá e não haverá como
renomear os recursos de nuvem ou as pastas locais sem reconfigurar a sincronização.
Consulte a seção anterior sobre como configurar sincronização de arquivos do Azure em um Windows Server.
Resumo da etapa 4
Neste ponto, você terá configurado com êxito Sincronização de Arquivos do Azure na VM do Azure que montou os
clones de volume do StorSimple via iSCSI. Agora, os dados estão fluindo da VM do Azure para vários
compartilhamentos de arquivos do Azure e, a partir daí, um namespace totalmente cansado aparece no Windows
Server local.
IMPORTANT
Verifique se não há nenhuma alteração feita ou acesso de usuário concedido ao Windows Server no momento.
Os dados de clone de volume inicial que se movem pela VM do Azure para os compartilhamentos de arquivos do
Azure podem levar muito tempo, possivelmente semanas. Estimar o tempo que isso levará é complicado e
dependerá de muitos fatores. Mais notavelmente, a velocidade na qual a VM do Azure pode acessar arquivos nos
volumes do StorSimple e a rapidez com que Sincronização de Arquivos do Azure pode processar os arquivos e as
pastas que precisam de sincronização.
A partir da experiência, podemos pressupor que a largura de banda, portanto, o tamanho real dos dados, reproduz
uma função subordinada. O momento em que esse ou qualquer intervalo de migração subsequente levará
dependerá, principalmente, do número de itens que podem ser processados por segundo. Portanto, por exemplo 1
TiB com um 100.000 arquivos e pastas, provavelmente terminará mais devagar que 1 TiB com apenas 50.000
arquivos e pastas.
Fase 5: iterar por meio de vários clones de volume

Conforme discutido na fase anterior, a sincronização inicial pode levar muito tempo. Seus usuários e aplicativos
ainda estão acessando o dispositivo StorSimple 8100 ou 8600 local. Isso significa que as alterações estão sendo
acumuladas e, com todos os dias, um Delta maior entre os dados dinâmicos e o clone do volume inicial, no
momento, você está migrando, formulários. Nesta seção, você aprenderá a minimizar o tempo de inatividade
usando vários clones de volume e dizendo quando a sincronização é feita.
Infelizmente, o processo de migração não é instantâneo. Isso significa que o Delta mencionado anteriormente para
os dados dinâmicos é uma consequência inevitável. A boa notícia é que você pode repetir o processo de
montagem de novos clones de volume. O Delta de cada clone de volume será progressivamente menor. Portanto,
eventualmente, uma sincronização será concluída em uma duração de tempo que você considerar aceitável para
colocar os usuários e aplicativos offline para passar para o Windows Server local.
Repita as etapas a seguir até que a sincronização seja concluída em uma duração rápida o suficiente que você sinta
à vontade para colocar os usuários e aplicativos offline:
1. Determine se a sincronização foi concluída para um determinado clone de volume.
2. Faça um novo clone (s) de volume e monte-o no dispositivo virtual 8020.
3. Determine quando a sincronização é feita.
4. Estratégia de recorte
O próximo clone (s) de volume
Discutimos um clone (s) de volume anteriormente neste artigo. Esta fase tem duas ações:
1. Fazer um clone de volume
2. Montar esse clone de volume (veja acima)
Determinar quando a sincronização está concluída
Quando a sincronização é concluída, você pode interromper sua medição de tempo e determinar se precisa repetir
o processo de fazer um clone de volume e montá-lo ou se a sincronização de tempo executada com o último clone
de volume era suficientemente pequena.
Para determinar se a sincronização foi concluída:
1. Abra o Visualizador de Eventos e navegue até aplicativos e ser viços
2. Navegue e abra Microsoft\FileSync\Agent\Telemetr y
3. Procure o evento 9102 mais recente, que corresponde a uma sessão de sincronização concluída
4. Selecione detalhes e confirme se o valor de SyncDirection é upload
5. Verifique o HRESULT e confirme se ele mostra 0 . Isso significa que a sessão de sincronização foi bem-sucedida.
Se HResult for um valor diferente de zero, ocorrerá um erro durante a sincronização. Se o PerItemErrorCount
for maior que 0, alguns arquivos ou pastas não foram sincronizados corretamente. É possível ter um HResult de
0, mas um PerItemErrorCount que seja maior que 0. Neste ponto, você não precisa se preocupar com o
PerItemErrorCount. Capturaremos esses arquivos mais tarde. Se essa contagem de erros for significativa,
milhares de itens, entre em contato com o atendimento ao cliente e peça para estar conectado ao grupo de
produtos Sincronização de Arquivos do Azure para obter orientação direta sobre as próximas fases.
6. Verifique para ver vários eventos 9102 com HResult 0 em uma linha. Isso indica que a sincronização foi
concluída para este clone de volume.
Estratégia de recorte
1. Determine se a sincronização de um clone de volume é rápida o suficiente agora. (Delta pequeno o suficiente.)
2. Coloque o dispositivo StorSimple offline.
3. Um RoboCopy final.
Meça o tempo e determine se a sincronização de um clone de volume recente pode ser concluída dentro de uma
janela de tempo pequena o suficiente, que você pode pagar como tempo de inatividade em seu sistema.
Agora é hora de desabilitar o acesso do usuário ao dispositivo StorSimple. Não há mais alterações. O tempo de
inatividade foi iniciado. Você precisa deixar o dispositivo online e conectado, mas agora deve impedir alterações
nele.
Na fase 6, você encontrará qualquer Delta nos dados dinâmicos desde o último clone de volume.
Fase 6: um RoboCopy final

Neste ponto, há duas diferenças entre o Windows Server local e o dispositivo StorSimple 8100 ou 8600:
1. Pode haver arquivos que não foram sincronizados (consulte PerItemErrors no log de eventos acima)
2. O dispositivo StorSimple tem um cache populado versus o Windows Server apenas um namespace sem
conteúdo de arquivo armazenado localmente no momento.
Podemos colocar o cache do Windows Server até o estado do dispositivo e garantir que nenhum arquivo seja
deixado para trás com um RoboCopy final.
Cau t i on
É imperativo que o comando RoboCopy que você seguir, é exatamente o descrito abaixo. Queremos apenas copiar
os arquivos que são locais e os arquivos que não foram movidos pela abordagem de clonagem de volume +
sincronização antes. Podemos resolver os problemas por que não sincronizaram mais tarde, após a conclusão da
migração. (Consulte sincronização de arquivos do Azure solução de problemas. É mais provável que os caracteres
não imprimíveis sejam impressos em nomes de arquivos que você não perderá quando forem excluídos.)
Comando RoboCopy:
Plano de fundo:
/MT
/UNILOG:
/TEE
/B
/MIR
Permite que o RoboCopy considere apenas deltas entre origem (dispositivo StorSimple) e destino (diretório do
Windows Server).
/COPY: copyflag [s]
auditoria
/COPYALL
carimbos de hora
Você deve executar esse comando RoboCopy para cada um dos diretórios no Windows Server como um destino,
que você configurou com a sincronização de arquivos para um arquivo do Azure.
Você pode executar vários desses comandos em paralelo. Depois que essa etapa do RoboCopy for concluída, você
poderá permitir que seus usuários e aplicativos acessem o Windows Server como faziam o dispositivo StorSimple
antes.
Consulte os arquivos de log do Robocopy para ver se os arquivos foram deixados para trás. Se houver problemas,
na maioria dos casos, você poderá resolvê-los depois que a migração for concluída e seus usuários e aplicativos
tiverem sido redirecionados para o Windows Server. Se você precisar corrigir quaisquer problemas, faça isso antes
da fase 7.
É provável que seja necessário criar os compartilhamentos SMB no Windows Server que você tinha nos dados do
StorSimple antes. Você pode carregar essa etapa e fazer isso mais cedo para não perder tempo aqui, mas deve
garantir que antes desse ponto, nenhuma alteração nos arquivos ocorra no Windows Server.
Se você tiver uma implantação DFS-N, poderá apontar os namespaces DFN para os locais da nova pasta do
servidor. Se você não tiver uma implantação DFS-N e, em seguida, o dispositivo 8100 8600 foi disponibilizado
localmente com um servidor Windows, você poderá pegar esse servidor fora do domínio e ingressar no domínio
em seu novo Windows Server com o AFS para o domínio, atribuir a ele o mesmo nome de servidor que o servidor
antigo e os mesmos nomes de compartilhamento, e o novo servidor permanecerá transparente para seus , política
de grupo ou scripts.
Fase 7: desprovisionar
Durante a última fase, você fez a iteração por meio de vários clones de volume e, eventualmente, conseguiu reduzir
o acesso do usuário para o novo Windows Server depois de colocar o dispositivo StorSimple offline.
Agora você pode começar a desprovisionar recursos desnecessários. Antes de começar, é uma prática
recomendada observar sua nova implantação de Sincronização de Arquivos do Azure em produção, por um pouco.
Isso oferece opções para corrigir quaisquer problemas que você possa encontrar.
Quando estiver satisfeito e tiver observado sua implantação AFS por pelo menos alguns dias, você poderá
começar a desprovisionar os recursos nesta ordem:
1. Desative a VM do Azure que usamos para mover dados dos clones de volume para os compartilhamentos
de arquivos do Azure por meio da sincronização de arquivos.
2. Vá para o recurso de serviço de sincronização de armazenamento no Azure e cancele o registro da VM do
Azure. Isso o Remove de todos os grupos de sincronização.
WARNING
Cer tifique-se de escolher o computador cer to. Você desativou a VM de nuvem, isso significa que ela deve ser
mostrada como o único servidor offline na lista de servidores registrados. Você não deve escolher o Windows Server
local nesta etapa. isso cancelará o seu registro.
3. Exclua a VM do Azure e seus recursos.

4. Desabilite o dispositivo virtual StorSimple 8020.
5. Desprovisione todos os recursos do StorSimple no Azure.
6. Desconecte o dispositivo físico StorSimple do seu data center.
A migração foi concluída.
Próximas etapas
Familiarize-se com o Sincronização de Arquivos do Azure. Especialmente com a flexibilidade das políticas de
camadas de nuvem.
Se você vir no portal do Azure ou nos eventos anteriores, que alguns arquivos não estão sincronizando
permanentemente, examine o guia de solução de problemas para obter as etapas para resolver esses problemas.
Visão geral do Sincronização de Arquivos do Azure: aka.ms/AFS
Camadas de nuvem
Guia de solução de problemas Sincronização de Arquivos do Azure
Migração do StorSimple 1200 para o Sincronização
de Arquivos do Azure
O StorSimple 1200 Series é uma solução de virtualização que é executada em um data center local. É possível
migrar os dados desse dispositivo para um ambiente Sincronização de Arquivos do Azure. Sincronização de
Arquivos do Azure é o serviço do Azure de longo prazo padrão e estratégico para o qual os dispositivos StorSimple
podem ser migrados.
A série StorSimple 1200 atingirá o fim da vida útil em 2022 de dezembro. É importante começar a planejar sua
migração assim que possível. Este artigo fornece as etapas de conhecimento e migrações em segundo plano
necessárias para uma migração bem-sucedida para o Sincronização de Arquivos do Azure.

IMPORTANT
A Microsoft está comprometida em auxiliar os clientes em sua migração. Email AzureFilesMigration@microsoft . com para um
plano de migração personalizado, bem como assistência durante a migração.
Sincronização de Arquivos do Azure é um serviço de nuvem da Microsoft, com base em dois componentes
principais:
Sincronização de arquivos e camadas de nuvem.
Compartilhamentos de arquivos como armazenamento nativo no Azure, que podem ser acessados por meio de
vários protocolos, como SMB e REST de arquivo. Um compartilhamento de arquivos do Azure é comparável a
um compartilhamento de arquivos em um Windows Server, que você pode montar nativamente como uma
unidade de rede. Ele dá suporte a aspectos de fidelidade de arquivo importantes, como atributos, permissões e
carimbos de data/hora. Ao contrário do StorSimple, nenhum aplicativo/serviço é necessário para interpretar os
arquivos e as pastas armazenados na nuvem. A abordagem ideal e mais flexível para armazenar dados de
servidor de arquivos de uso geral, bem como alguns dados de aplicativo, na nuvem.
Este artigo se concentra nas etapas de migração. Se antes de migrar você gostaria de saber mais sobre
Sincronização de Arquivos do Azure, recomendamos os seguintes artigos:
Sincronização de Arquivos do Azure-visão geral
Sincronização de Arquivos do Azure-guia de implantação
Metas de migração
O objetivo é garantir a integridade dos dados de produção, bem como garantir a disponibilidade. O segundo
requer um mínimo de tempo de inatividade, para que ele possa se ajustar ou ter apenas um pouco mais de uma
janela de manutenção regular.
Caminho de migração do StorSimple 1200 para Sincronização de

Arquivos do Azure
Um servidor Windows local é necessário para executar um agente de Sincronização de Arquivos do Azure. O
Windows Server pode ser, no mínimo, um servidor 2012R2, mas o ideal é o Windows Server 2019.
Há inúmeros caminhos de migração alternativos e criaria um artigo muito longo para documentar todos eles e
ilustrar por que eles têm risco ou desvantagens na rota que recomendamos como prática recomendada neste
artigo.
A imagem anterior descreve as etapas que correspondem às seções neste artigo.

Etapa 1: provisionar o Windows Server e o armazenamento no local
1. Crie um Windows Server 2019 – no mínimo 2012R2-como uma máquina virtual ou um servidor físico.
Também há suporte para um cluster de failover do Windows Server.
2. Provisione ou adicione armazenamento de conexão direta (DAS em comparação com o NAS, para o qual não há
suporte). O tamanho do armazenamento do Windows Server deve ser igual ou maior que o tamanho da
capacidade disponível do seu dispositivo virtual StorSimple 1200.
Etapa 2: configurar o armazenamento do Windows Server
Nesta etapa, você mapeia sua estrutura de armazenamento do StorSimple (volumes e compartilhamentos) para
sua estrutura de armazenamento do Windows Server. Se você planeja fazer alterações em sua estrutura de
armazenamento, o que significa o número de volumes, a associação de pastas de dados a volumes ou a estrutura
de subpastas acima ou abaixo de seus compartilhamentos SMB/NFS atuais, agora é o momento em que essas
alterações serão levadas em consideração. Alterar a estrutura de arquivos e pastas depois que Sincronização de
Arquivos do Azure é configurado, é complicado e deve ser evitado. Este artigo pressupõe que você está mapeando
1:1, portanto, você deve levar em consideração as alterações de mapeamento ao seguir as etapas neste artigo.
Nenhum dos dados de produção deve terminar no volume do Windows Server System. Não há suporte para
camadas de nuvem em volumes do sistema. No entanto, esse recurso é necessário para a migração, bem como
para operações contínuas como uma substituição do StorSimple.
Provisione o mesmo número de volumes no seu Windows Server que você tem em seu dispositivo virtual
StorSimple 1200.
Configure quaisquer funções, recursos e configurações do Windows Server necessárias. Recomendamos que
você opte pelas atualizações do Windows Server para manter seu so seguro e atualizado. Da mesma forma,
recomendamos optar por Microsoft Update manter os aplicativos da Microsoft atualizados, incluindo o agente
de Sincronização de Arquivos do Azure.
Não configure pastas ou compartilhamentos antes de ler as etapas a seguir.
Etapa 3: implantar a primeira Sincronização de Arquivos do Azure recurso de nuvem
Etapa 4: corresponder o volume local e a estrutura de pastas para Sincronização de Arquivos do Azure e
recursos de compartilhamento de arquivos do Azure
mapeamento 1:1.
transferência.
TIP

IMPORTANT
Azure.
Etapa 5: provisionar compartilhamentos de arquivos do Azure

do Azure neles.
Cau t i on
Etapa 6: configurar pastas de destino do Windows Server
Nas etapas anteriores, você considerou todos os aspectos que determinarão os componentes de suas topologias
de sincronização. Agora é hora, preparar o servidor para receber arquivos para carregamento.
Crie todas as pastas, que sincronizarão cada uma com seu próprio compartilhamento de arquivos do Azure. É
importante que você siga a estrutura de pastas que você documentou anteriormente. Se, por exemplo, você
decidiu sincronizar vários compartilhamentos SMB locais juntos em um único compartilhamento de arquivos do
Azure, precisará colocá-los em uma pasta raiz comum no volume. Crie essa pasta raiz de destino no volume agora.
O número de compartilhamentos de arquivos do Azure que você provisionou deve corresponder ao número de
pastas que você criou nesta etapa + o número de volumes que você sincronizará no nível raiz.
Etapa 7: implantar o agente de Sincronização de Arquivos do Azure

agente.
de rede.
arquivos do Azure.
Etapa 8: configurar a sincronização
etapas anteriores.
correspondente.
WARNING
Cer tifique-se de ativar a disposição em camadas de nuvem! Isso será necessário se o servidor local não tiver espaço
suficiente para armazenar o tamanho total dos dados no armazenamento em nuvem do StorSimple. Defina a política de
camadas, temporariamente para a migração, para 99% de espaço livre no volume.
Repita as etapas da criação do grupo de sincronização e adição da pasta de servidor correspondente como um
ponto de extremidade do servidor para todos os compartilhamentos de arquivos/locais de servidor do Azure que
Etapa 9: copiar os arquivos
A abordagem de migração básica é um RoboCopy de seu dispositivo virtual StorSimple para o Windows Server e
Sincronização de Arquivos do Azure aos compartilhamentos de arquivos do Azure.
Identifique o primeiro local em seu dispositivo virtual StorSimple.
Identifique a pasta correspondente no Windows Server, que já tem Sincronização de Arquivos do Azure
configurada nela.
Iniciar a cópia usando o RoboCopy
O comando RoboCopy a seguir irá recuperar os arquivos do armazenamento do Azure do StorSimple para o
StorSimple local e, em seguida, movê-los para a pasta de destino do Windows Server. O Windows Server irá
sincronizá-lo para os compartilhamentos de arquivos do Azure. Como o volume do Windows Server local fica
cheio, a disposição em camadas da nuvem será iniciada e os arquivos de camada que já foram sincronizados com
êxito. A camada de nuvem irá gerar espaço suficiente para continuar a cópia do dispositivo virtual StorSimple. As
verificações de camadas de nuvem uma vez por hora para ver o que foi sincronizado e liberar espaço em disco
para alcançar o espaço livre do volume de 99%.
Plano de fundo:
/MT
/UNILOG:
/TEE
/B
/MIR
Permite executar esse comando RoboCopy várias vezes, sequencialmente no mesmo destino/destino. Ele identifica
o que foi copiado antes e o omite. Somente as alterações, adições e "exclusões" serão processadas, ocorridas desde
a última execução. Se o comando não for executado antes, nada será omitido. Essa é uma opção excelente para os
locais de origem que ainda são usados e alterados ativamente.
/COPY: copyflag [s]
auditoria
/COPYALL
carimbos de hora
Quando você executa o comando RoboCopy pela primeira vez, os usuários e os aplicativos ainda estão acessando
os arquivos e pastas do StorSimple e, potencialmente, alterá-lo. É possível que o RoboCopy tenha processado um
diretório, passe para o próximo e, em seguida, um usuário no local de origem (StorSimple) adicione, altere ou
exclua um arquivo que agora não será processado nesta execução atual do RoboCopy. Tudo bem.
A primeira execução é sobre a movimentação da massa dos dados de volta para o local, para o Windows Server e
para o backup na nuvem por meio de Sincronização de Arquivos do Azure. Isso pode levar muito tempo,
dependendo de:
sua largura de banda de download
a velocidade de recuperação do serviço de nuvem do StorSimple
a largura de banda de upload
o número de itens (arquivos e pastas) que precisam ser processados por qualquer serviço
A segunda vez que terminará mais rapidamente, porque ele só precisa transportar alterações ocorridas desde a
última execução. Essas alterações provavelmente são locais para o StorSimple, já que elas são recentes. Isso reduz
ainda mais o tempo, pois a necessidade de recuperação da nuvem é reduzida. Durante essa segunda execução,
ainda assim, novas alterações podem ser acumuladas.
Repita esse processo até que você esteja satisfeito com o tempo que leva para concluir é um inatividade aceitável.
Quando você considera o tempo de inatividade aceitável e está preparado para colocar o local do StorSimple
offline, faça isso agora: por exemplo, remova o compartilhamento SMB para que nenhum usuário possa acessar a
pasta ou execute qualquer outra etapa apropriada que impeça o conteúdo a ser alterado nessa pasta no
StorSimple.
Executar uma última rodada do RoboCopy. Isso selecionará todas as alterações, que podem ter sido perdidas.
Quanto tempo leva essa etapa final, depende da velocidade da verificação do RoboCopy. Você pode estimar o
tempo (que é igual ao seu tempo de inatividade) medindo quanto tempo a execução anterior levou.
apontar para ele. Certifique-se de definir as mesmas permissões de nível de compartilhamento que no
compartilhamento SMB do StorSimple.
Você concluiu a migração de um compartilhamento/grupo de compartilhamentos em um volume ou raiz comum.
(Dependendo do que você mapeou e decidiu que precisava entrar no mesmo compartilhamento de arquivos do
Azure.)
WARNING
Depois de mover todos os dados do seu StorSimple para o Windows Server e sua migração estiver concluída: retorne a
todos os grupos de sincronização na portal do Azure e ajuste o valor de porcentagem de espaço livre do volume de
camadas da nuvem para algo mais adequado para a utilização do cache, digamos 20%.
A política de espaço livre do volume de camadas de nuvem age em um nível de volume com potencialmente vários
pontos de extremidade de servidor sincronizando a partir dele. Se você se esquecer de ajustar o espaço livre em
um ponto de extremidade de servidor, a sincronização continuará a aplicar a regra mais restritiva e tentará manter
99% de espaço livre em disco, tornando o cache local não funcionando como você poderia esperar. A menos que
seja o objetivo de ter apenas o namespace para um volume que contenha apenas dados de arquivamento
raramente acessados.
O problema mais provável que você pode encontrar é que o comando RoboCopy falha com "volume cheio" no
lado do Windows Server. Se esse for o caso, a velocidade de download provavelmente será melhor do que a
velocidade de carregamento. A camada de nuvem age uma vez a cada hora para evacuar o conteúdo do disco local
do Windows Server, que foi sincronizado.
explorador de arquivos no seu Windows Server.
Quando o seu Windows Server tiver capacidade disponível suficiente, a reexecução do comando resolverá o
problema. Nada é interrompido quando você entra nessa situação e pode avançar com confiança. A inconveniência
de executar o comando novamente é a única consequência.
Você também pode encontrar outros problemas de Sincronização de Arquivos do Azure. Como é improvável que
possa ser, se isso acontecer, dê uma olhada no LINK sincronização de arquivos do Azure guia de solução de
problemas .
Links relevantes
Conteúdo de migração:
Guia de migração da série StorSimple 8000
Sincronização de Arquivos do Azure conteúdo:
Visão geral de AFS
Guia de implantação AFS
Solução de problemas AFS
Configurar cadeias de conexão do Armazenamento
do Azure
Uma cadeia de conexão inclui as informações de autorização necessárias para que seu aplicativo acesse dados em
uma conta de armazenamento do Azure em tempo de execução usando a autorização de chave compartilhada.
Você pode configurar cadeias de conexão para:
Conecte-se ao emulador de armazenamento do Azure.
Acesse uma conta de armazenamento no Azure.
Acessar recursos especificados no Azure por uma SAS (Assinatura de Acesso Compartilhado).
Para saber como exibir as chaves de acesso da conta e copiar uma cadeia de conexão, consulte gerenciar chaves de
acesso da conta de armazenamento.
Proteger suas chaves de acesso

As chaves de acesso da conta de armazenamento são semelhantes a uma senha raiz para sua conta de
armazenamento. Sempre tenha cuidado para proteger suas chaves de acesso. Use Azure Key Vault para gerenciar e
girar suas chaves com segurança. Evite distribuir chaves de acesso para outros usuários, embuti-las em código ou
salvá-las em qualquer lugar em texto sem formatação que seja acessível a outras pessoas. Gire suas chaves se
acreditar que elas podem ter sido comprometidas.
Se possível, use Azure Active Directory (Azure AD) para autorizar solicitações para o armazenamento de BLOBs e
de filas em vez da chave compartilhada. O Azure AD fornece segurança superior e facilidade de uso sobre chave
compartilhada. Para obter mais informações sobre como autorizar o acesso a dados com o Azure AD, consulte
autorizar o acesso a BLOBs e filas do Azure usando o Azure Active Directory.
Armazenar uma cadeia de conexão

Seu aplicativo precisara acessar a cadeia de conexão no runtime para autorizar as solicitações feitas para o
Armazenamento do Microsoft Azure. Você tem várias opções diferentes para armazenar a cadeia de conexão:
Você pode armazenar a cadeia de conexão em uma variável de ambiente.
Um aplicativo em execução na área de trabalho ou em um dispositivo pode armazenar a cadeia de conexão em
um arquivo app.config ou web.config . Adicione a cadeia de conexão à seção AppSettings nesses arquivos.
Um aplicativo em execução em um serviço de nuvem do Azure pode armazenar a cadeia de conexão no
arquivo de esquema (.cscfg) de configuração de serviço do Azure. Adicionar a cadeia de conexão à seção
ConfigurationSettings do arquivo de configuração de serviço.
Armazenar a cadeia de conexão em um arquivo de configuração facilita a atualização da cadeia de conexão para
alternar entre o emulador de armazenamento e uma conta de Armazenamento do Azure na nuvem. Você precisa
apenas editar a cadeia de conexão para apontar para seu ambiente de destino.
Você pode usar o Gerenciador de Configuração do Microsoft Azure para acessar a cadeia de conexão no runtime,
independentemente do local em que seu aplicativo esteja sendo executado.
Configurar uma cadeia de conexão para o emulador de

armazenamento
O emulador de armazenamento dá suporte a uma única conta fixa e uma chave de autenticação conhecida para a
autenticação da Chave Compartilhada. Essa conta e a chave são as únicas credenciais de Chave Compartilhada
permitidas para uso com o emulador de armazenamento. Eles são:
Account name: devstoreaccount1

Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
NOTE
A chave de autenticação suportada pelo emulador de armazenamento destina-se somente para testar a funcionalidade do
seu código de autenticação de cliente. Ela não serve para fins de segurança. Você não pode usar sua conta de
armazenamento de produção e a chave com o emulador de armazenamento. Você não deve usar a conta de
desenvolvimento com dados de produção.
O emulador de armazenamento oferece suporte à conexão via HTTP apenas. No entanto, o HTTPS é o protocolo
recomendado para acessar os recursos em uma conta de armazenamento de produção do Azure.
Conectar-se à conta do emulador usando um atalho

A maneira mais fácil de conectar o emulador de armazenamento do seu aplicativo é configurar uma cadeia de
conexão no arquivo de configuração do aplicativo que faz referência ao atalho UseDevelopmentStorage=true . Aqui
está um exemplo de uma cadeia de conexão para o emulador de armazenamento em um arquivo app. config :
<appSettings>
<add key="StorageConnectionString" value="UseDevelopmentStorage=true" />
</appSettings>
Conectar-se à conta do emulador usando o nome de conta e a chave conhecidos

Para criar uma cadeia de conexão que referencia o nome da conta do emulador e a chave, você deve especificar os
pontos de extremidade para cada um dos serviços do emulador na cadeia de conexão que você deseja usar. Isso é
necessário para que a cadeia de conexão faça referência aos pontos de extremidade do emulador, que são
diferentes daqueles para uma conta de armazenamento de produção. Por exemplo, o valor da sua cadeia de
conexão terá esta aparência:
DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;
AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;
BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;
TableEndpoint=http://127.0.0.1:10002/devstoreaccount1;
QueueEndpoint=http://127.0.0.1:10001/devstoreaccount1;
Esse valor é idêntico ao atalho mostrado acima, UseDevelopmentStorage=true .

Especificar um proxy HTTP
Você também pode especificar um proxy HTTP para usar quando estiver testando seu serviço no emulador de
armazenamento. Isso pode ser útil para observar solicitações e respostas HTTP enquanto você estiver depurando
operações nos serviços de armazenamento. Para especificar um proxy, adicione a opção
DevelopmentStorageProxyUri à cadeia de conexão e defina o seu valor para o URI de proxy. Por exemplo, aqui está
uma cadeia de conexão que aponta para o emulador de armazenamento e configura um proxy HTTP:
UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://myProxyUri
Consulte Usar o emulador do Armazenamento do Azure para desenvolvimento e teste para obter mais
informações sobre o emulador de armazenamento.
Configurar uma cadeia de conexão para uma conta de armazenamento
do Azure
Para criar uma cadeia de conexão para sua conta de Armazenamento do Azure, use o formato de cadeia de
conexão a seguir. Indique se você deseja se conectar à conta de armazenamento por meio de HTTPS
(recomendado) ou HTTP, substitua myAccountName pelo nome da sua conta de armazenamento e substitua
myAccountKey pela chave de acesso da sua conta:
DefaultEndpointsProtocol=[http|https];AccountName=myAccountName;AccountKey=myAccountKey
Por exemplo, a cadeia de conexão pode parecer com o seguinte:

DefaultEndpointsProtocol=https;AccountName=storagesample;AccountKey=<account-key>
Embora o Armazenamento do Azure dê suporte a HTTP e HTTPS em uma cadeia de conexão, usar HTTPS é
altamente recomendável.
TIP
Você pode encontrar as cadeias de conexão da conta de armazenamento no Portal do Azure. Navegue até configurações >
chaves de acesso na folha do menu da sua conta de armazenamento para ver cadeias de conexão para as chaves de
acesso primária e secundária.
Criar uma cadeia de conexão usando uma assinatura de acesso

compartilhado
Se você possui uma URL de SAS (assinatura de acesso compartilhado) que concede acesso a recursos em uma
conta de armazenamento, pode usar a SAS em uma cadeia de conexão. Como a SAS contém as informações
necessárias para autenticar a solicitação, uma cadeia de conexão com uma SAS fornece o protocolo, o ponto de
extremidade de serviço e as credenciais necessárias para acessar o recurso.
Para criar uma cadeia de conexão que inclui uma assinatura de acesso compartilhado, especifique a cadeia de
caracteres no seguinte formato:
BlobEndpoint=myBlobEndpoint;
QueueEndpoint=myQueueEndpoint;
TableEndpoint=myTableEndpoint;
FileEndpoint=myFileEndpoint;
SharedAccessSignature=sasToken
Cada ponto de extremidade de serviço é opcional, embora a cadeia de conexão deve conter pelo menos um.
NOTE
Usar HTTPS com uma SAS é uma prática recomendada.
Se você estiver especificando uma SAS em uma cadeia de conexão em um arquivo de configuração, precisará codificar
caracteres especiais na URL.
Exemplo de SAS de serviço

Aqui está um exemplo de uma cadeia de conexão que inclui um serviço SAS para o Armazenamento de Blobs:
BlobEndpoint=https://storagesample.blob.core.windows.net;
SharedAccessSignature=sv=2015-04-05&sr=b&si=tutorial-policy-
635959936145100803&sig=9aCzs76n0E7y5BpEi2GvsSv433BZa22leDOZXX%2BXXIU%3D
E aqui está um exemplo da mesma cadeia de conexão com codificação de caracteres especiais:
SharedAccessSignature=sv=2015-04-05&sr=b&si=tutorial-policy-
635959936145100803&sig=9aCzs76n0E7y5BpEi2GvsSv433BZa22leDOZXX%2BXXIU%3D
Exemplo de SAS de conta

Aqui está um exemplo de uma cadeia de conexão que inclui uma conta SAS para o Armazenamento de Blobs e de
Arquivos: Observe que os pontos de extremidade para ambos os serviços são especificados:
FileEndpoint=https://storagesample.file.core.windows.net;
SharedAccessSignature=sv=2015-07-08&sig=iCvQmdZngZNW%2F4vw43j6%2BVz6fndHF5LI639QJba4r8o%3D&spr=https&st=2016-
04-12T03%3A24%3A31Z&se=2016-04-13T03%3A29%3A31Z&srt=s&ss=bf&sp=rwl
E aqui está um exemplo da mesma cadeia de conexão com a codificação de URL:
FileEndpoint=https://storagesample.file.core.windows.net;
SharedAccessSignature=sv=2015-07-
08&sig=iCvQmdZngZNW%2F4vw43j6%2BVz6fndHF5LI639QJba4r8o%3D&spr=https&st=2016-04-
12T03%3A24%3A31Z&se=2016-04-13T03%3A29%3A31Z&srt=s&ss=bf&sp=rwl
Criar uma cadeia de conexão para um ponto de extremidade explícito

do armazenamento
Você pode especificar explicitamente os pontos de extremidade de serviço na sua cadeia de conexão em vez dos
pontos de extremidade padrão. Para criar uma cadeia de conexão que especifique um ponto de extremidade
explícito, especifique o ponto de extremidade de serviço completo para cada serviço, incluindo a especificação do
protocolo (HTTP ou HTTPS, sendo este o recomendado) usando o seguinte formato:
DefaultEndpointsProtocol=[http|https];
BlobEndpoint=myBlobEndpoint;
FileEndpoint=myFileEndpoint;
QueueEndpoint=myQueueEndpoint;
TableEndpoint=myTableEndpoint;
AccountName=myAccountName;
AccountKey=myAccountKey
Um cenário em que pode ser útil especificar um ponto de extremidade explícito é se você mapeou o ponto de
extremidade do Armazenamento de Blobs para um domínio personalizado. Nesse caso, você pode especificar o
ponto de extremidade personalizado para o armazenamento de Blobs em sua cadeia de conexão. Opcionalmente,
você poderá especificar os pontos de extremidade padrão para os outros serviços se eles forem usados pelo seu
aplicativo.
Este é um exemplo de uma cadeia de conexão que especifica um ponto de extremidade explícito para o serviço
Blob:
# Blob endpoint only
DefaultEndpointsProtocol=https;
BlobEndpoint=http://www.mydomain.com;
AccountName=storagesample;
AccountKey=<account-key>
Este exemplo especifica pontos de extremidade explícitos para todos os serviços, incluindo um domínio
personalizado para o serviço Blob:
# All service endpoints

BlobEndpoint=http://www.mydomain.com;
FileEndpoint=https://myaccount.file.core.windows.net;
QueueEndpoint=https://myaccount.queue.core.windows.net;
TableEndpoint=https://myaccount.table.core.windows.net;
AccountKey=<account-key>
Os valores de ponto de extremidade em uma cadeia de conexão são usados para construir os URIs de solicitação
para os serviços de armazenamento e determinar a forma de quaisquer URIs retornados ao seu código.
Se você tiver mapeado um ponto de extremidade de armazenamento para um domínio personalizado e omitir
esse ponto de extremidade de uma cadeia de conexão, você não poderá usar essa cadeia de conexão para acessar
os dados nesse serviço do seu código.
IMPORTANT
Valores de ponto de extremidade de serviço em suas cadeias de conexão devem ser URIs bem formados, incluindo
https:// (recomendado) ou http:// . Já que o armazenamento do Azure ainda não dá suporte a HTTPS para domínios
personalizados, você deve especificar http:// para qualquer URI de ponto de extremidade que aponta para um domínio
personalizado.
Criar uma cadeia de conexão com um sufixo de ponto de extremidade

Para criar uma cadeia de conexão para um serviço de armazenamento em regiões ou instâncias com sufixos de
ponto de extremidade diferentes, como para o Azure China 21Vianet ou Azure governamental, use o seguinte
formato de cadeia de conexão. Indique se deseja se conectar à conta de armazenamento por meio de HTTP ou
HTTPS (recomendado), substitua myAccountName pelo nome da sua conta de armazenamento, substitua
myAccountKey pela chave de acesso da sua conta e substitua mySuffix pelo sufixo do URI:
DefaultEndpointsProtocol=[http|https];
AccountName=myAccountName;
AccountKey=myAccountKey;
EndpointSuffix=mySuffix;
Aqui está um exemplo de cadeia de conexão para serviços de armazenamento na 21Vianet do Azure na China:
AccountKey=<account-key>;
EndpointSuffix=core.chinacloudapi.cn;
Analisando uma cadeia de conexão

A Biblioteca do Gerenciador de Configuração do Microsoft Azure para .NET fornece uma classe para analisar uma
cadeia de conexão de um arquivo de configuração. A classe CloudConfigurationManager analisa as definições de
configuração. Ele analisa as configurações para aplicativos cliente que são executados na área de trabalho, em um
dispositivo móvel, em uma máquina virtual do Azure ou em um serviço de nuvem do Azure.
Para fazer referência CloudConfigurationManager ao pacote, adicione as using seguintes diretivas:
using Microsoft.Azure; //Namespace for CloudConfigurationManager

using Microsoft.Azure.Storage;
Aqui está um exemplo que mostra como recuperar uma cadeia de conexão de um arquivo de configuração:
// Parse the connection string and return a reference to the storage account.
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
CloudConfigurationManager.GetSetting("StorageConnectionString"));
O uso do Gerenciador de Configurações do Azure é opcional. Você também pode usar uma API como a classe
ConfigurationManagerdo .NET Framework.
Próximas etapas
Usar o Emulador de Armazenamento do Azure para desenvolvimento e teste
Gerenciadores do Armazenamento do Azure
Usando SAS (Assinatura de Acesso Compartilhado)
Desenvolvimento para o Arquivos do Azure com
.NET
Este tutorial demonstra as noções básicas de usar o .NET para desenvolver aplicativos que usam os Arquivos do
Azure para armazenar dados de arquivo. Este tutorial cria um aplicativo de console simples para executar ações
básicas com o .NET e os arquivos do Azure:
Obter o conteúdo de um arquivo.
Defina o tamanho máximo ou a cota para o compartilhamento de arquivos.
Crie uma assinatura de acesso compartilhado (chave SAS) para um arquivo que usa uma política de acesso
armazenada definida no compartilhamento.
Copie um arquivo em outro arquivo na mesma conta de armazenamento.
Copie um arquivo em um blob na mesma conta de armazenamento.
Use as métricas de armazenamento do Azure para solução de problemas.
Para saber mais sobre os arquivos do Azure, confira o que são os arquivos do Azure?
TIP
Confira o repositório de exemplos de código do Armazenamento do Azure
Para exemplos de código fácil de usar ponta a ponta do Armazenamento do Azure que você pode baixar e executar, consulte
nossa lista de Exemplos de Armazenamento do Azure.
Compreendendo as APIs do .NET

Os Arquivos do Azure fornecem duas abordagens amplas para aplicativos cliente: protocolo SMB e REST. No .NET,
as System.IO APIs WindowsAzure.Storage e abstraim essas abordagens.
API Q UA N DO USA R O B SERVA Ç Õ ES
System.IO Seu aplicativo: A e/s de arquivo implementada com os

Precisa ler/gravar arquivos arquivos do Azure via SMB geralmente
usando SMB é a mesma de e/s com qualquer
Está em execução em um compartilhamento de arquivos de rede
dispositivo que tem acesso pela ou dispositivo de armazenamento local.
porta 445 à sua conta do Para obter uma introdução a vários
Arquivos do Azure recursos no .NET, incluindo e/s de
Não precisa gerenciar nenhum arquivo, consulte o tutorial aplicativo de
das configurações console .
administrativas do
compartilhamento de arquivo
API Q UA N DO USA R O B SERVA Ç Õ ES
Microsoft. Azure. Storage. File Seu aplicativo: Este artigo demonstra o uso de
Não é possível acessar os Microsoft.Azure.Storage.File para
arquivos do Azure usando SMB e/s de arquivo usando REST em vez de
na porta 445 devido a restrições SMB e gerenciamento do
de firewall ou ISP compartilhamento de arquivos.
Requer a funcionalidade
administrativa, como a
capacidade de definir uma cota
de compartilhamento de
arquivos ou criar uma assinatura
de acesso compartilhado
Criar o aplicativo do console e obter o assembly

No Visual Studio, crie um novo aplicativo de console do Windows. As etapas a seguir mostram como criar um
aplicativo de console no Visual Studio 2019. As etapas são semelhantes em outras versões do Visual Studio.
1. Inicie o Visual Studio e selecione Criar um projeto .
2. Em criar um novo projeto , escolha aplicativo de console (.NET Framework) para C# e, em seguida,
selecione Avançar .
3. Em configurar seu novo projeto , insira um nome para o aplicativo e selecione criar .
Você pode adicionar todos os exemplos de código neste tutorial ao Main() método do arquivo do Program.cs seu
aplicativo de console.
Você pode usar a biblioteca de cliente de armazenamento do Azure em qualquer tipo de aplicativo .NET. Esses tipos
incluem um serviço de nuvem do Azure ou aplicativo Web, e aplicativos móveis e de desktop. Neste guia, usamos
um aplicativo de console para simplificar.
Use o NuGet para instalar os pacotes necessários

Consulte estes pacotes em seu projeto para concluir este tutorial:
Armazenamento do Microsoft Azure biblioteca comum para .NET
Este pacote fornece acesso programático a recursos comuns em sua conta de armazenamento.
Armazenamento do Microsoft Azure biblioteca de BLOBs para .NET
Este pacote fornece acesso programático a recursos de BLOB em sua conta de armazenamento.
Biblioteca de arquivos Armazenamento do Microsoft Azure para .NET
Este pacote fornece acesso programático a recursos de arquivo em sua conta de armazenamento.
Microsoft Azure Configuration Manager biblioteca para .NET
Esse pacote fornece uma classe para analisar uma cadeia de conexão em um arquivo de configuração, onde
quer que seu aplicativo seja executado.
Você pode usar NuGet para obter os dois pacotes. Siga estas etapas:
1. Em Gerenciador de soluções , clique com o botão direito do mouse em seu projeto e escolha gerenciar
pacotes NuGet .
2. No Gerenciador de pacotes NuGet , selecione procurar . Em seguida, pesquise e escolha Microsoft.
Azure. Storage. blob e, em seguida, selecione instalar .
Esta etapa instala o pacote e suas dependências.
3. Pesquise e instale esses pacotes:
Microsoft. Azure. Storage. Common
Microsoft. Azure. Storage. File
Microsoft. Azure. ConfigurationManager
Salvar as credenciais da conta de armazenamento no arquivo app.

config
Em seguida, salve suas credenciais no arquivo do App.config seu projeto. Em Gerenciador de soluções , clique
App.config duas vezes e edite o arquivo para que ele seja semelhante ao exemplo a seguir. Substitua myaccount
pelo nome da conta de armazenamento mykey e pela sua chave de conta de armazenamento.
<?xml version="1.0" encoding="utf-8" ?>

<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<appSettings>
<add key="StorageConnectionString"
value="DefaultEndpointsProtocol=https;AccountName=myaccount;AccountKey=StorageAccountKeyEndingIn==" />
</appSettings>
</configuration>
NOTE
A versão mais recente do emulador de armazenamento do Azure não dá suporte aos Arquivos do Azure. Sua cadeia de
conexão deve ter como destino uma Conta de Armazenamento do Azure na nuvem para funcionar com os Arquivos do
Azure.
Adicionar diretivas using

No Gerenciador de soluções , abra o Program.cs arquivo e adicione as seguintes diretivas using à parte
superior do arquivo.
using Microsoft.Azure; // Namespace for Azure Configuration Manager

using Microsoft.Azure.Storage; // Namespace for Storage Client Library
using Microsoft.Azure.Storage.Blob; // Namespace for Azure Blobs
using Microsoft.Azure.Storage.File; // Namespace for Azure Files
A Biblioteca do Gerenciador de Configuração do Microsoft Azure para .NET fornece uma classe para analisar uma
cadeia de conexão de um arquivo de configuração. A classe CloudConfigurationManager analisa as definições de
configuração. Ele analisa as configurações para aplicativos cliente que são executados na área de trabalho, em um
dispositivo móvel, em uma máquina virtual do Azure ou em um serviço de nuvem do Azure.
Para fazer referência CloudConfigurationManager ao pacote, adicione as using seguintes diretivas:
using Microsoft.Azure; //Namespace for CloudConfigurationManager

using Microsoft.Azure.Storage;
Aqui está um exemplo que mostra como recuperar uma cadeia de conexão de um arquivo de configuração:
// Parse the connection string and return a reference to the storage account.
CloudConfigurationManager.GetSetting("StorageConnectionString"));
O uso do Gerenciador de Configurações do Azure é opcional. Você também pode usar uma API como a classe
ConfigurationManagerdo .NET Framework.
Acessar o compartilhamento de arquivos programaticamente

Em seguida, adicione o seguinte conteúdo ao Main() método, após o código mostrado acima, para recuperar a
cadeia de conexão. Esse código obtém uma referência ao arquivo que criamos anteriormente e gera seu conteúdo.
// Create a CloudFileClient object for credentialed access to Azure Files.

CloudFileClient fileClient = storageAccount.CreateCloudFileClient();
// Get a reference to the file share we created previously.

CloudFileShare share = fileClient.GetShareReference("logs");
// Ensure that the share exists.

if (share.Exists())
{
// Get a reference to the root directory for the share.
CloudFileDirectory rootDir = share.GetRootDirectoryReference();
// Get a reference to the directory we created previously.

CloudFileDirectory sampleDir = rootDir.GetDirectoryReference("CustomLogs");
// Ensure that the directory exists.

if (sampleDir.Exists())
{
// Get a reference to the file we created previously.
CloudFile file = sampleDir.GetFileReference("Log1.txt");
// Ensure that the file exists.

if (file.Exists())
{
// Write the contents of the file to the console window.
Console.WriteLine(file.DownloadTextAsync().Result);
}
}
}
Execute o aplicativo de console para ver a saída.
Definir o tamanho máximo de um compartilhamento de arquivos

A partir da versão 5. x da biblioteca de cliente do armazenamento do Azure, você pode definir a cota (tamanho
máximo) para um compartilhamento de arquivos. Você também pode verificar a quantidade de dados atualmente
armazenada no compartilhamento.
Definir a cota de um compartilhamento limita o tamanho total dos arquivos armazenados no compartilhamento.
Se o tamanho total dos arquivos no compartilhamento exceder a cota definida no compartilhamento, os clientes
não poderão aumentar o tamanho dos arquivos existentes. Os clientes não podem criar novos arquivos, a menos
que esses arquivos estejam vazios.
O exemplo a seguir mostra como verificar o uso atual de um compartilhamento e como definir a cota para o
compartilhamento.
// Parse the connection string for the storage account.
Microsoft.Azure.CloudConfigurationManager.GetSetting("StorageConnectionString"));



if (share.Exists())
{
// Check current usage stats for the share.
// Note that the ShareStats object is part of the protocol layer for the File service.
Microsoft.Azure.Storage.File.Protocol.ShareStats stats = share.GetStats();
Console.WriteLine("Current share usage: {0} GB", stats.Usage.ToString());
// Specify the maximum size of the share, in GB.

// This line sets the quota to be 10 GB greater than the current usage of the share.
share.Properties.Quota = 10 + stats.Usage;
share.SetProperties();
// Now check the quota for the share. Call FetchAttributes() to populate the share's properties.
share.FetchAttributes();
Console.WriteLine("Current share quota: {0} GB", share.Properties.Quota);
}
Gerar uma assinatura de acesso compartilhado para um arquivo ou compartilhamento de arquivos

A partir da versão 5.x da Biblioteca de Cliente do Armazenamento do Azure, você pode gerar uma SAS (assinatura
de acesso compartilhado) para um compartilhamento de arquivos ou para um arquivo individual. Você também
pode criar uma política de acesso armazenada em um compartilhamento de arquivos para gerenciar assinaturas
de acesso compartilhado. É recomendável criar uma política de acesso armazenada porque ela permite revogar a
SAS se ela for comprometida.
O exemplo a seguir cria uma política de acesso armazenada em um compartilhamento. O exemplo usa essa
política para fornecer as restrições para uma SAS em um arquivo no compartilhamento.



if (share.Exists())
{
string policyName = "sampleSharePolicy" + DateTime.UtcNow.Ticks;
// Create a new stored access policy and define its constraints.

SharedAccessFilePolicy sharedPolicy = new SharedAccessFilePolicy()
{
SharedAccessExpiryTime = DateTime.UtcNow.AddHours(24),
Permissions = SharedAccessFilePermissions.Read | SharedAccessFilePermissions.Write
};
// Get existing permissions for the share.

FileSharePermissions permissions = share.GetPermissions();
// Add the stored access policy to the share's policies. Note that each policy must have a unique name.
permissions.SharedAccessPolicies.Add(policyName, sharedPolicy);
share.SetPermissions(permissions);
// Generate a SAS for a file in the share and associate this access policy with it.
CloudFile file = sampleDir.GetFileReference("Log1.txt");
string sasToken = file.GetSharedAccessSignature(null, policyName);
Uri fileSasUri = new Uri(file.StorageUri.PrimaryUri.ToString() + sasToken);
// Create a new CloudFile object from the SAS, and write some text to the file.
CloudFile fileSas = new CloudFile(fileSasUri);
fileSas.UploadText("This write operation is authorized via SAS.");
Console.WriteLine(fileSas.DownloadText());
}
Para obter mais informações sobre como criar e usar assinaturas de acesso compartilhado, consulte como
funciona uma assinatura de acesso compartilhado.
Copiar arquivos
A partir da versão 5.x da Biblioteca de Cliente do Armazenamento do Azure, você pode copiar um arquivo em
outro arquivo, um arquivo em um blob ou um blob em um arquivo. Nas próximas seções, demonstraremos como
fazer essas operações de cópia programaticamente.
Você também pode usar AzCopy para copiar um arquivo para outro ou para copiar um blob para um arquivo ou o
contrário. Confira Introdução ao AzCopy.
NOTE
Se você estiver copiando um blob em um arquivo, ou um arquivo em um blob, use uma assinatura de acesso compartilhado
(SAS) para autorizar o acesso ao objeto de origem, mesmo se estiver copiando dentro da mesma conta de armazenamento.
Copiar um arquivo para outro arquivo

O exemplo a seguir copia um arquivo em outro arquivo no mesmo compartilhamento. Como essa operação de
cópia copia entre arquivos na mesma conta de armazenamento, você pode usar a autenticação de chave
compartilhada para fazer a cópia.




if (share.Exists())
{
// Get a reference to the directory we created previously.

// Ensure that the directory exists.

if (sampleDir.Exists())
{
// Get a reference to the file we created previously.
CloudFile sourceFile = sampleDir.GetFileReference("Log1.txt");
// Ensure that the source file exists.

if (sourceFile.Exists())
{
// Get a reference to the destination file.
CloudFile destFile = sampleDir.GetFileReference("Log1Copy.txt");
// Start the copy operation.

destFile.StartCopy(sourceFile);
// Write the contents of the destination file to the console window.

Console.WriteLine(destFile.DownloadText());
}
}
}
Copiar um arquivo em um blob

O exemplo a seguir cria um arquivo e o copia em um blob dentro da mesma conta de armazenamento. O exemplo
cria uma SAS para o arquivo de origem, que o serviço usa para autorizar o acesso ao arquivo de origem durante a
operação de cópia.

// Create a new file share, if it does not already exist.

CloudFileShare share = fileClient.GetShareReference("sample-share");
share.CreateIfNotExists();
// Create a new file in the root directory.

CloudFile sourceFile = share.GetRootDirectoryReference().GetFileReference("sample-file.txt");
sourceFile.UploadText("A sample file in the root directory.");
// Get a reference to the blob to which the file will be copied.

CloudBlobContainer container = blobClient.GetContainerReference("sample-container");
container.CreateIfNotExists();
CloudBlockBlob destBlob = container.GetBlockBlobReference("sample-blob.txt");
// Create a SAS for the file that's valid for 24 hours.

// Note that when you are copying a file to a blob, or a blob to a file, you must use a SAS
// to authorize access to the source object, even if you are copying within the same
// storage account.
string fileSas = sourceFile.GetSharedAccessSignature(new SharedAccessFilePolicy()
{
// Only read permissions are required for the source file.
Permissions = SharedAccessFilePermissions.Read,
SharedAccessExpiryTime = DateTime.UtcNow.AddHours(24)
});
// Construct the URI to the source file, including the SAS token.
Uri fileSasUri = new Uri(sourceFile.StorageUri.PrimaryUri.ToString() + fileSas);
// Copy the file to the blob.

destBlob.StartCopy(fileSasUri);
// Write the contents of the file to the console window.

Console.WriteLine("Source file contents: {0}", sourceFile.DownloadText());
Console.WriteLine("Destination blob contents: {0}", destBlob.DownloadText());
Você pode copiar um blob em um arquivo da mesma maneira. Se o objeto de origem for um blob, crie uma SAS
para autorizar o acesso ao blob durante a operação de cópia.
Instantâneos de compartilhamento
A partir da versão 8.5 da Biblioteca de Cliente do Armazenamento do Microsoft Azure, você pode criar um
instantâneo de compartilhamento. Também pode listar ou procurar os instantâneos de compartilhamento e excluir
os instantâneos de compartilhamento. Instantâneos de compartilhamentos são somente leitura, portanto,
nenhuma operação de gravação é permitida em instantâneos de compartilhamento.
Criar instantâneos de compartilhamento
O exemplo a seguir cria um instantâneo de compartilhamento de arquivos.
storageAccount = CloudStorageAccount.Parse(ConnectionString);
fClient = storageAccount.CreateCloudFileClient();
string baseShareName = "myazurefileshare";
CloudFileShare myShare = fClient.GetShareReference(baseShareName);
var snapshotShare = myShare.Snapshot();
O exemplo a seguir lista os instantâneos de compartilhamento em um compartilhamento.
var shares = fClient.ListShares(baseShareName, ShareListingDetails.All);
Procurar arquivos e diretórios nos instantâneos de compartilhamento

O exemplo a seguir procura arquivos e diretórios nos instantâneos de compartilhamento.
CloudFileShare mySnapshot = fClient.GetShareReference(baseShareName, snapshotTime);

var rootDirectory = mySnapshot.GetRootDirectoryReference();
var items = rootDirectory.ListFilesAndDirectories();
Listar compartilhamentos e instantâneos de compartilhamento e restaurar arquivos ou compartilhamentos de

arquivos dos instantâneos de compartilhamento
Tirar um instantâneo de um compartilhamento de arquivos permite a recuperação de arquivos individuais ou de
todo o compartilhamento de arquivo no futuro.
Você pode restaurar um arquivo de um instantâneo de compartilhamento de arquivo consultando os instantâneos
de compartilhamento de um compartilhamento de arquivos. Em seguida, você pode recuperar um arquivo que
pertence a um instantâneo de compartilhamento específico. Use essa versão para ler e comparar diretamente ou
para restaurar o.
CloudFileShare liveShare = fClient.GetShareReference(baseShareName);

var rootDirOfliveShare = liveShare.GetRootDirectoryReference();
var dirInliveShare = rootDirOfliveShare.GetDirectoryReference(dirName);
var fileInliveShare = dirInliveShare.GetFileReference(fileName);
CloudFileShare snapshot = fClient.GetShareReference(baseShareName, snapshotTime);

var rootDirOfSnapshot = snapshot.GetRootDirectoryReference();
var dirInSnapshot = rootDirOfSnapshot.GetDirectoryReference(dirName);
var fileInSnapshot = dir1InSnapshot.GetFileReference(fileName);
string sasContainerToken = string.Empty;

SharedAccessFilePolicy sasConstraints = new SharedAccessFilePolicy();
sasConstraints.SharedAccessExpiryTime = DateTime.UtcNow.AddHours(24);
sasConstraints.Permissions = SharedAccessFilePermissions.Read;
//Generate the shared access signature on the container, setting the constraints directly on the signature.
sasContainerToken = fileInSnapshot.GetSharedAccessSignature(sasConstraints);
string sourceUri = (fileInSnapshot.Uri.ToString() + sasContainerToken + "&" +

fileInSnapshot.SnapshotTime.ToString()); ;
fileInliveShare.StartCopyAsync(new Uri(sourceUri));
Excluir instantâneos de compartilhamento

O exemplo a seguir exclui um instantâneo de compartilhamento de arquivos.
CloudFileShare mySnapshot = fClient.GetShareReference(baseShareName, snapshotTime); mySnapshot.Delete(null,

null, null);
Solucionar problemas de arquivos do Azure usando métricas

A Análise de Armazenamento do Azure agora dá suporte a métricas para os Arquivos do Azure. Com dados de
métricas, você pode rastrear solicitações e diagnosticar problemas.
Você pode habilitar as métricas para arquivos do Azure do portal do Azure. Você também pode habilitar as
métricas programaticamente chamando a operação definir propriedades do serviço de arquivo com a API REST ou
uma de suas analogias na biblioteca do cliente de armazenamento.
O exemplo de código a seguir mostra como usar a Biblioteca de Cliente de Armazenamento para .NET para
habilitar as métricas para os Arquivos do Azure.
Primeiro, adicione as seguintes using diretivas ao seu Program.cs arquivo, juntamente com aquelas que você
adicionou acima:
using Microsoft.Azure.Storage.File.Protocol;
using Microsoft.Azure.Storage.Shared.Protocol;
Embora os BLOBs do Azure, as tabelas do Azure e as filas do ServiceProperties Azure usem o

Microsoft.Azure.Storage.Shared.Protocol tipo compartilhado no namespace, os arquivos do Azure usam
FileServiceProperties seu próprio tipo Microsoft.Azure.Storage.File.Protocol , o tipo no namespace. Você deve
referenciar ambos os namespaces do seu código, no entanto, para que o código a seguir seja compilado.
// Parse your storage connection string from your application's configuration file.
// Create the File service client.
// Set metrics properties for File service.

// Note that the File service currently uses its own service properties type,
// available in the Microsoft.Azure.Storage.File.Protocol namespace.
fileClient.SetServiceProperties(new FileServiceProperties()
{
// Set hour metrics
HourMetrics = new MetricsProperties()
{
MetricsLevel = MetricsLevel.ServiceAndApi,
RetentionDays = 14,
Version = "1.0"
},
// Set minute metrics
MinuteMetrics = new MetricsProperties()
{
MetricsLevel = MetricsLevel.ServiceAndApi,
RetentionDays = 7,
Version = "1.0"
}
});
// Read the metrics properties we just set.

FileServiceProperties serviceProperties = fileClient.GetServiceProperties();
Console.WriteLine("Hour metrics:");
Console.WriteLine(serviceProperties.HourMetrics.MetricsLevel);
Console.WriteLine(serviceProperties.HourMetrics.RetentionDays);
Console.WriteLine(serviceProperties.HourMetrics.Version);
Console.WriteLine();
Console.WriteLine("Minute metrics:");
Console.WriteLine(serviceProperties.MinuteMetrics.MetricsLevel);
Console.WriteLine(serviceProperties.MinuteMetrics.RetentionDays);
Console.WriteLine(serviceProperties.MinuteMetrics.Version);
Se você encontrar algum problema, poderá consultar solucionar problemas de arquivos do Azure no Windows.
Próximas etapas
Para obter mais informações sobre os arquivos do Azure, consulte os seguintes recursos:
Artigos e vídeos conceituais
Arquivos do Azure: um sistema de arquivos SMB de nuvem ininterrupta para Windows e Linux
Suporte de ferramentas para o armazenamento de arquivos
Introdução ao AzCopy
Solucionar problemas de Arquivos do Azure no Windows
Referência
APIs do Armazenamento do Azure para .NET
API REST do serviço de arquivo
Postagens no blog
Armazenamento de arquivos do Azure, agora disponível para o público geral
Dentro do armazenamento de arquivos do Azure
Introdução ao serviço de arquivos de Microsoft Azure
Persistindo conexões para arquivos do Microsoft Azure
Java
TIP
Confira o repositório de exemplos de código do Armazenamento do Azure
Para exemplos de código fácil de usar ponta a ponta do Armazenamento do Azure que você pode baixar e executar, consulte
nossa lista de Exemplos de Armazenamento do Azure.
Sobre este tutorial

Este tutorial demonstrará as noções básicas de usar Java para desenvolver aplicativos ou serviços que usam o
Arquivos do Azure para armazenar dados de arquivo. Neste tutorial, criaremos um aplicativo de console e
mostraremos como executar ações básicas com arquivos Java e Azure:
Criar e excluir Compartilhamentos de Arquivos do Azure
Criar e excluir diretórios
Enumerar arquivos e diretórios em um Compartilhamento de Arquivos do Azure
Carregar, baixar e excluir um arquivo
NOTE
Como os Arquivos do Azure podem ser acessados por meio do SMB, é possível gravação de aplicativos que acessam o
compartilhamento de arquivos do Azure usando as classes de E / S padrão do Java. Este artigo descreverá como criar
aplicativos que usam o SDK do Java do Armazenamento do Azure, que usa a API REST do Arquivos do Azure para se
comunicar com o Arquivos do Azure.
Criar um aplicativo Java

Para construir as amostras, você precisará do Java Development Kit (JDK) e do Azure Storage SDK para Java . Você
também deverá ter criado uma conta de armazenamento do Azure.
Configurar seu aplicativo para usar os Arquivos do Azure

Para usar as APIs de armazenamento do Azure, adicione a instrução a seguir à parte superior do arquivo Java do
qual você pretende acessar o serviço de armazenamento.
// Include the following imports to use blob APIs.

import com.microsoft.azure.storage.*;
import com.microsoft.azure.storage.file.*;
Configurar uma cadeia de conexão de armazenamento do Azure

Para usar o Arquivos do Azure, será necessário se conectar à sua conta de armazenamento do Azure. A primeira
etapa é configurar uma cadeia de conexão que usaremos para nos conectar à sua conta de armazenamento.
Vamos definir uma variável estática para fazer isso.
// Configure the connection-string with your values

public static final String storageConnectionString =
"DefaultEndpointsProtocol=http;" +
"AccountName=your_storage_account_name;" +
"AccountKey=your_storage_account_key";
NOTE
Substitua nome_da_sua_conta_de_armazenamento e chave_da_sua_conta_de_armazenamento pelos valores reais da sua
Conectar-se a uma conta de armazenamento do Azure

Para se conectar à sua conta de armazenamento, você precisa usar o objeto CloudStorageAccount , passando
uma cadeia de conexão para seu método de análise .
// Use the CloudStorageAccount object to connect to your storage account

try {
CloudStorageAccount storageAccount = CloudStorageAccount.parse(storageConnectionString);
} catch (InvalidKeyException invalidKey) {
// Handle the exception
}
CloudStorageAccount.parse gera uma InvalidKeyException; portanto, você precisará colocá-lo dentro de um

bloco try/catch.

Todos os arquivos e diretórios do Arquivos do Azure residem em um contêiner chamado Compar tilhamento .
Sua conta de armazenamento pode a quantidade de compartilhamentos que a capacidade da conta permitir. Para
obter acesso a um compartilhamento e seu conteúdo, é necessário usar um cliente de Arquivos do Azure.
// Create the Azure Files client.

CloudFileClient fileClient = storageAccount.createCloudFileClient();
Usando o cliente do Arquivos do Azure, será possível obter uma referência a um compartilhamento.
// Get a reference to the file share

CloudFileShare share = fileClient.getShareReference("sampleshare");
Para realmente criar o compartilhamento, use o método createIfNotExists do objeto CloudFileShare.
if (share.createIfNotExists()) {
System.out.println("New share created");
}
Neste ponto, compar tilhar contém uma referência a um compartilhamento chamado sampleshare .
Excluir um Compartilhamento de Arquivos do Azure

Para excluir um compartilhamento deve-se chamar o método deleteIfExists em um objeto CloudFileShare. O
código fornecido a seguir é um exemplo de como fazer isso.
try
{
// Retrieve storage account from connection-string.
CloudStorageAccount storageAccount = CloudStorageAccount.parse(storageConnectionString);
// Create the file client.

CloudFileClient fileClient = storageAccount.createCloudFileClient();

CloudFileShare share = fileClient.getShareReference("sampleshare");
if (share.deleteIfExists()) {
System.out.println("sampleshare deleted");
}
} catch (Exception e) {
e.printStackTrace();
}
Criar um diretório
Você também pode organizar o armazenamento colocando arquivos em subdiretórios em vez de manter todos
eles no diretório raiz. Os Arquivos do Azure permitem que você crie quantos diretórios a conta permitir. O código
abaixo irá criar um subdiretório chamado ** sampledir ** sob o diretório raiz.
//Get a reference to the root directory for the share.

CloudFileDirectory rootDir = share.getRootDirectoryReference();
//Get a reference to the sampledir directory

CloudFileDirectory sampleDir = rootDir.getDirectoryReference("sampledir");
if (sampleDir.createIfNotExists()) {
System.out.println("sampledir created");
} else {
System.out.println("sampledir already exists");
}
Excluir um diretório
A exclusão de um diretório é uma tarefa simples, embora deva ser observado que você não pode excluir um
diretório que ainda contenha arquivos ou outros diretórios.

// Get a reference to the directory you want to delete

CloudFileDirectory containerDir = rootDir.getDirectoryReference("sampledir");
// Delete the directory

if ( containerDir.deleteIfExists() ) {
System.out.println("Directory deleted");
}
Enumerar arquivos e diretórios em um Compartilhamento de Arquivos

do Azure
A lista de arquivos e diretórios em um compartilhamento pode ser obtida facilmente chamando
listFilesAndDirectories em uma referência CloudFileDirectory. O método retorna uma lista de objetos
ListFileItem nos quais você pode iterar. Como exemplo, o código a seguir lista os arquivos e diretórios contidos no
diretório raiz.

for ( ListFileItem fileItem : rootDir.listFilesAndDirectories() ) {

System.out.println(fileItem.getUri());
}
Carregar um arquivo
Nesta seção, você aprenderá a carregar um arquivo do armazenamento local para o diretório raiz de um
compartilhamento.
A primeira etapa do carregamento de um arquivo é obter uma referência para o diretório onde ele deve residir.
Para isso, você deve chamar o método getRootDirector yReference do objeto de compartilhamento.

Agora que você tem uma referência para o diretório raiz do compartilhamento, pode carregar um arquivo usando
o código a seguir.
// Define the path to a local file.

final String filePath = "C:\\temp\\Readme.txt";
CloudFile cloudFile = rootDir.getFileReference("Readme.txt");

cloudFile.uploadFromFile(filePath);
Baixar um arquivo
Uma das operações mais frequentes executadas no Arquivos do Azure é baixar arquivos. No exemplo a seguir, o
código baixa o arquivo SampleFile.txt e exibe seu conteúdo.

//Get a reference to the directory that contains the file

CloudFileDirectory sampleDir = rootDir.getDirectoryReference("sampledir");
//Get a reference to the file you want to download

CloudFile file = sampleDir.getFileReference("SampleFile.txt");
//Write the contents of the file to the console.

System.out.println(file.downloadText());
Excluir um arquivo
Outra operação comum do Arquivos do Azure é a exclusão de arquivos. O código a seguir exclui um arquivo
chamado SampleFile.txt armazenado em um diretório chamado sampledir .
// Get a reference to the directory where the file to be deleted is in

CloudFileDirectory containerDir = rootDir.getDirectoryReference("sampledir");
String filename = "SampleFile.txt"

CloudFile file;
file = containerDir.getFileReference(filename)
if ( file.deleteIfExists() ) {
System.out.println(filename + " was deleted");
}
Próximas etapas
Se você quiser saber mais sobre outras APIs de armazenamento do Azure, siga estes links.
Azure para desenvolvedores Java/)
Microsoft Azure Storage SDK for Java (SDK de Armazenamento do Microsoft Azure para Java)
SDK de Armazenamento do Azure para Android
Referência de SDK do Cliente de Armazenamento do Azure
Azure Storage Services REST API Reference (Referência de API REST dos Serviços de Armazenamento do Azure)
Blog da equipe de Armazenamento do Azure
Transferir dados com o Utilitário da Linha de Comando AzCopy
Solução de problemas de Arquivos do Azure – Windows
C++
TIP
Experimente usar o Gerenciador de Armazenamento do Microsoft Azure
O Gerenciador de Armazenamento do Microsoft Azure é um aplicativo autônomo e gratuito da Microsoft que possibilita o
trabalho visual com os dados do Armazenamento do Azure no Windows, MacOS e Linux.
Sobre este tutorial

Neste tutorial, você aprenderá a executar operações básicas no Arquivos do Azure. Por meio de exemplos escritos
em C++, você aprenderá a criar compartilhamentos e diretórios, carregar, listar e excluir arquivos. Se você for
novo no Arquivos do Azure, será muito útil percorrer os conceitos nas seções a seguir para entender os exemplos.
Criar e excluir Compartilhamentos de Arquivos do Azure
Criar e excluir diretórios
Definir a cota (tamanho máximo) para um compartilhamento de arquivos do Azure
Crie uma assinatura de acesso compartilhado (chave SAS) para um arquivo que usa uma política de acesso
compartilhado definida no compartilhamento.
NOTE
Como o Arquivos do Azure pode ser acessado via SMB, é possível criar aplicativos simples que acessam o Compartilhamento
de Arquivos do Azure usando as classes e funções padrão de E/S do C++. Este artigo descreverá como criar aplicativos que
usam o SDK do Armazenamento do Azure C++, que usa a API REST de Arquivo para se comunicar com o Arquivos do
Azure.
Criar um aplicativo em C++

Para criar os exemplos, você precisará instalar a Biblioteca do Cliente de Armazenamento do Azure 2.4.0 para C++.
Você também deverá ter criado uma conta de armazenamento do Azure.
Para instalar o Cliente de Armazenamento do Azure 2.4.0 para C++, você poderá usar os seguintes métodos:
Linux: siga as instruções dadas na página README da Biblioteca do Cliente de Armazenamento do Azure para
C++ .
Windows: no Visual Studio, clique em Ferramentas > Gerenciador de Pacotes do NuGet > Console do
Gerenciador de Pacotes . Digite o seguinte comando no console do Gerenciador de Pacotes do NuGet e
pressione ENTER .
Install-Package wastorage
Adicione as seguintes instruções include na parte superior do arquivo de origem C++ no qual você deseja
manipular Arquivos do Azure:
#include <was/storage_account.h>
#include <was/file.h>
Configurar uma cadeia de conexão de armazenamento do Azure

Para usar o armazenamento de arquivos, será necessário se conectar à sua conta de armazenamento do Azure. A
primeira etapa é configurar uma cadeia de conexão que usaremos para nos conectar à sua conta de
armazenamento. Vamos definir uma variável estática para fazer isso.
// Define the connection-string with your values.

const utility::string_t
storage_connection_string(U("DefaultEndpointsProtocol=https;AccountName=your_storage_account;AccountKey=your_s
torage_account_key"));
Conectar-se a uma conta de armazenamento do Azure

Você pode usar a classe cloud_storage_account para representar as informações da conta de armazenamento.
Para recuperar as informações da conta de armazenamento na cadeia de conexão de armazenamento, você pode
usar o método Analisar .
// Retrieve storage account from connection string.

azure::storage::cloud_storage_account storage_account =
azure::storage::cloud_storage_account::parse(storage_connection_string);

Todos os arquivos e diretórios em um compartilhamento de Arquivos do Azure residem em um contêiner
chamado Compar tilhamento . Sua conta de armazenamento pode a quantidade de compartilhamentos que a
capacidade da conta permitir. Para obter acesso a um compartilhamento e seu conteúdo, é necessário usar um
cliente de Arquivos do Azure.
// Create the Azure Files client.

azure::storage::cloud_file_client file_client =
storage_account.create_cloud_file_client();
Usando o cliente do Arquivos do Azure, será possível obter uma referência a um compartilhamento.

azure::storage::cloud_file_share share =
file_client.get_share_reference(_XPLATSTR("my-sample-share"));
Para criar o compartilhamento, use o método create_if_not_exists do objeto cloud_file_share .
if (share.create_if_not_exists()) {
std::wcout << U("New share created") << std::endl;
}
Neste ponto, compar tilhar contém uma referência a um compartilhamento chamado my-sample-share .
Excluir um Compartilhamento de Arquivos do Azure

A exclusão de um compartilhamento é feita chamando o método delete_if_exists em um objeto cloud_file_share.
O código fornecido a seguir é um exemplo de como fazer isso.
// Get a reference to the share.

// delete the share if exists

share.delete_share_if_exists();
Criar um diretório
Também é possível organizar o armazenamento colocando arquivos em subdiretórios em vez de manter todos
a seguir criará um diretório chamado my-sample-director y no diretório raiz, bem como um subdiretório
nomeado my-sample-subdirector y .
// Retrieve a reference to a directory

azure::storage::cloud_file_directory directory = share.get_directory_reference(_XPLATSTR("my-sample-
directory"));
// Return value is true if the share did not exist and was successfully created.
directory.create_if_not_exists();
// Create a subdirectory.
azure::storage::cloud_file_directory subdirectory =
directory.get_subdirectory_reference(_XPLATSTR("my-sample-subdirectory"));
subdirectory.create_if_not_exists();
Excluir um diretório
Excluir um diretório é uma tarefa simples, embora deva-se observar que não é possível excluir um diretório que
ainda contenha arquivos ou outros diretórios.

// Get a reference to the directory.

azure::storage::cloud_file_directory directory =
share.get_directory_reference(_XPLATSTR("my-sample-directory"));
// Get a reference to the subdirectory you want to delete.

azure::storage::cloud_file_directory sub_directory =
directory.get_subdirectory_reference(_XPLATSTR("my-sample-subdirectory"));
// Delete the subdirectory and the sample directory.

sub_directory.delete_directory_if_exists();
directory.delete_directory_if_exists();

do Azure
A obtenção de uma lista de arquivos e diretórios em um compartilhamento é facilmente feita chamando
list_files_and_directories em uma referência de cloud_file_director y . Para acessar o conjunto avançado de
propriedades e métodos para um list_file_and_director y_item retornado, você deverá chamar o método
list_file_and_director y_item.as_file a fim de obter um objeto cloud_file ou o método
list_file_and_director y_item.as_director y a fim de obter um objeto cloud_file_director y .
O código a seguir demonstra como recuperar e apresentar a saída do URI de cada item no diretório raiz do
compartilhamento.

azure::storage::cloud_file_directory root_dir =
share.get_root_directory_reference();
// Output URI of each item.

azure::storage::list_file_and_directory_result_iterator end_of_results;
for (auto it = directory.list_files_and_directories(); it != end_of_results; ++it)

{
if(it->is_directory())
{
ucout << "Directory: " << it->as_directory().uri().primary_uri().to_string() << std::endl;
}
else if (it->is_file())
{
ucout << "File: " << it->as_file().uri().primary_uri().to_string() << std::endl;
}
}
Carregar um arquivo
No mínimo, um compartilhamento de Arquivos do Azure contém um diretório raiz no qual os arquivos podem
residir. Nesta seção, você aprenderá a carregar um arquivo do armazenamento local para o diretório raiz de um
compartilhamento.
A primeira etapa do carregamento de um arquivo é obter uma referência para o diretório onde ele deve residir.
Você faz isso chamando o método get_root_director y_reference do objeto de compartilhamento.

azure::storage::cloud_file_directory root_dir = share.get_root_directory_reference();
Agora que você tem uma referência para o diretório raiz do compartilhamento, pode carregar um arquivo nele.
Este exemplo carrega de um arquivo, de um texto e de um fluxo.
// Upload a file from a stream.
concurrency::streams::istream input_stream =
concurrency::streams::file_stream<uint8_t>::open_istream(_XPLATSTR("DataFile.txt")).get();
azure::storage::cloud_file file1 =
root_dir.get_file_reference(_XPLATSTR("my-sample-file-1"));
file1.upload_from_stream(input_stream);
// Upload some files from text.

file2.upload_text(_XPLATSTR("more text"));
// Upload a file from a file.

file4.upload_from_file(_XPLATSTR("DataFile.txt"));
Baixar um arquivo
Para baixar arquivos, primeiro recupere uma referência de arquivo e, em seguida, chame o método
download_to_stream para transferir o conteúdo do arquivo para um objeto de fluxo, que você pode persistir em
um arquivo local. Como alternativa, você pode usar o método download_to_file para baixar o conteúdo de um
arquivo em um arquivo local. Você pode usar o método download_text para baixar o conteúdo de um arquivo
como uma cadeia de texto.
O exemplo a seguir usa os métodos download_to_stream e download_text para demonstrar o download dos
arquivos, que foram criados nas seções anteriores.
// Download as text
azure::storage::cloud_file text_file =
utility::string_t text = text_file.download_text();
ucout << "File Text: " << text << std::endl;
// Download as a stream.
azure::storage::cloud_file stream_file =
concurrency::streams::container_buffer<std::vector<uint8_t>> buffer;
concurrency::streams::ostream output_stream(buffer);
stream_file.download_to_stream(output_stream);
std::ofstream outfile("DownloadFile.txt", std::ofstream::binary);
std::vector<unsigned char>& data = buffer.collection();
outfile.write((char *)&data[0], buffer.size());
outfile.close();
Excluir um arquivo
Outra operação comum do Arquivos do Azure é a exclusão de arquivos. O código a seguir exclui um arquivo
chamado my-sample-file-3 armazenado no diretório raiz.
azure::storage::cloud_file file =
file.delete_file_if_exists();
Definir a cota (tamanho máximo) para um compartilhamento de

arquivos do Azure
Você pode definir a cota (ou o tamanho máximo) de um compartilhamento de arquivo em gigabytes. Você
também pode verificar a quantidade de dados atualmente armazenada no compartilhamento.
Ao definir a cota para um compartilhamento, você pode limitar o tamanho total dos arquivos armazenados no
compartilhamento. Se o tamanho total dos arquivos no compartilhamento ultrapassar a cota definida no
compartilhamento, os clientes não poderão aumentar o tamanho dos arquivos existentes ou criar novos arquivos,
a menos que eles estejam vazios.
O exemplo a seguir mostra como verificar o uso atual de um compartilhamento e como definir a cota para o
compartilhamento.

// Create the file client.


if (share.exists())
{
std::cout << "Current share usage: " << share.download_share_usage() << "/" << share.properties().quota();
//This line sets the quota to 2560GB

share.resize(2560);
std::cout << "Quota increased: " << share.download_share_usage() << "/" << share.properties().quota();
Gerar uma assinatura de acesso compartilhado para um arquivo ou

Você pode gerar uma SAS (assinatura de acesso compartilhado) para um compartilhamento de arquivo ou para
um arquivo individual. Você também pode criar uma política de acesso compartilhado em um compartilhamento
de arquivos para gerenciar assinaturas de acesso compartilhado. Recomendamos a criação de uma política de
acesso compartilhado, pois ela fornece um meio de revogar o SAS se ele for comprometido.
O exemplo a seguir cria uma política de acesso compartilhado em um compartilhamento e, em seguida, usa essa
política para fornecer as restrições a um SAS em um arquivo no compartilhamento.
// Create the file client and get a reference to the share

if (share.exists())
{
// Create and assign a policy
utility::string_t policy_name = _XPLATSTR("sampleSharePolicy");
azure::storage::file_shared_access_policy sharedPolicy =
azure::storage::file_shared_access_policy();
//set permissions to expire in 90 minutes

sharedPolicy.set_expiry(utility::datetime::utc_now() +
utility::datetime::from_minutes(90));
//give read and write permissions

sharedPolicy.set_permissions(azure::storage::file_shared_access_policy::permissions::write |
azure::storage::file_shared_access_policy::permissions::read);
//set permissions for the share

azure::storage::file_share_permissions permissions;
//retrieve the current list of shared access policies

azure::storage::shared_access_policies<azure::storage::file_shared_access_policy> policies;
//add the new shared policy

policies.insert(std::make_pair(policy_name, sharedPolicy));
//save the updated policy list

permissions.set_policies(policies);
share.upload_permissions(permissions);
//Retrieve the root directory and file references

azure::storage::cloud_file file =
// Generate a SAS for a file in the share

// and associate this access policy with it.
utility::string_t sas_token = file.get_shared_access_signature(sharedPolicy);
// Create a new CloudFile object from the SAS, and write some text to the file.
azure::storage::cloud_file
file_with_sas(azure::storage::storage_credentials(sas_token).transform_uri(file.uri().primary_uri()));
utility::string_t text = _XPLATSTR("My sample content");
file_with_sas.upload_text(text);
//Download and print URL with SAS.

utility::string_t downloaded_text = file_with_sas.download_text();
ucout << downloaded_text << std::endl;
ucout <<
azure::storage::storage_credentials(sas_token).transform_uri(file.uri().primary_uri()).to_string() <<
std::endl;
}
Próximas etapas
Para saber mais sobre o Armazenamento do Azure, explore estes recursos:
Biblioteca do Cliente de Armazenamento para C++
Exemplos do Serviço de Arquivo de Armazenamento do Microsoft Azure em C++
Gerenciador de Armazenamento do Azure
Documentação do armazenamento do Azure
Python
TIP
Experimente usar o Gerenciador de Armazenamento do Microsoft Azure
O Gerenciador de Armazenamento do Microsoft Azure é um aplicativo autônomo e gratuito da Microsoft que possibilita o
trabalho visual com os dados do Armazenamento do Azure no Windows, MacOS e Linux.
Este tutorial demonstrará as noções básicas do uso do Python para desenvolver aplicativos ou serviços que usam
os Arquivos do Azure para armazenar dados de arquivo. Neste tutorial, criaremos um aplicativo de console
simples e mostraremos como executar ações básicas com Python e os Arquivos do Azure:
Criar Compartilhamentos de Arquivos do Azure
Criar diretórios
NOTE
Como os Arquivos do Azure podem ser acessados via SMB, é possível criar aplicativos simples que acessam o
Compartilhamento de Arquivos do Azure usando as classes e funções padrão de E/S do Python. Este artigo descreverá
como criar aplicativos que usam o SDK do Python do Armazenamento do Azure, que usa a API REST dos Arquivos do Azure
para se comunicar com os Arquivos do Azure.
Baixar e instalar o SDK do Armazenamento do Azure para Python

O SDK do Armazenamento do Azure para Python requer o Python 2.7, 3.3, 3.4, 3.5 ou 3.6.
Instalar por meio de PyPi

Para instalar por meio do Índice de Pacote do Python (PyPI), digite:
pip install azure-storage-file
NOTE
Se você estiver fazendo upgrade do SDK de Armazenamento do Azure para Python versão 0.36 ou anterior, desinstale o
SDK mais antigo usando pip uninstall azure-storage antes de instalar o pacote mais recente.
Para métodos de instalação alternativos, visite o SDK do Armazenamento do Microsoft Azure para Python no
GitHub.
Visualizar o aplicativo de exemplo

f para exibir e executar um aplicativo de exemplo que mostra como usar o Python com os arquivos do Azure,
consulte armazenamento do Azure: introdução com arquivos do Azure em Python.
Para executar o aplicativo de exemplo, verifique se você instalou os pacotes azure-storage-file e
azure-storage-common .

Adicione o seguinte próximo à parte superior de qualquer arquivo de origem Python no qual você deseja acessar
o Armazenamento do Azure com programação.
from azure.storage.file import FileService
Configurar uma conexão com os Arquivos do Azure

O objeto FileService permite que você trabalhe com compartilhamentos, diretórios e arquivos. O código a seguir
cria um objeto FileService usando o nome da conta de armazenamento e a chave de conta. Substitua
<myaccount> e <mykey> pelo nome e pela chave da sua conta.
file_service = FileService(account_name='myaccount', account_key='mykey')

No exemplo de código a seguir, é possível usar um objeto FileService para criar o compartilhamento, se ele não
existir.
file_service.create_share('myshare')
Criar um diretório
Você também pode organizar o armazenamento colocando arquivos em subdiretórios em vez de manter todos
a seguir criará um subdiretório chamado SampleDir no diretório raiz.
file_service.create_directory('myshare', 'sampledir')

do Azure
Para listar os arquivos e diretórios em um compartilhamento, use o método list_directories_and_files . Esse
método retorna um gerador. O código a seguir produz o nome de cada arquivo e diretório em um
compartilhamento para o console.
generator = file_service.list_directories_and_files('myshare')
for file_or_dir in generator:
print(file_or_dir.name)
Carregar um arquivo
Um Compartilhamento de Arquivos do Azure contém, no mínimo, um diretório raiz em que os arquivos podem
residir. Nesta seção, você aprenderá a carregar um arquivo do armazenamento local para o diretório raiz de um
compartilhamento.
Para criar um arquivo e carregar dados, use os métodos create_file_from_path , create_file_from_stream ,
create_file_from_bytes ou create_file_from_text . Esses são métodos de alto nível que realizam a separação por
partes necessária quando o tamanho do arquivo excede 64 MB.
create_file_from_path carrega o conteúdo de um arquivo do caminho especificado e create_file_from_stream
carrega o conteúdo de um arquivo/fluxo já aberto. create_file_from_bytes carrega uma matriz de bytes e
create_file_from_text carrega o valor do texto especificado usando a codificação especificada (padronizada para
UTF-8).
O exemplo a seguir carrega o conteúdo do arquivo sunset.png no arquivo myfile .
from azure.storage.file import ContentSettings

file_service.create_file_from_path(
'myshare',
None, # We want to create this blob in the root directory, so we specify None for the directory_name
'myfile',
'sunset.png',
content_settings=ContentSettings(content_type='image/png'))
Baixar um arquivo
Para baixar dados de um arquivo, use get_file_to_path , get_file_to_stream , get_file_to_bytes ou
get_file_to_text . Esses são métodos de alto nível que realizam a separação por partes necessária quando o
tamanho do arquivo excede 64 MB.
O exemplo a seguir demonstra como usar get_file_to_path para baixar o conteúdo do arquivo myfile e
armazená-lo no arquivo out-sunset.png .
file_service.get_file_to_path('myshare', None, 'myfile', 'out-sunset.png')
Excluir um arquivo
Por fim, para excluir um arquivo, chame delete_file .
file_service.delete_file('myshare', None, 'myfile')
Criar instantâneo de compartilhamento

Você pode criar uma cópia de ponto no tempo do seu compartilhamento de arquivo inteiro.
snapshot = file_service.snapshot_share(share_name)
snapshot_id = snapshot.snapshot
Criar instantâneo de compar tilhamento com metadados
metadata = {"foo": "bar"}

snapshot = file_service.snapshot_share(share_name, metadata=metadata)
Listar compartilhamentos e instantâneos
Você pode listar todos os instantâneos para um determinado compartilhamento.
shares = list(file_service.list_shares(include_snapshots=True))
Procurar instantâneo de compartilhamento

Você pode procurar o conteúdo de cada instantâneo de compartilhamento para recuperar arquivos e diretórios
desse ponto no tempo.
directories_and_files = list(
file_service.list_directories_and_files(share_name, snapshot=snapshot_id))
Obter arquivo de instantâneo de compartilhamento

Você pode baixar um arquivo de um instantâneo de compartilhamento para seu cenário de restauração.
with open(FILE_PATH, 'wb') as stream:

file = file_service.get_file_to_stream(
share_name, directory_name, file_name, stream, snapshot=snapshot_id)
Excluir um único instantâneo de compartilhamento

Você pode excluir um único instantâneo de compartilhamento.
file_service.delete_share(share_name, snapshot=snapshot_id)
Excluir compartilhamento quando existem instantâneos de

compartilhamento
Um compartilhamento que contém instantâneos não pode ser excluído, a menos que todos os instantâneos sejam
excluídos primeiro.
file_service.delete_share(share_name, delete_snapshots=DeleteSnapshot.Include)
Próximas etapas
Agora que você aprendeu como manipular s Arquivos do Azure com o Python, siga estes links para saber mais.
Centro de desenvolvedores do Python
Azure Storage Services REST API Reference (Referência de API REST dos Serviços de Armazenamento do Azure)
SDK do Armazenamento do Microsoft Azure para Python
Determinar qual modelo de chave de criptografia de
armazenamento do Azure está em uso para a conta
de armazenamento
Os dados em sua conta de armazenamento são automaticamente criptografados pelo armazenamento do Azure. A
criptografia de armazenamento do Azure oferece duas opções para gerenciar chaves de criptografia no nível da
conta de armazenamento:
Chaves gerenciadas pela Microsoft. Por padrão, a Microsoft gerencia as chaves usadas para criptografar
sua conta de armazenamento.
Chaves gerenciadas pelo cliente. Opcionalmente, você pode optar por gerenciar chaves de criptografia para
sua conta de armazenamento. As chaves gerenciadas pelo cliente devem ser armazenadas em Azure Key Vault.
Além disso, você pode fornecer uma chave de criptografia no nível de uma solicitação individual para algumas
operações de armazenamento de BLOBs. Quando uma chave de criptografia é especificada na solicitação, essa
chave substitui a chave de criptografia que está ativa na conta de armazenamento. Para obter mais informações,
consulte especificar uma chave fornecida pelo cliente em uma solicitação para o armazenamento de BLOBs.
Para obter mais informações sobre chaves de criptografia, consulte criptografia de armazenamento do Azure para
dados em repouso.
Verificar o modelo de chave de criptografia para a conta de

armazenamento
Para determinar se uma conta de armazenamento está usando chaves gerenciadas pela Microsoft ou chaves
gerenciadas pelo cliente para criptografia, use uma das abordagens a seguir.
Azure portal
PowerShell
CLI do Azure
Para verificar o modelo de criptografia para a conta de armazenamento usando o portal do Azure, siga estas
etapas:
1. No portal do Azure, navegue até sua conta de armazenamento.
2. Selecione a configuração de criptografia e anote a configuração.
A imagem a seguir mostra uma conta de armazenamento criptografada com chaves gerenciadas pela Microsoft:
E a imagem a seguir mostra uma conta de armazenamento criptografada com chaves gerenciadas pelo cliente:
Próximas etapas
Usar chaves gerenciadas pelo cliente com Azure Key Vault para gerenciar a criptografia de armazenamento do
Azure
Configurar chaves gerenciadas pelo cliente com o
Azure Key Vault usando o portal do Azure
O armazenamento do Azure criptografa todos os dados em uma conta de armazenamento em repouso. Por
padrão, os dados são criptografados com chaves gerenciadas pela Microsoft. Para obter controle adicional sobre
as chaves de criptografia, você pode fornecer chaves gerenciadas pelo cliente para usar para criptografia de dados
de BLOB e arquivo.
As chaves gerenciadas pelo cliente devem ser armazenadas em um Azure Key Vault. Você pode criar suas próprias
de armazenamento e o cofre de chaves devem estar na mesma região, mas podem estar em assinaturas
diferentes. Para obter mais informações sobre criptografia de armazenamento do Azure e gerenciamento de
chaves, consulte criptografia de armazenamento do Azure para dados em repouso. Para obter mais informações
sobre Azure Key Vault, consulte o que é Azure Key Vault?
Este artigo mostra como configurar um Azure Key Vault com chaves gerenciadas pelo cliente usando o portal do
Azure. Para saber como criar um cofre de chaves usando o portal do Azure, consulte início rápido: definir e
recuperar um segredo de Azure Key Vault usando o portal do Azure.
Configurar o Azure Key Vault

O uso de chaves gerenciadas pelo cliente com a criptografia de armazenamento do Azure requer que duas
propriedades sejam definidas no cofre de chaves, exclusão reversível e não sejam limpas . Essas propriedades
não são habilitadas por padrão, mas podem ser habilitadas usando o PowerShell ou CLI do Azure em um cofre de
chaves novo ou existente.
Para saber como habilitar essas propriedades em um cofre de chaves existente, consulte as seções intituladas
habilitar a exclusão reversível e habilitar a proteção de limpeza em um dos seguintes artigos:
Como usar a exclusão reversível com o PowerShell.
Como usar a exclusão reversível com a CLI.
Habilitar chaves gerenciadas pelo cliente

Para habilitar as chaves gerenciadas pelo cliente no portal do Azure, siga estas etapas:
2. Na folha Configurações da conta de armazenamento, clique em Criptografia . Selecione a opção chaves
gerenciadas pelo cliente , conforme mostrado na imagem a seguir.
Especificar uma chave
Depois de habilitar as chaves gerenciadas pelo cliente, você terá a oportunidade de especificar uma chave a ser
associada à conta de armazenamento.
Especificar uma chave como URI
Para especificar uma chave como um URI, siga estas etapas:
1. Para localizar o URI de chave no portal do Azure, navegue até o cofre de chaves e selecione a configuração
chaves . Selecione a chave desejada e clique na chave para exibir suas versões. Selecione uma versão de
chave para exibir as configurações dessa versão.
2. Copie o valor do campo identificador de chave , que fornece o URI.
3. Nas configurações de criptografia para sua conta de armazenamento, escolha a opção inserir URI de
chave .
4. Cole o URI que você copiou no campo URI da chave .
5. Especifique a assinatura que contém o cofre de chaves.
6. Salve suas alterações.
Especificar uma chave de um cofre de chaves
Para especificar uma chave de um cofre de chaves, primeiro verifique se você tem um cofre de chaves que contém
uma chave. Para especificar uma chave de um cofre de chaves, siga estas etapas:
1. Escolha a opção Selecionar do Cofre de chaves .
2. Selecione o cofre de chaves que contém a chave que você deseja usar.
3. Selecione a chave no cofre de chaves.
Atualizar a versão de chave

Ao criar uma nova versão de uma chave, atualize a conta de armazenamento para usar a nova versão. Siga estas
etapas:
1. Navegue até sua conta de armazenamento e exiba as configurações de criptografia .
2. Insira o URI para a nova versão de chave. Como alternativa, você pode selecionar o cofre de chaves e a chave
novamente para atualizar a versão.
Usar uma chave diferente

Para alterar a chave usada para a criptografia de armazenamento do Azure, siga estas etapas:
2. Insira o URI para a nova chave. Como alternativa, você pode selecionar o cofre de chaves e escolher uma nova
chave.
Desabilitar chaves gerenciadas pelo cliente

Quando você desabilita chaves gerenciadas pelo cliente, sua conta de armazenamento é novamente criptografada
com chaves gerenciadas pela Microsoft. Para desabilitar as chaves gerenciadas pelo cliente, siga estas etapas:
2. Desmarque a caixa de seleção ao lado da configuração usar sua própria chave .
Próximas etapas
O que é Azure Key Vault?
Configurar chaves gerenciadas pelo cliente com
Azure Key Vault usando o PowerShell
de BLOB e arquivo.
Este artigo mostra como configurar um Azure Key Vault com chaves gerenciadas pelo cliente usando o
PowerShell. Para saber como criar um cofre de chaves usando CLI do Azure, consulte início rápido: definir e
recuperar um segredo de Azure Key Vault usando o PowerShell.
Atribuir uma identidade à conta de armazenamento

Para habilitar chaves gerenciadas pelo cliente para sua conta de armazenamento, primeiro atribua uma identidade
gerenciada atribuída pelo sistema à conta de armazenamento. Você usará essa identidade gerenciada para
conceder permissões de conta de armazenamento para acessar o cofre de chaves.
Para atribuir uma identidade gerenciada usando o PowerShell, chame set-AzStorageAccount. Lembre-se de
substituir os valores de espaço reservado entre colchetes por seus próprios valores.
$storageAccount = Set-AzStorageAccount -ResourceGroupName <resource_group> `

-Name <storage-account> `
-AssignIdentity
Para obter mais informações sobre como configurar identidades gerenciadas atribuídas pelo sistema com o
PowerShell, consulte Configurar identidades gerenciadas para recursos do Azure em uma VM do Azure usando o
PowerShell.
Criar um novo cofre de chaves

Para criar um novo cofre de chaves usando o PowerShell, chame New-AzKeyVault. O cofre de chaves que você usa
para armazenar chaves gerenciadas pelo cliente para criptografia de armazenamento do Azure deve ter duas
configurações de proteção de chave habilitadas, exclusão reversível e não limpar .
Lembre-se de substituir os valores de espaço reservado entre colchetes por seus próprios valores.
$keyVault = New-AzKeyVault -Name <key-vault> `

-ResourceGroupName <resource_group> `
-Location <location> `
-EnableSoftDelete `
-EnablePurgeProtection
Para saber como habilitar a exclusão reversível e não limpar em um cofre de chaves existente com o
PowerShell, consulte as seções intituladas habilitar a exclusão reversível e habilitar a proteção de limpeza
em como usar a exclusão reversível com o PowerShell.
Configurar a política de acesso do cofre de chaves

Em seguida, configure a política de acesso para o cofre de chaves para que a conta de armazenamento tenha
permissões para acessá-la. Nesta etapa, você usará a identidade gerenciada que você atribuiu anteriormente à
Para definir a política de acesso para o cofre de chaves, chame set-AzKeyVaultAccessPolicy. Lembre-se de substituir
os valores de espaço reservado entre colchetes por seus próprios valores e usar as variáveis definidas nos
exemplos anteriores.
Set-AzKeyVaultAccessPolicy `
-VaultName $keyVault.VaultName `
-ObjectId $storageAccount.Identity.PrincipalId `
-PermissionsToKeys wrapkey,unwrapkey,get
Criar uma nova chave

Em seguida, crie uma nova chave no cofre de chaves. Para criar uma nova chave, chame Add-AzKeyVaultKey.
Lembre-se de substituir os valores de espaço reservado entre colchetes por seus próprios valores e usar as
variáveis definidas nos exemplos anteriores.
$key = Add-AzKeyVaultKey -VaultName $keyVault.VaultName -Name <key> -Destination 'Software'
Configurar a criptografia com chaves gerenciadas pelo cliente

Por padrão, a criptografia de armazenamento do Azure usa chaves gerenciadas pela Microsoft. Nesta etapa,
configure sua conta de armazenamento do Azure para usar chaves gerenciadas pelo cliente e especifique a chave
a ser associada à conta de armazenamento.
Chame set-AzStorageAccount para atualizar as configurações de criptografia da conta de armazenamento,
conforme mostrado no exemplo a seguir. Inclua a opção -KeyvaultEncr yption para habilitar chaves gerenciadas
pelo cliente para a conta de armazenamento. Lembre-se de substituir os valores de espaço reservado entre
colchetes por seus próprios valores e usar as variáveis definidas nos exemplos anteriores.
Set-AzStorageAccount -ResourceGroupName $storageAccount.ResourceGroupName `

-AccountName $storageAccount.StorageAccountName `
-KeyvaultEncryption `
-KeyName $key.Name `
-KeyVersion $key.Version `
-KeyVaultUri $keyVault.VaultUri

Ao criar uma nova versão de uma chave, você precisará atualizar a conta de armazenamento para usar a nova
versão. Primeiro, chame Get-AzKeyVaultKey para obter a versão mais recente da chave. Em seguida, chame set-
AzStorageAccount para atualizar as configurações de criptografia da conta de armazenamento para usar a nova
versão da chave, conforme mostrado na seção anterior.

Para alterar a chave usada para a criptografia de armazenamento do Azure, chame set-AzStorageAccount
conforme mostrado em Configurar criptografia com chaves gerenciadas pelo cliente e forneça o novo nome e
versão da chave. Se a nova chave estiver em um cofre de chaves diferente, atualize também o URI do cofre de
chaves.
Revogar chaves gerenciadas pelo cliente

Se você acreditar que uma chave pode ter sido comprometida, poderá revogar chaves gerenciadas pelo cliente
removendo a política de acesso do cofre de chaves. Para revogar uma chave gerenciada pelo cliente, chame o
comando Remove-AzKeyVaultAccessPolicy , conforme mostrado no exemplo a seguir. Lembre-se de substituir os
valores de espaço reservado entre colchetes por seus próprios valores e usar as variáveis definidas nos exemplos
anteriores.
Remove-AzKeyVaultAccessPolicy -VaultName $keyVault.VaultName `

-ObjectId $storageAccount.Identity.PrincipalId `

com chaves gerenciadas pela Microsoft. Para desabilitar as chaves gerenciadas pelo cliente, chame set-
AzStorageAccount com a -StorageEncryption opção, conforme mostrado no exemplo a seguir. Lembre-se de
substituir os valores de espaço reservado entre colchetes por seus próprios valores e usar as variáveis definidas
nos exemplos anteriores.
Set-AzStorageAccount -ResourceGroupName $storageAccount.ResourceGroupName `

-AccountName $storageAccount.StorageAccountName `
-StorageEncryption
Próximas etapas
Configurar chaves gerenciadas pelo cliente com
Azure Key Vault usando CLI do Azure
de BLOB e arquivo.
Este artigo mostra como configurar um Azure Key Vault com chaves gerenciadas pelo cliente usando CLI do Azure.
Para saber como criar um cofre de chaves usando CLI do Azure, consulte início rápido: definir e recuperar um
segredo de Azure Key Vault usando CLI do Azure.
Atribuir uma identidade à conta de armazenamento

Para habilitar chaves gerenciadas pelo cliente para sua conta de armazenamento, primeiro atribua uma identidade
gerenciada atribuída pelo sistema à conta de armazenamento. Você usará essa identidade gerenciada para
conceder permissões de conta de armazenamento para acessar o cofre de chaves.
Para atribuir uma identidade gerenciada usando CLI do Azure, chame AZ Storage Account Update. Lembre-se de
substituir os valores de espaço reservado entre colchetes por seus próprios valores.
az account set --subscription <subscription-id>
az storage account update \

--name <storage-account> \
--resource-group <resource_group> \
--assign-identity
Para obter mais informações sobre como configurar identidades gerenciadas atribuídas pelo sistema com CLI do
Azure, consulte Configurar identidades gerenciadas para recursos do Azure em uma VM do Azure usando CLI do
Azure.
Criar um novo cofre de chaves

O cofre de chaves que você usa para armazenar chaves gerenciadas pelo cliente para criptografia de
armazenamento do Azure deve ter duas configurações de proteção de chave habilitadas, exclusão reversível e
não limpar . Para criar um novo cofre de chaves usando o PowerShell ou CLI do Azure com essas configurações
habilitadas, execute os comandos a seguir. Lembre-se de substituir os valores de espaço reservado entre colchetes
por seus próprios valores.
Para criar um novo cofre de chaves usando CLI do Azure, chame AZ keyvault Create. Lembre-se de substituir os
valores de espaço reservado entre colchetes por seus próprios valores.
az keyvault create \
--name <key-vault> \
--location <region> \
--enable-soft-delete \
--enable-purge-protection
Para saber como habilitar a exclusão reversível e não limpar em um cofre de chaves existente com CLI do
Azure, consulte as seções intituladas habilitar a exclusão reversível e habilitar a proteção de limpeza em
como usar a exclusão reversível com a CLI.
Configurar a política de acesso do cofre de chaves

Em seguida, configure a política de acesso para o cofre de chaves para que a conta de armazenamento tenha
permissões para acessá-la. Nesta etapa, você usará a identidade gerenciada que você atribuiu anteriormente à
Para definir a política de acesso para o cofre de chaves, chame AZ keyvault Set-Policy. Lembre-se de substituir os
valores de espaço reservado entre colchetes por seus próprios valores.
storage_account_principal=$(az storage account show \

--resource-group <resource-group> \
--query identity.principalId \
--output tsv)
az keyvault set-policy \
--resource-group <resource_group>
--object-id $storage_account_principal \
--key-permissions get unwrapKey wrapKey
Criar uma nova chave

Em seguida, crie uma chave no cofre de chaves. Para criar uma chave, chame a chave AZ keyvault Key Create.
Lembre-se de substituir os valores de espaço reservado entre colchetes por seus próprios valores.
az keyvault key create \

--name <key> \
--vault-name <key-vault>
Configurar a criptografia com chaves gerenciadas pelo cliente

Por padrão, a criptografia de armazenamento do Azure usa chaves gerenciadas pela Microsoft. Configure sua
conta de armazenamento do Azure para chaves gerenciadas pelo cliente e especifique a chave a ser associada à
Para atualizar as configurações de criptografia da conta de armazenamento, chame AZ Storage Account Update,
conforme mostrado no exemplo a seguir. Inclua o --encryption-key-source parâmetro e defina-o
Microsoft.Keyvault como para habilitar chaves gerenciadas pelo cliente para a conta de armazenamento. O
exemplo também consulta o URI do Key Vault e a versão mais recente da chave, ambos os valores necessários
para associar a chave à conta de armazenamento. Lembre-se de substituir os valores de espaço reservado entre
colchetes por seus próprios valores.
key_vault_uri=$(az keyvault show \

--query properties.vaultUri \
--output tsv)
key_version=$(az keyvault key list-versions \
--name <key> \
--vault-name <key-vault> \
--query [-1].kid \
--output tsv | cut -d '/' -f 6)
az storage account update
--encryption-key-name <key> \
--encryption-key-version $key_version \
--encryption-key-source Microsoft.Keyvault \
--encryption-key-vault $key_vault_uri

Ao criar uma nova versão de uma chave, você precisará atualizar a conta de armazenamento para usar a nova
versão. Primeiro, consulte o URI do cofre de chaves chamando AZ keyvault showe para a versão de chave
chamando AZ keyvault Key List-Versions. Em seguida, chame AZ Storage Account Update para atualizar as
configurações de criptografia da conta de armazenamento para usar a nova versão da chave, conforme mostrado
na seção anterior.

Para alterar a chave usada para a criptografia de armazenamento do Azure, chame AZ Storage Account Update ,
conforme mostrado em Configurar a criptografia com chaves gerenciadas pelo cliente e forneça o novo nome e a
versão da chave. Se a nova chave estiver em um cofre de chaves diferente, atualize também o URI do cofre de
chaves.
Revogar chaves gerenciadas pelo cliente

Se você acreditar que uma chave pode ter sido comprometida, poderá revogar chaves gerenciadas pelo cliente
removendo a política de acesso do cofre de chaves. Para revogar uma chave gerenciada pelo cliente, chame o
comando AZ keyvault excluir-Policy , conforme mostrado no exemplo a seguir. Lembre-se de substituir os valores
de espaço reservado entre colchetes por seus próprios valores e usar as variáveis definidas nos exemplos
anteriores.
az keyvault delete-policy \
--object-id $storage_account_principal

com chaves gerenciadas pela Microsoft. Para desabilitar as chaves gerenciadas pelo cliente, chame AZ Storage
Account Update e --encryption-key-source parameter defina Microsoft.Storage como, conforme mostrado no
exemplo a seguir. Lembre-se de substituir os valores de espaço reservado entre colchetes por seus próprios
valores e usar as variáveis definidas nos exemplos anteriores.
az storage account update
--encryption-key-source Microsoft.Storage
Próximas etapas
Configurar redes virtuais e firewalls do
Armazenamento do Microsoft Azure
O Armazenamento do Microsoft Azure fornece um modelo de segurança em camadas. Esse modelo permite que
você proteja e controle o nível de acesso às suas contas de armazenamento que seus aplicativos e ambientes
empresariais exigem, com base no tipo e no subconjunto de redes usadas. Quando as regras de rede são
configuradas, somente os aplicativos que solicitam dados no conjunto especificado de redes podem acessar uma
conta de armazenamento. Você pode limitar o acesso à sua conta de armazenamento a solicitações originadas de
endereços IP especificados, intervalos de IP ou de uma lista de sub-redes em uma VNet (rede virtual) do Azure.
As contas de armazenamento têm um ponto de extremidade público que pode ser acessado pela Internet. Você
também pode criar pontos de extremidade privados para sua conta de armazenamento, que atribui um endereço
IP privado de sua vnet à conta de armazenamento e protege todo o tráfego entre sua vnet e a conta de
armazenamento por um link privado. O Firewall do armazenamento do Azure fornece acesso de controle de
acesso para o ponto de extremidade público da sua conta de armazenamento. Você também pode usar o firewall
para bloquear todo o acesso por meio do ponto de extremidade público ao usar pontos de extremidades privados.
A configuração do firewall de armazenamento também permite selecionar serviços confiáveis da plataforma
Azure para acessar a conta de armazenamento com segurança.
Um aplicativo que acessa uma conta de armazenamento quando as regras de rede estão em vigor ainda requer
autorização adequada para a solicitação. Há suporte para autorização com as credenciais do Azure Active
Directory (Azure AD) para BLOBs e filas, com uma chave de acesso de conta válida ou com um token SAS.
IMPORTANT
A ativação de regras de firewall para sua conta de armazenamento bloqueia solicitações de entrada de dados por padrão, a
menos que as solicitações sejam originadas de um serviço operando em uma VNet (rede virtual) do Azure ou de endereços
IP públicos permitidos. Solicitações que estão bloqueadas incluem as de outros serviços do Azure, do portal do Azure, de
registro em log e serviços de métricas e assim por diante.
Você pode conceder acesso aos serviços do Azure que operam de dentro de uma VNet, permitindo o tráfego da sub-rede
que hospeda a instância do serviço. Você também pode habilitar um número limitado de cenários por meio do mecanismo
de exceções descrito abaixo. Para acessar dados da conta de armazenamento por meio do portal do Azure, você precisa
estar em um computador dentro do limite confiável (IP ou VNet) que você configurou.
NOTE
Cenários
Para proteger sua conta de armazenamento, primeiro você deve configurar uma regra para negar o acesso ao
tráfego de todas as redes (incluindo o tráfego da Internet) no ponto de extremidade público, por padrão. Em
seguida, você deve configurar regras que concedem acesso ao tráfego de VNets específicas. Você também pode
configurar regras para conceder acesso ao tráfego de selecionar intervalos de endereços IP públicos da Internet,
permitindo conexões de clientes locais ou da Internet específicos. Essa configuração permite que você crie um
limite de rede seguro para seus aplicativos.
Você pode combinar as regras de firewall que permitem o acesso de redes virtuais específicas e de intervalos de
endereços IP públicos na mesma conta de armazenamento. As regras de firewall de armazenamento podem ser
aplicadas a contas de armazenamento existentes ou ao criar novas contas de armazenamento.
As regras de firewall de armazenamento se aplicam ao ponto de extremidade público de uma conta de
armazenamento. Você não precisa de nenhuma regra de acesso de firewall para permitir o tráfego para pontos de
extremidade privados de uma conta de armazenamento. O processo de aprovar a criação de um ponto de
extremidade privado concede acesso implícito ao tráfego da sub-rede que hospeda o ponto de extremidade
privado.
As regras de rede são aplicadas em todos os protocolos de rede para o armazenamento do Azure, incluindo REST
e SMB. Para acessar dados usando ferramentas como o portal do Azure, Gerenciador de Armazenamento e
AZCopy, as regras de rede explícitas devem ser configuradas.
Depois que as regras de rede são aplicadas, elas são impostas para todas as solicitações. Os tokens SAS que
concedem acesso a um serviço de endereço IP específico limitam o acesso do proprietário do token, mas não
concedem um novo acesso além das regras de rede configuradas.
O tráfego de disco da máquina virtual (incluindo as operações de montagem e desmontagem e E/S de disco) não
é afetado pelas regras de rede. O acesso REST a blobs de página é protegido pelas regras de rede.
As contas de armazenamento clássicas não dão suporte a firewalls e redes virtuais.
Você pode usar discos não gerenciados nas contas de armazenamento com as regras de rede aplicadas às VMs de
backup e restauração com a criação de uma exceção. Esse processo está documentado na seção Exceções deste
artigo. Exceções de firewall não são aplicáveis com discos gerenciados, pois eles já são gerenciados pelo Azure.
Alterar a regra de acesso de rede padrão

Por padrão, as contas de armazenamento aceitam conexões de clientes em qualquer rede. Para limitar o acesso a
redes selecionadas, primeiro você deve alterar a ação padrão.
WARNING
Fazer alterações em regras de rede pode afetar a capacidade de seus aplicativos se conectarem ao Armazenamento do
Azure. A definição da regra de rede padrão para negar bloqueia todo o acesso aos dados, a menos que regras de rede
específicas que concedem acesso também sejam aplicadas. Certifique-se de conceder acesso a qualquer uma das redes
permitidas usando regras de rede antes de alterar a regra padrão para negar o acesso.
Como alterar as regras de acesso de rede padrão

Você pode gerar as regras de acesso à rede padrão para contas de armazenamento através do portal do Azure,
PowerShell ou CLIv2.
Portal do Azure
1. Vá até a conta de armazenamento que você deseja proteger.
2. Clique no menu de configurações chamado Firewalls e redes vir tuais .
3. Para negar acesso por padrão, escolha permitir o acesso de redes selecionadas . Para permitir o tráfego
de todas as redes, escolha permitir o acesso de todas as redes .
4. Clique em Salvar para aplicar suas alterações.
PowerShell
1. Instalar o Azure PowerShell e entrar.
2. Exiba o status da regra padrão para a conta de armazenamento.
(Get-AzStorageAccountNetworkRuleSet -ResourceGroupName "myresourcegroup" -AccountName

"mystorageaccount").DefaultAction
3. Defina a regra padrão para negar o acesso à rede por padrão.
Update-AzStorageAccountNetworkRuleSet -ResourceGroupName "myresourcegroup" -Name "mystorageaccount" -

DefaultAction Deny
4. Defina a regra padrão para permitir o acesso à rede por padrão.

DefaultAction Allow
CLIv2
1. Instalar a CLI do Azure e entrar.
2. Exiba o status da regra padrão para a conta de armazenamento.
az storage account show --resource-group "myresourcegroup" --name "mystorageaccount" --query

networkRuleSet.defaultAction
3. Defina a regra padrão para negar o acesso à rede por padrão.
az storage account update --resource-group "myresourcegroup" --name "mystorageaccount" --default-action

Deny
4. Defina a regra padrão para permitir o acesso à rede por padrão.
az storage account update --resource-group "myresourcegroup" --name "mystorageaccount" --default-action

Allow
Conceder acesso de uma rede virtual

Você pode configurar contas de armazenamento para permitir o acesso somente de sub-redes específicas. As sub-
redes permitidas podem pertencer a uma VNet na mesma assinatura ou àquelas em uma assinatura diferente,
incluindo assinaturas que pertencem a um locatário de Azure Active Directory diferente.
Habilitar um Ponto de extremidade de serviço do Armazenamento do Microsoft Azure dentro da VNet. O ponto de
extremidade de serviço roteia o tráfego da VNet por meio de um caminho ideal para o serviço de armazenamento
do Azure. As identidades da sub-rede e da rede virtual também são transmitidas com cada solicitação. Os
administradores podem configurar as regras de rede para a conta de armazenamento que permitem que as
solicitações sejam recebidas de sub-redes específicas em uma VNet. Os clientes com o acesso concedido por meio
dessas regras de rede devem continuar a atender aos requisitos de autorização da conta de armazenamento para
acessar os dados.
Cada conta de armazenamento pode dar suporte a até 100 regras da rede virtual que podem ser combinadas
com regras de rede IP.
Regiões de rede virtual disponíveis
Em geral, os pontos de extremidade de serviço funcionam entre redes virtuais e instâncias de serviço na mesma
região do Azure. Ao usar pontos de extremidade de serviço com o Armazenamento do Microsoft Azure, este
escopo cresce para incluir a região emparelhada. Pontos de extremidade de serviço permitem continuidade
durante um failover regional e acesso a instâncias de armazenamento com redundância geográfica somente
leitura (RA-GRS). As regras de rede que concedem acesso de uma rede virtual para uma conta de armazenamento
também concedem acesso a qualquer instância de RA-GRS.
Ao planejar a recuperação de desastre durante uma interrupção regional, você deve criar as VNets na região
emparelhada com antecedência. Habilite pontos de extremidade de serviço para o Armazenamento do Microsoft
Azure, com as regras de rede concedendo acesso dessas redes virtuais alternativas. Em seguida, aplica essas
regras às contas de armazenamento com redundância geográfica.
NOTE
Os Pontos de Extremidade de Serviço não se aplicam ao tráfego de fora da região da rede virtual e ao par da região
designada. Você pode aplicar as regras de rede concedendo acesso das redes virtuais para as conta de armazenamento na
região primária de uma conta de armazenamento ou na região emparelhada designada.
Permissões necessárias
Para aplicar uma regra da rede virtual a uma conta de armazenamento, o usuário deve ter permissão para as sub-
redes sendo adicionadas. A permissão necessária é Ingressar o Serviço em uma Sub-rede e está incluída na
função interna Colaborador da conta de armazenamento. Também podem ser adicionado às definições de função
personalizada.
A conta de armazenamento e as redes virtuais com acesso concedido podem estar em assinaturas diferentes,
incluindo assinaturas que fazem parte de um locatário diferente do Azure AD.
NOTE
A configuração de regras que concedem acesso a sub-redes em redes virtuais que fazem parte de um locatário Azure Active
Directory diferente atualmente só tem suporte por meio do PowerShell, da CLI e de APIs REST. Essas regras não podem ser
configuradas por meio do portal do Azure, embora possam ser exibidas no Portal.
Gerenciando regras da rede virtual

Você pode gerenciar as regras da rede virtual para contas de armazenamento através do portal do Azure,
PowerShell ou CIv2.
Portal do Azure
3. Certifique-se de que você optou por permitir o acesso de Redes selecionadas .
4. Para conceder acesso a uma rede virtual com uma nova regra de rede, em Redes vir tuais , clique em
Adicionar rede vir tual existente , selecione Redes vir tuais e as opções Sub-redes e clique Adicionar .
Para criar uma nova rede virtual e conceder acesso, clique em Adicionar nova rede vir tual . Forneça as
informações necessárias para criar a nova rede virtual e, em seguida, clique em Criar .
NOTE
Se um ponto de extremidade de Armazenamento do Microsoft Azure não foi configurado anteriormente para a rede
virtual selecionada e as sub-redes, você pode configurá-lo como parte dessa operação.
Atualmente, somente as redes virtuais que pertencem ao mesmo locatário Azure Active Directory são mostradas
para seleção durante a criação da regra. Para conceder acesso a uma sub-rede em uma rede virtual que pertence a
outro locatário, use o PowerShell, a CLI ou as APIs REST.
5. Para remover uma regra de rede virtual ou sub-rede, clique em ... para abrir o menu de contexto da rede
virtual ou da sub-rede e clique em Remover .
PowerShell
2. Liste as regras da rede virtual.

"mystorageaccount").VirtualNetworkRules
3. Habilite o ponto de extremidade de serviço do Armazenamento do Microsoft Azure em uma rede virtual
existente e sub-rede.
Get-AzVirtualNetwork -ResourceGroupName "myresourcegroup" -Name "myvnet" | Set-

AzVirtualNetworkSubnetConfig -Name "mysubnet" -AddressPrefix "10.0.0.0/24" -ServiceEndpoint
"Microsoft.Storage" | Set-AzVirtualNetwork
4. Adicionar uma regra de rede para uma rede virtual e sub-rede.
$subnet = Get-AzVirtualNetwork -ResourceGroupName "myresourcegroup" -Name "myvnet" | Get-

AzVirtualNetworkSubnetConfig -Name "mysubnet"
Add-AzStorageAccountNetworkRule -ResourceGroupName "myresourcegroup" -Name "mystorageaccount" -
VirtualNetworkResourceId $subnet.Id
TIP
Para adicionar uma regra de rede para uma sub-rede em uma VNet que pertence a outro locatário do Azure AD, use
um parâmetro Vir tualNetworkResourceId totalmente qualificado no formato "/subscriptions/Subscription-
ID/resourceGroups/resourceGroup-Name/Providers/Microsoft.Network/virtualNetworks/vNet-
Name/Subnets/subnet-Name".
5. Remova uma regra de rede para uma rede virtual e uma sub-rede.
$subnet = Get-AzVirtualNetwork -ResourceGroupName "myresourcegroup" -Name "myvnet" | Get-

AzVirtualNetworkSubnetConfig -Name "mysubnet"
Remove-AzStorageAccountNetworkRule -ResourceGroupName "myresourcegroup" -Name "mystorageaccount" -
VirtualNetworkResourceId $subnet.Id
IMPORTANT
Não se esqueça de definir a regra padrão para negar ou as regras de rede não terão efeito.
CLIv2
2. Liste as regras da rede virtual.
az storage account network-rule list --resource-group "myresourcegroup" --account-name

"mystorageaccount" --query virtualNetworkRules
3. Habilite o ponto de extremidade de serviço do Armazenamento do Microsoft Azure em uma rede virtual
existente e sub-rede.
az network vnet subnet update --resource-group "myresourcegroup" --vnet-name "myvnet" --name "mysubnet"
--service-endpoints "Microsoft.Storage"
4. Adicionar uma regra de rede para uma rede virtual e sub-rede.
$subnetid=(az network vnet subnet show --resource-group "myresourcegroup" --vnet-name "myvnet" --name
"mysubnet" --query id --output tsv)
az storage account network-rule add --resource-group "myresourcegroup" --account-name
"mystorageaccount" --subnet $subnetid
TIP
Para adicionar uma regra para uma sub-rede em uma VNet que pertence a outro locatário do Azure AD, use uma ID
de sub-rede totalmente qualificada na forma<"/subscriptions/Subscription>-<ID/resourceGroups/resourcegroup-
name>/Providers/Microsoft.Network/virtualNetworks/<VNet-name>/Subnets/<subnet-name>".
Você pode usar o parâmetro de assinatura para recuperar a ID de sub-rede de uma VNet que pertence a outro
locatário do Azure AD.
5. Remova uma regra de rede para uma rede virtual e uma sub-rede.
$subnetid=(az network vnet subnet show --resource-group "myresourcegroup" --vnet-name "myvnet" --name
"mysubnet" --query id --output tsv)
az storage account network-rule remove --resource-group "myresourcegroup" --account-name
"mystorageaccount" --subnet $subnetid
IMPORTANT
Conceder acesso de um intervalo de IP de Internet

Você pode configurar as contas de armazenamento para permitir acesso dos intervalos de endereço IP da Internet
pública. Essa configuração garante acesso a serviços públicos baseados na Internet e redes locais e bloqueia o
tráfego de Internet geral.
Forneça intervalos de endereços de Internet permitidos usando a notação CIDR no formulário 16.17.18.0/24 ou
como endereços IP individuas como 16.17.18.19.
NOTE
Os intervalos de endereços pequenos usando o prefixo "/31" ou "/32" não têm suporte. Esses intervalos devem ser
configurados usando regras de endereço IP individuais.
As regras de rede de IP são permitidas apenas para endereços IP de Internet pública . Intervalos de endereços IP
reservados para redes privadas (conforme definido em RFC 1918) não são permitidos nas regras de IP. Redes
privadas incluem endereços que começam com 10. *, 172,16. * - 172,31. * e 192,168. *.
NOTE
As regras de rede IP não terão efeito sobre solicitações originadas da mesma região do Azure que a conta de
armazenamento. Use regras de rede virtual para permitir solicitações de mesma região.
NOTE
Os serviços implantados na mesma região que a conta de armazenamento usam endereços IP privados do Azure para
comunicação. Portanto, você não pode restringir o acesso a serviços específicos do Azure com base em seu intervalo de
endereços IP de saída público.
Somente endereços IPV4 têm suporte para a configuração de regras de firewall de armazenamento.
Cada conta de armazenamento dá suporte a até 100 regras de rede IP.
Configurando o acesso de redes locais
Para conceder acesso de suas redes locais para sua conta de armazenamento com uma regra de rede IP, você deve
identificar os endereços IP voltados para Internet usados por sua rede. Entre em contato com o administrador de
rede para obter ajuda.
Se você estiver usando ExpressRoute de suas instalações, para emparelhamento público ou emparelhamento da
Microsoft, será necessário identificar os endereços IP NAT usados. Para emparelhamento público, cada circuito do
ExpressRoute usará dois endereços IP de NAT, que serão aplicados ao tráfego do serviço do Azure quando o
tráfego entrar no backbone da rede do Microsoft Azure. Para o emparelhamento da Microsoft, os endereços IP de
NAT usados são fornecidos pelo cliente ou são fornecidos pelo provedor de serviços. Para permitir o acesso aos
recursos do serviço, você deve permitir estes endereços IP públicos na configuração do firewall de IP do recurso.
Para localizar os endereços IP públicos do circuito do ExpressRoute de emparelhamento, abra um tíquete de
suporte com o ExpressRoute por meio do Portal do Azure. Saiba mais sobre NAT para emparelhamento público
de ExpressRoute e emparelhamento da Microsoft.
Gerenciando regras de rede IP
Você pode gerenciar as regras de rede IP para contas de armazenamento através do portal do Azure, PowerShell
ou CIv2.
Portal do Azure
4. Para conceder acesso a um intervalo IP da Internet, insira o endereço IP ou o intervalo de endereços (no
formato CIDR) eminter valo de endereços do Firewall > .
5. Para remover uma regra de rede IP, clique no ícone de lixeira próximo da regra de endereço.
PowerShell
2. Liste as regras de rede IP.

"mystorageaccount").IPRules
3. Adicione uma regra de rede para um endereço IP individual.
Add-AzStorageAccountNetworkRule -ResourceGroupName "myresourcegroup" -AccountName "mystorageaccount" -

IPAddressOrRange "16.17.18.19"
4. Adicione uma regra de rede para um intervalo de endereços IP.
Add-AzStorageAccountNetworkRule -ResourceGroupName "myresourcegroup" -AccountName "mystorageaccount" -

IPAddressOrRange "16.17.18.0/24"
5. Remova uma regra de rede para um endereço IP individual.
Remove-AzStorageAccountNetworkRule -ResourceGroupName "myresourcegroup" -AccountName "mystorageaccount"

-IPAddressOrRange "16.17.18.19"
6. Remova uma regra de rede para um intervalo de endereços IP.
Remove-AzStorageAccountNetworkRule -ResourceGroupName "myresourcegroup" -AccountName "mystorageaccount"

-IPAddressOrRange "16.17.18.0/24"
IMPORTANT
CLIv2
2. Liste as regras de rede IP.
az storage account network-rule list --resource-group "myresourcegroup" --account-name

"mystorageaccount" --query ipRules
3. Adicione uma regra de rede para um endereço IP individual.

"mystorageaccount" --ip-address "16.17.18.19"
4. Adicione uma regra de rede para um intervalo de endereços IP.

"mystorageaccount" --ip-address "16.17.18.0/24"
5. Remova uma regra de rede para um endereço IP individual.

"mystorageaccount" --ip-address "16.17.18.19"
6. Remova uma regra de rede para um intervalo de endereços IP.

"mystorageaccount" --ip-address "16.17.18.0/24"
IMPORTANT
Exceções
As regras de rede ajudam a criar um ambiente seguro para conexões entre seus aplicativos e seus dados para a
maioria dos cenários. No entanto, alguns aplicativos dependem de serviços do Azure que não podem ser isolados
exclusivamente por meio de regras de endereço IP ou rede virtual. Mas esses serviços devem ser concedidos ao
armazenamento para habilitar a funcionalidade completa do aplicativo. Nessas situações, você pode usar a
configuração permitir que ser viços confiáveis da Microsoft... para permitir que esses serviços acessem seus
dados, logs ou análises.
Serviços Microsoft confiáveis
Alguns serviços da Microsoft operam de redes que não podem ser incluídas em suas regras de rede. Você pode
conceder a um subconjunto desses serviços confiáveis da Microsoft acesso à conta de armazenamento, mantendo
as regras de rede para outros aplicativos. Esses serviços confiáveis usarão a autenticação forte para se conectar à
sua conta de armazenamento com segurança. Habilitamos dois modos de acesso confiável para serviços da
Microsoft.
Os recursos de alguns serviços, quando registrados em sua assinatura , podem acessar sua conta de
armazenamento na mesma assinatura para operações SELECT, como gravar logs ou backup.
Os recursos de alguns serviços podem receber acesso explícito à sua conta de armazenamento atribuindo
uma função de RBAC à sua identidade gerenciada atribuída pelo sistema.
Quando você habilita a configuração permitir ser viços confiáveis da Microsoft... , os recursos dos seguintes
serviços registrados na mesma assinatura que sua conta de armazenamento recebem acesso a um conjunto
limitado de operações, conforme descrito:
SERVIÇ O N O M E DO P RO VEDO R DE REC URSO S O P ERA Ç Õ ES P ERM IT IDA S
Serviço de Backup do Azure Microsoft.RecoveryServices Execute backups e restaurações de

discos não gerenciados em máquinas
virtuais IAAS. (não é necessário para
discos gerenciados). Saiba mais.
Azure Data Box Microsoft.DataBox Permite a importação de dados para o

Azure usando Data Box. Saiba mais.
Azure DevTest Labs Microsoft.DevTestLab Criação de imagem personalizada e

instalação de artefato. Saiba mais.
SERVIÇ O N O M E DO P RO VEDO R DE REC URSO S O P ERA Ç Õ ES P ERM IT IDA S
Grade de Eventos do Azure Microsoft.EventGrid Habilite a publicação de eventos do

Armazenamento de Blobs e permita
que a Grade de Eventos publique em
filas de armazenamento. Saiba mais
sobre eventos de Armazenamento de
Blobs e publicação em filas.
Hubs de eventos do Azure Microsoft.EventHub Arquivar dados com a Captura de Hubs

de Evento. Saiba mais.
Sincronização de Arquivos do Azure Microsoft.StorageSync Permite transformar seu servidor de

arquivos local em um cache para
compartilhamentos de arquivos do
Azure. Permitir a sincronização de
vários sites, recuperação rápida de
desastres e backup no lado da nuvem.
Saiba mais
Azure HDInsight Microsoft.HDInsight Provisione o conteúdo inicial do

sistema de arquivos padrão para um
novo cluster HDInsight. Saiba mais.
Exportação de importação do Azure Microsoft.ImportExport Permite a importação de dados para o

Azure e a exportação de dados do
Azure usando o serviço de
importação/exportação. Saiba mais.
Azure Monitor Microsoft.insights Permite gravar dados de

monitoramento em uma conta de
armazenamento protegida, incluindo
logs de recursos, Azure Active Directory
de entrada e logs de auditoria e logs de
Microsoft Intune. Saiba mais.
Rede do Azure Microsoft.Network Armazenar e analisar os logs de tráfego

de rede. Saiba mais.
Azure Site Recovery Microsoft.SiteRecovery Habilite a replicação para recuperação

de desastre de máquinas virtuais IaaS
do Azure ao usar as contas de
armazenamento de cache, origem ou
destino habilitadas para firewall. Saiba
mais.
A configuração permitir ser viços confiáveis da Microsoft... também permite que uma instância específica
dos serviços a seguir acesse a conta de armazenamento, se você atribuir explicitamente uma função RBAC à
identidade gerenciada atribuída pelo sistema para essa instância de recurso. Nesse caso, o escopo de acesso para
a instância corresponde à função RBAC atribuída à identidade gerenciada.
SERVIÇ O N O M E DO P RO VEDO R DE REC URSO S F IN A L IDA DE
Pesquisa Cognitiva do Azure Microsoft.Search/searchServices Permite que os serviços de Pesquisa

Cognitiva acessem contas de
armazenamento para indexação,
processamento e consulta.
SERVIÇ O N O M E DO P RO VEDO R DE REC URSO S F IN A L IDA DE
Tarefas do Registro de Contêiner do Microsoft.ContainerRegistry/registries As tarefas de ACR podem acessar

Azure contas de armazenamento ao criar
imagens de contêiner.
Fábrica de dados do Azure Microsoft.DataFactory/factories Permite o acesso a contas de

armazenamento por meio do tempo de
execução do ADF.
Azure Data Share Microsoft. DataShare/accounts Permite o acesso a contas de

armazenamento por meio do
compartilhamento de dados.
Aplicativos Lógicos do Azure Microsoft.Logic/workflows Permite que os aplicativos lógicos

acessem contas de armazenamento.
Saiba mais.
Serviço do Azure Machine Learning Microsoft.MachineLearningServices Os espaços de trabalho Azure Machine

Learning autorizados gravam a saída de
experimento, os modelos e os logs no
armazenamento de BLOBs e lêem os
dados. Saiba mais.
SQL Data Warehouse do Azure Microsoft.Sql Permite a importação e a exportação

de dados de instâncias específicas do
banco do dados SQL usando o
polybase. Saiba mais.
Stream Analytics do Azure Microsoft.StreamAnalytics Permite que os dados de um trabalho

de streaming sejam gravados no
armazenamento de BLOBs. Esse recurso
está atualmente na visualização. Saiba
mais.
Azure Synapse Analytics Microsoft. Synapse/Workspaces Habilita o acesso a dados no

armazenamento do Azure do Synapse
Analytics.
Acesso a dados de análise de armazenamento

Em alguns casos, o acesso para ler os logs de recursos e as métricas é necessário fora do limite de rede. Ao
configurar o acesso de serviços confiáveis à conta de armazenamento, você pode permitir o acesso de leitura para
os arquivos de log, as tabelas de métricas ou ambos. Saiba mais sobre como trabalhar com a análise de
armazenamento.
Gerenciando exceções
Você pode gerenciar as exceções de regra da rede através do portal do Azure, PowerShell ou CLI do Azure v2.
Portal do Azure
4. Em exceções , selecione as exceções que você deseja conceder.
PowerShell
2. Exiba as exceções para as regras de rede da conta de armazenamento.
(Get-AzStorageAccountNetworkRuleSet -ResourceGroupName "myresourcegroup" -Name

"mystorageaccount").Bypass
3. Configure as exceções para as regras de rede da conta de armazenamento.

Bypass AzureServices,Metrics,Logging
4. Remova as exceções para as regras de rede da conta de armazenamento.

Bypass None
IMPORTANT
Não se esqueça de definir a regra padrão para negar ou a remoção das exceções não terá efeito.
CLIv2
2. Exiba as exceções para as regras de rede da conta de armazenamento.
az storage account show --resource-group "myresourcegroup" --name "mystorageaccount" --query

networkRuleSet.bypass
3. Configure as exceções para as regras de rede da conta de armazenamento.
az storage account update --resource-group "myresourcegroup" --name "mystorageaccount" --bypass Logging

Metrics AzureServices
4. Remova as exceções para as regras de rede da conta de armazenamento.
az storage account update --resource-group "myresourcegroup" --name "mystorageaccount" --bypass None
IMPORTANT
Não se esqueça de definir a regra padrão para negar ou a remoção das exceções não terá efeito.
Próximas etapas
Saiba mais sobre os pontos de extremidade de serviço de rede do Azure em pontos de extremidade de serviço.
Aprofunde-se na segurança de armazenamento do Azure no Guia de segurança do armazenamento do Azure.
Exigir transferência segura para garantir conexões
seguras
Você pode configurar sua conta de armazenamento para aceitar solicitações de conexões seguras somente
definindo a propriedade de transferência segura necessária para a conta de armazenamento. Quando você
precisar de transferência segura, todas as solicitações provenientes de uma conexão insegura serão rejeitadas.
A Microsoft recomenda que você sempre precise de transferência segura para todas as suas contas de
armazenamento.
Quando a transferência segura é necessária, uma chamada para uma operação da API REST do armazenamento
do Azure deve ser feita via HTTPS. Qualquer solicitação feita via HTTP é rejeitada.
A conexão com um compartilhamento de arquivos do Azure via SMB sem criptografia falha quando a
transferência segura é necessária para a conta de armazenamento. Exemplos de conexões inseguras incluem as
feitas sobre SMB 2,1, SMB 3,0 sem criptografia ou algumas versões do cliente SMB do Linux.
Por padrão, a propriedade de transferência segura necessária é habilitada quando você cria uma conta de
armazenamento.
NOTE
Como o armazenamento do Azure não dá suporte a HTTPS para nomes de domínio personalizado, essa opção não será
aplicada ao usar um nome de domínio personalizado. Não há suporte para contas de armazenamento clássicas.
Exigir transferência segura no portal do Azure

Você pode ativar a propriedade transferência segura necessária ao criar uma conta de armazenamento no
portal do Azure. Você também pode habilitá-la para uma conta de armazenamento existente.
Requer transferência segura de uma conta de armazenamento nova
1. Abra o painel Criar conta de armazenamento no portal do Azure.
2. Em Transferência segura obrigatória , selecione habilitado .
Requer transferência segura de uma conta de armazenamento existente
1. Selecionar uma conta de armazenamento existente no portal do Azure.
2. No painel do menu de conta de armazenamento, em DEFINIÇÕES , selecione Configuração .
3. Em Transferência segura obrigatória , selecione habilitado .
Exigir transferência segura do código

Para exigir transferência segura de forma programática, defina a propriedade supportsHttpsTrafficOnly na
conta de armazenamento. Você pode definir essa propriedade usando a API REST do provedor de recursos de
armazenamento, bibliotecas de cliente ou ferramentas:
REST API
PowerShell
CLI
NodeJS
SDK .NET
SDK do Python
SDK do Ruby
Exigir transferência segura com o PowerShell

NOTE
Este artigo foi atualizado para usar o novo módulo Az do Azure PowerShell. Você ainda pode usar o módulo AzureRM,
que continuará a receber as correções de bugs até pelo menos dezembro de 2020. Para saber mais sobre o novo módulo
Az e a compatibilidade com o AzureRM, confira Apresentação do novo módulo Az do Azure PowerShell. Para obter
instruções de instalação do módulo Az, confira Instalar o Azure PowerShell.
O exemplo requer o módulo Az do Azure PowerShell, versão 0.7 ou posterior. Execute

Get-Module -ListAvailable Az para encontrar a versão. Se você precisar instalá-lo ou atualizá-lo, confira Instalar
o módulo do Azure PowerShell.
Execute Connect-AzAccount para criar uma conexão com o Azure.
Use a linha de comando a seguir para verificar a configuração:
Get-AzStorageAccount -Name "{StorageAccountName}" -ResourceGroupName "{ResourceGroupName}"

StorageAccountName : {StorageAccountName}
Kind : Storage
EnableHttpsTrafficOnly : False
...
Use a linha de comando a seguir para habilitar a configuração:
Set-AzStorageAccount -Name "{StorageAccountName}" -ResourceGroupName "{ResourceGroupName}" -

EnableHttpsTrafficOnly $True
StorageAccountName : {StorageAccountName}
Kind : Storage
EnableHttpsTrafficOnly : True
...
Exigir transferência segura com CLI do Azure

Para executar esta amostra, instale a última versão da CLI do Azure. Para iniciar, execute az login para criar
uma conexão com o Azure.
As amostras da CLI do Azure são escritas para o shell bash . Para executar esta amostra no prompt de comando
ou no Windows PowerShell, talvez você precise alterar os elementos do script.
Use o seguinte comando para verificar a configuração:
az storage account show -g {ResourceGroupName} -n {StorageAccountName}
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": false,
"type": "Microsoft.Storage/storageAccounts"
...
}
Use o seguinte comando para habilitar a configuração:
az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true

{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": true,
"type": "Microsoft.Storage/storageAccounts"
...
}
Próximas etapas
Recomendações de segurança para o armazenamento de BLOBs
Habilitar a autenticação de Active Directory Domain
Services local sobre SMB para compartilhamentos
Arquivos do Azure oferece suporte à autenticação baseada em identidade sobre o protocolo SMB por meio de
dois tipos de serviços de domínio: Azure Active Directory Domain Services (Azure AD DS) e Active Directory
Domain Services local (AD DS) (visualização). Este artigo se concentra no suporte introduzido recentemente
(versão prévia), aproveitando o serviço Domínio do Active Directory para autenticação em compartilhamentos de
arquivos do Azure. Se você estiver interessado em habilitar a autenticação do Azure AD DS (GA) para
compartilhamentos de arquivos do Azure, consulte nosso artigo sobre o assunto.
NOTE
Os compartilhamentos de arquivos do Azure dão suporte apenas à autenticação em um serviço de domínio, seja Azure
Active Directory serviço de domínio (AD DS do Azure) ou Active Directory Domain Services local (AD DS).
AD DS identidades usadas para a autenticação de compartilhamento de arquivos do Azure devem ser sincronizadas com o
Azure AD. A sincronização de hash de senha é opcional.
A autenticação de AD DS local não oferece suporte à autenticação em relação às contas de computador criadas no AD DS.
A autenticação de AD DS local só pode ser suportada em uma floresta do AD na qual a conta de armazenamento está
registrada. Você só pode acessar compartilhamentos de arquivos do Azure com as credenciais de AD DS de uma única
floresta por padrão. Se você precisar acessar o compartilhamento de arquivos do Azure de uma floresta diferente, verifique
se você tem a relação de confiança de floresta apropriada configurada, consulte as perguntas frequentes para obter
detalhes.
Há suporte para a autenticação AD DS para acesso SMB e persistência de ACL em compartilhamentos de arquivos do
Azure gerenciados pelo Sincronização de Arquivos do Azure.
Os arquivos do Azure dão suporte à autenticação Kerberos com o AD com a criptografia RC4-HMAC. A criptografia
Kerberos AES ainda não tem suporte.
Quando você habilita AD DS para compartilhamentos de arquivos do Azure via SMB, seus computadores
ingressados AD DS podem montar compartilhamentos de arquivos do Azure usando suas credenciais existentes
do AD. Esse recurso pode ser habilitado com um ambiente de AD DS hospedado em computadores locais ou
hospedado no Azure.
As identidades usadas para acessar os compartilhamentos de arquivos do Azure devem ser sincronizadas com o
Azure AD para impor permissões de arquivo de nível de compartilhamento por meio do modelo RBAC (controle
de acesso baseado em função) . As DACLs de estilo do Windows em arquivos/diretórios transferidos de
servidores de arquivos existentes serão preservadas e impostas. Esse recurso oferece integração direta com o
ambiente de AD DS empresarial. Ao substituir servidores de arquivos locais por compartilhamentos de arquivos
do Azure, os usuários existentes podem acessar compartilhamentos de arquivos do Azure de seus clientes atuais
com uma experiência de logon único, sem nenhuma alteração nas credenciais em uso.
NOTE
Para ajudá-lo a configurar a autenticação do AD dos arquivos do Azure para alguns casos de uso comuns, publicamos dois
vídeos com orientações passo a passo:
Substituindo servidores de arquivos locais por arquivos do Azure (incluindo a instalação no link privado para arquivos e
autenticação do AD)
Usando os arquivos do Azure como o contêiner de perfil para a área de trabalho virtual do Windows (incluindo a
configuração na autenticação do AD e FsLogix)
Pré-requisitos
Antes de habilitar a autenticação AD DS para compartilhamentos de arquivos do Azure, verifique se você concluiu
os seguintes pré-requisitos:
Selecione ou crie seu ambiente de AD DS e Sincronize-o com o Azure ad.
Você pode habilitar o recurso em um ambiente de AD DS local novo ou existente. As identidades usadas
para o acesso devem ser sincronizadas com o Azure AD. O locatário do Azure AD e o compartilhamento de
arquivos que você está acessando devem ser associados à mesma assinatura.
Para configurar um ambiente de domínio do AD, consulte Active Directory Domain Services visão geral. Se
você não tiver sincronizado seu AD com o Azure AD, siga as orientações em Azure ad Connect e Azure ad
Connect Health roteiro de instalação para configurar e configurar o Azure ad Connect.
Domínio-ingresse em um computador local ou em uma VM do Azure para AD DS local.
Para acessar um compartilhamento de arquivos usando credenciais do AD de um computador ou VM, seu
dispositivo deve estar ingressado no domínio para AD DS. Para obter informações sobre como ingressar
no domínio, consulte ingressar um computador em um domínio.
Selecione ou crie uma conta de armazenamento do Azure. Para obter um desempenho ideal,
recomendamos que você implante a conta de armazenamento na mesma região da VM da qual você
planeja acessar o compartilhamento.
Certifique-se de que a conta de armazenamento que contém seus compartilhamentos de arquivos ainda
não esteja configurada para autenticação de AD DS do Azure. Se a autenticação de AD DS do Azure for
habilitada na conta de armazenamento, ela precisará ser desabilitada antes da alteração para usar o AD DS
local. Isso implica que as ACLs existentes configuradas no ambiente de AD DS do Azure precisarão ser
reconfiguradas para a imposição de permissão adequada.
Para obter informações sobre como criar um novo compartilhamento de arquivos, consultecriar um
compartilhamento de arquivos em arquivos do Azure.
Verifique a conectividade montando compartilhamentos de arquivos do Azure usando sua chave de conta
de armazenamento.
Para verificar se o dispositivo e o compartilhamento de arquivos estão configurados corretamente, tente
montar o compartilhamento de arquivos usando sua chave de conta de armazenamento. Se você tiver
problemas ao conectar-se aos arquivos do Azure, consulte a ferramenta de solução de problemas que
publicamos para erros de montagem de arquivos do Azure no Windows. Também fornecemos orientações
para contornar cenários quando a porta 445 é bloqueada.
A autenticação de arquivos do Azure com AD DS (versão prévia) está disponível em todas as regiões públicas e
regiões do Azure gov.
Visão geral
Se você planeja habilitar qualquer configuração de rede em seu compartilhamento de arquivos, recomendamos
que você avalie a consideração de rede e conclua a configuração relacionada primeiro antes de habilitar a
autenticação de AD DS.
Habilitar a autenticação de AD DS para seus compartilhamentos de arquivos do Azure permite que você se
autentique em seus compartilhamentos de arquivos do Azure com suas credenciais de AD DS local. Além disso,
ele permite que você gerencie melhor suas permissões para permitir o controle de acesso granular. Isso requer a
sincronização de identidades do AD DS local para o Azure AD com o AD Connect. Você controla o acesso de nível
de compartilhamento com identidades sincronizadas com o Azure AD enquanto gerencia o acesso de nível de
arquivo/compartilhamento com credenciais de AD DS local.
Em seguida, siga as etapas abaixo para configurar os arquivos do Azure para autenticação AD DS:
1. Habilitar a autenticação de AD DS de arquivos do Azure em sua conta de armazenamento
2. Atribuir permissões de acesso para um compartilhamento para a identidade do Azure AD (um usuário,
grupo ou entidade de serviço) que está em sincronia com a identidade do AD de destino
3. Configurar ACLs sobre SMB para diretórios e arquivos
4. Montar um compartilhamento de arquivos do Azure para uma VM ingressada em seu AD DS
5. Atualize a senha da sua identidade de conta de armazenamento no AD DS
O diagrama a seguir ilustra o fluxo de trabalho de ponta a ponta para habilitar a autenticação do Azure AD sobre
SMB para compartilhamentos de arquivos do Azure.
NOTE
Só há suporte para a autenticação AD DS sobre SMB para compartilhamentos de arquivos do Azure em máquinas ou VMs
em execução em versões do sistema operacional mais recentes do que o Windows 7 ou o Windows Server 2008 R2.
1 habilitar a autenticação AD DS para sua conta

Para habilitar a autenticação de AD DS sobre o SMB para compartilhamentos de arquivos do Azure, primeiro
você precisa registrar sua conta de armazenamento com AD DS e, em seguida, definir as propriedades de
domínio necessárias na conta de armazenamento. Quando o recurso é habilitado na conta de armazenamento,
ele se aplica a todos os compartilhamentos de arquivos novos e existentes na conta. Baixe o módulo do
PowerShell do AzFilesHybrid e use join-AzStorageAccountForAuth para habilitar o recurso. Você pode encontrar a
descrição detalhada do fluxo de trabalho de ponta a ponta no script dentro desta seção.
IMPORTANT
O Join-AzStorageAccountForAuth cmdlet fará modificações no seu ambiente do AD. Leia a explicação a seguir para
entender melhor o que está fazendo para garantir que você tenha as permissões adequadas para executar o comando e
que as alterações aplicadas se alinhem às políticas de conformidade e segurança.
O Join-AzStorageAccountForAuth cmdlet executará o equivalente a um ingresso no domínio offline em nome da

conta de armazenamento indicada. O script usa o cmdlet para criar uma conta em seu domínio do AD, seja uma
conta de computador (padrão) ou uma conta de logon de serviço. Se você optar por fazer isso manualmente,
deverá selecionar a conta mais adequada para o seu ambiente.
A conta de AD DS criada pelo cmdlet representa a conta de armazenamento no domínio do AD. Se a conta de AD
DS for criada em uma UO (unidade organizacional) que impõe a expiração da senha, você deverá atualizar a
senha antes da duração máxima da senha. A falha ao atualizar a senha da conta resultará em falhas de
autenticação ao acessar compartilhamentos de arquivos do Azure. Para saber como atualizar a senha, consulte
atualizar a senha da conta do AD DS.
Você pode usar o script a seguir para executar o registro e habilitar o recurso ou, como alternativa, você pode
executar manualmente as operações que o script faria. Essas operações são descritas na seção após o script. Você
não precisa fazer as duas.
pré -requisitos de script do 1,1
Baixar e descompactar o módulo AzFilesHybrid
Instale e execute o módulo em um dispositivo que esteja ingressado no domínio no local AD DS com
credenciais de AD DS que tenham permissões para criar uma conta de logon de serviço ou uma conta de
computador no AD de destino.
Execute o script usando uma credencial de AD DS local que é sincronizada com o Azure AD. A credencial de AD
DS local deve ter as permissões de proprietário da conta de armazenamento ou da função de RBAC do
colaborador.
Verifique se sua conta de armazenamento está em uma região com suporte.
1,2 domínio ingressar em sua conta de armazenamento
Lembre-se de substituir os valores de espaço reservado pelos seus próprios nos parâmetros abaixo antes de
executá-los no PowerShell.
IMPORTANT
O cmdlet ingresso no domínio criará uma conta do AD para representar a conta de armazenamento (compartilhamento de
arquivos) no AD. Você pode optar por se registrar como uma conta de computador ou conta de logon de serviço, consulte
perguntas frequentes para obter detalhes. Para contas de computador, há uma duração de expiração de senha padrão
definida no AD em 30 dias. Da mesma forma, a conta de logon do serviço pode ter uma duração de expiração de senha
padrão definida no domínio do AD ou na UO (unidade organizacional). Para ambos os tipos de conta, é altamente
recomendável verificar qual é a idade de expiração de senha configurada no seu ambiente do AD e planejar atualizar a
senha da sua identidade de conta de armazenamento no AD da conta do AD abaixo antes da duração máxima da senha.
Você pode considerar criar uma nova ou (unidade organizacional) do AD no AD e desabilitar a política de expiração de
senha em contas de computador ou contas de logon de serviço de acordo.
#Change the execution policy to unblock importing AzFilesHybrid.psm1 module
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
# Navigate to where AzFilesHybrid is unzipped and stored and run to copy the files into your path
.\CopyToPSPath.ps1
#Import AzFilesHybrid module

Import-Module -Name AzFilesHybrid
#Login with an Azure AD credential that has either storage account owner or contributer RBAC assignment
Connect-AzAccount
#Define parameters
$SubscriptionId = "<your-subscription-id-here>"
$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
#Select the target subscription for the current session

Select-AzSubscription -SubscriptionId $SubscriptionId
# Register the target storage account with your active directory environment under the target OU (for
example: specify the OU with Name as "UserAccounts" or DistinguishedName as
"OU=UserAccounts,DC=CONTOSO,DC=COM").
# You can use to this PowerShell cmdlet: Get-ADOrganizationalUnit to find the Name and DistinguishedName of
your target OU. If you are using the OU Name, specify it with -OrganizationalUnitName as shown below. If you
are using the OU DistinguishedName, you can set it with -OrganizationalUnitDistinguishedName. You can choose
to provide one of the two names to specify the target OU.
# You can choose to create the identity that represents the storage account as either a Service Logon Account
or Computer Account (default parameter value), depends on the AD permission you have and preference.
# You can run Get-Help Join-AzStorageAccountForAuth to find more details on this cmdlet.
Join-AzStorageAccountForAuth `
-ResourceGroupName $ResourceGroupName `
-Name $StorageAccountName `
-DomainAccountType "<ComputerAccount|ServiceLogonAccount>" `
-OrganizationalUnitName "<ou-name-here>" #You can also use -OrganizationalUnitDistinguishedName "<ou-
distinguishedname-here>" instead. If you don't provide the OU name as an input parameter, the AD identity
that represents the storage account will be created under the root directory.
#You can run the Debug-AzStorageAccountAuth cmdlet to conduct a set of basic checks on your AD configuration
with the logged on AD user. This cmdlet is supported on AzFilesHybrid v0.1.2+ version. For more details on
the checks performed in this cmdlet, go to Azure Files FAQ.
Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -
Verbose
A descrição a seguir resume todas as ações executadas quando o Join-AzStorageAccountForAuth cmdlet é

executado. Você pode executar essas etapas manualmente, se preferir não usar o comando:
NOTE
Se você já executou o Join-AzStorageAccountForAuth script acima com êxito, vá para a próxima seção "1,3 confirmar que
o recurso está habilitado". Você não precisa executar as operações abaixo novamente.
a. Verificando o ambiente
Primeiro, o script verifica seu ambiente. Especificamente, ele verifica se Active Directory PowerShell está instalado
e se o Shell está sendo executado com privilégios de administrador. Em seguida, ele verifica se o módulo AZ.
Storage 1.11.1-Preview está instalado e instala-o se não estiver. Se essas verificações forem aprovadas, ele
verificará sua AD DS para ver se há uma conta de computador (padrão) ou conta de logon de serviço que já foi
criada com o SPN/UPN como "CIFS/Your-Storage-Account-Name-aqui. File. Core. Windows. net". Se a conta não
existir, ela criará uma, conforme descrito na seção b abaixo.
b. Criando uma identidade que representa a conta de armazenamento em seu AD manualmente
Para criar essa conta manualmente, crie uma nova chave Kerberos para sua conta de armazenamento usando
New-AzStorageAccountKey -KeyName kerb1 . Em seguida, use essa chave Kerberos como a senha para sua conta.
Essa chave só é usada durante a instalação e não pode ser usada para nenhuma operação de controle ou plano
de dados na conta de armazenamento.
Depois de ter essa chave, crie uma conta de serviço ou de computador em sua UO. Use a seguinte especificação:
SPN: "CIFS/Your-Storage-Account-Name-aqui. File. Core. Windows. net" Password: chave Kerberos para sua conta
de armazenamento.
Se sua UO impõe a expiração de senha, você deve atualizar a senha antes da duração máxima da senha para
evitar falhas de autenticação ao acessar compartilhamentos de arquivos do Azure. Consulte Atualizar senha de
sua identidade de conta de armazenamento no AD DS para obter detalhes.
Mantenha o SID da conta recém-criada, você precisará dela para a próxima etapa. A identidade que você criou
que representa a conta de armazenamento não precisa ser sincronizada com o Azure AD.
c . H a b i l i t a r o r e c u r so e m su a c o n t a d e a r m a z e n a m e n t o
O script, em seguida, habilitaria o recurso em sua conta de armazenamento. Para executar essa configuração
manualmente, forneça alguns detalhes de configuração para as propriedades de domínio no comando a seguir e,
em seguida, execute-a. O SID da conta de armazenamento necessário no comando a seguir é o SID da identidade
que você criou em seu AD DS na seção anterior.
# Set the feature flag on the target storage account and provide the required AD domain information
Set-AzStorageAccount `
-ResourceGroupName "<your-resource-group-name-here>" `
-Name "<your-storage-account-name-here>" `
-EnableActiveDirectoryDomainServicesForFile $true `
-ActiveDirectoryDomainName "<your-domain-name-here>" `
-ActiveDirectoryNetBiosDomainName "<your-netbios-domain-name-here>" `
-ActiveDirectoryForestName "<your-forest-name-here>" `
-ActiveDirectoryDomainGuid "<your-guid-here>" `
-ActiveDirectoryDomainsid "<your-domain-sid-here>" `
-ActiveDirectoryAzureStorageSid "<your-storage-account-sid>"
1,3 confirmar que o recurso está habilitado

Você pode verificar para confirmar se o recurso está habilitado em sua conta de armazenamento, pode usar o
seguinte script:
# Get the target storage account

$storageaccount = Get-AzStorageAccount `
-Name "<your-storage-account-name-here>"
# List the directory service of the selected service account

$storageAccount.AzureFilesIdentityBasedAuth.DirectoryServiceOptions
# List the directory domain information if the storage account has enabled AD DS authentication for file
shares
$storageAccount.AzureFilesIdentityBasedAuth.ActiveDirectoryProperties
Agora você ativou com êxito o recurso em sua conta de armazenamento. Agora que o recurso está habilitado, há
mais etapas que você deve executar para usar o recurso.
2 atribuir permissões de acesso a uma identidade

Para acessar os recursos de arquivos do Azure com autenticação baseada em identidade, uma identidade (um
usuário, grupo ou entidade de serviço) deve ter as permissões necessárias no nível de compartilhamento. Esse
processo é semelhante à especificação de permissões de compartilhamento do Windows, em que você especifica
o tipo de acesso que um usuário específico tem a um compartilhamento de arquivos. As orientações nesta seção
demonstram como atribuir ler, gravar ou excluir as permissões para um compartilhamento de arquivos para uma
identidade.
Introduzimos três funções internas do Azure para conceder permissões de nível de compartilhamento aos
usuários:
O leitor de compar tilhamento SMB de dados de arquivo de armazenamento permite acesso de
leitura em compartilhamentos de arquivos de armazenamento do Azure via SMB
O colaborador de compar tilhamento SMB de dados de arquivo de armazenamento permite acesso
de leitura, gravação e exclusão em compartilhamentos de arquivos de armazenamento do Azure via SMB.
O colaborador elevado de compar tilhamento SMB de dados de arquivo de armazenamento
permite a leitura, gravação, exclusão e modificação de permissões NTFS em compartilhamentos de arquivos
de armazenamento do Azure via SMB.
IMPORTANT
O controle administrativo total de um compartilhamento de arquivos, incluindo a capacidade de apropriar-se de um
arquivo, requer o uso da chave da conta de armazenamento. O controle administrativo não é compatível com credenciais
do Azure AD.
Você pode usar o portal do Azure, o PowerShell ou o CLI do Azure para atribuir as funções internas à identidade
do Azure AD de um usuário para conceder permissões de nível de compartilhamento. Lembre-se de que a
atribuição de função RBAC de nível de compartilhamento pode levar algum tempo para estar em vigor.
NOTE
Lembre-se de sincronizar suas credenciais do AD DS com o AD do Azure se você planeja usar sua AD DS local para
autenticação. A sincronização de hash de senha de AD DS para o Azure AD é opcional. A permissão de nível de
compartilhamento será concedida à identidade do Azure AD que é sincronizada a partir de seu AD DS local.
A recomendação geral é usar a permissão de nível de compartilhamento para o gerenciamento de acesso de alto
nível para um grupo do AD que representa um grupo de usuários e identidades e, em seguida, aproveitar as
permissões de NTFS para o controle de acesso granular no nível de diretório/arquivo.
Portal do Azure
Para atribuir uma função de RBAC a uma identidade do Azure AD, usando o portal do Azure, siga estas etapas:
1. No portal do Azure, vá para o compartilhamento de arquivos ou crie um compartilhamento de arquivos.
2. Selecione controle de acesso (iam) .
3. Selecione Adicionar uma atribuição de função
4. Na folha Adicionar atribuição de função , selecione a função interna apropriada (leitor de
compartilhamento SMB de dados de arquivo de armazenamento, colaborador de compartilhamento SMB de
dados de arquivo de armazenamento) na lista de funções . Deixe atribuir acesso à na configuração padrão:
usuário, grupo ou entidade de ser viço do Azure ad . Selecione a identidade do Azure AD de destino por
nome ou endereço de email.
5. Selecione salvar para concluir a operação de atribuição de função.
PowerShell
O exemplo do PowerShell a seguir mostra como atribuir uma função de RBAC a uma identidade do Azure AD,
com base no nome de entrada. Para obter mais informações sobre como atribuir funções do RBAC ao PowerShell,
consulte Gerenciar acesso usando o RBAC e o Azure PowerShell.
Antes de executar o script de exemplo a seguir, lembre-se de substituir os valores de espaço reservado, incluindo
colchetes, pelos seus próprios valores.
#Get the name of the custom role

$FileShareContributorRole = Get-AzRoleDefinition "<role-name>" #Use one of the built-in roles: Storage File
Data SMB Share Reader, Storage File Data SMB Share Contributor, Storage File Data SMB Share Elevated
Contributor
#Constrain the scope to the target file share
$scope = "/subscriptions/<subscription-id>/resourceGroups/<resource-
group>/providers/Microsoft.Storage/storageAccounts/<storage-account>/fileServices/default/fileshares/<share-
name>"
#Assign the custom role to the target identity with the specified scope.
New-AzRoleAssignment -SignInName <user-principal-name> -RoleDefinitionName $FileShareContributorRole.Name -
Scope $scope
CLI
O comando da CLI 2,0 a seguir mostra como atribuir uma função de RBAC a uma identidade do Azure AD, com
base no nome de entrada. Para obter mais informações sobre como atribuir funções RBAC com CLI do Azure,
consulte gerenciar o acesso usando RBAC e CLI do Azure.
#Assign the built-in role to the target identity: Storage File Data SMB Share Reader, Storage File Data SMB
Share Contributor, Storage File Data SMB Share Elevated Contributor
az role assignment create --role "<role-name>" --assignee <user-principal-name> --scope
"/subscriptions/<subscription-id>/resourceGroups/<resource-
name>"
3 configurar permissões NTFS em relação ao SMB

Depois de atribuir permissões no nível de compartilhamento com o RBAC, você deve atribuir permissões de
NTFS corretas no nível raiz, de diretório ou de arquivo. Considere as permissões de nível de compartilhamento
como o gatekeeper de alto nível que determina se um usuário pode acessar o compartilhamento. Enquanto as
permissões de NTFS atuam em um nível mais granular para determinar quais operações o usuário pode fazer no
nível do diretório ou do arquivo.
Os arquivos do Azure dá suporte a todo o conjunto de permissões de NTFS básicos e avançados. Você pode
exibir e configurar as permissões NTFS em diretórios e arquivos em um compartilhamento de arquivos do Azure
montando o compartilhamento e usando o explorador de arquivos do Windows ou executando o comando icacls
do Windows ou Set-ACL .
Para configurar o NTFS com permissões de superusuário, você deve montar o compartilhamento usando sua
chave de conta de armazenamento de sua VM ingressada no domínio. Siga as instruções na próxima seção para
montar um compartilhamento de arquivos do Azure no prompt de comando e configurar as permissões NTFS
adequadamente.
Conjuntos de permissões a seguir têm suporte para o diretório raiz de um compartilhamento de arquivos:
BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Users:(Rx)
BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
NT AUTHORITY\Authenticated Users:(OI)(CI)(M)
NT AUTHORITY\SYSTEM:(F)
CREATOR OWNER:(OI)(CI)(IO)(F)
Montar um compartilhamento de arquivos do Azure no prompt de comando
Usar o Windows net use comando para montar o compartilhamento de arquivos do Azure. Lembre-se de
substituir os valores de espaço reservado no exemplo a seguir pelos seus próprios valores. Para obter mais
informações sobre como montar compartilhamentos de arquivos, consulte usar um compartilhamento de
net use <desired-drive-letter>: \\<storage-account-name>.file.core.windows.net\<share-name> /user:Azure\

<storage-account-name> <storage-account-key>
Se você tiver problemas ao conectar-se aos arquivos do Azure, consulte a ferramenta de solução de problemas
que publicamos para erros de montagem de arquivos do Azure no Windows. Também fornecemos orientações
Configurar permissões NTFS com o explorador de arquivos do Windows
Use o explorador de arquivos do Windows para conceder permissão total a todos os diretórios e arquivos no
compartilhamento de arquivos, incluindo o diretório raiz.
1. Abra o explorador de arquivos do Windows e clique com o botão direito do mouse no arquivo/diretório e
selecione Propriedades .
2. Selecione a guia Segurança .
3. Selecione Editar... para alterar permissões.
4. Você pode alterar as permissões de usuários existentes ou selecionar Adicionar... para conceder permissões a
novos usuários.
5. Na janela de prompt para adicionar novos usuários, insira o nome de usuário de destino ao qual você deseja
conceder permissão na caixa Inserir os nomes de objeto a serem selecionados e selecione verificar
nomes para localizar o nome UPN completo do usuário de destino.
6. Selecione OK .
7. Na guia segurança , selecione todas as permissões que você deseja conceder ao novo usuário.
8. Escolha Aplicar .
Configurar permissões NTFS com icacls
Use o seguinte comando do Windows para conceder permissões completas para todos os diretórios e arquivos
no compartilhamento de arquivos, incluindo o diretório raiz. Lembre-se de substituir os valores de espaço
reservado no exemplo pelos seus próprios valores.
icacls <mounted-drive-letter>: /grant <user-email>:(f)
Para obter mais informações sobre como usar o icacls para definir permissões NTFS e sobre os diferentes tipos
de permissões com suporte, consulte a referência de linha de comando para icacls.
4 montar um compartilhamento de arquivos de uma VM ingressada

no domínio
O processo a seguir verifica se as permissões de acesso e compartilhamento de arquivos foram configuradas
corretamente e se você pode acessar um compartilhamento de arquivos do Azure de uma VM ingressada no
domínio. Lembre-se de que a atribuição de função RBAC de nível de compartilhamento pode levar algum tempo
para estar em vigor.
Entre na VM usando a identidade do Azure AD à qual você concedeu permissões, conforme mostrado na imagem
a seguir. Se você habilitou a autenticação de AD DS local para arquivos do Azure, use suas credenciais de AD DS.
Para a autenticação de AD DS do Azure, entre com as credenciais do Azure AD.
Use o comando a seguir para montar o compartilhamento de arquivos do Azure. Lembre-se de substituir os
valores de espaço reservado por seus próprios valores. Como você foi autenticado, não precisa fornecer a chave
de conta de armazenamento, as credenciais de AD DS locais ou as credenciais de AD DS do Azure. Há suporte
para a experiência de logon único para autenticação com AD DS local ou AD DS do Azure. Se você tiver
problemas para montar com credenciais de AD DS, consulte solucionar problemas de arquivos do Azure no
Windows para obter diretrizes.
net use <desired-drive-letter>: \\<storage-account-name>.file.core.windows.net\<share-name>
Agora você habilitou com êxito AD DS autenticação sobre o SMB e atribuiu uma função personalizada que
fornece acesso a um compartilhamento de arquivos do Azure com uma identidade de AD DS. Para conceder a
usuários adicionais acesso ao seu compartilhamento de arquivos, siga as instruções nas seções atribuir
permissões de acesso para usar uma identidade e configurar permissões NTFS em relação ao SMB .
5 atualize a senha da sua identidade de conta de armazenamento no

AD DS
Se você registrou o AD DS identidade/conta que representa sua conta de armazenamento em uma UO que
impõe o tempo de expiração da senha, você deve girar a senha antes da duração máxima da senha. A falha ao
atualizar a senha da conta de AD DS resultará em falhas de autenticação para acessar compartilhamentos de
arquivos do Azure.
Para disparar a rotação de senha, você pode executar o Update-AzStorageAccountADObjectPassword comando do
módulo AzFilesHybrid. O cmdlet executa ações semelhantes à rotação de chaves da conta de armazenamento. Ele
obtém a segunda chave Kerberos da conta de armazenamento e a usa para atualizar a senha da conta registrada
no AD DS. Em seguida, ele regenera a chave Kerberos de destino da conta de armazenamento e atualiza a senha
da conta registrada no AD DS. Você deve executar esse cmdlet em um ambiente ingressado no domínio AD DS
local.
# Update the password of the AD DS account registered for the storage account
Update-AzStorageAccountADObjectPassword `
-RotateToKerbKey kerb2 `
-StorageAccountName "<your-storage-account-name-here>"
Próximas etapas
Para obter mais informações sobre os arquivos do Azure e como usar o AD sobre SMB, consulte estes recursos:
Visão geral do suporte de autenticação baseada em identidade de arquivos do Azure para acesso SMB
Habilitar a autenticação de Azure Active Directory
Domain Services nos arquivos do Azure
Os arquivos do Azure oferecem suporte à autenticação baseada em identidade sobre o protocolo SMB por meio
do Active Directory Domain Services local (AD DS) (visualização) e Azure Active Directory Domain Services
(Azure AD DS). Este artigo se concentra em como os compartilhamentos de arquivos do Azure podem usar os
serviços de domínio, no local ou no Azure, para dar suporte ao acesso baseado em identidade aos
compartilhamentos de arquivos do Azure por SMB. Habilitar o acesso baseado em identidade para seus
compartilhamentos de arquivos do Azure permite que você substitua servidores de arquivos existentes por
compartilhamentos de arquivos do Azure sem substituir o serviço de diretório existente, mantendo acesso
contínuo de usuário a compartilhamentos.
Os arquivos do Azure impõe a autorização no acesso do usuário ao compartilhamento e aos níveis de
diretório/arquivo. A atribuição de permissão de nível de compartilhamento pode ser executada em usuários do
Azure Active Directory (Azure AD) ou grupos gerenciados por meio do modelo RBAC (controle de acesso
baseado em função) . Com o RBAC, as credenciais usadas para o acesso ao arquivo devem estar disponíveis ou
sincronizadas com o Azure AD. Você pode atribuir funções RBAC internas como o leitor de compartilhamento
SMB de dados de arquivo de armazenamento a usuários ou grupos no Azure AD para conceder acesso de leitura
a um compartilhamento de arquivos do Azure.
No nível de diretório/arquivo, os arquivos do Azure dão suporte à preservação, herança e imposição de DACLs
do Windows , assim como qualquer servidor de arquivos do Windows. Você pode optar por manter as DACLs do
Windows ao copiar dados via SMB entre o compartilhamento de arquivos existente e os compartilhamentos de
arquivos do Azure. Se você planeja impor autorização ou não, pode usar compartilhamentos de arquivos do
Azure para fazer backup de ACLs junto com seus dados.
Para obter uma visão geral da autenticação do Azure AD sobre SMB para compartilhamentos de arquivos do
Azure, consulte visão geral da autenticação de Azure Active Directory sobre o SMB para arquivos do Azure. Este
artigo se concentra em como habilitar a autenticação com o Azure Active Directory Domain Services (AD DS do
Azure) em arquivos do Azure.
NOTE
Os arquivos do Azure dão suporte à autenticação Kerberos com o Azure AD DS com a criptografia RC4-HMAC. A
criptografia Kerberos AES ainda não tem suporte.
Pré-requisitos
Antes de habilitar o Azure AD sobre SMB para compartilhamentos de arquivos do Azure, verifique se você
concluiu os seguintes pré-requisitos:
1. Selecione ou crie um locatário do Azure AD.
Você pode usar um inquilino novo ou existente para a autenticação do Azure AD em SMB. O locatário e o
compartilhamento de arquivos que você deseja acessar devem estar associados à mesma assinatura.
Para criar um novo locatário do Azure AD, você pode adicionar um locatário do Azure AD e uma
assinatura do Azure AD. Se você tiver um locatário existente do Azure AD, mas quiser criar um novo
locatário para uso com compartilhamentos de arquivos do Azure, consulte criar um locatário Azure Active
Directory.
2. Ative os Ser viços de Domínio do Azure AD no locatário do Azure AD.
Para oferecer suporte à autenticação com credenciais do Azure AD, você deve habilitar os Serviços de
Domínio do Azure AD para o seu locatário do Azure AD. Se você não for o administrador do locatário do
Azure AD, entre em contato com o administrador e siga as orientações passo a passo para Habilitar os
Serviços de Domínio do Active Directory do Azure usando o portal do Azure.
Normalmente, leva cerca de 15 minutos para que uma implantação de AD DS do Azure seja concluída.
Verifique se o status de integridade do Azure AD DS mostra em execução , com a sincronização de hash
de senha habilitada, antes de prosseguir para a próxima etapa.
3. Ingressar no domínio de uma VM do Azure com o Azure AD DS.
Para acessar um compartilhamento de arquivos usando as credenciais do Azure AD de uma VM, sua VM
deve estar ingressada no domínio para o Azure AD DS. Para obter mais informações sobre como
ingressar no domínio de uma VM, consulte Ingressar uma máquina virtual do Windows Server em um
domínio gerenciado.
NOTE
A autenticação do Azure AD DS sobre SMB com compartilhamentos de arquivos do Azure tem suporte apenas em
VMs do Azure em execução nas versões do sistema operacional acima do Windows 7 ou do Windows Server 2008
R2.
4. Selecione ou crie um compar tilhamento de arquivos do Azure.

Selecione um compartilhamento de arquivos novo ou existente associado à mesma assinatura que o seu
locatário do Azure AD. Para obter informações sobre como criar um novo compartilhamento de arquivos,
consulte Criar um compartilhamento de arquivos no Azure Files. Para obter um desempenho ideal,
recomendamos que o compartilhamento de arquivos esteja na mesma região da VM da qual você planeja
acessar o compartilhamento.
5. Verifique a conectividade de arquivos do Azure montando compar tilhamentos de arquivos
do Azure usando a chave da sua conta de armazenamento.
Para verificar se sua VM e seu compartilhamento de arquivos estão configurados corretamente, tente
montar o compartilhamento de arquivos usando sua chave de conta de armazenamento. Para obter mais
informações, consulte Montar um compartilhamento de arquivos do Azure e acessar o compartilhamento
no Windows.
Visão geral do fluxo de trabalho

Antes de habilitar a autenticação do Azure AD DS sobre o SMB para compartilhamentos de arquivos do Azure,
verifique se os ambientes do Azure AD e do armazenamento do Azure estão configurados corretamente.
Recomendamos que você percorra os pré-requisitos para ter certeza de que concluiu todas as etapas
necessárias.
Em seguida, faça o seguinte para conceder acesso aos recursos de arquivos do Azure com as credenciais do
Azure AD:
1. Habilite a autenticação de AD DS do Azure sobre SMB para sua conta de armazenamento para registrar a
conta de armazenamento com a implantação de AD DS do Azure associada.
2. Atribuir permissões de acesso para um compartilhamento a uma identidade do Azure AD (um usuário, grupo
ou responsável pelo serviço).
3. Configurar permissões NTFS em SMB para diretórios e arquivos.
4. Montar um compartilhamento de arquivos do Azure de uma VM associada ao domínio.
O diagrama a seguir ilustra o fluxo de trabalho de ponta a ponta para habilitar a autenticação de AD DS do Azure
sobre SMB para arquivos do Azure.
1. habilitar a autenticação de AD DS do Azure para sua conta

Para habilitar a autenticação de AD DS do Azure sobre o SMB para arquivos do Azure, você pode definir uma
propriedade em contas de armazenamento usando o portal do Azure, Azure PowerShell ou CLI do Azure. Definir
essa propriedade implicitamente "ingressa no domínio" é a conta de armazenamento com a implantação de AD
DS do Azure associada. A autenticação do Azure AD DS sobre o SMB é então habilitada para todos os
compartilhamentos de arquivos novos e existentes na conta de armazenamento.
Tenha em mente que você pode habilitar a autenticação AD DS do Azure somente por SMB depois de ter
implantado com êxito o Azure AD DS em seu locatário do Azure AD. Para obter mais informações, consulte os
pré-requisitos.
Portal do Azure
Para habilitar a autenticação de AD DS do Azure sobre SMB com o portal do Azure, siga estas etapas:
1. Na portal do Azure, vá para sua conta de armazenamento existente ou crie uma conta de armazenamento.
2. Na seção Configurações , selecione Configuração .
3. Em acesso baseado em identidade para compar tilhamentos de arquivos , alterne a alternância para
o ser viço de domínio Azure Active Director y (AAD DS) para habilitado .
4. Selecione Salvar .
A imagem a seguir mostra como habilitar a autenticação de AD DS do Azure sobre SMB para sua conta de
armazenamento.
PowerShell
Para habilitar a autenticação de AD DS do Azure sobre SMB com Azure PowerShell, instale o módulo AZ mais
recente (2,4 ou mais recente) ou o módulo AZ. Storage (1,5 ou mais recente). Para obter mais informações sobre
como instalar o PowerShell, consulte instalar Azure PowerShell no Windows com PowerShellGet.
Para criar uma nova conta de armazenamento, chame New-AzStorageAccounte, em seguida, defina o parâmetro
EnableAzureActiveDirector yDomainSer vicesForFile como true . No exemplo a seguir, lembre-se de
substituir os valores de espaço reservado pelos seus próprios valores. (Se você estava usando o módulo de
visualização anterior, o parâmetro para a habilitação de recursos é EnableAzureFilesAadIntegrationForSMB .)
# Create a new storage account

New-AzStorageAccount -ResourceGroupName "<resource-group-name>" `
-Name "<storage-account-name>" `
-Location "<azure-region>" `
-SkuName Standard_LRS `
-Kind StorageV2 `
-EnableAzureActiveDirectoryDomainServicesForFile $true
Para habilitar esse recurso em contas de armazenamento existentes, use o seguinte comando:
# Update a storage account

Set-AzStorageAccount -ResourceGroupName "<resource-group-name>" `
-Name "<storage-account-name>" `
-EnableAzureActiveDirectoryDomainServicesForFile $true
CLI do Azure
Para habilitar a autenticação do Azure AD em SMB com o CLI do Azure, instale a versão mais recente da CLI
(versão 2.0.70 ou mais recente). Para obter mais informações sobre como instalar o CLI do Azure, consulte
instalar o CLI do Azure.
Para criar uma nova conta de armazenamento, chameAZ Storage Account Createe defina a
--enable-files-aadds Propriedade como true . No exemplo a seguir, lembre-se de substituir os valores de
espaço reservado pelos seus próprios valores. (Se você estava usando o módulo de visualização anterior, o
parâmetro para habilitação de recurso é File-AAD .)
# Create a new storage account
az storage account create -n <storage-account-name> -g <resource-group-name> --enable-files-aadds $true
Para habilitar esse recurso em contas de armazenamento existentes, use o seguinte comando:
# Update a new storage account

az storage account update -n <storage-account-name> -g <resource-group-name> --enable-files-aadds $true
2 atribuir permissões de acesso a uma identidade

Para acessar os recursos de arquivos do Azure com autenticação baseada em identidade, uma identidade (um
usuário, grupo ou entidade de serviço) deve ter as permissões necessárias no nível de compartilhamento. Esse
processo é semelhante à especificação de permissões de compartilhamento do Windows, em que você
especifica o tipo de acesso que um usuário específico tem a um compartilhamento de arquivos. As orientações
nesta seção demonstram como atribuir ler, gravar ou excluir as permissões para um compartilhamento de
arquivos para uma identidade.
Introduzimos três funções internas do Azure para conceder permissões de nível de compartilhamento aos
usuários:
O leitor de compar tilhamento SMB de dados de arquivo de armazenamento permite acesso de
leitura em compartilhamentos de arquivos de armazenamento do Azure via SMB
O colaborador de compar tilhamento SMB de dados de arquivo de armazenamento permite acesso
de leitura, gravação e exclusão em compartilhamentos de arquivos de armazenamento do Azure via SMB.
O colaborador elevado de compar tilhamento SMB de dados de arquivo de armazenamento
permite a leitura, gravação, exclusão e modificação de permissões NTFS em compartilhamentos de arquivos
de armazenamento do Azure via SMB.
IMPORTANT
O controle administrativo total de um compartilhamento de arquivos, incluindo a capacidade de apropriar-se de um
arquivo, requer o uso da chave da conta de armazenamento. O controle administrativo não é compatível com credenciais
do Azure AD.
Você pode usar o portal do Azure, o PowerShell ou o CLI do Azure para atribuir as funções internas à identidade
do Azure AD de um usuário para conceder permissões de nível de compartilhamento. Lembre-se de que a
atribuição de função RBAC de nível de compartilhamento pode levar algum tempo para estar em vigor.
NOTE
Lembre-se de sincronizar suas credenciais do AD DS com o AD do Azure se você planeja usar sua AD DS local para
autenticação. A sincronização de hash de senha de AD DS para o Azure AD é opcional. A permissão de nível de
compartilhamento será concedida à identidade do Azure AD que é sincronizada a partir de seu AD DS local.
A recomendação geral é usar a permissão de nível de compartilhamento para o gerenciamento de acesso de alto
nível para um grupo do AD que representa um grupo de usuários e identidades e, em seguida, aproveitar as
permissões de NTFS para o controle de acesso granular no nível de diretório/arquivo.
Portal do Azure
Para atribuir uma função de RBAC a uma identidade do Azure AD, usando o portal do Azure, siga estas etapas:
1. No portal do Azure, vá para o compartilhamento de arquivos ou crie um compartilhamento de arquivos.
2. Selecione controle de acesso (iam) .
3. Selecione Adicionar uma atribuição de função
4. Na folha Adicionar atribuição de função , selecione a função interna apropriada (leitor de
compartilhamento SMB de dados de arquivo de armazenamento, colaborador de compartilhamento SMB de
dados de arquivo de armazenamento) na lista de funções . Deixe atribuir acesso à na configuração padrão:
usuário, grupo ou entidade de ser viço do Azure ad . Selecione a identidade do Azure AD de destino por
nome ou endereço de email.
5. Selecione salvar para concluir a operação de atribuição de função.
PowerShell
O exemplo do PowerShell a seguir mostra como atribuir uma função de RBAC a uma identidade do Azure AD,
com base no nome de entrada. Para obter mais informações sobre como atribuir funções do RBAC ao
PowerShell, consulte Gerenciar acesso usando o RBAC e o Azure PowerShell.
#Get the name of the custom role

$FileShareContributorRole = Get-AzRoleDefinition "<role-name>" #Use one of the built-in roles: Storage File
Data SMB Share Reader, Storage File Data SMB Share Contributor, Storage File Data SMB Share Elevated
Contributor
#Constrain the scope to the target file share
$scope = "/subscriptions/<subscription-id>/resourceGroups/<resource-
name>"
#Assign the custom role to the target identity with the specified scope.
New-AzRoleAssignment -SignInName <user-principal-name> -RoleDefinitionName $FileShareContributorRole.Name -
Scope $scope
CLI
O comando da CLI 2,0 a seguir mostra como atribuir uma função de RBAC a uma identidade do Azure AD, com
base no nome de entrada. Para obter mais informações sobre como atribuir funções RBAC com CLI do Azure,
consulte gerenciar o acesso usando RBAC e CLI do Azure.
#Assign the built-in role to the target identity: Storage File Data SMB Share Reader, Storage File Data SMB
Share Contributor, Storage File Data SMB Share Elevated Contributor
az role assignment create --role "<role-name>" --assignee <user-principal-name> --scope
"/subscriptions/<subscription-id>/resourceGroups/<resource-
name>"
3 configurar permissões NTFS em relação ao SMB

Depois de atribuir permissões no nível de compartilhamento com o RBAC, você deve atribuir permissões de
NTFS corretas no nível raiz, de diretório ou de arquivo. Considere as permissões de nível de compartilhamento
como o gatekeeper de alto nível que determina se um usuário pode acessar o compartilhamento. Enquanto as
permissões de NTFS atuam em um nível mais granular para determinar quais operações o usuário pode fazer no
nível do diretório ou do arquivo.
Os arquivos do Azure dá suporte a todo o conjunto de permissões de NTFS básicos e avançados. Você pode
exibir e configurar as permissões NTFS em diretórios e arquivos em um compartilhamento de arquivos do Azure
montando o compartilhamento e usando o explorador de arquivos do Windows ou executando o comando
icacls do Windows ou Set-ACL .
Para configurar o NTFS com permissões de superusuário, você deve montar o compartilhamento usando sua
chave de conta de armazenamento de sua VM ingressada no domínio. Siga as instruções na próxima seção para
montar um compartilhamento de arquivos do Azure no prompt de comando e configurar as permissões NTFS
adequadamente.
Conjuntos de permissões a seguir têm suporte para o diretório raiz de um compartilhamento de arquivos:
BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Users:(Rx)
BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
NT AUTHORITY\Authenticated Users:(OI)(CI)(M)
NT AUTHORITY\SYSTEM:(F)
CREATOR OWNER:(OI)(CI)(IO)(F)
Montar um compartilhamento de arquivos do Azure no prompt de comando
Usar o Windows net use comando para montar o compartilhamento de arquivos do Azure. Lembre-se de
substituir os valores de espaço reservado no exemplo a seguir pelos seus próprios valores. Para obter mais
informações sobre como montar compartilhamentos de arquivos, consulte usar um compartilhamento de
net use <desired-drive-letter>: \\<storage-account-name>.file.core.windows.net\<share-name> /user:Azure\

<storage-account-name> <storage-account-key>
Se você tiver problemas ao conectar-se aos arquivos do Azure, consulte a ferramenta de solução de problemas
que publicamos para erros de montagem de arquivos do Azure no Windows. Também fornecemos orientações
Configurar permissões NTFS com o explorador de arquivos do Windows
Use o explorador de arquivos do Windows para conceder permissão total a todos os diretórios e arquivos no
compartilhamento de arquivos, incluindo o diretório raiz.
1. Abra o explorador de arquivos do Windows e clique com o botão direito do mouse no arquivo/diretório e
selecione Propriedades .
2. Selecione a guia Segurança .
3. Selecione Editar... para alterar permissões.
4. Você pode alterar as permissões de usuários existentes ou selecionar Adicionar... para conceder permissões
a novos usuários.
5. Na janela de prompt para adicionar novos usuários, insira o nome de usuário de destino ao qual você deseja
conceder permissão na caixa Inserir os nomes de objeto a serem selecionados e selecione verificar
nomes para localizar o nome UPN completo do usuário de destino.
6. Selecione OK .
7. Na guia segurança , selecione todas as permissões que você deseja conceder ao novo usuário.
8. Escolha Aplicar .
Configurar permissões NTFS com icacls
Use o seguinte comando do Windows para conceder permissões completas para todos os diretórios e arquivos
no compartilhamento de arquivos, incluindo o diretório raiz. Lembre-se de substituir os valores de espaço
reservado no exemplo pelos seus próprios valores.
icacls <mounted-drive-letter>: /grant <user-email>:(f)

Para obter mais informações sobre como usar o icacls para definir permissões NTFS e sobre os diferentes tipos
de permissões com suporte, consulte a referência de linha de comando para icacls.
4 montar um compartilhamento de arquivos de uma VM ingressada

no domínio
O processo a seguir verifica se as permissões de acesso e compartilhamento de arquivos foram configuradas
corretamente e se você pode acessar um compartilhamento de arquivos do Azure de uma VM ingressada no
domínio. Lembre-se de que a atribuição de função RBAC de nível de compartilhamento pode levar algum tempo
para estar em vigor.
Entre na VM usando a identidade do Azure AD à qual você concedeu permissões, conforme mostrado na
imagem a seguir. Se você habilitou a autenticação de AD DS local para arquivos do Azure, use suas credenciais
de AD DS. Para a autenticação de AD DS do Azure, entre com as credenciais do Azure AD.
Use o comando a seguir para montar o compartilhamento de arquivos do Azure. Lembre-se de substituir os
valores de espaço reservado por seus próprios valores. Como você foi autenticado, não precisa fornecer a chave
de conta de armazenamento, as credenciais de AD DS locais ou as credenciais de AD DS do Azure. Há suporte
para a experiência de logon único para autenticação com AD DS local ou AD DS do Azure. Se você tiver
problemas para montar com credenciais de AD DS, consulte solucionar problemas de arquivos do Azure no
Windows para obter diretrizes.
net use <desired-drive-letter>: \\<storage-account-name>.file.core.windows.net\<share-name>
Agora você habilitou com êxito a autenticação do Azure AD DS sobre o SMB e atribuiu uma função
personalizada que fornece acesso a um compartilhamento de arquivos do Azure com uma identidade do Azure
AD. Para conceder a usuários adicionais acesso ao seu compartilhamento de arquivos, siga as instruções nas
seções atribuir permissões de acesso para usar uma identidade e configurar permissões NTFS em relação ao
SMB.
Próximas etapas
Para obter mais informações sobre os arquivos do Azure e como usar o Azure AD em SMB, consulte estes
recursos:
Visão geral do suporte de autenticação baseada em identidade de arquivos do Azure para acesso SMB
Habilitar TLS seguro para cliente de Armazenamento
do Microsoft Azure
Os protocolos TLS e SSL são protocolos criptográficos que fornecem segurança de comunicações em uma rede de
computadores. Foram localizados SSL 1.0, 2.0 e 3.0 vulneráveis. Eles foram proibidos pelo RFC. O TLS 1.0 torna-se
não seguro por usar codificação de Bloco (DES CBC e RC2 CBC) e criptografia de Fluxo (RC4) não seguras. O
conselho PCI também recomendou a migração para versões superiores do TLS. Para obter mais detalhes, consulte
Protocolo TLS.
O Armazenamento do Microsoft Azure encerrou o SSL 3.0 desde 2015 e usa o TLS 1.2 em pontos de extremidade
HTTPs públicos, mas o TLS 1.0 e o TLS 1.1 ainda têm suporte para compatibilidade com versões anteriores.
Para garantir uma conexão segura e compatível com o Armazenamento do Microsoft Azure, é necessário habilitar o
TLS 1.2 ou versão mais recente no lado do cliente antes de enviar solicitações para operar o serviço de
Habilitar TLS 1.2 no cliente .NET

Para o cliente negociar TLS 1.2, SO e a versão do .NET Framework, ambos precisam dar suporte ao TLS 1.2.
Consulte mais detalhes em Suporte para TLS 1.2.
O exemplo a seguir mostra como habilitar TLS 1.2 no cliente .NET.
static void EnableTls12()

{
// Enable TLS 1.2 before connecting to Azure Storage
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
// Connect to Azure Storage

CloudStorageAccount storageAccount =
CloudStorageAccount.Parse("DefaultEndpointsProtocol=https;AccountName={yourstorageaccount};AccountKey=
{yourstorageaccountkey};EndpointSuffix=core.windows.net");
CloudBlobContainer container = blobClient.GetContainerReference("foo");

container.CreateIfNotExists();
}
Habilitar TLS 1.2 no cliente do PowerShell

NOTE
O exemplo a seguir mostra como habilitar TLS 1.2 no cliente do PowerShell.

# Enable TLS 1.2 before connecting to Azure Storage
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;
$resourceGroup = "{YourResourceGroupName}"
$storageAccountName = "{YourStorageAccountNme}"
$prefix = "foo"
# Connect to Azure Storage

$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroup -Name $storageAccountName
$ctx = $storageAccount.Context
$listOfContainers = Get-AzStorageContainer -Context $ctx -Prefix $prefix
$listOfContainers
Verificar a conexão TLS 1.2

É possível usar o Fiddler para verificar se o TLS 1.2 realmente é utilizado. Abra o Fiddler para iniciar a captura do
tráfego de rede do cliente e execute o exemplo acima. Em seguida, você poderá localizar a versão do TLS na
conexão que o exemplo executa.
A captura de tela a seguir é um exemplo para a verificação.
Confira também
Protocolo TLS
Conformidade com PCI no TLS
Habilitar TLS no cliente de Java
AzCopy é um utilitário de linha de comando que você pode usar para copiar BLOBs ou arquivos de ou para uma conta de
armazenamento. Este artigo ajuda você a baixar o AzCopy, conectar-se à sua conta de armazenamento e, em seguida, transferir
arquivos.
NOTE
AzCopy V10 é a versão com suporte no momento do AzCopy.
Se você precisar usar uma versão anterior do AzCopy, consulte a seção usar a versão anterior do AzCopy deste artigo.
Baixar o AzCopy
Primeiro, baixe o arquivo executável AzCopy V10 em qualquer diretório em seu computador. AzCopy V10 é apenas um arquivo
executável, portanto, não há nada a ser instalado.
Windows de 64 bits (zip)
Windows de 32 bits (zip)
Linux (tar)
MacOS (zip)
Esses arquivos são compactados como um arquivo zip (Windows e Mac) ou um arquivo tar (Linux). Para baixar e descompactar o
arquivo tar no Linux, consulte a documentação para sua distribuição do Linux.
NOTE
Se você quiser copiar dados de e para o serviço de armazenamento de tabelas do Azure , instale o AzCopy versão 7,3.
Executar AzCopy
Para sua conveniência, considere adicionar o local do diretório do executável AzCopy ao caminho do sistema para facilitar o uso.
Dessa forma, você pode azcopy digitar de qualquer diretório em seu sistema.
Se você optar por não adicionar o diretório AzCopy ao seu caminho, terá que alterar os diretórios para o local do seu executável
AzCopy e digitar azcopy ou .\azcopy em prompts de comando do Windows PowerShell.
Para ver uma lista de comandos, digite azcopy -h e pressione a tecla Enter.
Para saber mais sobre um comando específico, apenas inclua o nome do comando (por exemplo: azcopy list -h ).
Para encontrar a documentação de referência detalhada para cada comando e parâmetro de comando, consulte azcopy
NOTE
Como proprietário de sua conta de armazenamento do Azure, você não recebe automaticamente permissões para acessar dados. Antes de poder
fazer qualquer coisa significativa com o AzCopy, você precisa decidir como fornecerá credenciais de autorização para o serviço de armazenamento.
Escolha como você fornecerá credenciais de autorização

Você pode fornecer credenciais de autorização usando o Azure Active Directory (AD) ou usando um token SAS (assinatura de acesso
compartilhado).
Use esta tabela como um guia:
T IP O DE A RM A Z EN A M EN TO M ÉTO DO DE A UTO RIZ A Ç Ã O AT UA L M EN T E C O M SUP O RT E
Armazenamento de Blobs SAS do Azure AD &
Armazenamento de BLOBs (namespace hierárquico) SAS do Azure AD &
Armazenamento de arquivos Somente SAS
Opção 1: usar Azure Active Directory

Usando Azure Active Directory, você pode fornecer credenciais uma vez, em vez de ter que acrescentar um token SAS a cada
comando.
NOTE
Na versão atual, se você planeja copiar BLOBs entre contas de armazenamento, precisará acrescentar um token SAS a cada URL de origem. Você
pode omitir o token SAS somente da URL de destino. Para obter exemplos, consulte copiar BLOBs entre contas de armazenamento.
O nível de autorização de que você precisa se baseia se você planeja carregar arquivos ou apenas baixá-los.
Se você apenas deseja baixar arquivos, verifique se o leitor de dados de blob de armazenamento foi atribuído à sua identidade de
usuário, identidade gerenciada ou entidade de serviço.
Identidades de usuário, identidades gerenciadas e entidades de serviço são cada um tipo de entidade de segurança, portanto,
usaremos a entidade de segurança do termo para o restante deste artigo.
Se você quiser carregar arquivos, verifique se uma dessas funções foi atribuída à sua entidade de segurança:
Colaborador de dados de blob de armazenamento
Proprietário de Dados do Blob de Armazenamento
Essas funções podem ser atribuídas à entidade de segurança em qualquer um desses escopos:
Contêiner (sistema de arquivos)
Conta de armazenamento
Resource group
Subscription
Para saber como verificar e atribuir funções, consulte conceder acesso ao blob do Azure e dados de fila com RBAC no portal do Azure.
NOTE
Tenha em mente que as atribuições de função do RBAC podem levar até cinco minutos para serem propagadas.
Você não precisará ter uma dessas funções atribuídas à entidade de segurança se sua entidade de segurança for adicionada à lista de
controle de acesso (ACL) do contêiner ou diretório de destino. Na ACL, sua entidade de segurança precisa de permissão de gravação
no diretório de destino e permissão de execução no contêiner e em cada diretório pai.
Para saber mais, consulte controle de acesso em Azure data Lake Storage Gen2.
Autenticar uma identidade de usuário
Depois de verificar se a identidade do usuário recebeu o nível de autorização necessário, abra um prompt de comando, digite o
comando a seguir e pressione a tecla ENTER.
azcopy login
Se você pertencer a mais de uma organização, inclua a ID de locatário da organização à qual a conta de armazenamento pertence.
azcopy login --tenant-id=<tenant-id>
Substitua o <tenant-id> espaço reservado pela ID de locatário da organização à qual a conta de armazenamento pertence. Para
localizar a ID de locatário, selecione Azure Active Director y Propriedades de > > ID de diretório no portal do Azure.
Esse comando retorna um código de autenticação e a URL de um site. Abra o site, forneça o código e, em seguida, escolha o botão
Avançar .
Uma janela de entrada será exibida. Nessa janela, entre em sua conta do Azure usando suas credenciais de conta do Azure. Depois de
entrar com êxito, feche a janela do navegador e comece a usar o AzCopy.
Autenticar uma entidade de serviço
Essa é uma ótima opção se você planeja usar o AzCopy dentro de um script que é executado sem interação do usuário, especialmente
quando executado no local. Se você planeja executar o AzCopy em VMs que são executadas no Azure, uma identidade de serviço
gerenciada é mais fácil de administrar. Para saber mais, consulte a seção autenticar uma identidade gerenciada deste artigo.
Antes de executar um script, você precisa entrar interativamente pelo menos uma vez para que possa fornecer AzCopy com as
credenciais de sua entidade de serviço. Essas credenciais são armazenadas em um arquivo seguro e criptografado para que o script
não precise fornecer essas informações confidenciais.
Você pode entrar em sua conta usando um segredo do cliente ou usando a senha de um certificado associado ao registro do
aplicativo da sua entidade de serviço.
Para saber mais sobre como criar a entidade de serviço, consulte como: usar o portal para criar um aplicativo do Azure AD e uma
entidade de serviço que possa acessar recursos.
Para saber mais sobre as entidades de serviço em geral, consulte objetos de aplicativo e entidade de serviço no Azure Active Directory
U sa n d o u m se g r e d o d o c l i e n t e
Comece definindo a AZCOPY_SPA_CLIENT_SECRET variável de ambiente como o segredo do cliente do registro do aplicativo da sua
entidade de serviço.
NOTE
Certifique-se de definir esse valor no prompt de comando e não nas configurações de variável de ambiente do seu sistema operacional. Dessa
forma, o valor estará disponível somente para a sessão atual.
Este exemplo mostra como você pode fazer isso no PowerShell.
$env:AZCOPY_SPA_CLIENT_SECRET="$(Read-Host -prompt "Enter key")"

NOTE
Considere usar um prompt, conforme mostrado neste exemplo. Dessa forma, sua senha não aparecerá no histórico de comandos do console.
Em seguida, digite o comando a seguir e pressione a tecla ENTER.
azcopy login --service-principal --application-id <application-id> --tenant-id=<tenant-id>
Substitua o espaço reservado pela ID do aplicativo do registro do aplicativo da sua entidade de serviço. Substitua o
<application-id>
<tenant-id> espaço reservado pela ID de locatário da organização à qual a conta de armazenamento pertence. Para localizar a ID de
locatário, selecione Azure Active Director y Propriedades de > > ID de diretório no portal do Azure.
U sa n d o u m c e r t i fi c a d o
Se preferir usar suas próprias credenciais para autorização, você poderá carregar um certificado para o registro do aplicativo e, em
seguida, usar esse certificado para fazer logon.
Além de carregar seu certificado para o registro do aplicativo, você também precisará ter uma cópia do certificado salvo no
computador ou na VM em que o AzCopy será executado. Esta cópia do certificado deve estar no. PFX ou. O formato PEM e deve incluir
a chave privada. A chave privada deve ser protegida por senha. Se você estiver usando o Windows e seu certificado existir somente
em um repositório de certificados, certifique-se de exportar esse certificado para um arquivo PFX (incluindo a chave privada). Para
obter diretrizes, consulte Export-PfxCertificate
Em seguida, defina AZCOPY_SPA_CERT_PASSWORD a variável de ambiente como a senha do certificado.
NOTE
Certifique-se de definir esse valor no prompt de comando e não nas configurações de variável de ambiente do seu sistema operacional. Dessa
forma, o valor estará disponível somente para a sessão atual.
Este exemplo mostra como você pode executar essa tarefa no PowerShell.
$env:AZCOPY_SPA_CERT_PASSWORD="$(Read-Host -prompt "Enter key")"
Em seguida, digite o comando a seguir e pressione a tecla ENTER.
azcopy login --service-principal --certificate-path <path-to-certificate-file> --tenant-id=<tenant-id>
Substitua o <path-to-certificate-file> espaço reservado pelo caminho relativo ou totalmente qualificado para o arquivo de
certificado. AzCopy salva o caminho para esse certificado, mas não salva uma cópia do certificado, portanto, certifique-se de manter
esse certificado em vigor. Substitua o <tenant-id> espaço reservado pela ID de locatário da organização à qual a conta de
armazenamento pertence. Para localizar a ID de locatário, selecione Azure Active Director y Propriedades de > > ID de
diretório no portal do Azure.
NOTE
Considere usar um prompt, conforme mostrado neste exemplo. Dessa forma, sua senha não aparecerá no histórico de comandos do console.
Autenticar uma identidade gerenciada

Essa é uma ótima opção se você planeja usar o AzCopy dentro de um script que é executado sem interação do usuário e o script é
executado de uma VM (máquina virtual) do Azure. Ao usar essa opção, você não precisará armazenar nenhuma credencial na VM.
Você pode entrar em sua conta usando a identidade gerenciada de todo o sistema que você habilitou em sua VM ou usando a ID do
cliente, a ID de objeto ou a ID de recurso de uma identidade gerenciada atribuída pelo usuário que você atribuiu à sua VM.
Para saber mais sobre como habilitar uma identidade gerenciada em todo o sistema ou criar uma identidade gerenciada atribuída
pelo usuário, consulte Configurar identidades gerenciadas para recursos do Azure em uma VM usando o portal do Azure.
U sa n d o u m a i d e n t i d a d e g e r e n c i a d a e m t o d o o si st e m a
Primeiro, verifique se você habilitou uma identidade gerenciada em todo o sistema em sua VM. Consulte identidade gerenciada
atribuída pelo sistema.
Em seguida, no console de comando, digite o comando a seguir e pressione a tecla ENTER.
azcopy login --identity
U sa n d o u m a i d e n t i d a d e g e r e n c i a d a a t r i b u í d a p e l o u su á r i o
Primeiro, verifique se você habilitou uma identidade gerenciada atribuída pelo usuário em sua VM. Consulte identidade gerenciada
atribuída pelo usuário.
Em seguida, no console de comando, digite qualquer um dos comandos a seguir e pressione a tecla ENTER.
azcopy login --identity --identity-client-id "<client-id>"
Substitua o <client-id> espaço reservado pela ID do cliente da identidade gerenciada atribuída pelo usuário.
azcopy login --identity --identity-object-id "<object-id>"
Substitua o <object-id> espaço reservado pela ID de objeto da identidade gerenciada atribuída pelo usuário.
azcopy login --identity --identity-resource-id "<resource-id>"
Substitua o <resource-id> espaço reservado pela ID de recurso da identidade gerenciada atribuída pelo usuário.
Opção 2: usar um token SAS
Você pode acrescentar um token SAS a cada URL de origem ou de destino que usa em seus comandos AzCopy.
Esse comando de exemplo copia recursivamente os dados de um diretório local para um contêiner de BLOB. Um token SAS fictício é
acrescentado ao final do da URL do contêiner.
azcopy copy "C:\local\path" "https://account.blob.core.windows.net/mycontainer1/?sv=2018-03-

28&ss=bjqt&srt=sco&sp=rwddgcup&se=2019-05-01T05:01:17Z&st=2019-04-
30T21:01:17Z&spr=https&sig=MGCXiyEzbtttkr3ewJIh2AR8KrghSy1DGM9ovN734bQF4%3D" --recursive=true
Para saber mais sobre tokens SAS e como obter um, consulte usando assinaturas de acesso compartilhado (SAS).
Transferir arquivos
Depois de autenticar sua identidade ou obter um token SAS, você pode começar a transferir arquivos.
Para encontrar comandos de exemplo, consulte qualquer um desses artigos.
Transferir dados com o AzCopy e o Armazenamento de Blobs
Transferir dados com o AzCopy e o Armazenamento de Arquivos
Transferir dados com o AzCopy e os buckets do Amazon S3
Transferir dados com AzCopy e armazenamento de Azure Stack
Usar AzCopy em um script

Obter um link de download estático
Ao longo do tempo, o link de download do AzCopy apontará para novas versões do AzCopy. Se o script baixar AzCopy, o script poderá
parar de funcionar se uma versão mais recente do AzCopy modificar os recursos dependentes do seu script.
Para evitar esses problemas, obtenha um link estático (sem alteração) para a versão atual do AzCopy. Dessa forma, o script baixará a
mesma versão exata do AzCopy cada vez que for executado.
Para obter o link, execute este comando:
SIST EM A O P ERA C IO N A L C O M A N DO
Linux curl -s -D- https://aka.ms/downloadazcopy-v10-linux | grep

^Location
Windows (curl https://aka.ms/downloadazcopy-v10-windows -

MaximumRedirection 0 -ErrorAction
silentlycontinue).headers.location
NOTE
Para o Linux --strip-components=1 , no tar comando Remove a pasta de nível superior que contém o nome da versão e, em vez disso, extrai
o binário diretamente para a pasta atual. Isso permite que o script seja atualizado com uma nova versão do azcopy atualizando apenas a wget
URL.
A URL aparece na saída deste comando. O script pode então baixar o AzCopy usando essa URL.
Linux wget -O azcopy_v10.tar.gz https://aka.ms/downloadazcopy-v10-

linux && tar -xf azcopy_v10.tar.gz --strip-components=1
Windows Invoke-WebRequest
https://azcopyvnext.azureedge.net/release20190517/azcopy_windows_amd64_10.1.2.zi
-OutFile azcopyv10.zip <<Unzip here>>
Caracteres especiais de escape em tokens SAS

Em arquivos em lotes que têm .cmd a extensão, você terá que escapar os % caracteres que aparecem nos tokens SAS. Você pode
fazer isso adicionando um caractere adicional % ao lado dos caracteres % existentes na cadeia de caracteres do token SAS.
Executar scripts usando Jenkins
Se você planeja usar o Jenkins para executar scripts, certifique-se de colocar o comando a seguir no início do script.
/usr/bin/keyctl new_session
Usar AzCopy no Gerenciador de Armazenamento do Azure

Gerenciador de armazenamento usa AzCopy para executar todas as operações de transferência de dados. Você pode usar Gerenciador
de armazenamento se quiser aproveitar as vantagens de desempenho do AzCopy, mas preferir usar uma interface gráfica do usuário
em vez da linha de comando para interagir com seus arquivos.
Gerenciador de Armazenamento usa sua chave de conta para executar operações, portanto, depois de entrar no Gerenciador de
Armazenamento, você não precisará fornecer credenciais de autorização adicionais.
Usar a versão anterior do AzCopy

Se você precisar usar a versão anterior do AzCopy, consulte um dos links a seguir:
AzCopy no Windows (v8)
AzCopy no Linux (v7)
Configurar, otimizar e solucionar problemas do AzCopy

Consulte Configurar, otimizar e solucionar problemas do AzCopy
Próximas etapas
Se você tiver dúvidas, problemas ou comentários gerais, envie-os na página do GitHub .
AzCopy é um utilitário de linha de comando que você pode usar para copiar BLOBs ou arquivos de ou para uma conta de armazenamento. Este
artigo contém comandos de exemplo que funcionam com os arquivos do Azure.
Antes de começar, consulte o artigo introdução ao AzCopy para baixar o AzCopy e se familiarizar com a ferramenta.
TIP
Os exemplos neste artigo incluem argumentos de caminho com aspas simples (' '). Use aspas simples em todos os shells de comando, exceto pelo shell de
comando do Windows (cmd. exe). Se você estiver usando um shell de comando do Windows (cmd. exe), coloque argumentos de caminho com aspas duplas ("")
em vez de aspas simples (' ').
Criar compartilhamentos de arquivos

Você pode usar o comando azcopy Make para criar um compartilhamento de arquivos. O exemplo nesta seção cria um compartilhamento de
arquivos chamado myfileshare .
Sintaxe azcopy make 'https://<storage-account-

name>.file.core.windows.net/<file-share-name><SAS-token>'
Exemplo azcopy make 'https://mystorageaccount.file.core.windows.net/myfileshare?sv=2018-03-

28&ss=bjqt&srs=sco&sp=rjklhjup&se=2019-05-10T04:37:48Z&st=2019-05-
09T20:37:48Z&spr=https&sig=%2FSOVEFfsKDqRry4bk3qz1vAQFwY5DDzp2%2B%2F3Eykf%2FJLs%3D'
Para obter documentos de referência detalhados, consulte Make azcopy.
Carregar arquivos
Você pode usar o comando azcopy Copy para carregar arquivos e diretórios do seu computador local.
Esta seção contém os seguintes exemplos:
Carregar um arquivo
Carregar um diretório
Carregar o conteúdo de um diretório
Carregar um arquivo específico
TIP
Você pode ajustar sua operação de carregamento usando sinalizadores opcionais. Aqui estão alguns exemplos.
CENÁR I O SI NAL I Z AD O R
Copie listas de controle de acesso (ACLs) junto com os arquivos. --Preser ve-SMB-permissões =[verdadeiro|falso]
Copie informações de propriedade SMB junto com os arquivos. --Preser ve-SMB-info =[true|false]
Carregar arquivos como BLOBs de acréscimo ou BLOBs de página. --blob-Type =[BlockBlob|PageBlob|AppendBlob]
Carregue para uma camada de acesso específica (como a camada de arquivo --Block-blob-camada =[nenhum|arquivo|frio|quente]
morto).
Para obter uma lista completa, consulte Opções.
NOTE
AzCopy não calcula e armazena automaticamente o código hash MD5 do arquivo. Se você quiser que o AzCopy faça isso, anexe o --put-md5 sinalizador a cada
comando de cópia. Dessa forma, quando o arquivo for baixado, AzCopy calculará um hash MD5 para dados baixados e verificará se o hash MD5 armazenado na
Propriedade do Content-md5 arquivo corresponde ao hash calculado.
Carregar um arquivo
Sintaxe azcopy copy '<local-file-path>' 'https://<storage-account-
name>.file.core.windows.net/<file-share-name>/<file-name><SAS-
token>'
Exemplo azcopy copy 'C:\myDirectory\myTextFile.txt'

'https://mystorageaccount.file.core.windows.net/myfileshare/myTextFile.txt?sv=2018-
03-28&ss=bjqt&srs=sco&sp=rjklhjup&se=2019-05-10T04:37:48Z&st=2019-05-
Você também pode carregar um arquivo usando um símbolo curinga (*) em qualquer lugar no caminho do arquivo ou nome do arquivo. Por
exemplo: 'C:\myDirectory\*.txt' , ou C:\my*\*.txt .
Carregar um diretório
Este exemplo copia um diretório (e todos os arquivos nesse diretório) para um compartilhamento de arquivos. O resultado é um diretório no
compartilhamento de arquivos com o mesmo nome.
Sintaxe azcopy copy '<local-directory-path>' 'https://<storage-account-

name>.file.core.windows.net/<file-share-name><SAS-token>' --
recursive
Exemplo azcopy copy 'C:\myDirectory'

'https://mystorageaccount.file.core.windows.net/myfileshare?sv=2018-03-
28&ss=bjqt&srs=sco&sp=rjklhjup&se=2019-05-10T04:37:48Z&st=2019-05-
--recursive
Para copiar para um diretório dentro do compartilhamento de arquivos, basta especificar o nome desse diretório na cadeia de caracteres de
comando.

'https://mystorageaccount.file.core.windows.net/myfileshare/myFileShareDirectory?
sv=2018-03-28&ss=bjqt&srs=sco&sp=rjklhjup&se=2019-05-10T04:37:48Z&st=2019-05-
--recursive
Se você especificar o nome de um diretório que não existe no compartilhamento de arquivos, o AzCopy criará um novo diretório com esse nome.
Carregar o conteúdo de um diretório
Você pode carregar o conteúdo de um diretório sem copiar o próprio diretório contido usando o símbolo curinga (*).
Sintaxe azcopy copy '<local-directory-path>/*' 'https://<storage-account-

name>.file.core.windows.net/<file-share-name>/<directory-path><SAS-
token>
Exemplo azcopy copy 'C:\myDirectory\*'

09T20:37:48Z&spr=https&sig=%2FSOVEFfsKDqRry4bk3qz1vAQFwY5DDzp2%2B%2F3Eykf%2FJLs%3D"
NOTE
Acrescente o --recursive sinalizador para carregar arquivos em todos os subdiretórios.
Carregar arquivos específicos

Você pode especificar nomes de arquivo completos ou usar nomes parciais com caracteres curinga (*).
Especificar vários nomes de arquivo completos
Use o comando azcopy Copy com a --include-path opção. Separe os nomes de arquivo individuais usando um ponto ; -e-vírgula ().

name>.file.core.windows.net/<file-share-or-directory-name><SAS-
token>' --include-path <semicolon-separated-file-list>

28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-07-04T05:30:08Z&st=2019-07-
03T21:30:08Z&spr=https&sig=CAfhgnc9gdGktvB=ska7bAiqIddM845yiyFwdMH481QA8%3D'
--include-path 'photos;documents\myFile.txt'
Neste exemplo, AzCopy transfere o C:\myDirectory\photos diretório e o C:\myDirectory\documents\myFile.txt arquivo. Você precisa incluir a
--recursive opção para transferir todos os arquivos no C:\myDirectory\photos diretório.
Você também pode excluir arquivos usando a --exclude-path opção. Para saber mais, consulte azcopy Copy Reference docs.
Usar caracteres curinga
Use o comando azcopy Copy com a --include-pattern opção. Especifique nomes parciais que incluam os caracteres curinga. Separe os nomes
usando um semicolin ( ; ).

token>' --include-pattern <semicolon-separated-file-list-with-
wildcard-characters>

--include-pattern 'myFile*.txt;*.pdf*'
Você também pode excluir arquivos usando a --exclude-pattern opção. Para saber mais, consulte azcopy Copy Reference docs.
As --include-pattern opções --exclude-pattern e aplicam-se somente a nomes de filename e não ao caminho. Se você quiser copiar todos os
arquivos de texto que existem em uma árvore de diretório, use a –recursive opção para obter a árvore de diretórios inteira e, em seguida
–include-pattern , use *.txt o e especifique para obter todos os arquivos de texto.
Baixar arquivos
Você pode usar o comando azcopy Copy para baixar arquivos, diretórios e compartilhamentos de arquivos em seu computador local.
Baixar um arquivo
Baixar um diretório
Baixar o conteúdo de um diretório
Baixar arquivos específicos
TIP
Você pode ajustar sua operação de download usando sinalizadores opcionais. Aqui estão alguns exemplos.
Descompacte arquivos automaticamente. --descompactar
NOTE
Se o Content-md5 valor da propriedade de um arquivo contiver um hash, AzCopy calculará um hash MD5 para os dados baixados e verificará se o hash MD5
armazenado Content-md5 na Propriedade do arquivo corresponde ao hash calculado. Se esses valores não corresponderem, o download falhará, a menos que
você --check-md5=NoCheck substitua --check-md5=LogOnly esse comportamento acrescentando ou ao comando de cópia.
Baixar um arquivo
Sintaxe azcopy copy 'https://<storage-account-

name>.file.core.windows.net/<file-share-name>/<file-path><SAS-
token>' '<local-file-path>'
Exemplo azcopy copy

'https://mystorageaccount.file.core.windows.net/myfileshare/myTextFile.txt?sv=2018-
03-28&ss=bjqt&srs=sco&sp=rjklhjup&se=2019-05-10T04:37:48Z&st=2019-05-
'C:\myDirectory\myTextFile.txt'
Baixar um diretório
token>' '<local-directory-path>' --recursive
Exemplo azcopy copy

'C:\myDirectory' --recursive
Este exemplo resulta em um diretório chamado C:\myDirectory\myFileShareDirectory que contém todos os arquivos baixados.
Baixar o conteúdo de um diretório
Você pode baixar o conteúdo de um diretório sem copiar o próprio diretório contido usando o símbolo curinga (*).

name>.file.core.windows.net/<file-share-name>/*<SAS-token>' '<local-
directory-path>/'
Exemplo azcopy copy

'https://mystorageaccount.file.core.windows.net/myfileshare/myFileShareDirectory/*?
'C:\myDirectory'
NOTE
Acrescente o --recursive sinalizador para baixar arquivos em todos os subdiretórios.
Baixar arquivos específicos

Você pode especificar nomes de arquivo completos ou usar nomes parciais com caracteres curinga (*).
Especificar vários nomes de arquivo completos
Use o comando azcopy Copy com a --include-path opção. Separe os nomes de arquivo individuais usando um semicolin ; ().

token>' '<local-directory-path>' --include-path <semicolon-
separated-file-list>
Exemplo azcopy copy

'https://mystorageaccount.file.core.windows.net/myFileShare/myDirectory?
sv=2018-03-28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-07-04T05:30:08Z&st=2019-
07-
'C:\myDirectory' --include-path 'photos;documents\myFile.txt' --recursive
Neste exemplo, AzCopy transfere o diretório e o

https://mystorageaccount.file.core.windows.net/myFileShare/myDirectory/photos
https://mystorageaccount.file.core.windows.net/myFileShare/myDirectory/documents/myFile.txt arquivo. Você precisa incluir a --recursive opção
para transferir todos os arquivos no https://mystorageaccount.file.core.windows.net/myFileShare/myDirectory/photos diretório.
Você também pode excluir arquivos usando a --exclude-path opção. Para saber mais, consulte azcopy Copy Reference docs.
Usar caracteres curinga
Use o comando azcopy Copy com a --include-pattern opção. Especifique nomes parciais que incluam os caracteres curinga. Separe os nomes
usando um semicolin ( ; ).
Sintaxe azcopy copy 'https://<storage-account-name>.<blob or

dfs>.core.windows.net/<container-or-directory-name><SAS-token>'
'<local-directory-path>' --include-pattern <semicolon-separated-
file-list-with-wildcard-characters>
Exemplo azcopy copy

'https://mystorageaccount.blob.core.windows.net/mycontainer/FileDirectory?
07-
'C:\myDirectory' --include-pattern 'myFile*.txt;*.pdf*'
Você também pode excluir arquivos usando a --exclude-pattern opção. Para saber mais, consulte azcopy Copy Reference docs.
As --include-pattern opções --exclude-pattern e aplicam-se somente a nomes de filename e não ao caminho. Se você quiser copiar todos os
arquivos de texto que existem em uma árvore de diretório, use a –recursive opção para obter a árvore de diretórios inteira e, em seguida
–include-pattern , use *.txt o e especifique para obter todos os arquivos de texto.
Copiar arquivos entre as contas de armazenamento

Você pode usar o AzCopy para copiar arquivos para outras contas de armazenamento. A operação de cópia é síncrona, portanto, quando o
comando retorna, isso indica que todos os arquivos foram copiados.
O AzCopy usa APIsde servidor para servidor , portanto, os dados são copiados diretamente entre os servidores de armazenamento. Essas
operações de cópia não usam a largura de banda de rede do seu computador. Você pode aumentar a taxa de transferência dessas operações
definindo o valor da variável AZCOPY_CONCURRENCY_VALUE de ambiente. Para saber mais, consulte otimizar a taxa de transferência.
Copiar um arquivo para outra conta de armazenamento
Copiar um diretório para outra conta de armazenamento
Copiar um compartilhamento de arquivos para outra conta de armazenamento
Copiar todos os compartilhamentos de arquivos, diretórios e arquivos para outra conta de armazenamento
TIP
Você pode ajustar sua operação de cópia usando sinalizadores opcionais. Aqui estão alguns exemplos.
Copie arquivos como BLOBs de acréscimo ou BLOBs de página. --blob-Type =[BlockBlob|PageBlob|AppendBlob]
Copie para uma camada de acesso específica (como a camada de arquivo --Block-blob-camada =[nenhum|arquivo|frio|quente]
morto).
Copiar um arquivo para outra conta de armazenamento
Sintaxe azcopy copy 'https://<source-storage-account-

token>' 'https://<destination-storage-account-
token>'
Exemplo azcopy copy

'https://mysourceaccount.file.core.windows.net/mycontainer/myTextFile.txt?
sv=2018-03-28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-07-04T05:30:08Z&st=2019-07-
'https://mydestinationaccount.file.core.windows.net/mycontainer/myTextFile.txt?
Copiar um diretório para outra conta de armazenamento

recursive
Exemplo azcopy copy

'https://mysourceaccount.file.core.windows.net/mycontainer/myBlobDirectory?
07-
'https://mydestinationaccount.file.core.windows.net/mycontainer?sv=2018-03-
--recursive
Copiar um compartilhamento de arquivos para outra conta de armazenamento

'https://<destination-storage-account-
recursive
Exemplo azcopy copy 'https://mysourceaccount.file.core.windows.net/mycontainer?
07-
'https://mydestinationaccount.file.core.windows.net/mycontainer?sv=2018-03-
--recursive
Copiar todos os compartilhamentos de arquivos, diretórios e arquivos para outra conta de armazenamento

name>.file.core.windows.net/<SAS-token>' 'https://<destination-
storage-account-name>.file.core.windows.net/<SAS-token>' --
recursive'
Exemplo azcopy copy 'https://mysourceaccount.file.core.windows.net?sv=2018-03-

'https://mydestinationaccount.file.core.windows.net?sv=2018-03-
--recursive
Sincronizar arquivos
Você pode sincronizar o conteúdo de um compartilhamento de arquivos com outro compartilhamento de arquivos. Você também pode sincronizar
o conteúdo de um diretório em um compartilhamento de arquivos com o conteúdo de um diretório localizado em outro compartilhamento de
arquivos. A sincronização é unidirecional. Em outras palavras, você escolhe quais desses dois pontos de extremidade são a origem e qual deles é o
destino. A sincronização também usa APIs de servidor para servidor.
NOTE
Atualmente, esse cenário tem suporte apenas para contas que não têm um namespace hierárquico. A versão atual do AzCopy não é sincronizada entre os
arquivos do Azure e o armazenamento de BLOBs.
O comando Sync compara os nomes de arquivo e os últimos carimbos de data/hora. Defina o --delete-destination sinalizador opcional como um
valor de true ou prompt para excluir arquivos no diretório de destino se esses arquivos não existirem mais no diretório de origem.
Se você definir o --delete-destination sinalizador como true AzCopy exclui arquivos sem fornecer um prompt. Se você quiser que um prompt
apareça antes de AzCopy excluir um arquivo, defina --delete-destination o sinalizador prompt como.
TIP
Você pode ajustar a operação de sincronização usando sinalizadores opcionais. Aqui estão alguns exemplos.
Especifique como os hashes MD5 estritamente devem ser validados durante o --check-MD5 =[NOCHECK||FailIfDifferent|logon FailIfDifferentOrMissing]
download.
Excluir arquivos com base em um padrão. --Exclude-caminho
Especifique o quão detalhado você deseja que suas entradas de log relacionadas -- =[||informações|de erro de aviso em nível de log nenhum]
à sincronização sejam.
Atualizar um compartilhamento de arquivos com alterações em outro compartilhamento de arquivos

O primeiro compartilhamento de arquivos que aparece nesse comando é a origem. O segundo é o destino.
Sintaxe azcopy sync 'https://<source-storage-account-

'https://<destination-storage-account-
recursive
Exemplo azcopy sync 'https://mysourceaccount.file.core.windows.net/myfileShare?
07-
'https://mydestinationaccount.file.core.windows.net/myfileshare?sv=2018-03-
--recursive
Atualizar um diretório com alterações em um diretório em outro compartilhamento de arquivos

O primeiro diretório que aparece nesse comando é a origem. O segundo é o destino.

name>.file.core.windows.net/<file-share-name>/<directory-name><SAS-
name>.file.core.windows.net/<file-share-name>/<directory-name><SAS-
token>' --recursive
Exemplo azcopy sync

'https://mysourceaccount.file.core.windows.net/myFileShare/myDirectory?
07-
'https://mydestinationaccount.file.core.windows.net/myFileShare/myDirectory?
07-
--recursive
Atualizar um compartilhamento de arquivos para corresponder ao conteúdo de um instantâneo de compartilhamento

O primeiro compartilhamento de arquivos que aparece nesse comando é a origem. No final do URI, acrescente a cadeia de caracteres
&sharesnapshot= seguida pelo valor DateTime do instantâneo.

name>.file.core.windows.net/<file-share-name><SAS-
token>&sharesnapsot<snapshot-ID>' 'https://<destination-storage-
account-name>.file.core.windows.net/<file-share-name><SAS-token>' --
recursive
Exemplo azcopy sync 'https://mysourceaccount.file.core.windows.net/myfileShare?sv=2018-03-

03T21:30:08Z&spr=https&sig=CAfhgnc9gdGktvB=ska7bAiqIddM845yiyFwdMH481QA8%3D&sharesnapsh
03-03T20%3A24%3A13.0000000Z' 'https://mydestinationaccount.file.core.windows.net/myfile
03T21:30:08Z&spr=https&sig=CAfhgnc9gdGktvB=ska7bAiqIddM845yiyFwdMH481QA8%3D' --recursiv
Para saber mais sobre instantâneos de compartilhamento, consulte visão geral de instantâneos de compartilhamento para arquivos do Azure.
Próximas etapas
Encontre mais exemplos em qualquer um destes artigos:
AzCopy é um utilitário de linha de comando que você pode usar para copiar BLOBs ou arquivos de ou para uma conta de
armazenamento. Este artigo ajuda você a executar tarefas de configuração avançadas e ajuda a solucionar problemas que podem surgir
ao usar o AzCopy.
NOTE
Se você estiver procurando conteúdo para ajudá-lo a começar a usar o AzCopy, consulte qualquer um dos seguintes artigos:
Definir configurações de proxy

Para definir as configurações de proxy para AzCopy, defina https_proxy a variável de ambiente. Se você executar o AzCopy no
Windows, o AzCopy detectará automaticamente as configurações de proxy, de modo que você não precisa usar essa configuração no
Windows. Se você optar por usar essa configuração no Windows, ela substituirá a detecção automática.
Windows Em um prompt de comando, use:

set https_proxy=<proxy IP>:<proxy port>
No PowerShell, use: $env:https_proxy="<proxy IP>:<proxy port>"
Linux export https_proxy=<proxy IP>:<proxy port>
MacOS export https_proxy=<proxy IP>:<proxy port>
Atualmente, o AzCopy não dá suporte a proxies que exigem autenticação com NTLM ou Kerberos.
Otimizar desempenho
Você pode obter o desempenho do benchmark e, em seguida, usar comandos e variáveis de ambiente para encontrar uma
compensação ideal entre o consumo de recursos e o desempenho.
Esta seção ajuda você a executar essas tarefas de otimização:
Executar testes de benchmark
Otimizar a taxa de transferência
Otimizar o uso de memória
Otimizar a sincronização de arquivos
Executar testes de benchmark
Você pode executar um teste de benchmark de desempenho em contêineres de blob específicos para exibir estatísticas gerais de
desempenho e para identificar afunilamentos de desempenho.
Use o comando a seguir para executar um teste de benchmark de desempenho.
Sintaxe azcopy bench 'https://<storage-account-

name>.blob.core.windows.net/<container-name>'
Exemplo azcopy bench

'https://mystorageaccount.blob.core.windows.net/mycontainer/myBlobDirectory?
09T20:37:48Z&spr=https&sig=%2FSOVEFfsKDqRry4bk3qz1vAQFwY5DDzp2%2B%2F3Eykf%2FJLs%3
TIP
Este exemplo inclui argumentos de caminho com aspas simples (' '). Use aspas simples em todos os shells de comando, exceto pelo shell de comando
do Windows (cmd. exe). Se você estiver usando um shell de comando do Windows (cmd. exe), coloque argumentos de caminho com aspas duplas ("")
em vez de aspas simples (' ').
Esse comando executa um parâmetro de comparação de desempenho carregando dados de teste para um destino especificado. Os
dados de teste são gerados na memória, carregados no destino e, em seguida, excluídos do destino após a conclusão do teste. Você
pode especificar quantos arquivos serão gerados e qual tamanho você gostaria que eles estivéssemos usando parâmetros de comando
opcionais.
Para obter documentos de referência detalhados, consulte bancada de azcopy.
Para exibir as diretrizes de ajuda detalhadas para este comando azcopy bench -h , digite e pressione a tecla Enter.
Otimizar a taxa de transferência
Você pode usar o cap-mbps sinalizador em seus comandos para inserir um teto na taxa de dados de produtividade. Por exemplo, o
comando a seguir retoma um trabalho e a taxa de 10 transferência de Caps para megabytes (MB) por segundo.
azcopy jobs resume <job-id> --cap-mbps 10
A taxa de transferência pode diminuir ao transferir arquivos pequenos. Você pode aumentar a taxa de transferência definindo a
AZCOPY_CONCURRENCY_VALUE variável de ambiente. Essa variável especifica o número de solicitações simultâneas que podem ocorrer.
Se o computador tiver menos de 5 CPUs, o valor dessa variável será definido como 32 . Caso contrário, o valor padrão é igual a 16
multiplicado pelo número de CPUs. O valor padrão máximo dessa variável é 3000 , mas você pode definir manualmente esse valor
como maior ou menor.
Windows set AZCOPY_CONCURRENCY_VALUE=<value>
Linux export AZCOPY_CONCURRENCY_VALUE=<value>
MacOS export AZCOPY_CONCURRENCY_VALUE=<value>
Use o azcopy env para verificar o valor atual dessa variável. Se o valor estiver em branco, você poderá ler qual valor está sendo usado
observando o início de qualquer arquivo de log do AzCopy. O valor selecionado e o motivo pelo qual ele foi selecionado são relatados
lá.
Antes de definir essa variável, recomendamos que você execute um teste de parâmetro de comparação. O processo de teste de
benchmark relatará o valor de simultaneidade recomendado. Como alternativa, se as suas condições de rede e suas cargas variam,
defina essa variável como AUTO a palavra em vez de um número específico. Isso fará com que o AzCopy sempre execute o mesmo
processo de ajuste automático que ele usa nos testes de parâmetro de comparação.
Otimizar o uso de memória
Defina a AZCOPY_BUFFER_GB variável de ambiente para especificar a quantidade máxima de memória do sistema que você deseja que o
AzCopy use ao baixar e carregar arquivos. Expresse esse valor em gigabytes (GB).
Windows set AZCOPY_BUFFER_GB=<value>
Linux export AZCOPY_BUFFER_GB=<value>
MacOS export AZCOPY_BUFFER_GB=<value>
Otimizar a sincronização de arquivos

O comando Sync identifica todos os arquivos no destino e compara os nomes de arquivo e os últimos carimbos de data/hora antes do
início da operação de sincronização. Se você tiver um grande número de arquivos, poderá melhorar o desempenho eliminando esse
processamento antecipado.
Para fazer isso, use o comando azcopy Copy , em vez disso, --overwrite e defina ifSourceNewer o sinalizador como. O AzCopy
comparará os arquivos conforme eles forem copiados sem executar verificações e comparações iniciais. Isso fornece uma margem de
desempenho em casos em que há um grande número de arquivos para comparar.
O comando azcopy Copy não exclui arquivos do destino, portanto, se você quiser excluir arquivos no destino quando eles não existirem
na origem, use o comando de sincronização azcopy com o --delete-destination sinalizador definido como um valor de true ou.
prompt
O AzCopy cria arquivos de log e de plano para cada trabalho. Você pode usar os logs para investigar e solucionar problemas potenciais.
Os logs conterão o status de falha ( UPLOADFAILED , COPYFAILED ,e DOWNLOADFAILED ), o caminho completo e o motivo da falha.
Por padrão, os arquivos de log e de plano estão localizados %USERPROFILE%\.azcopy no diretório no Windows $HOME$\.azcopy ou no
diretório no Mac e no Linux, mas você pode alterar esse local, se desejar.
O erro relevante não é necessariamente o primeiro erro que aparece no arquivo. Para erros como erros de rede, tempos limite e erros
de servidor ocupado, o AzCopy tentará novamente até 20 vezes e, geralmente, o processo de repetição será executado com sucesso. O
primeiro erro que você vê pode ser algo inofensivo que foi repetido com êxito. Então, em vez de olhar o primeiro erro no arquivo,
procure os erros que estão próximos UPLOADFAILED , COPYFAILED ou. DOWNLOADFAILED
IMPORTANT
Ao enviar uma solicitação para Suporte da Microsoft (ou solucionar o problema que envolve terceiros), compartilhe a versão redação do comando
que você deseja executar. Isso garante que a SAS não seja compartilhada acidentalmente com ninguém. Você pode encontrar a versão editada no
início do arquivo de log.
Examinar os logs em busca de erros

O comando a seguir receberá todos os UPLOADFAILED erros com o 04dc9ca9-158f-7945-5933-564021086c79 status do log:
Windows (PowerShell)
Select-String UPLOADFAILED .\04dc9ca9-158f-7945-5933-564021086c79.log
Linux
grep UPLOADFAILED .\04dc9ca9-158f-7945-5933-564021086c79.log
Exibir e retomar trabalhos

Cada operação de transferência criará um trabalho do AzCopy. Use o seguinte comando para exibir o histórico de trabalhos:
azcopy jobs list
Para exibir as estatísticas de trabalho, use o seguinte comando:
azcopy jobs show <job-id>
Para filtrar as transferências por status, use o seguinte comando:
azcopy jobs show <job-id> --with-status=Failed
Use o comando a seguir para retomar um trabalho com falha/cancelado. Esse comando usa seu identificador junto com o token SAS,
pois ele não é persistente por motivos de segurança:
azcopy jobs resume <job-id> --source-sas="<sas-token>"

azcopy jobs resume <job-id> --destination-sas="<sas-token>"
TIP
Coloque argumentos de caminho, como o token SAS com aspas simples (' '). Use aspas simples em todos os shells de comando, exceto pelo shell de
comando do Windows (cmd. exe). Se você estiver usando um shell de comando do Windows (cmd. exe), coloque argumentos de caminho com aspas
duplas ("") em vez de aspas simples (' ').
Quando você reinicia um trabalho, o AzCopy examina o arquivo de plano de trabalho. O arquivo de plano lista todos os arquivos que
foram identificados para processamento quando o trabalho foi criado pela primeira vez. Quando você retomar um trabalho, o AzCopy
tentará transferir todos os arquivos listados no arquivo de plano que ainda não foram transferidos.
Alterar o local do plano e dos arquivos de log

Por padrão, os arquivos de plano e de log estão %USERPROFILE%\.azcopy localizados no diretório no Windows ou no $HOME$\.azcopy
diretório no Mac e no Linux. Você pode alterar esse local.
Alterar o local dos arquivos de plano
Use qualquer um desses comandos.
Windows set AZCOPY_JOB_PLAN_LOCATION=<value>
Linux export AZCOPY_JOB_PLAN_LOCATION=<value>
MacOS export AZCOPY_JOB_PLAN_LOCATION=<value>
Use o azcopy env para verificar o valor atual dessa variável. Se o valor estiver em branco, os arquivos de plano serão gravados no local
padrão.
Alterar o local dos arquivos de log
Use qualquer um desses comandos.
Windows set AZCOPY_LOG_LOCATION=<value>
Linux export AZCOPY_LOG_LOCATION=<value>
MacOS export AZCOPY_LOG_LOCATION=<value>
Use o azcopy env para verificar o valor atual dessa variável. Se o valor estiver em branco, os logs serão gravados no local padrão.
Alterar o nível de log padrão

Por padrão, o nível de log AzCopy é INFO definido como. Se você quiser reduzir o detalhamento de log para economizar espaço em
disco, substitua essa configuração usando a --log-level opção.
Os níveis de log disponíveis NONE são DEBUG : INFO , WARNING , ERROR , PANIC ,, FATAL e.
Remover arquivos de plano e de log

Se você quiser remover todos os arquivos de plano e de log do computador local para economizar espaço em disco, azcopy jobs clean
use o comando.
Para remover o plano e os arquivos de log associados a apenas um trabalho azcopy jobs rm <job-id> , use. Substitua o <job-id>
espaço reservado neste exemplo pela ID do trabalho.
Solucionar problemas de Arquivos do Azure no
Windows
Este artigo lista os problemas comuns relacionados aos Arquivos do Microsoft Azure quando você se conecta de
clientes Windows. Também fornece as possíveis causas e resoluções para esses problemas. Além das etapas de
solução de problemas neste artigo, você também pode usar o AzFileDiagnostics para garantir que o ambiente de
cliente do Windows tenha pré-requisitos corretos. O AzFileDiagnostics automatiza a detecção da maioria dos
sintomas mencionados neste artigo e ajuda a configurar seu ambiente para obter um desempenho ideal. Você
também pode encontrar essas informações no solucionador de problemas de compartilhamentos de arquivos
do Azure que fornece etapas para ajudá-lo com problemas de conexão/mapeamento/montagem de
Erro 5 ao montar um compartilhamento de arquivos do Azure

Quando você tenta montar um compartilhamento de arquivos, pode receber o erro a seguir:
Ocorreu um erro de sistema 5. O acesso foi negado.
Causa 1: Canal de comunicação não criptografado
Por motivos de segurança, as conexões para compartilhamentos de arquivos do Azure são bloqueadas se o canal
de comunicação não está criptografado e a tentativa de conexão não é feita do mesmo datacenter onde residem
os compartilhamentos de arquivos do Azure. As conexões não criptografadas dentro do mesmo datacenter
também podem ser bloqueadas se o transferência segura obrigatória está habilitada na conta de
armazenamento. Um canal de comunicação criptografado é fornecido somente quando o sistema operacional do
cliente do usuário dá suporte à criptografia SMB.
O Windows 8, o Windows Server 2012 e versões posteriores de cada solicitação de negociação de sistema que
inclua o SMB 3.0, que dá suporte à criptografia.
Solução para a causa 1
1. Conecte a partir de um cliente com suporte à criptografia SMB (Windows 8, Windows Server 2012 ou
posterior) ou conecte a partir de uma máquina virtual que está no mesmo datacenter da conta de
armazenamento do Azure usada para o compartilhamento de arquivos do Azure.
2. Verifique se a configuração Transferência segura obrigatória está desabilitada na conta de armazenamento se
o cliente não oferecer suporte à criptografia SMB.
Causa 2: as regras de firewall ou de rede virtual estão habilitadas na conta de armazenamento
Se as regras de firewall e de VNET (rede virtual) estiverem configuradas na conta de armazenamento, o tráfego
de rede terá acesso negado a menos que o endereço IP do cliente ou da rede virtual tenha permissão de acesso.
Verifique se regras de firewall e de rede virtual estão configuradas corretamente na conta de armazenamento.
Para testar se as regras de firewall ou de rede virtuais estão causando o problema, altere temporariamente a
configuração da conta de armazenamento para Permitir o acesso de todas as redes . Para saber mais, confira
Configurar redes virtuais e firewalls do Armazenamento do Azure.
Causa 3: permissões de nível de compartilhamento incorretas ao usar a autenticação baseada em identidade
Se os usuários estiverem acessando o compartilhamento de arquivos do Azure usando a autenticação Active
Directory (AD) ou Azure Active Directory Domain Services (Azure AD DS), o acesso ao compartilhamento de
arquivos falhará com o erro "acesso negado" se as permissões de nível de compartilhamento estiverem
incorretas.
Para atualizar as permissões de nível de compartilhamento, consulte atribuir permissões de acesso a uma
identidade.
Erro 53, Erro 67 ou Erro 87 ao montar ou desmontar um

compartilhamento de arquivos do Azure
Quando você tenta montar um compartilhamento de arquivos do local ou de um datacenter diferente, você
poderá receber os seguintes erros:
Ocorreu um erro de sistema 53. O caminho da rede não foi encontrado.
Ocorreu um erro de sistema 67. O nome de rede não foi encontrado.
Ocorreu um erro de sistema 87. O parâmetro está incorreto.
Causa 1: a porta 445 está bloqueada
Pode ocorrer um erro de sistema 53 ou erro de sistema 67 se a comunicação de saída na porta 445 para o
datacenter de Arquivos do Azure estiver bloqueada. Para ver o resumo de ISPs que permitem ou proíbem o
acesso a partir da porta 445, vá para TechNet.
Para verificar se o firewall ou ISP está bloqueando a porta 445, use a ferramenta AzFileDiagnostics ou o cmdlet
Test-NetConnection .
Para usar o Test-NetConnection cmdlet, o módulo Azure PowerShell deve ser instalado, consulte instalar Azure
PowerShell módulo para obter mais informações. Lembre-se de substituir <your-storage-account-name> e
<your-resource-group-name> pelos nomes referentes a sua conta de armazenamento.
# This command requires you to be logged into your Azure account, run Login-AzAccount if you haven't
# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.

# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445
Se a conexão foi bem-sucedida, você verá a seguinte saída:
ComputerName : <your-storage-account-name>
RemoteAddress : <storage-account-ip-address>
RemotePort : 445
InterfaceAlias : <your-network-interface>
SourceAddress : <your-ip-address>
TcpTestSucceeded : True
NOTE
O comando acima retorna o endereço IP atual da conta de armazenamento. Não há garantia de que esse endereço IP será
sempre o mesmo; ele pode mudar a qualquer momento. Não codifique esse endereço IP em um script ou em uma
configuração de firewall.
Solução 1 - Usar a Sincronização de Arquivos do Azure
Sincronização de Arquivos do Azure pode transformar seu Windows Server local em um cache rápido do seu
compartilhamento de arquivos do Azure. Use qualquer protocolo disponível no Windows Server para acessar
seus dados localmente, incluindo SMB, NFS e FTPS. Sincronização de Arquivos do Azure funciona na porta 443 e,
portanto, pode ser usado como uma solução alternativa para acessar os arquivos do Azure de clientes que têm a
porta 445 bloqueada. Saiba como configurar o sincronização de arquivos do Azure.
Solução 2 - Usar a VPN
Ao configurar uma VPN para sua conta de armazenamento específica, o tráfego passará por um túnel seguro em
oposição à Internet. Siga as instruções para configurar a VPN para acessar os arquivos do Azure do Windows.
Solução 3 - Desbloquear a porta 445 com a ajuda de seu ISP / administrador de TI
Trabalhe com seu departamento de ti ou ISP para abrir a porta 445 de saída para intervalos de IP do Azure.
Solução 4 – Usar a API REST com base em ferramentas como o Gerenciador de armazenamento/Powershell
Os arquivos do Azure também dão suporte ao REST, além do SMB. O acesso REST funciona pela porta 443 (TCP
padrão). Há várias ferramentas que são escritas usando a API REST que possibilitam uma experiência de interface
do usuário rica. Gerenciador de armazenamento é um deles. Baixe e instale o Gerenciador de armazenamento e
conecte-se ao compartilhamento de arquivos apoiado pelos arquivos do Azure. Você também pode usar o
PowerShell que também a API REST do usuário.
Causa 2: NTLMv1 está habilitado
O erro de sistema 53 ou erro de sistema 87 também pode ocorrer se a comunicação NTLMv1 está habilitada no
cliente. Os Arquivos do Azure dão suporte apenas a autenticação NTLMv2. Ter NTLMv1 habilitado faz com que o
cliente esteja menos seguro. Portanto, a comunicação será bloqueada para Arquivos do Azure.
Para verificar se essa é a causa do erro, verifique se a seguinte subchave do registro está definida como um valor
de 3:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel
Para saber mais, confira o tópico LmCompatibilityLevel no TechNet.
Reverter o valor LmCompatibilityLevel para o valor padrão de 3 na seguinte subchave do registro:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Erro 1816 "Não há cota suficiente disponível para processar este

comando" quando você copia para um compartilhamento de arquivos
do Azure
Causa
O Erro 1816 ocorre quando você atingir o limite superior de identificadores abertos simultâneos permitidos para
um arquivo no computador onde o compartilhamento de arquivos está sendo montado.
Solução
Reduza o número de identificadores abertos simultâneos fechando alguns identificadores e tentando
novamente. Para obter mais informações, consulte armazenamento do Microsoft Azure lista de verificação de
desempenho e escalabilidade.
Para exibir identificadores abertos para um compartilhamento de arquivos, diretório ou arquivo, use o cmdlet
Get-AzStorageFileHandle do PowerShell.
Para fechar identificadores abertos para um compartilhamento de arquivos, diretório ou arquivo, use o cmdlet
Close-AzStorageFileHandle do PowerShell.
NOTE
Os cmdlets Get-AzStorageFileHandle e close-AzStorageFileHandle estão incluídos no módulo AZ PowerShell versão 2,4 ou
posterior. Para instalar o módulo AZ PowerShell mais recente, consulte instalar o Azure PowerShell Module.
Erro "sem acesso" ao tentar acessar ou excluir um compartilhamento

Ao tentar acessar ou excluir um compartilhamento de arquivos do Azure no portal, você pode receber o seguinte
erro:
Sem acesso
Código de erro: 403
Causa 2: sua conta de usuário não tem acesso à conta de armazenamento
Navegue até a conta de armazenamento onde o compartilhamento de arquivos do Azure está localizado, clique
em Controle de acesso (IAM) e verifique se sua conta de usuário tem acesso à conta de armazenamento. Para
saber mais, confira Como proteger a conta de armazenamento com o RBAC (Controle de Acesso Baseado em
Função).
Não é possível excluir um arquivo ou diretório em um

Ao tentar excluir um arquivo, você pode receber o seguinte erro:
O recurso especificado está marcado para exclusão por um cliente SMB.
Causa
Esse problema normalmente ocorre se o arquivo ou diretório tiver um identificador aberto.
Solução
Se os clientes SMB tiverem fechado todos os identificadores abertos e o problema continuar ocorrendo, execute
o seguinte:
Use o cmdlet do PowerShell Get-AzStorageFileHandle para exibir identificadores abertos.
Use o cmdlet do PowerShell Close-AzStorageFileHandle para fechar identificadores abertos.
NOTE
Cópia de arquivos bidirecional lenta dos Arquivos do Azure no
Windows
Você pode ver o desempenho lento ao tentar transferir arquivos para o Serviço de Arquivos do Azure.
Se você não tiver um requisito mínimo de tamanho de E / S específico, recomendamos usar 1 MiB como o
tamanho de E / S para um desempenho ideal.
Se você sabe o tamanho final de um arquivo que você está estendendo com gravações e o seu software não
tem problemas de compatibilidade com o final ainda não escrito desse arquivo que contém zeros, defina o
tamanho do arquivo antecipadamente em vez de realizar cada gravação como uma gravação de extensão.
Use o método de cópia correto:
Use AzCopy para qualquer transferência entre dois compartilhamentos de arquivos.
Use o Robocopy entre compartilhamentos de arquivos e um computador local.
Considerações para Windows 8.1 ou Windows Server 2012 R2
Para clientes que estão executando o Windows 8.1 ou o Windows Server 2012 R2, verifique se o hotfix
KB3114025 está instalado. Esse hotfix melhora o desempenho dos identificadores de criação e fechamento.
Você pode executar o script abaixo para verificar se o hotfix foi instalado:
reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies
Se o hotfix foi instalado, a seguinte saída será exibida:

HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-
477b-8fcd-bea1a564241c} REG_DWORD 0x1
NOTE
As imagens do Windows Server 2012 R2 no Azure Marketplace têm o hotfix KB3114025 instalado por padrão desde
dezembro de 2015.
Nenhuma pasta com uma letra de unidade em "Meu Computador" ou

"este computador"
Se você mapear um compartilhamento de arquivos do Azure como administrador por meio do uso de rede, o
compartilhamento parece estar ausente.
Causa
Por padrão, o Explorador de Arquivos do Windows não é executado como administrador. Se você executar net
use em um prompt de comando de administrador, mapeará a unidade de rede como um administrador. Como as
unidades mapeadas são focadas no usuário, a conta de usuário que está conectada não exibe as unidades se eles
estão montadas em uma conta de usuário diferente.
Solução
Monte o compartilhamento de uma linha de comando de não administrador. Como alternativa, você pode seguir
este tópico TechNet para configurar o valor do registro EnableLinkedConnections .
O comando net use falha se a conta de armazenamento contém uma

barra
Causa
O comando net use interpreta uma barra (/) como uma opção de linha de comando. Se o nome da sua conta de
usuário começa com uma barra, o mapeamento da unidade falhará.
Solução
Você pode usar qualquer uma das seguintes etapas para contornar o problema:
Execute o seguinte comando do PowerShell:
New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can
contain / and \ etc"
A partir de um arquivo em lotes, você pode executar o comando desta forma:

Echo new-smbMapping ... | powershell -command –
Colocando aspas duplas em torno da chave para contornar esse problema, a menos que a barra seja o
primeiro caractere. Se for, use o modo interativo e digite sua senha separadamente ou regenere as chaves
para obter uma chave que não comece com uma barra.
O aplicativo ou serviço não pode acessar uma unidade de Arquivos do

Azure montada
Causa
As unidades são montadas por usuário. Se o seu aplicativo ou serviço estiver em execução em uma conta de
usuário diferente da que montou a unidade, o aplicativo não verá a unidade.
Solução
use uma das seguintes soluções:
Monte a unidade a partir da mesma conta de usuário que contém o aplicativo. Você pode usar uma
ferramenta como o PsExec.
Passe o nome da conta de armazenamento e a chave nos parâmetros de nome do usuário e senha do
comando net use.
Use o comando cmdkey para adicionar as credenciais no Gerenciador de Credenciais. Execute-o em uma
linha de comando no contexto da conta de serviço, seja por meio de um runas logon interativo ou
usando.
cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:
<storage-account-key>
Mapeie o compartilhamento diretamente sem usar uma letra de unidade mapeada. Alguns aplicativos
podem não se reconectar à letra da unidade corretamente, portanto, usar o caminho UNC completo pode
ser mais confiável.
net use * \\storage-account-name.file.core.windows.net\share
Depois de seguir estas instruções, você pode receber a seguinte mensagem de erro quando você executa o net
use para a conta de serviço de rede/sistema: "Ocorreu um erro de sistema 1312. Uma sessão de logon
especificada não existe. Talvez ela já tenha sido finalizada.” Se isso ocorrer, verifique se o nome de usuário que é
passado para net use inclui informações de domínio (por exemplo: "[nome da conta de
armazenamento].file.core.windows.net").
Erro "Você está copiando um arquivo para um destino que não dá

suporte à criptografia"
Quando um arquivo é copiado pela rede, o arquivo é descriptografado no computador de origem, transmitido
em texto não criptografado e criptografado novamente no destino. No entanto, você pode ver o seguinte erro
quando estiver tentando copiar um arquivo criptografado: "Você está copiando o arquivo para um destino que
não dá suporte à criptografia".
Causa
Esse problema pode ocorrer se você estiver usando o sistema de arquivos com criptografia (EFS). Os arquivos
criptografados pelo BitLocker podem ser copiados para os Arquivos do Azure. No entanto, os Arquivos do Azure
não dão suporte a EFS NTFS.
Solução alternativa
Para copiar um arquivo pela rede, você deve primeiro descriptografá-lo. Use um dos métodos a seguir:
Use o comando copy /d . Ele permite que os arquivos criptografados sejam salvos como arquivos
descriptografados no destino.
Defina a seguinte chave do registro:
Caminho = HKLM\Software\Policies\Microsoft\Windows\System
Tipo de valor = DWORD
Name = CopyFileAllowDecryptedRemoteDestination
Value = 1
Observe que a definição da chave do registro afeta todas as operações de cópia que são feitas para
compartilhamentos de rede.
Enumeração lenta dos arquivos e pastas

Causa
Esse problema poderá ocorrer se não houver cache suficiente no computador cliente para diretórios grandes.
Solução
Para resolver esse problema, ajuste o valor do registro Director yCacheEntr ySizeMax para permitir o cache de
listagens de diretório maiores no computador cliente:
Local: HKLM\System\CCS\Services\Lanmanworkstation\Parameters
Emaranhado do valor: DirectoryCacheEntrySizeMax
Tipo de valor: DWORD
Por exemplo, você pode defini-lo como 0x100000 e ver se o desempenho se torna melhor.
Erro AadDsTenantNotFound ao habilitar a autenticação do AAD DS

(serviço de domínio Azure Active Directory) para arquivos do Azure
"não é possível localizar locatários ativos com a ID de locatário AAD-
Tenant-ID"
Causa
O erro AadDsTenantNotFound ocorre quando você tenta habilitar a autenticação Azure Active Directory Domain
Services (Azure AD DS) em arquivos do Azure em uma conta de armazenamento em que o AAD DS (serviço de
domínio do AAD) não é criado no locatário do AAD da assinatura associada.
Solução
Habilite o AAD DS no locatário do AAD da assinatura na qual a conta de armazenamento é implantada. Você
precisa de privilégios de administrador do locatário do AAD para criar um domínio gerenciado. Se você não for o
administrador do locatário do Azure AD, entre em contato com o administrador e siga as orientações passo a
passo para Habilitar os Serviços de Domínio do Active Directory do Azure usando o portal do Azure.
Erro ConditionHeadersNotSupported de um aplicativo Web usando
arquivos do Azure do navegador
O erro ConditionHeadersNotSupported ocorre ao acessar o conteúdo hospedado nos arquivos do Azure por
meio de um aplicativo que utiliza cabeçalhos condicionais, como um navegador da Web, o acesso falha. O erro
informa que os cabeçalhos de condição não têm suporte.
Causa
Ainda não há suporte para cabeçalhos condicionais. Os aplicativos que a implementam precisarão solicitar o
arquivo completo toda vez que o arquivo for acessado.
Quando um novo arquivo é carregado, a propriedade Cache-Control por padrão é "no-cache". Para forçar o
aplicativo a solicitar o arquivo a cada vez, a propriedade Cache-Control do arquivo precisa ser atualizada de "no-
cache" para "no-cache, no-Store, deve-revalidate". Isso pode ser feito usando Gerenciador de armazenamento do
Azure.
Erro ' ocorreu o erro de sistema 1359. Um erro interno ' recebido por
meio de acesso SMB a compartilhamentos de arquivos com a
autenticação AAD DS (Azure Active Directory Domain Service)
habilitada
Causa
Erro ' ocorreu o erro de sistema 1359. Um erro interno ' ocorre quando você tenta se conectar ao
compartilhamento de arquivos com a autenticação do AAD DS habilitada em um AAD DS com um nome DNS de
domínio começando com um caractere numérico. Por exemplo, se o nome DNS do domínio do AAD DS for
"1domain", você receberá esse erro ao tentar montar o compartilhamento de arquivos usando as credenciais do
AAD.
Solução
No momento, você pode considerar reimplantar seu AAD DS usando um novo nome DNS de domínio que se
aplica com as regras abaixo:
Os nomes não podem começar com um caractere numérico.
Os nomes devem ter de 3 a 63 caracteres de comprimento.
Não é possível montar os arquivos do Azure com as credenciais do AD

Etapas de autodiagnóstico
Primeiro, certifique-se de ter seguido todas as quatro etapas para habilitar a autenticação do AD dos arquivos do
Azure.
Em segundo lugar, tente montar o compartilhamento de arquivos do Azure com a chave da conta de
armazenamento. Se você não conseguiu montar, baixe AzFileDiagnostics. ps1 para ajudá-lo a validar o cliente
que está executando o ambiente, detectar a configuração de cliente incompatível que causaria falha de acesso
para os arquivos do Azure, fornece orientação prescritiva sobre AutoCorreção e coleta de rastreamentos de
diagnóstico.
Em terceiro lugar, você pode executar o cmdlet Debug-AzStorageAccountAuth para conduzir um conjunto de
verificações básicas em sua configuração do AD com o usuário conectado do AD. Esse cmdlet tem suporte na
versão AzFilesHybrid v 0.1.2 +. Você precisa executar esse cmdlet com um usuário do AD que tenha permissão
de proprietário na conta de armazenamento de destino.
$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -

Verbose
O cmdlet executa essas verificações abaixo em sequência e fornece diretrizes para falhas:
1. CheckPort445Connectivity: Verifique se a porta 445 está aberta para conexão SMB
2. CheckDomainJoined: validar se o computador cliente está ingressado no domínio no AD
3. CheckADObject: Confirme se o usuário conectado tem uma representação válida no domínio do AD à qual a
conta de armazenamento está associada
4. CheckGetKerberosTicket: tentativa de obter um tíquete Kerberos para conectar-se à conta de armazenamento
5. CheckADObjectPasswordIsCorrect: Verifique se a senha configurada na identidade do AD que representa a
conta de armazenamento corresponde à chave de Kerb da conta de armazenamento
6. CheckSidHasAadUser: Verifique se o usuário conectado do AD está sincronizado com o Azure AD
Estamos trabalhando ativamente para estender esse cmdlet de diagnóstico para fornecer melhor orientação para
a solução de problemas.
Precisa de ajuda? Entre em contato com o suporte.

Caso ainda precise de ajuda, contate o suporte para resolver seu problema rapidamente.
Solucionar problemas de Arquivos do Azure no
Linux
Este artigo lista os problemas comuns relacionados aos Arquivos do Azure quando você se conecta de clientes
Linux. Também fornece as possíveis causas e resoluções para esses problemas.
Além das etapas de solução de problemas deste artigo, você pode usar AzFileDiagnostics para garantir que o
cliente Linux tenha pré-requisitos corretos. O AzFileDiagnostics automatiza a detecção da maioria dos sintomas
mencionados neste artigo. Isso ajuda a configurar seu ambiente para obter um desempenho ideal. Você também
pode encontrar essas informações na solução de problemas do Compartilhamento de arquivos do Azure. A
solução de problemas fornece etapas para ajudá-lo com problemas de conexão, o mapeamento e montar os
Não é possível se conectar a ou montar um compartilhamento de

arquivos do Azure
Causa
Causas comuns para esse problema são:
Você está usando um cliente de distribuição Linux incompatível. Recomendamos que você use as seguintes
distribuições do Linux para se conectar a um compartilhamento de arquivos do Azure:
SM B 2. 1 SM B 3. 0
( M O N TA GEN S EM VM S N A M ESM A ( M O N TA GEN S DE LO C A L E EN T RE
REGIÃ O DO A Z URE) REGIÕ ES)
Ubuntu Server 14.04+ 16.04+
RHEL 7+ 7.5+
CentOS 7+ 7.5+
Debian Mais de 8
openSUSE 13.2+ 42.3+
SUSE Linux Enterprise Server 12 12 SP3+
Os utilitários CIFS (CIFS-utils) não estão instalados no cliente.

A versão mínima do SMB / CIFS, 2.1, não está instalada no cliente.
A criptografia SMB 3.0 não é suportada no cliente. A tabela anterior fornece uma lista de distribuições do Linux
que dão suporte à montagem do local e entre regiões usando criptografia. Outras distribuições requerem o
kernel 4.11 e versões posteriores.
Você está tentando se conectar a uma conta de armazenamento pela porta TCP 445, que não é suportada.
Você está tentando se conectar a um compartilhamento de arquivos do Azure de uma VM do Azure, e a VM
não está na mesma região que a conta de armazenamento.
Se a configuração Transferência segura necessária estiver ativada na conta de armazenamento, os Arquivos do
Azure só permitirão conexões que usem o SMB 3.0 com criptografia.
Solução
Para resolver o problema, use o ferramenta de solução de problemas para os arquivos do Azure erros de
montagem no Linux. Essa ferramenta:
Ajuda a validar o ambiente de execução de cliente.
Detecta a configuração de cliente incompatível que causaria falha de acesso para arquivos do Azure.
Dá orientação prescritiva sobre auto-fixação.
Coleta os rastreamentos de diagnóstico.
"Erro de montagem (13): permissão negada" ao montar um

Causa 1: Canal de comunicação não criptografado
Por motivos de segurança, as conexões para compartilhamentos de arquivos do Azure são bloqueadas se o canal
de comunicação não está criptografado e a tentativa de conexão não é feita do mesmo datacenter onde residem
os compartilhamentos de arquivos do Azure. As conexões não criptografadas dentro do mesmo datacenter
também podem ser bloqueadas se o transferência segura obrigatória está habilitada na conta de armazenamento.
Um canal de comunicação criptografado é fornecido somente quando o sistema operacional do cliente do usuário
dá suporte à criptografia SMB.
Para saber mais, confira Pré-requisitos para montar um compartilhamento de arquivos do Azure com o Linux e o
pacote cifs-utils.
1. Conecte-se de um cliente com suporte à criptografia SMB ou conecte a partir de uma máquina virtual que está
no mesmo datacenter da conta de armazenamento do Azure usada para o compartilhamento de arquivos do
Azure.
2. Verifique se a configuração Transferência segura obrigatória está desabilitada na conta de armazenamento se
o cliente não oferecer suporte à criptografia SMB.
Se as regras de firewall e de VNET (rede virtual) estiverem configuradas na conta de armazenamento, o tráfego
de rede terá acesso negado a menos que o endereço IP do cliente ou da rede virtual tenha permissão de acesso.
“[permissão negada] Cota de disco excedida” ao tentar abrir um

arquivo
No Linux, você recebe uma mensagem de erro semelhante à seguinte:
<nome de arquivo> [permissão negada] cota de disco excedida
Causa
Você atingiu o limite máximo de identificadores abertos simultâneos permitidos para um arquivo.
Há uma cota de 2.000 identificadores abertos em um único arquivo. Quando você tem 2.000 identificadores
abertos, uma mensagem de erro é exibida informando que a cota foi atingida.
Solução
Reduza o número de identificadores abertos simultâneos fechando alguns deles e repita a operação.
Para exibir identificadores abertos para um compartilhamento de arquivos, diretório ou arquivo, use o cmdlet
Get-AzStorageFileHandle do PowerShell.
Para fechar identificadores abertos para um compartilhamento de arquivos, diretório ou arquivo, use o cmdlet
Close-AzStorageFileHandle do PowerShell.
NOTE
Cópia de arquivos bidirecional lenta dos Arquivos do Azure no Linux

Se você não tiver um requisito mínimo de tamanho de E / S específico, recomendamos usar 1 MiB como o
tamanho de E / S para um desempenho ideal.
Use o método de cópia correto:
Use AzCopy para qualquer transferência entre dois compartilhamentos de arquivos.
Usar CP ou DD com Parallel pode melhorar a velocidade de cópia, o número de threads depende do seu
caso de uso e da carga de trabalho. Os exemplos a seguir usam seis:
exemplo de CP (CP usará o tamanho de bloco padrão do sistema de arquivos como o tamanho da
find * -type f | parallel --will-cite -j 6 cp {} /mntpremium/ & parte):.
exemplo de DD (este comando define explicitamente o tamanho da parte como 1 MiB):
find * -type f | parallel --will-cite-j 6 dd if={} of=/mnt/share/{} bs=1M
Ferramentas de terceiros de código aberto, como:
GNU Parallel.
Fpart -classifica os arquivos e os compacta em partições.
Fpsync -usa fpart e uma ferramenta de cópia para gerar várias instâncias para migrar dados de
src_dir para dst_url.
Vários multithreaded CP e md5sum com base no GNU coreutils.
Definir o tamanho do arquivo com antecedência, em vez de fazer cada gravação de uma gravação de extensão,
ajuda a melhorar a velocidade de cópia em cenários em que o tamanho do arquivo é conhecido. Se for
necessário evitar gravações estendidas, você poderá definir um tamanho de arquivo de
truncate - size <size><file> destino com o comando. Depois disso,
dd if=<source> of=<target> bs=1M conv=notrunc o comando copiará um arquivo de origem sem precisar
atualizar repetidamente o tamanho do arquivo de destino. Por exemplo, você pode definir o tamanho do
arquivo de destino para cada arquivo que deseja copiar (Suponha que um compartilhamento seja montado
em/mnt/share):
$ for i in `` find * -type f``; do truncate --size ``stat -c%s $i`` /mnt/share/$i; done
e, em seguida, copiar arquivos sem estender gravações em paralelo:
$find * -type f | parallel -j6 dd if={} of =/mnt/share/{} bs=1M conv=notrunc
“Erro de montagem (115): operação em andamento” durante a

montagem dos Arquivos do Azure usando o SMB 3.0
Causa
Algumas distribuições Linux ainda não suportam recursos de criptografia no SMB 3.0. Os usuários podem
receber uma mensagem de erro "115" se tentarem montar arquivos do Azure usando o SMB 3.0 devido a um
recurso ausente. O SMB 3.0 com criptografia completa é suportado apenas quando você está usando o Ubuntu
16.04 ou posterior.
Solução
O recurso de criptografia para SMB 3.0 para Linux foi introduzido no kernel 4.11. Esse recurso permite a
montagem de um compartilhamento de arquivos do Azure de local ou de uma região diferente do Azure.
Algumas distribuições do Linux podem ter alterações reportadas do kernel 4,11 para versões mais antigas do
kernel do Linux que eles mantêm. Para ajudar a determinar se sua versão do Linux dá suporte a SMB 3,0 com
criptografia, consulte usar os arquivos do Azure com o Linux.
Se o seu cliente SMB do Linux não oferecer suporte à criptografia, monte os arquivos do Azure usando o SMB 2.1
de uma VM do Azure Linux que esteja no mesmo datacenter do compartilhamento de arquivos. Verifique se a
configuração Transferência segura necessária está desativada na conta de armazenamento.
Erro "sem acesso" ao tentar acessar ou excluir um compartilhamento

Ao tentar acessar ou excluir um compartilhamento de arquivos do Azure no portal, você pode receber o seguinte
erro:
Sem acesso
Código de erro: 403
Causa 2: sua conta de usuário não tem acesso à conta de armazenamento
Navegue até a conta de armazenamento onde o compartilhamento de arquivos do Azure está localizado, clique
em Controle de acesso (IAM) e verifique se sua conta de usuário tem acesso à conta de armazenamento. Para
saber mais, confira Como proteger a conta de armazenamento com o RBAC (Controle de Acesso Baseado em
Função).
Não é possível excluir um arquivo ou diretório em um

Causa
Esse problema normalmente ocorre se o arquivo ou diretório tiver um identificador aberto.
Solução
Se os clientes SMB tiverem fechado todos os identificadores abertos e o problema continuar ocorrendo, execute o
seguinte:
Use o cmdlet do PowerShell Get-AzStorageFileHandle para exibir identificadores abertos.
Use o cmdlet do PowerShell Close-AzStorageFileHandle para fechar identificadores abertos.
NOTE
Desempenho lento em um compartilhamento de arquivos do Azure

montado em uma VM Linux
Causa 1: Caching
Uma possível causa da lentidão no desempenho é o cache desabilitado. O Caching pode ser útil se você estiver
acessando um arquivo repetidamente, caso contrário, pode ser uma sobrecarga. Verifique se você está usando o
cache antes de desabilitá-lo.
Para verificar se o cache está desabilitado, procure a entrada cache= .
Cache=none indica que o cache está desabilitado. Remonte o compartilhamento usando o comando de
montagem padrão ou adicionando explicitamente a opção cache=strict ao comando de montagem para
garantir que o modo de cache padrão ou de cache “strict” seja habilitado.
Em alguns cenários, a opção de montagem ser verino pode fazer com que o comando ls execute stat em cada
entrada do diretório. Esse comportamento resulta em degradação de desempenho quando você está listando um
diretório grande. Verifique as opções de montagem na entrada /etc/fstab :
//azureuser.file.core.windows.net/cifs /cifs cifs
vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777
Você também pode verificar se as opções corretas estão sendo usadas executando o sudo mount | grep cifs
comando e verificando sua saída. A seguir está a saída de exemplo:
//azureuser.file.core.windows.net/cifs on /cifs type cifs

(rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=1
92.168.10.1,file_mode=0777,
dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)
Se a opção cache=strict ou ser verino não estiver presente, desmonte e monte os Arquivos do Azure
novamente executando o comando de montagem da documentação. Em seguida, verifique novamente se a
entrada /etc/fstab tem as opções corretas.
Causa 2: limitação
É possível que você esteja enfrentando a limitação e que suas solicitações estejam sendo enviadas para uma fila.
Você pode verificar isso aproveitando as métricas de armazenamento do Azure no Azure monitor.
Verifique se seu aplicativo está dentro dos destinos de escala de arquivos do Azure.
Os carimbos de data/hora foram perdidos durante a cópia de arquivos

do Windows para o Linux
Em plataformas Linux / Unix, o comando cp -p falha se usuários diferentes possuírem o arquivo 1 e o arquivo 2.
Causa
O sinalizador de força f em COPYFILE resulta na execução de cp -p -f no Unix. Esse comando também não
preserva o carimbo de data/hora do arquivo que você não possui.
Use o usuário da conta de armazenamento para copiar os arquivos:
Useadd : [storage account name]
Passwd [storage account name]
Su [storage account name]
Cp -p filename.txt /share
ls: não é possível acessar '<caminho>': erro de entrada/saída

Quando você tenta listar arquivos em um compartilhamento de arquivos do Azure usando o comando ls, o
comando trava ao listar arquivos. Você obterá o seguinte erro:
ls: não é possível acessar '<caminho>': erro de entrada/saída
Solução
Atualize o kernel do Linux para as seguintes versões que possuem uma correção para esse problema:
4.4.87+
4.9.48+
4.12.11+
Todas as versões que são maiores ou iguais a 4,13
Não é possível criar links simbólicos - ln: falhou ao criar link simbólico
't': Operação não suportada
Causa
Por padrão, a montagem de compartilhamentos de arquivos do Azure no Linux usando o CIFS não habilita o
suporte a links simbólicos (links simbólicos). Você verá um erro como este:
ln -s linked -n t
ln: failed to create symbolic link 't': Operation not supported
Solução
O cliente CIFS do Linux não suporta a criação de links simbólicos no estilo do Windows sobre o protocolo SMB 2
ou 3. Atualmente, o cliente Linux suporta outro estilo de links simbólicos chamado Minshall + francês symlinks
para criar e seguir operações. Os clientes que precisam de links simbólicos podem usar a opção de montagem
"mfsymlinks". Recomendamos "mfsymlinks" porque também é o formato que os Macs usam.
Para usar links simbólicos, adicione o seguinte ao final do seu comando de montagem CIFS:
,mfsymlinks
Então o comando parece algo como:
sudo mount -t cifs //<storage-account-name>.file.core.windows.net/<share-name> <mount-point> -o vers=<smb-

version>,username=<storage-account-name>,password=<storage-account-
key>,dir_mode=0777,file_mode=0777,serverino,mfsymlinks
Em seguida, você pode criar links simbólicos como sugerido na wiki.

Erro ConditionHeadersNotSupported de um aplicativo Web usando
arquivos do Azure do navegador
O erro ConditionHeadersNotSupported ocorre ao acessar o conteúdo hospedado nos arquivos do Azure por
meio de um aplicativo que utiliza cabeçalhos condicionais, como um navegador da Web, o acesso falha. O erro
informa que os cabeçalhos de condição não têm suporte.
Causa
Ainda não há suporte para cabeçalhos condicionais. Os aplicativos que a implementam precisarão solicitar o
arquivo completo toda vez que o arquivo for acessado.
Quando um novo arquivo é carregado, a propriedade Cache-Control por padrão é "no-cache". Para forçar o
aplicativo a solicitar o arquivo a cada vez, a propriedade Cache-Control do arquivo precisa ser atualizada de "no-
cache" para "no-cache, no-Store, deve-revalidate". Isso pode ser feito usando Gerenciador de armazenamento do
Azure.
“Erro de montagem (112): o host está inativo” devido a um tempo

limite de reconexão
Um erro de montagem “112” ocorre no cliente Linux quando o cliente ficou ocioso por um longo período. Após
um tempo ocioso estendido, o cliente se desconecta e a conexão atinge o tempo limite.
Causa
A conexão pode ficar ociosa pelos seguintes motivos:
Falhas de comunicação de rede que impedem o restabelecimento de uma conexão TCP com o servidor quando
a opção de montagem "soft" padrão é usada
Correções de reconexão recentes que não estão presentes nos kernels mais antigos
Solução
Esse problema de reconexão no kernel do Linux agora foi corrigido como parte das seguintes alterações:
Corrigir a reconexão para não adiar a sessão smb3 por muito tempo após a reconexão do soquete
Chamar o serviço de eco imediatamente após a reconexão do soquete
CIFS: corrigir uma possível corrupção de memória durante a reconexão
CIFS: corrigir um possível bloqueio duplo de mutex durante a reconexão (para kernel v4.9 e posterior)
No entanto, essas alterações ainda podem não ter sido portadas para todas as distribuições do Linux. Se você
estiver usando uma distribuição do Linux popular, poderá verificar em usar os arquivos do Azure com o Linux
para ver qual versão da sua distribuição tem as alterações de kernel necessárias.
Resolva esse problema especificando uma montagem rígida. Uma montagem rígida força o cliente a esperar até
que uma conexão seja estabelecida ou até que seja explicitamente interrompida. Você pode usá-lo para evitar
erros devido a tempos limite da rede. No entanto, essa solução alternativa pode causar esperas indefinidas. Esteja
preparado para interromper conexões, conforme necessário.
Se você não pode atualizar para as versões mais recentes do kernel, você pode contornar esse problema
mantendo um arquivo no compartilhamento de arquivos do Azure que você grava a cada 30 segundos ou
menos. Essa deve ser uma operação de gravação, como regravar a data de criação ou de modificação no arquivo.
Caso contrário, você poderá obter resultados em cache e a operação poderá não disparar a reconexão.
"CIFS VFS: Error-22 no IOCTL para obter a lista de interfaces" ao

montar um compartilhamento de arquivos do Azure usando SMB 3,0
Causa
Esse erro é registrado porque os arquivos do Azure atualmente não dão suporte ao SMB multicanal.
Solução
Este erro pode ser ignorado.
Precisa de ajuda? Entre em contato com o suporte.

Caso ainda precise de ajuda, contate o suporte para resolver seu problema rapidamente.
Solucionar problemas de desempenho de arquivos
do Azure
Este artigo lista alguns problemas comuns relacionados aos compartilhamentos de arquivos do Azure. Ele fornece
possíveis causas e soluções alternativas quando esses problemas são encontrados.
Alta latência, baixa taxa de transferência e problemas gerais de

desempenho
Causa 1: compartilhamento com limitação
A cota padrão em um compartilhamento Premium é 100 GiB, que fornece um IOPS de linha de base 100 (com um
potencial de disparo de até 300 por uma hora). Para obter mais informações sobre o provisionamento e sua
relação com o IOPS, consulte a seção compartilhamentos provisionados do guia de planejamento.
Para confirmar se o compartilhamento está sendo limitado, você pode aproveitar as métricas do Azure no Portal.
2. Selecione todos os ser viços e, em seguida, pesquise métricas .
3. Selecione métricas .
4. Selecione sua conta de armazenamento como o recurso.
5. Selecione arquivo como o namespace de métrica.
6. Selecione Transações como a métrica.
7. Adicione um filtro para ResponseType e verifique se alguma solicitação tem um código de resposta de
SUCCESSWITHTHROTTLING (para SMB) ou ClientThrottlingError (para REST).
NOTE
Para receber um alerta se um compartilhamento de arquivos for limitado, consulte como criar um alerta se um
compartilhamento de arquivos for limitado.
Solução
Aumente a capacidade de compartilhamento provisionada especificando uma cota maior em seu
compartilhamento.
Causa 2: carga de trabalho pesada de metadados/namespace
Se a maioria de suas solicitações for centrada em metadados, (como
CreateFile/OpenFile/CloseFile/QueryInfo/querydirectory), a latência será pior quando comparada com as
operações de leitura/gravação.
Para confirmar se a maioria das suas solicitações são centradas em metadados, você pode usar as mesmas etapas
acima. Exceto em vez de adicionar um filtro para ResponseType , adicione um filtro para o nome da API .
Verifique se o aplicativo pode ser modificado para reduzir o número de operações de metadados.
Adicione um VHD no compartilhamento de arquivos e monte o VHD sobre SMB do cliente para executar
operações de arquivos nos dados. Essa abordagem funciona para cenários de gravador único e vários leitores e
permite que as operações de metadados sejam locais, oferecendo desempenho semelhante a um
armazenamento de conexão direta local.
Causa 3: aplicativo de thread único
Se o aplicativo que está sendo usado pelo cliente for de thread único, isso poderá resultar em IOPS/taxa de
transferência significativamente menor do que o máximo possível com base no tamanho do compartilhamento
provisionado.
Solução
Aumente o paralelismo do aplicativo aumentando o número de threads.
Alterne para aplicativos onde o paralelismo é possível. Por exemplo, para operações de cópia, os clientes podem
usar o AzCopy ou o RoboCopy de clientes Windows ou o comando paralelo em clientes Linux.
Latência muito alta para solicitações

Causa
A VM do cliente pode estar localizada em uma região diferente do compartilhamento de arquivos.
Solução
Execute o aplicativo de uma VM que está localizada na mesma região que o compartilhamento de arquivos.
O cliente não consegue obter a taxa de transferência máxima com

suporte pela rede
Uma causa potencial disso é a falta de suporte a vários canais SMB. Atualmente, os compartilhamentos de
arquivos do Azure dão suporte apenas a um único canal, portanto, há apenas uma conexão da VM do cliente com
o servidor. Essa conexão única é vinculada a um único núcleo na VM do cliente, portanto, a taxa de transferência
máxima Obtida de uma VM é associada a um único núcleo.
A obtenção de uma VM com um núcleo maior pode ajudar a melhorar a taxa de transferência.
A execução do aplicativo cliente de várias VMs aumentará a taxa de transferência.
Use as APIs REST sempre que possível.
A taxa de transferência em clientes Linux é significativamente menor

quando comparada aos clientes Windows.
Causa
Esse é um problema conhecido com a implementação do cliente SMB no Linux.
Espalhe a carga entre várias VMs.
Na mesma VM, use vários pontos de montagem com a opção nosharesock e espalhe a carga entre esses
pontos de montagem.
No Linux, tente montar com a opção nostrictsync para evitar forçar a liberação SMB em cada chamada fsync .
Para arquivos do Azure, essa opção não interfere na consistência dos dados, mas pode resultar em metadados
de arquivo obsoletos na listagem de diretório (comandols-l ). Consultar diretamente os metadados do arquivo
(comandostat ) retornará os metadados de arquivo mais atualizados.
Altas latências de metadados cargas de trabalho pesadas envolvendo

operações de abertura/fechamento extensivas.
Causa
Falta de suporte para concessões de diretório.
Se possível, evite um excesso de identificadores de abertura/fechamento no mesmo diretório em um curto
período de tempo.
Para VMs do Linux, aumente o tempo limite do cache de entrada de diretório especificando actimeo =<SEC>
como uma opção de montagem. Por padrão, é um segundo, portanto, um valor maior, como três ou cinco, pode
ajudar.
Para VMs do Linux, atualize o kernel para 4,20 ou superior.
IOPS baixo no CentOS/RHEL

Causa
A profundidade de e/s maior que uma não tem suporte no CentOS/RHEL.
Atualize para o CentOS 8/RHEL 8.
Altere para Ubuntu.
Cópia de arquivos bidirecional lenta dos Arquivos do Azure no Linux

Se estiver experimentando uma cópia de arquivos lenta de e para arquivos do Azure, confira a seção cópia de
arquivo lento de e para arquivos do Azure no Linux no guia de solução de problemas do Linux.
Tremulação/padrão de serra-Tooth para IOPS

Causa
O aplicativo cliente excede consistentemente o IOPS de linha de base. Atualmente, não há nenhuma suavização do
lado do serviço da carga da solicitação; portanto, se o cliente exceder o IOPS de linha de base, ele será limitado
pelo serviço. Essa limitação pode resultar no cliente com um padrão de IOPS de tremulação/Serra-Tooth. Nesse
caso, o IOPS médio obtido pelo cliente pode ser menor do que o IOPS de linha de base.
Reduza a carga de solicitação do aplicativo cliente, para que o compartilhamento não seja limitado.
Aumente a cota do compartilhamento para que o compartilhamento não seja limitado.
Chamadas excessivas de DirectoryOpen/DirectoryClose
Causa
Se o número de chamadas DirectoryOpen/DirectoryClose estiver entre as principais chamadas de API e você não
espera que o cliente esteja fazendo essa quantidade de chamadas, pode ser um problema com o antivírus
instalado na VM do cliente do Azure.
Uma correção para esse problema está disponível na atualização da plataforma de abril para Windows.
A criação do arquivo é mais lenta do que o esperado

Causa
As cargas de trabalho que dependem da criação de um grande número de arquivos não verão uma diferença
significativa entre o desempenho de compartilhamentos de arquivos Premium e compartilhamentos de arquivos
padrão.
Nenhum.
Desempenho lento do Windows 8.1 ou do servidor 2012 R2

Causa
Maior que a latência esperada Acessando arquivos do Azure para cargas de trabalho com uso intensivo de e
Instale o hotfixdisponível.
Como criar um alerta se um compartilhamento de arquivos for limitado

1. Na portal do Azure, clique em Monitor .
2. Clique em aler tas e, em seguida, clique em + nova regra de aler ta .
3. Clique em selecionar para selecionar o recurso de conta de armazenamento/arquivo que contém o
compartilhamento de arquivos no qual você deseja alertar e clique em concluído . Por exemplo, se o nome
da conta de armazenamento for contoso, selecione o recurso contoso/File.
4. Clique em Adicionar para adicionar uma condição.
5. Você verá uma lista de sinais com suporte para a conta de armazenamento, selecione a métrica Transações
.
6. Na folha Configurar lógica de sinal , vá para a dimensão tipo de resposta , clique na lista suspensa
valores de dimensão e selecione SuccessWithThrottling (para SMB) ou ClientThrottlingError (para
REST).
NOTE
Se o valor da dimensão SuccessWithThrottling ou ClientThrottlingError não estiver listado, isso significará que o recurso não
foi limitado. Para adicionar o valor de dimensão, clique + na lista suspensa ao lado dos valores de dimensão , digite
SuccessWithThrottling ou ClientThrottlingError , clique em OK e repita a etapa #6.
7. Vá para a dimensão de compar tilhamento de arquivos , clique na lista suspensa valores de dimensão e
selecione os compartilhamentos de arquivos que você deseja alertar.
NOTE
Se o compartilhamento de arquivos for um compartilhamento de arquivos padrão, a lista suspensa valores de dimensão
ficará em branco porque as métricas por compartilhamento não estão disponíveis para compartilhamentos de arquivos
padrão. Os alertas de limitação para compartilhamentos de arquivos padrão serão disparados se algum compartilhamento
de arquivos dentro da conta de armazenamento for limitado e o alerta não identificar qual compartilhamento de arquivos foi
limitado. Como as métricas por compartilhamento não estão disponíveis para compartilhamentos de arquivos padrão, a
recomendação é ter um compartilhamento de arquivos por conta de armazenamento.
8. Defina os parâmetros de aler ta (limite, operador, granularidade de agregação e frequência) que são usados
para avaliar a regra de alerta de métrica e clique em concluído .
TIP
Se você estiver usando um limite estático, o gráfico de métrica poderá ajudar a determinar um limite razoável se o
compartilhamento de arquivos estiver sendo limitado no momento. Se você estiver usando um limite dinâmico, o gráfico de
métrica exibirá os limites calculados com base nos dados recentes.
9. Adicione um grupo de ação (email, SMS, etc.) ao alerta selecionando um grupo de ação existente ou
criando um novo grupo de ação.
10. Preencha os detalhes do aler ta , como nome da regra de aler ta , Descrição e severidade .
11. Clique em criar regra de aler ta para criar o alerta.
Para saber mais sobre como configurar alertas no Azure Monitor, consulte visão geral de alertas no Microsoft
Azure.
Solucionar problemas da Sincronização de Arquivos
do Azure
Use a Sincronização de Arquivos do Azure para centralizar os compartilhamentos de arquivos da sua

organização em Arquivos do Azure enquanto mantém a flexibilidade, o desempenho e a compatibilidade de um
servidor de arquivos local. A Sincronização de arquivos do Azure transforma o Windows Server em um cache
rápido do compartilhamento de arquivos do Azure. Use qualquer protocolo disponível no Windows Server para
acessar seus dados localmente, incluindo SMB, NFS e FTPS. Você pode ter tantos caches quantos precisar em
todo o mundo.
Este artigo foi projetado para ajudá-lo a solucionar problemas e resolver problemas encontrados com a
implantação da Sincronização de arquivos do Azure. Nós também descrevemos como coletar logs importantes
do sistema para ajudar em uma investigação mais profunda dos problemas. Se você não vir a resposta para sua
pergunta aqui, poderá entrar em contato conosco pelos seguintes canais (em ordem progressiva):
1. Fórum do armazenamento do Azure.
2. O UserVoice do Arquivos do Azure.
3. O Suporte da Microsoft. Para criar uma nova solicitação de suporte, no Portal do Azure, na guia Ajuda ,
selecione o botão Ajuda + supor te e, em seguida, selecione Nova solicitação de supor te .
Estou tendo um problema com o Azure File Sync no meu servidor

(sincronização, nível de nuvem, etc.). Deve remover e recriar o ponto
de extremidade do meu servidor?
Não: a remoção de um ponto de extremidade do servidor não é como reinicializar um servidor! Remover e
recriar o ponto de extremidade do servidor quase nunca é uma solução apropriada para corrigir problemas
com sincronização, camadas de nuvem ou outros aspectos de Sincronização de Arquivos do Azure. A remoção
de um ponto de extremidade do servidor é uma operação destrutiva. Isso pode resultar em perda de dados,
caso os arquivos em camadas existam fora do namespace do ponto de extremidade do servidor. Veja por que
arquivos em camadas existem fora do namespace do ponto de extremidade do servidor para obter mais
informações. Ou pode resultar em arquivos inacessíveis para arquivos em camadas que existem dentro do
namespace do ponto de extremidade do servidor. Esses problemas não serão resolvidos quando o ponto de
extremidade do servidor for recriado. Arquivos em camadas podem existir em seu ponto de extremidade do
servidor, mesmo se você nunca tiver habilitado nuvem em camadas. É por isso que é recomendável não
remover o ponto de extremidade do servidor, a menos que você queira parar de usar Sincronização de
Arquivos do Azure com essa pasta específica ou tenha sido instruído explicitamente a fazer isso por um
engenheiro da Microsoft. Para obter mais informações sobre remover pontos de extremidade do servidor,
consulte remover um ponto de extremidade do servidor.
Instalação do agente e registro do servidor

Solucionar problemas de falhas de instalação do agente
Se a instalação do agente de Sincronização de arquivos do Azure estiver falhando, execute o seguinte comando
em um prompt de comandos com privilégios elevados para habilitar o registro em log durante a instalação do
agente:
StorageSyncAgent.msi /l*v AFSInstaller.log
Examine o installer.log para determinar a causa da falha de instalação.

A instalação do agente falha no Controlador de Domínio do Active Director y
Se você tentar instalar o agente de sincronização em um controlador de domínio do Active Directory no qual o
proprietário da função PDC esteja em uma versão do Windows Server 2008 R2 ou inferior, poderá atingir o
problema em que o agente de sincronização não será instalado.
Para resolver, transfira a função de PDC para outro controlador de domínio em execução no Windows Server
2012 R2 ou mais recente e, em seguida, instale a sincronização.
Falha ao acessar um volume no Windows Ser ver 2012 R2 com o erro: o parâmetro está incorreto
Depois de criar um ponto de extremidade de servidor no Windows Server 2012 R2, o seguinte erro ocorrerá ao
acessar o volume:
letra_da_unidade: \ Não está acessível.
O parâmetro está incorreto.
Para resolver, instale as atualizações mais recentes do Windows Server 2012 R2 e reinicie o servidor.
O registro do ser vidor não lista todas as assinaturas do Azure
Ao registrar um servidor usando o ServerRegistration. exe, as assinaturas estão ausentes quando você clica na
lista suspensa assinatura do Azure.
Esse problema ocorre porque o ServerRegistration. exe não oferece suporte a ambientes de multilocatário no
momento. Esse problema será corrigido em uma atualização futura do agente de Sincronização de Arquivos do
Azure.
Para solucionar esse problema, use os seguintes comandos do PowerShell para registrar o servidor:
Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.PowerShell.Cmdlets.dll"

Login-AzureRmStorageSync -SubscriptionID "<guid>" -TenantID "<guid>"
Register-AzureRmStorageSyncServer -SubscriptionId "<guid>" -ResourceGroupName "<string>" -
StorageSyncServiceName "<string>"
O registro do ser vidor exibe a seguinte mensagem: "pré-requisitos estão ausentes"

Essa mensagem será exibida se o módulo do PowerShell AZ ou AzureRM não estiver instalado no PowerShell
5,1.
NOTE
ServerRegistration. exe não dá suporte ao PowerShell 6. x. Você pode usar o cmdlet Register-AzStorageSyncServer no
PowerShell 6. x para registrar o servidor.
Para instalar o módulo AZ ou AzureRM no PowerShell 5,1, execute as seguintes etapas:

1. Digite PowerShell em um prompt de comandos com privilégios elevados e pressione Enter.
2. Instale o módulo AZ ou AzureRM mais recente seguindo a documentação:
Módulo AZ (requer .NET 4.7.2)
Módulo AzureRM
3. Execute ServerRegistration.exe e siga o assistente para registrar o servidor com um Serviço de
O registro do ser vidor exibe a seguinte mensagem: "este ser vidor já está registrado"
Esta mensagem é exibida se o servidor foi registrado anteriormente com um Serviço de Sincronização de
Armazenamento. Para cancelar o registro do servidor com o Serviço de Sincronização de Armazenamento atual
e registrar com o novo Serviço de Sincronização de Armazenamento, siga as etapas para Cancelar o registro de
um servidor com uma Sincronização de arquivos do Azure.
Se o servidor não estiver listado em Ser vidores registrados no Serviço de Sincronização de
Armazenamento, no servidor cujo registro você deseja cancelar, execute os seguintes comandos do PowerShell:

Reset-StorageSyncServer
NOTE
Se o servidor for parte de um cluster, você pode usar opcional StorageSyncServer Reset - CleanClusterRegistration
parâmetro também para remover o registro de cluster.
Quando registro um ser vidor, vejo várias respostas de "sites não confiáveis". Por?
Esse erro ocorre porque a política Segurança reforçada do Internet Explorer está habilitada durante o
registro do servidor. Para obter mais informações sobre como desabilitar corretamente a política Segurança
aprimorada do Internet Explorer , consulte Preparar o Windows Server para usar com o Azure File Sync e
Como implantar o Azure File Sync.
O ser vidor não está listado em ser vidores registrados no por tal do Azure
Se algum servidor não estiver listado em Ser vidores registrados de um Serviço de Sincronização de
Armazenamento:
1. Entre no servidor que você deseja registrar.
2. Abra o Explorador de arquivos e, em seguida, vá para o diretório de instalação do agente de sincronização
de armazenamento (o local padrão é C:\Program Files\Azure\StorageSyncAgent).
3. Execute ServerRegistration.exe e siga o assistente para registrar o servidor com um Serviço de
Gerenciamento de grupo de sincronização

Falha na criação de ponto de extremidade de nuvem, com este erro: "O FileShare do Azure
especificado já está sendo usado por um CloudEndpoint diferente"
Esse erro ocorre se o compartilhamento de arquivo do Azure já está em uso por outro ponto de extremidade da
nuvem.
Se essa mensagem aparecer e o compartilhamento de arquivos do Azure não estiver sendo usado por um
ponto de extremidade de nuvem no momento, conclua as seguintes etapas para limpar os metadados da
Sincronização de arquivos do Azure no compartilhamento de arquivos do Azure:
WARNING
Excluir os metadados em um compartilhamento de arquivos do Azure que está sendo usado no momento por um ponto
de extremidade de nuvem faz com que as operações da Sincronização de arquivos do Azure falhem.
1. Navegue até o seu compartilhamento de arquivos do Azure no Portal do Azure.

2. Clique com o botão direito do mouse no compartilhamento de arquivos do Azure e selecione Editar
metadados .
3. Clique com o botão direito do mouse em SyncSer vice e selecione excluir .
Falha na criação de ponto de extremidade de nuvem, com este erro: "AuthorizationFailed"
Esse erro ocorrerá se sua conta de usuário não tiver direitos suficientes para criar um ponto de extremidade de
nuvem.
Para criar um ponto de extremidade de nuvem, sua conta de usuário deve ter as seguintes permissões de
Autorização da Microsoft:
Leitura: Obter a definição da função
Gravação: Criar ou atualizar definição de função personalizada
Leitura: Obter a atribuição da função
Gravação: Criar a atribuição da função
As seguintes funções internas têm as permissões de Autorização da Microsoft adequadas:
Proprietário
Administrador de Acesso do Usuário
Para determinar se sua função de conta de usuário tem as permissões necessárias:
1. No portal do Azure, clique em Grupos de recursos .
2. Selecione o grupo de recursos em que a conta de armazenamento está localizada e clique em Controle de
acesso (IAM) .
3. Selecione a guia Atribuições de função .
4. Selecione a função (por exemplo, proprietário ou colaborador) para sua conta de usuário.
5. Na lista provedor de recursos , selecione autorização da Microsoft .
A atribuição de função deve ter permissões de leitura e gravação .
A definição de função deve ter permissões de leitura e gravação .
Falha na criação do ponto de extremidade do ser vidor, com este erro: "MgmtSer verJobFailed"
(código de erro:-2134375898 ou 0x80c80226)
Esse erro ocorrerá se o caminho do ponto de extremidade de servidor estiver no volume do sistema e a camada
de nuvem estiver habilitada. A camada de nuvem não tem suporte no volume do sistema. Para criar um ponto
de extremidade do servidor no volume do sistema, desabilite a disposição em camadas da nuvem ao criar o
ponto de extremidade do servidor.
(código de erro:-2147024894 ou 0x80070002)
Esse erro ocorrerá se o caminho do ponto de extremidade do servidor especificado não for válido. Verifique se
o caminho do ponto de extremidade do servidor especificado é um volume NTFS anexado localmente. Observe
que Sincronização de Arquivos do Azure não oferece suporte a unidades mapeadas como um caminho de
ponto de extremidade do servidor.
Esse erro ocorrerá se o caminho do ponto de extremidade do servidor especificado não for um volume NTFS.
Verifique se o caminho do ponto de extremidade do servidor especificado é um volume NTFS anexado
localmente. Observe que Sincronização de Arquivos do Azure não oferece suporte a unidades mapeadas como
um caminho de ponto de extremidade do servidor.
(código de erro:-2134347507 ou 0x80c8710d)
Esse erro ocorre porque a Sincronização de Arquivos do Azure não é compatível com pontos de extremidade de
servidor em volumes que têm uma pasta de informações de volume do sistema compactada. Para resolver esse
problema, descompacte a pasta Informações de Volume do Sistema. Se a pasta Informações de Volume do
Sistema for a única pasta compactada no volume, execute as seguintes etapas:
1. Baixe a ferramenta PsExec .
2. Execute o seguinte comando em um prompt de comando elevado para iniciar um prompt de comando em
execução na conta do sistema: PsExec. exe-i-s-d cmd
3. No prompt de comando em execução na conta do sistema, digite os seguintes comandos e pressione Enter:
CD/d "letra da unidade: \ informações do volume do sistema"
compactar/u/s
(código de erro:-2134376345 ou 0x80C80067)
Esse erro ocorrerá se o limite de pontos de extremidade do servidor por servidor for atingido. A Sincronização
de Arquivos do Azure atualmente permite até 30 pontos de extremidade de servidor por servidor. Para obter
mais informações, consulte sincronização de arquivos do Azure dimensionar destinos.
Esse erro ocorrerá se outro ponto de extremidade do servidor já estiver sincronizando o caminho do ponto de
extremidade do servidor especificado. A Sincronização de Arquivos do Azure não é compatível com vários
pontos de extremidade de servidor sincronizando o mesmo diretório ou volume.
Esse erro ocorrerá se o caminho do ponto de extremidade do servidor contiver arquivos em camadas órfãos. Se
um ponto de extremidade do servidor tiver sido removido recentemente, aguarde a conclusão da limpeza de
arquivos em camadas órfãos. Uma ID de evento 6662 é registrada no log de eventos de telemetria quando a
limpeza de arquivos em camadas órfãos é iniciada. Uma ID de evento 6661 será registrada depois que a
limpeza de arquivos em camadas órfãos for concluída e um ponto de extremidade do servidor puder ser
recriado usando o caminho. Se a criação do ponto de extremidade do servidor falhar depois que uma ID de
evento 6661 for registrada, remova os arquivos em camadas órfãos executando as etapas documentadas nos
arquivos em camadas não estarão acessíveis no servidor após a exclusão de uma seção de ponto de
extremidade do servidor .
Falha na exclusão do ponto de extremidade do ser vidor, com este erro: "MgmtSer verJobExpired"
Esse erro ocorrerá se o servidor estiver offline ou não tiver conectividade de rede. Se o servidor não estiver
mais disponível, cancele o registro do servidor no portal que excluirá os pontos de extremidade do servidor.
Para excluir os pontos de extremidade do servidor, siga as etapas descritas em Cancelar o registro de um
servidor com a Sincronização de Arquivos do Azure.
Não é possível abrir a página de propriedades do ponto de extremidade do ser vidor ou atualizar
a política de camada de nuvem
Esse problema pode ocorrer se uma operação de gerenciamento no ponto de extremidade do servidor falhar.
Se a página de propriedades do ponto de extremidade de servidor não abrir no Portal do Azure, atualizar o
ponto de extremidade de servidor usando comandos do PowerShell a partir do servidor poderá solucionar esse
problema.
# Get the server endpoint id based on the server endpoint DisplayName property
Get-AzStorageSyncServerEndpoint `
-ResourceGroupName myrgname `
-StorageSyncServiceName storagesvcname `
-SyncGroupName mysyncgroup | `
Tee-Object -Variable serverEndpoint
# Update the free space percent policy for the server endpoint
Set-AzStorageSyncServerEndpoint `
-InputObject $serverEndpoint
-CloudTiering `
-VolumeFreeSpacePercent 60
O ponto de extremidade do ser vidor tem um status de integridade "nenhuma atividade" ou

"pendente" e o estado do ser vidor na folha ser vidores registrados é "aparece offline"
Esse problema pode ocorrer se o processo do monitor de sincronização de armazenamento
(AzureStorageSyncMonitor. exe) não estiver em execução ou se o servidor não puder acessar o serviço de
No servidor que está sendo exibido como "aparece offline" no portal, examine a ID do evento 9301 no log de
eventos de telemetria (localizado em Applications and Services\Microsoft\FileSync\Agent in Visualizador de
Eventos) para determinar por que o servidor não consegue acessar o serviço Sincronização de Arquivos do
Azure.
Se GetNextJob concluído com o status: 0 for registrado, o servidor poderá se comunicar com o
serviço de sincronização de arquivos do Azure.
Abra o Gerenciador de Tarefas no servidor e verifique se o processo do Monitor de Sincronização de
Armazenamento (AzureStorageSyncMonitor.exe) está em execução. Se o processo não estiver
funcionando, primeiro tente reiniciar o servidor. Se a reinicialização do servidor não resolver o
problema, atualize o agente de Sincronização de Arquivos do Azure para a versão.
Se GetNextJob concluído com status:-2134347756 for registrado, o servidor não poderá se
comunicar com o serviço de sincronização de arquivos do Azure devido a um firewall ou proxy.
Se o servidor estiver atrás de um firewall, verifique se a porta 443 de saída é permitida. Se o firewall
restringe o tráfego para domínios específicos, confirme se os domínios listados na documentação do
firewall estão acessíveis.
Se o servidor estiver protegido por um proxy, defina as configurações de proxy específicas do
computador ou do aplicativo seguindo as etapas na documentaçãodo proxy.
Use o cmdlet Test-StorageSyncNetworkConnectivity para verificar a conectividade de rede para os
pontos de extremidade de serviço. Para saber mais, confira testar a conectividade de rede para pontos
de extremidade de serviço.
Se GetNextJob concluído com status:-2134347764 for registrado, o servidor não poderá se
comunicar com o serviço de sincronização de arquivos do Azure devido a um certificado expirado ou
excluído.
Execute o seguinte comando do PowerShell no servidor para redefinir o certificado usado para
autenticação:
Reset-AzStorageSyncServerCertificate -ResourceGroupName <string> -StorageSyncServiceName <string>
O ponto de extremidade do ser vidor tem um status de integridade de "nenhuma atividade" e o

estado do ser vidor na folha ser vidores registrados é "online"
Um status de integridade do ponto de extremidade de servidor de “Sem Atividade” significa que o ponto de
extremidade do servidor não registrou a atividade de sincronização em log nas últimas duas horas.
Para verificar a atividade de sincronização atual em um servidor, confira Como fazer para monitorar o
andamento de uma sessão de sincronização atual?.
Um ponto de extremidade do servidor pode não registrar a atividade de sincronização por várias horas devido
a um bug ou recursos do sistema insuficientes. Verifique se a versão mais recente do agente de sincronização
de arquivos do Azure está instalada. Se o problema persistir, abra uma solicitação de suporte.
NOTE
Se o estado do servidor na folha servidores registrados for "aparecer offline", execute as etapas documentadas no ponto
de extremidade do servidor tem um status de integridade "sem atividade" ou "pendente" e o estado do servidor na folha
servidores registrados é "aparece offline" .
Sincronizar
Se eu criar um arquivo diretamente em meu compar tilhamento de arquivos do Azure usando SMB
ou por meio do por tal, quanto tempo levará para que o arquivo seja sincronizado com os
ser vidores no grupo de sincronização?
As alterações feitas ao compartilhamento de Arquivos do Azure usando o Portal do Azure ou SMB não são
detectadas e replicadas imediatamente como as alterações no Ponto de extremidade do servidor são. Os
Arquivos do Azure ainda não têm notificações/diário de alteração, portanto, não há nenhuma maneira de iniciar
automaticamente uma sessão de sincronização quando os arquivos são alterados. No Windows Server, a
sincronização de Arquivos do Azure usa o diário de USN do Windows para iniciar automaticamente uma sessão
de sincronização quando os arquivos são alterados.
Para detectar alterações para o compartilhamento de arquivos do Azure, a sincronização de arquivos do Azure
tem um trabalho agendado chamado um alterar o trabalho de detecção. Um trabalho de detecção de alteração
enumera todos os arquivos no compartilhamento de arquivos e, em seguida, compara a versão de
sincronização para esse arquivo. Quando o trabalho de detecção de alteração determina que os arquivos foram
alterados, a sincronização de Arquivos do Azure inicia uma sessão de sincronização. O trabalho de detecção de
alteração é iniciado a cada 24 horas. Como o trabalho de detecção de alteração funciona enumerando todos os
arquivos no compartilhamento de Arquivos do Azure, a detecção de troca demora mais nos namespaces
grandes do que namespaces menores. Para esses namespaces, pode levar mais de uma vez a cada 24 horas
para determinar quais arquivos foram alterados.
Para sincronizar imediatamente os arquivos que são alterados no compartilhamento de arquivos do Azure, o
cmdlet Invoke-AzStorageSyncChangeDetection do PowerShell pode ser usado para iniciar manualmente a
detecção de alterações no compartilhamento de arquivos do Azure. Esse cmdlet destina-se a cenários em que
algum tipo de processo automatizado está fazendo alterações no compartilhamento de arquivos do Azure ou
as alterações são feitas por um administrador (como mover arquivos e diretórios para o compartilhamento).
Para alterações do usuário final, a recomendação é instalar o agente de Sincronização de Arquivos do Azure em
uma VM IaaS e fazer com que os usuários finais acessem o compartilhamento de arquivos por meio da VM
IaaS. Dessa forma, todas as alterações serão rapidamente sincronizadas com outros agentes sem a necessidade
de usar o cmdlet Invoke-AzStorageSyncChangeDetection. Para saber mais, confira a documentação do Invoke-
NOTE
As alterações feitas em um compartilhamento de arquivos do Azure usando REST não atualizam a hora da última
modificação do SMB e não serão vistas como uma alteração por sincronização.
Estamos explorando adicionar detecção de alteração para um compartilhamento de arquivos do Azure

semelhante ao USN para volumes no Windows Server. Ajude-nos a priorizar esse recurso para
desenvolvimento futuro votando no UserVoice de Arquivos do Azure.
** A integridade do ponto de extremidade do servidor está em um estado pendente por várias horas**
Esse problema é esperado quando você cria um ponto de extremidade de nuvem e usa um compartilhamento
de arquivos do Azure que contém dados. A tarefa de enumeração de alterações que verifica as alterações no
compartilhamento de arquivos do Azure deve ser concluída antes que os arquivos possam ser sincronizados
entre os nós de extremidade da nuvem e do servidor. O tempo para concluir o trabalho depende do tamanho
do espaço para nome no compartilhamento de arquivos do Azure. A integridade do ponto de extremidade do
servidor deve ser atualizada quando o trabalho de enumeração de alterações for concluído.
Como fazer para monitorar a integridade da sincronização?
Portal
Servidor
Em cada grupo de sincronização, você pode detalhar seus pontos de extremidade de servidor individuais para
ver o status das últimas sessões de sincronização concluídas. Uma coluna de integridade verde e um valor de
não sincronização de arquivos de 0 indicam que a sincronização está funcionando conforme o esperado. Se
esse não for o caso, veja abaixo uma lista de erros comuns de sincronização e como manipular arquivos que
não estão sendo sincronizados.
Como monitoro o progresso de uma sessão de sincronização atual?

Portal
Servidor
Dentro do seu grupo de sincronização, vá para o ponto de extremidade do servidor em questão e examine a
seção Atividade de Sincronização para ver a contagem de arquivos carregados ou baixados na sessão de
sincronização atual. Observe que esse status será atrasado em cerca de 5 minutos e, se sua sessão de
sincronização for pequena o suficiente para ser concluída dentro desse período, ela pode não ser informada no
portal.
Como sei se meus servidores estão em sincronia um com o outro?
Portal
Servidor
Para cada servidor em um determinado grupo de sincronização, verifique se:
Os timestamps da última tentativa de sincronização para upload e download são recentes.
O status é verde para carregamento e download.
O campo Atividade de Sincronização mostra poucos ou nenhum arquivo restante para sincronizar.
O campo Arquivos que não são sincronizados é 0 para upload e download.
Como faço para ver se há arquivos ou pastas específicos que não estão sendo sincronizados?
Se seu PerItemErrorCount no servidor ou os arquivos que não estão sincronizando a contagem no portal forem
maiores que 0 para qualquer sessão de sincronização específica, isso significará que alguns itens não serão
sincronizados. Arquivos e pastas podem ter características que os impeçam de sincronizar. Essas características
podem ser persistentes e exigem ação explícita para retomar a sincronização, por exemplo, removendo
caracteres não suportados do nome do arquivo ou da pasta. Eles também podem ser temporários, o que
significa que o arquivo ou a pasta retornará automaticamente à sincronização. por exemplo, arquivos com
identificadores abertos retomarão automaticamente a sincronização quando o arquivo for fechado. Quando o
mecanismo do Azure File Sync detecta esse problema, é produzido um log de erros que pode ser analisado
para listar os itens que atualmente não estão sendo sincronizados corretamente.
Para ver esses erros, execute o script do PowerShell FileSyncErrorsRepor t.ps1 (localizado no diretório de
instalação do Agente do Azure File Sync) para identificar os arquivos que falharam na sincronização devido a
identificadores abertos, caracteres não suportados ou outros problemas . O campo ItemPath informa a
localização do arquivo em relação ao diretório de sincronização raiz. Veja abaixo a lista de erros comuns de
sincronização para as etapas de correção.
NOTE
Se o script FileSyncErrorsReport. ps1 retornar "não havia nenhum erro de arquivo encontrado" ou não listar erros por
item para o grupo de sincronização, a causa será:
Causa 1: a última sessão de sincronização concluída não tinha erros por item. O portal deve ser atualizado em
breve para mostrar 0 arquivos não sincronizando.
Verifique a ID do evento 9102 no log de eventos de telemetria para confirmar se o PerItemErrorCount é 0.
Causa 2: o log de eventos do doresults no servidor foi encapsulado devido a muitos erros por item e o log de
eventos não contém mais erros para esse grupo de sincronização.
Para evitar esse problema, aumente o tamanho do log de eventos do item de resultados. O log de eventos do
doresults pode ser encontrado em "Applications and Services Logs\Microsoft\FileSync\Agent" em Visualizador
de Eventos.
Solução de problemas por erros de sincronização de arquivos/diretórios

ItemResulta erros de sincronização de log por item
C A DEIA DE
C A RA C T ERES DE
H RESULT H RESULT ( DEC IM A L ) ERRO P RO B L EM A C O RREÇ Ã O
0x80070043 -2147942467 ERROR_BAD_NET_NA O arquivo em Para resolver esse

ME camadas no servidor problema, consulte
não está acessível. arquivos em camadas
Esse problema não podem ser
ocorrerá se o arquivo acessados no
em camadas não servidor após a
tiver sido recuperado exclusão de um
antes da exclusão de ponto de
um ponto de extremidade do
extremidade do servidor.
servidor.
0x80c80207 -2134375929 ECS_E_SYNC_CONST A alteração de Nenhuma ação é

RAINT_CONFLICT arquivo ou diretório necessária. Se o erro
ainda não pode ser persistir por vários
sincronizada porque dias, use o script do
uma pasta PowerShell
dependente ainda FileSyncErrorsReport.
não foi sincronizada. ps1 para determinar
Este item será por que a pasta
sincronizado após o dependente ainda
mudanças não está
dependentes serem sincronizada.
sincronizadas.
0x80c80284 -2134375804 ECS_E_SYNC_CONST A alteração de Nenhuma ação é

RAINT_CONFLICT_SE arquivo ou diretório necessária. Se o erro
SSION_FAILED ainda não pode ser persistir, investigue a
sincronizada porque falha da sessão de
uma pasta sincronização.
dependente ainda
não foi sincronizada e
a sessão de
sincronização falhou.
Este item será
sincronizado após o
mudanças
dependentes serem
sincronizadas.
0x8007007b -2147024773 ERROR_INVALID_NA O nome do arquivo Renomeie o arquivo

ME ou diretório é ou diretório em
inválido. questão. Veja
Tratamento de
caracteres sem
suporte para obter
mais informações.
0x80c80255 -2134375851 ECS_E_XSMB_REST_I O nome do arquivo Renomeie o arquivo

NCOMPATIBILITY ou diretório é ou diretório em
inválido. questão. Veja
Tratamento de
caracteres sem
suporte para obter
mais informações.
C A DEIA DE
C A RA C T ERES DE
0x80c80018 -2134376424 ECS_E_SYNC_FILE_IN O arquivo não pode Nenhuma ação é

_USE ser sincronizado necessária. O Azure
porque está em uso. File Sync cria um
O arquivo será instantâneo
sincronizado quando temporário do VSS
não estiver mais em uma vez por dia no
uso. servidor para
sincronizar arquivos
que tenham
identificadores
abertos.
0x80c8031d -2134375651 ECS_E_CONCURREN O arquivo foi Nenhuma ação é

CY_CHECK_FAILED alterado, mas a necessária.
alteração ainda não
foi detectada pela
sincronização. A
sincronização será
recuperada depois
que essa alteração
for detectada.
0x80070002 -2147024894 ERROR_FILE_NOT_FO O arquivo foi Nenhuma ação é

UND excluído e a necessária. A
sincronização não sincronização irá
está ciente da parar de registrar
alteração. esse erro quando a
detecção de alteração
detectar que o
arquivo foi excluído.
0x80070003 -2147942403 ERROR_PATH_NOT_F A exclusão de um Nenhuma ação é

OUND arquivo ou diretório necessária. A
não pode ser sincronização
sincronizada porque interromperá o
o item já foi excluído registro desse erro
no destino e a quando a detecção
sincronização não de alteração for
está ciente da executada no destino
alteração. e a sincronização
detectar que o item
foi excluído.
0x80c80205 -2134375931 ECS_E_SYNC_ITEM_S O arquivo ou Nenhuma ação será

KIP diretório foi necessária se esse
ignorado, mas será erro for relatado ao
sincronizado durante carregar o arquivo.
a próxima sessão de Se o erro for relatado
sincronização. Se esse durante o download
erro for relatado do arquivo, renomeie
durante o download o arquivo ou
do item, o nome do diretório em questão.
arquivo ou diretório Veja Tratamento de
é mais do que caracteres sem
provavelmente suporte para obter
inválido. mais informações.
C A DEIA DE
C A RA C T ERES DE
0x800700B7 -2147024713 ERROR_ALREADY_EXI A criação de um Nenhuma ação é

STS arquivo ou diretório necessária. A
não pode ser sincronização irá
sincronizada porque parar de registrar
o item já existe no esse erro quando a
destino e a detecção de alteração
sincronização não for executada no
está ciente da destino e a
alteração. sincronização estiver
ciente desse novo
item.
0x80c8603e -2134351810 ECS_E_AZURE_STOR O arquivo não pode Para resolver esse

AGE_SHARE_SIZE_LI ser sincronizado problema, veja a
MIT_REACHED porque o limite de seção Você atingiu o
compartilhamento de limite de
arquivos do Azure foi armazenamento de
atingido. compartilhamento de
arquivos do Azure no
guia de solução de
problemas.
0x80c8027C -2134375812 ECS_E_ACCESS_DENI O arquivo é Descriptografe o

ED_EFS criptografado por arquivo e use uma
uma solução sem solução de
suporte (como o EFS criptografia com
do NTFS). suporte. Para obter
uma lista de soluções
com suporte, veja a
seção Soluções de
criptografia no guia
de planejamento.
0x80c80283 -2160591491 ECS_E_ACCESS_DENI O arquivo está O arquivo está

ED_DFSRRO localizado em uma localizado em uma
pasta de replicação pasta de replicação
somente leitura do somente leitura do
DFS-R. DFS-R. A
Sincronização de
Arquivos do Azure
não oferece suporte
a pontos de
extremidade de
servidor em pastas
de replicação
somente leitura do
DFS-R. Consulte o
Guia de
planejamento para
obter mais
informações.
C A DEIA DE
C A RA C T ERES DE
0x80070005 -2147024891 ERROR_ACCESS_DEN O arquivo tem um Nenhuma ação é

IED estado de exclusão necessária. O arquivo
pendente. será excluído quando
todos os
identificadores de
arquivos abertos
forem fechados.
0x80c86044 -2134351804 ECS_E_AZURE_AUTH O arquivo não pode Adicione o endereço

ORIZATION_FAILED ser sincronizado IP do servidor ou a
porque as rede virtual seguindo
configurações de as etapas
firewall e rede virtual documentadas na
na conta de seção Configurar o
armazenamento firewall e as
estão habilitadas e o configurações de
servidor não tem rede virtual no guia
acesso à conta de de implantação.
armazenamento.
0x80c80243 -2134375869 ECS_E_SECURITY_DE O arquivo não pode Para resolver esse

SCRIPTOR_SIZE_TOO ser sincronizado problema, remova as
_LARGE porque o tamanho entradas de controle
do descritor de de acesso no arquivo
segurança excede o para reduzir o
limite de KiB de 64. tamanho do descritor
de segurança.
0x8000ffff -2147418113 E_UNEXPECTED O arquivo não pode Se o erro persistir por

ser sincronizado vários dias, abra um
devido a um erro caso de suporte.
inesperado.
0x80070020 -2147024864 ERROR_SHARING_VI O arquivo não pode Nenhuma ação é

OLATION ser sincronizado necessária.
porque está em uso.
O arquivo será
sincronizado quando
não estiver mais em
uso.
0x80c80017 -2134376425 ECS_E_SYNC_OPLOC O arquivo foi Nenhuma ação é

K_BROKEN alterado durante a necessária.
sincronização,
portanto, ele precisa
ser sincronizado
novamente.
C A DEIA DE
C A RA C T ERES DE
0x80070017 -2147024873 ERROR_CRC O arquivo não pode Para resolver esse

ser sincronizado problema, consulte
devido a um erro de arquivos em camadas
CRC. Esse erro não podem ser
poderá ocorrer se um acessados no
arquivo em camadas servidor após a
não tiver sido exclusão de um
rechamado antes da ponto de
exclusão de um extremidade do
ponto de servidor para
extremidade do remover arquivos em
servidor ou se o camadas que estão
arquivo estiver órfãos. Se o erro
corrompido. continuar ocorrendo
após a remoção de
arquivos em camadas
órfãos, execute
chkdsk no volume.
0x80c80200 -2134375936 ECS_E_SYNC_CONFLI O arquivo não pode Para resolver esse

CT_NAME_EXISTS ser sincronizado problema, reduza o
porque o número número de arquivos
máximo de arquivos de conflito. O arquivo
de conflito foi será sincronizado
atingido. O assim que o número
Sincronização de de arquivos de
Arquivos do Azure dá conflito for menor
suporte a arquivos que 100.
de conflito 100 por
arquivo. Para saber
mais sobre conflitos
de arquivo, consulte
Sincronização de
Arquivos do Azure
perguntas
frequentes.
Manipulando Caracteres Não Suportados

Se o script do PowerShell FileSyncErrorsRepor t. ps1 mostrar falhas devido a caracteres sem suporte (código
de erro 0x8007007b ou 0x80c80255), você deverá remover ou renomear os caracteres com falha dos
respectivos nomes de arquivo. PowerShell provavelmente será impresso esses caracteres como pontos de
interrogação ou retângulos vazios, pois a maior parte desses caracteres não têm nenhuma codificação de visual
padrão. Uma Ferramenta de Avaliação pode ser usada para identificar os caracteres sem suporte.
A tabela abaixo contém todos os caracteres unicode que o Azure File Sync ainda não suporta.
C O N JUN TO DE C A RA C T ERES C O N TA GEM DE C A RA C T ERES
0x0000009D (osc comando do sistema operacional) 6

0x00000090 (cadeia de controle de dispositivo de
controladores de domínio)
0x0000008F (ss3 único shift três)
0x00000081 (predefinição de octeto alta)
0x0000007F (del delete)
0x0000008D (ri reverso alimentação de linha)
C O N JUN TO DE C A RA C T ERES C O N TA GEM DE C A RA C T ERES
0x0000FDD0 - 0x0000FDEF (apresentação árabe 32

formulários-a)
0x0000FFF0 - 0x0000FFFF (especiais) 16
0x0001FFFE - 0x0001FFFF = 2 (não caracteres) 30

0x0002FFFE - 0x0002FFFF = 2 (não caracteres)
0x0003FFFE - 0x0003FFFF = 2 (noncharacter)
0x000AFFFE - 0x000AFFFF = 2 (noncharacter)
0x000BFFFE - 0x000BFFFF = 2 (noncharacter)
0x000CFFFE - 0x000CFFFF = 2 (noncharacter)
0x000DFFFE - 0x000DFFFF = 2 (noncharacter)
0x000EFFFE - 0x000EFFFF = 2 (undefined)
0x000FFFFE - 0x000FFFFF = 2 (área de
suplementares de uso particular)
0x0010FFFE, 0x0010FFFF 2
Erros comuns de sincronização

A sessão de sincronização foi cancelada.
HRESULT 0x800704c7
HRESULT (decimal) -2147023673
Cadeia de caracteres de erro ERROR_CANCELLED
Correção necessária Não
As sessões de sincronização podem falhar por vários motivos, incluindo o servidor que está sendo reiniciado ou
atualizado, instantâneos do VSS, etc. Embora esse erro pareça que ele requer acompanhamento, é seguro
ignorar esse erro, a menos que ele persista em um período de várias horas.
Não foi possível estabelecer uma conexão com o ser viço.
HRESULT 0x80072ee7
Cadeia de caracteres de erro WININET_E_NAME_NOT_RESOLVED
Correção necessária Sim

Esse erro pode ocorrer sempre que o serviço de Sincronização de Arquivos do Azure está acessível do servidor.
Você pode solucionar esse erro trabalhando nas seguintes etapas:
1. Verifique se o serviço Windows FileSyncSvc.exe não está bloqueado pelo firewall.
2. Verifique se a porta 443 está aberta para conexões de saída para o serviço de Sincronização de Arquivos
do Azure. Você pode fazer isso com o cmdlet Test-NetConnection . A URL para o espaço reservado
<azure-file-sync-endpoint> abaixo pode ser encontrada no documento de Configurações de proxy e
firewall de Sincronização de Arquivos do Azure.
Test-NetConnection -ComputerName <azure-file-sync-endpoint> -Port 443
3. Verifique se a configuração de proxy está definida conforme o esperado. Isso pode ser feito com o
cmdlet Get-StorageSyncProxyConfiguration . Mais informações sobre como definir a configuração de
proxy para Sincronização de Arquivos do Azure podem ser encontradas em Configurações de proxy e
firewall da Sincronização de Arquivos do Azure.
$agentPath = "C:\Program Files\Azure\StorageSyncAgent"

Import-Module "$agentPath\StorageSync.Management.ServerCmdlets.dll"
Get-StorageSyncProxyConfiguration
4. Use o cmdlet Test-StorageSyncNetworkConnectivity para verificar a conectividade de rede para os

pontos de extremidade de serviço. Para saber mais, confira testar a conectividade de rede para pontos de
extremidade de serviço.
5. Contate seu administrador de rede para obter mais assistência para a solução de problemas de
conectividade de rede.
A solicitação do usuário foi limitada pelo ser viço.
HRESULT 0x80c8004c
Cadeia de caracteres de erro ECS_E_USER_REQUEST_THROTTLED
Nenhuma ação é necessária; o servidor tentará novamente. Se esse erro persistir por várias horas, crie uma
solicitação de suporte.
A sincronização será bloqueada até que a detecção de alteração seja concluída após a restauração
HRESULT 0x80c83075
Cadeia de caracteres de erro ECS_E_SYNC_BLOCKED_ON_CHANGE_DETECTION_POST_RE

STORE

Nenhuma ação é necessária. Quando um compartilhamento de arquivo ou arquivo (ponto de extremidade de
nuvem) é restaurado usando o backup do Azure, a sincronização é bloqueada até que a detecção de alteração
seja concluída no compartilhamento de arquivos do Azure. A detecção de alteração é executada imediatamente
quando a restauração é concluída, e a duração é baseada no número de arquivos no compartilhamento de
arquivo.
Falha na sincronização porque o banco de dados de sincronização foi descarregado.
HRESULT 0x80041295
Cadeia de caracteres de erro SYNC_E_METADATA_INVALID_OPERATION
Esse erro normalmente ocorre quando um aplicativo de backup cria um instantâneo de VSS e o banco de dados
de sincronização é descarregado. Se esse erro persistir por várias horas, crie uma solicitação de suporte.
A sincronização não pode acessar o compar tilhamento de arquivos do Azure especificado no
ponto de extremidade da nuvem.
HRESULT 0x80c8305f
Cadeia de caracteres de erro ECS_E_EXTERNAL_STORAGE_ACCOUNT_AUTHORIZATION_F

AILED
Esse erro ocorre porque o agente do Azure File Sync não pode acessar o compartilhamento de arquivos do
Azure, o que pode ocorrer porque o compartilhamento de arquivos do Azure ou a conta de armazenamento
que o hospeda não existe mais. Você pode solucionar esse erro trabalhando nas seguintes etapas:
1. Verifique se a conta de armazenamento existe.
2. Verifique se o compartilhamento de arquivos do Azure existe.
3. Verifique se Sincronização de Arquivos do Azure tem acesso à conta de armazenamento.
4. Verifique se as configurações de firewall e de rede virtual na conta de armazenamento estão definidas
adequadamente (se habilitadas)
Falha na sincronização porque a solicitação não está autorizada a executar esta operação.
HRESULT 0x80c86044
Cadeia de caracteres de erro ECS_E_AZURE_AUTHORIZATION_FAILED

Esse erro ocorre porque o agente de Sincronização de Arquivos do Azure não está autorizado a acessar o
compartilhamento de arquivos do Azure. Você pode solucionar esse erro trabalhando nas seguintes etapas:
4. Verifique se Sincronização de Arquivos do Azure tem acesso à conta de armazenamento.
O nome da conta de armazenamento usado não pôde ser resolvido.
HRESULT 0x80C83060
Cadeia de caracteres de erro ECS_E_STORAGE_ACCOUNT_NAME_UNRESOLVED
1. Verifique se você pode resolver o nome DNS de armazenamento do servidor.
Test-NetConnection -ComputerName <storage-account-name>.file.core.windows.net -Port 443

Ocorreu um erro desconhecido ao acessar a conta de armazenamento.
HRESULT 0x80c8308a
Cadeia de caracteres de erro ECS_E_STORAGE_ACCOUNT_UNKNOWN_ERROR

Falha na sincronização devido à conta de armazenamento bloqueada.
HRESULT 0x80c83092
Cadeia de caracteres de erro ECS_E_STORAGE_ACCOUNT_LOCKED

Esse erro ocorre porque a conta de armazenamento tem um bloqueio de recursosomente leitura. Para resolver
esse problema, remova o bloqueio de recurso somente leitura na conta de armazenamento.
Falha na sincronização devido a um problema com o banco de dados de sincronização.
HRESULT 0x8e5e044e
Cadeia de caracteres de erro JET_errWriteConflict
Esse erro ocorre quando há um problema com o banco de dados interno usado pelo Sincronização de Arquivos
do Azure. Quando esse problema ocorrer, crie uma solicitação de suporte e entraremos em contato para ajudá-
lo a resolver esse problema.
A versão do agente de Sincronização de Arquivos do Azure instalada no ser vidor não tem
supor te.
HRESULT 0x80C8306B
Cadeia de caracteres de erro ECS_E_AGENT_VERSION_BLOCKED
Este erro ocorrerá se versão do agente de Sincronização de Arquivos do Azure instalada no servidor não for
compatível. Para resolver esse problema, atualize para uma versão de agente com suporte.
Você atingiu o limite de armazenamento de compar tilhamento de arquivos do Azure.
HRESULT 0x80c8603e
Cadeia de caracteres de erro ECS_E_AZURE_STORAGE_SHARE_SIZE_LIMIT_REACHED
Esse erro ocorre quando o limite de armazenamento de compartilhamento de arquivos do Azure é atingido, o
que pode acontecer se uma cota for aplicada a um compartilhamento de arquivos do Azure ou se o uso exceder
os limites de um compartilhamento de arquivos do Azure. Para obter mais informações, consulte o limites
atuais para um compartilhamento de arquivos do Azure.
1. Navegue até o grupo de sincronização no Serviço de Sincronização de Armazenamento.
2. Selecione o ponto final da nuvem dentro do grupo de sincronização.
3. Observe o nome do compartilhamento de arquivos do Azure no painel aberto.
4. Selecione a conta de armazenamento vinculada. Se esse link falhar, a conta de armazenamento
referenciada foi removida.
5. Selecione arquivos para exibir a lista de compartilhamentos de arquivos.

6. Clique nos três pontos no final da linha do compartilhamento de arquivos do Azure mencionado pelo
ponto de extremidade da nuvem.
7. Verifique se o Uso está abaixo da Cota . Observação: a menos que uma cota alternativa tenha sido
especificada, a cota corresponderá ao tamanho máximo do compartilhamento de arquivos do Azure.
Se o compartilhamento estiver cheio e uma cota não estiver configurada, uma maneira possível de corrigir esse
problema é transformar cada subpasta do terminal do servidor atual em seu próprio terminal do servidor em
seus próprios grupos de sincronização separados. Dessa forma, cada subpasta será sincronizada com
compartilhamentos de arquivos individuais do Azure.
O compar tilhamento de arquivos do Azure não foi encontrado.
HRESULT 0x80c86030
Cadeia de caracteres de erro ECS_E_AZURE_FILE_SHARE_NOT_FOUND
Este erro ocorre quando o compartilhamento de arquivos do Azure não está acessível. Para solucionar
problemas:
Se o compartilhamento de arquivos do Azure tiver sido excluído, você precisará criar um novo
compartilhamento de arquivos e, em seguida, recriar o grupo de sincronização.
A sincronização é pausada enquanto esta assinatura do Azure é suspensa.
HRESULT 0x80C83076
Cadeia de caracteres de erro ECS_E_SYNC_BLOCKED_ON_SUSPENDED_SUBSCRIPTION
Este erro ocorre quando a assinatura do Azure é suspensa. A sincronização será reativada quando a assinatura
do Azure for restaurada. Consulte Por que minha assinatura do Azure está desativada e como eu a reativo? para
obter mais informações.
** A conta de armazenamento tem um firewall ou redes virtuais configuradas.**
HRESULT 0x80c8306c
Cadeia de caracteres de erro ECS_E_MGMT_STORAGEACLSNOTSUPPORTED
Esse erro ocorre quando o compartilhamento de arquivos do Azure está inacessível devido a um firewall de
conta de armazenamento ou porque a conta de armazenamento pertence a uma rede virtual. Verifique se as
configurações de firewall e rede virtual na conta de armazenamento estão configuradas corretamente. Para
obter mais informações, consulte Configurar o firewall e as configurações de rede virtual.
Falha na sincronização devido a um problema com o banco de dados de sincronização.
HRESULT 0x80c80219
Cadeia de caracteres de erro ECS_E_SYNC_METADATA_WRITE_LOCK_TIMEOUT
Esse erro geralmente se resolve e pode ocorrer se houver:

Um alto número de alterações de arquivos nos servidores do grupo de sincronização.
Um grande número de erros em arquivos e diretórios individuais.
Se esse erro persistir por mais de algumas horas, crie uma solicitação de suporte e entraremos em contato para
ajudá-lo a resolver esse problema.
O ser vidor não pôde estabelecer uma conexão segura. O ser viço de nuvem recebeu um
cer tificado inesperado.
HRESULT 0x800b0109
Cadeia de caracteres de erro CERT_E_UNTRUSTEDROOT
Esse erro pode ocorrer se sua organização estiver usando um proxy de terminação de TLS ou se uma entidade
mal-intencionada estiver interceptando o tráfego entre o servidor e o serviço de Sincronização de Arquivos do
Azure. Se você tiver certeza de que isso é esperado (porque sua organização está usando um proxy de
terminação TLS), ignore a verificação de certificado com uma substituição de registro.
1. Crie o valor do Registro SkipVerifyingPinnedRootCertificate.
New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Azure\StorageSync -Name

SkipVerifyingPinnedRootCertificate -PropertyType DWORD -Value 1
2. Reinicie o serviço de sincronização no servidor registrado.
Restart-Service -Name FileSyncSvc -Force
Ao definir esse valor de registro, o agente de Sincronização de Arquivos do Azure aceitará qualquer certificado
TLS/SSL confiável localmente ao transferir dados entre o servidor e o serviço de nuvem.
Não foi possível estabelecer uma conexão com o ser viço.
HRESULT 0x80072ee2
Cadeia de caracteres de erro WININET_E_TIMEOUT
Esse erro pode ocorrer sempre que o serviço de Sincronização de Arquivos do Azure está acessível do servidor.
Você pode solucionar esse erro trabalhando nas seguintes etapas:
1. Verifique se o serviço Windows FileSyncSvc.exe não está bloqueado pelo firewall.
2. Verifique se a porta 443 está aberta para conexões de saída para o serviço de Sincronização de Arquivos
do Azure. Você pode fazer isso com o cmdlet Test-NetConnection . A URL para o espaço reservado
<azure-file-sync-endpoint> abaixo pode ser encontrada no documento de Configurações de proxy e
firewall de Sincronização de Arquivos do Azure.
Test-NetConnection -ComputerName <azure-file-sync-endpoint> -Port 443
3. Verifique se a configuração de proxy está definida conforme o esperado. Isso pode ser feito com o
cmdlet Get-StorageSyncProxyConfiguration . Mais informações sobre como definir a configuração de
proxy para Sincronização de Arquivos do Azure podem ser encontradas em Configurações de proxy e
firewall da Sincronização de Arquivos do Azure.
$agentPath = "C:\Program Files\Azure\StorageSyncAgent"

Import-Module "$agentPath\StorageSync.Management.ServerCmdlets.dll"
Get-StorageSyncProxyConfiguration
4. Use o cmdlet Test-StorageSyncNetworkConnectivity para verificar a conectividade de rede para os

pontos de extremidade de serviço. Para saber mais, confira testar a conectividade de rede para pontos de
extremidade de serviço.
5. Contate seu administrador de rede para obter mais assistência para a solução de problemas de
conectividade de rede.
** A sincronização falhou devido a um problema com a autenticação.**
HRESULT 0x80c80300
Cadeia de caracteres de erro ECS_E_SERVER_CREDENTIAL_NEEDED
Esse erro normalmente ocorre porque a hora do servidor está incorreta. Se o servidor estiver em execução em
uma máquina virtual, verifique se a hora no host está correta.
Falha na sincronização devido à expiração do cer tificado.
HRESULT 0x80c83078
Cadeia de caracteres de erro ECS_E_AUTH_SRV_CERT_EXPIRED
Esse erro ocorre porque o certificado usado para autenticação expirou.

Para confirmar se o certificado está expirado, faça o seguinte:
1. Abra o snap-in MMC de Certificados, selecione Conta de Computador e navegue até Certificados
(Computador Local)\Pessoal\Certificados.
2. Verifique se o certificado de autenticação do cliente expirou.
Se o certificado de autenticação de cliente tiver expirado, faça o seguinte para resolver o problema:
1. Verifique se a versão do agente de Sincronização de Arquivos do Azure 4.0.1.0 ou posterior está
instalada.
2. Execute o seguinte comando do PowerShell no servidor:
Falha na sincronização devido ao cer tificado de autenticação não encontrado.
HRESULT 0x80c80228
Cadeia de caracteres de erro ECS_E_AUTH_SRV_CERT_NOT_FOUND
Esse erro ocorre porque o certificado usado para autenticação não foi encontrado.
Para resolver esse problema, execute as seguintes etapas:
1. Verifique se a versão do agente de Sincronização de Arquivos do Azure 4.0.1.0 ou posterior está
instalada.
2. Execute o seguinte comando do PowerShell no servidor:
Falha na sincronização devido à identidade de autenticação não encontrada.
HRESULT 0x80c83079
Cadeia de caracteres de erro ECS_E_AUTH_IDENTITY_NOT_FOUND
Esse erro ocorre porque a exclusão do ponto de extremidade do servidor falhou, e o ponto de extremidade está
agora em um estado parcialmente excluído. Para resolver esse problema, repita a exclusão do ponto de
O volume onde se encontra o ponto de extremidade do ser vidor é baixo espaço em disco.
HRESULT 0x8e5e0211
Cadeia de caracteres de erro JET_errLogDiskFull
HRESULT 0x80c8031a
Cadeia de caracteres de erro ECS_E_NOT_ENOUGH_LOCAL_STORAGE
Este erro ocorre porque o volume foi preenchido. Esse erro geralmente ocorre porque os arquivos fora do
terminal do servidor estão usando espaço no volume. Libere espaço no volume adicionando terminais
adicionais do servidor, movendo arquivos para um volume diferente ou aumentando o tamanho do volume em
que o terminal do servidor está.
O ser viço ainda não está pronto para sincronizar com esse ponto de extremidade do ser vidor.
HRESULT 0x80c8300f
Cadeia de caracteres de erro ECS_E_REPLICA_NOT_READY
Esse erro ocorre porque o ponto de extremidade de nuvem foi criado com conteúdo já existente no
compartilhamento de arquivos do Azure. Sincronização de Arquivos do Azure deve verificar o
compartilhamento de arquivos do Azure para todo o conteúdo antes de permitir que o ponto de extremidade
do servidor prossiga com sua sincronização inicial.
Falha na sincronização devido a problemas com muitos arquivos individuais.
HRESULT 0x80c8023b
Cadeia de caracteres de erro ECS_E_SYNC_METADATA_KNOWLEDGE_SOFT_LIMIT_REACH

ED
HRESULT 0x80c8021c
Cadeia de caracteres de erro ECS_E_SYNC_METADATA_KNOWLEDGE_LIMIT_REACHED
HRESULT 0x80c80253
Cadeia de caracteres de erro ECS_E_TOO_MANY_PER_ITEM_ERRORS
Nos casos em que há muitos erros de sincronização por arquivo, as sessões de sincronização podem começar a
falhar.
NOTE
O Azure File Sync cria um instantâneo temporário do VSS uma vez por dia no servidor para sincronizar arquivos que
tenham identificadores abertos.
Falha na sincronização devido a um problema com o caminho do ponto de extremidade de

ser vidor.
HRESULT 0x80c80019
Cadeia de caracteres de erro ECS_E_SYNC_INVALID_PATH
Assegure-se de que o caminho exista, esteja em um volume NTFS local e não seja um ponto de nova análise ou
um terminal do servidor existente.
Falha na sincronização porque a versão do driver de filtro não é compatível com a versão do
agente
HRESULT 0x80C80277
Cadeia de caracteres de erro ECS_E_INCOMPATIBLE_FILTER_VERSION
Esse erro ocorre porque a versão do driver do filtro de Camada de Nuvem (StorageSync.sys) carregada não é
compatível com o serviço de Agente de Sincronização de Armazenamento (FileSyncSvc). Se o agente de
Sincronização de Arquivos do Azure tiver sido atualizado, reinicie o servidor para concluir a instalação. Se o
erro persistir, desinstale o agente, reinicie o servidor e reinstale o agente de Sincronização de Arquivos do
Azure.
O ser viço não está disponível no momento.
HRESULT 0x80c8004b
Cadeia de caracteres de erro ECS_E_SERVICE_UNAVAILABLE
Este erro ocorre porque o serviço de Sincronização de Arquivos do Azure está indisponível. Esse erro será
resolvido automaticamente quando o serviço de Sincronização de Arquivos do Azure estiver disponível
novamente.
Falha na sincronização devido a uma exceção.
HRESULT 0x80131500
Cadeia de caracteres de erro COR_E_EXCEPTION
Esse erro ocorre porque a sincronização falhou devido a uma exceção. Se o erro persistir por várias horas, crie
uma solicitação de suporte.
Falha na sincronização porque a conta de armazenamento fez failover para outra região.
HRESULT 0x80c83073

Cadeia de caracteres de erro ECS_E_STORAGE_ACCOUNT_FAILED_OVER
Esse erro ocorre porque a conta de armazenamento fez failover para outra região. A Sincronização de Arquivos
do Azure não oferece suporte ao recurso de failover da conta de armazenamento. Não deve ser realizado o
failover das contas de armazenamento que contêm compartilhamentos de arquivos do Azure que estejam
sendo usadas como pontos de extremidade de nuvem na Sincronização de Arquivos do Azure. Se isso for feito,
a sincronização deixará de funcionar e poderá causar a perda inesperada de dados no caso de arquivos recentes
em camadas. Para resolver esse problema, mova a conta de armazenamento para a região primária.
Falha na sincronização devido a um problema temporário com o banco de dados de
sincronização.
HRESULT 0x80c8020e
Cadeia de caracteres de erro ECS_E_SYNC_METADATA_WRITE_LEASE_LOST
Este erro ocorre devido a um problema interno com o banco de dados de sincronização. Esse erro será
resolvido automaticamente quando a sincronização ocorrer novamente. Se esse erro persistir por um período
prolongado, crie uma solicitação de suporte e entraremos em contato para ajudá-lo a resolver esse problema.
Falha na sincronização devido à alteração no locatário Azure Active Director y
HRESULT 0x80c83088
Cadeia de caracteres de erro ECS_E_INVALID_AAD_TENANT
Verifique se você tem o agente de Sincronização de Arquivos do Azure mais recente. A partir do agente v10,
Sincronização de Arquivos do Azure dá suporte à movimentação da assinatura para um locatário Azure Active
Directory diferente.
Depois de ter a versão mais recente do agente, você deve conceder ao aplicativo Microsoft. StorageSync acesso
à conta de armazenamento (consulte garantir que sincronização de arquivos do Azure tenha acesso à conta de
armazenamento).
Falha na sincronização devido a uma exceção de firewall e rede vir tual não configurada
HRESULT 0x80c83096
Cadeia de caracteres de erro ECS_E_MGMT_STORAGEACLSBYPASSNOTSET
Esse erro ocorre se as configurações de firewall e rede virtual estiverem habilitadas na conta de
armazenamento e a exceção "permitir que os serviços confiáveis da Microsoft acessem esta conta de
armazenamento" não estiver marcada. Para resolver esse problema, siga as etapas documentadas na seção
Definir configurações de rede virtual e de firewall no guia de implantação.
Falha na sincronização porque as permissões na pasta informações de volume do sistema estão
incorretas.
HRESULT 0x80070005
Cadeia de caracteres de erro ERROR_ACCESS_DENIED
Esse erro pode ocorrer se a conta NT AUTHORITY\SYSTEM não tiver permissões para a pasta Informações de
Volume do Sistema no volume em que o ponto de extremidade do servidor está localizado. Observe que, se os
arquivos individuais não conseguirem ser sincronizados com o ERROR_ACCESS_DENIED, execute as etapas
documentadas na seção solução de problemas por erros de sincronização de arquivo/diretório .
Para resolver esse problema, execute as seguintes etapas:
1. Baixe a ferramenta PsExec .
2. Execute o seguinte comando em um prompt de comando elevado para iniciar um prompt de comando
usando a conta do sistema: PsExec. exe-i-s-d cmd
3. No prompt de comando em execução na conta do sistema, execute o seguinte comando para confirmar se a
conta NT AUTHORITY\SYSTEM não tem acesso à pasta Informações de Volume do Sistema: cacls "letra da
unidade:\informações de volume do sistema" /T /C
4. Se a conta NT AUTHORITY\SYSTEM não tiver acesso à pasta Informações de Volume do Sistema, execute o
seguinte comando: cacls "letra da unidade:\informações de volume do sistema" /T /E /G "NT
AUTHORITY\SYSTEM:F"
Se a etapa 4 falhar com o acesso negado, execute o seguinte comando para se tornar proprietário da
pasta Informações de Volume do Sistema e repita a etapa 4: takeown /A /R /F "letra da
unidade:\Informações de volume do sistema"
Falha na sincronização porque o compar tilhamento de arquivos do Azure foi excluído e recriado.
HRESULT 0x80c8027e
Cadeia de caracteres de erro ECS_E_SYNC_REPLICA_ROOT_CHANGED

Esse erro ocorre porque Sincronização de Arquivos do Azure não dá suporte à exclusão e recriação de um
compartilhamento de arquivos do Azure no mesmo grupo de sincronização.
Para resolver esse problema, exclua e recrie o grupo de sincronização executando as seguintes etapas:
1. Exclua todos os pontos de extremidade do servidor no grupo de sincronização.
2. Exclua o ponto de extremidade de nuvem.
3. Exclua o grupo de sincronização.
4. Se a camada de nuvem foi habilitada em um ponto de extremidade do servidor, exclua os arquivos em
camadas órfãos no servidor executando as etapas documentadas nos arquivos em camadas não estão
acessíveis no servidor após a exclusão de uma seção de ponto de extremidade do servidor .
5. Recrie o grupo de sincronização.
Falha na sincronização porque a solicitação HTTP foi redirecionada
HRESULT 0x80190133
Cadeia de caracteres de erro HTTP_E_STATUS_REDIRECT_KEEP_VERB
Esse erro ocorre porque Sincronização de Arquivos do Azure não dá suporte ao redirecionamento de HTTP
(código de status 3xx). Para resolver esse problema, desabilite o redirecionamento HTTP no seu servidor proxy
ou dispositivo de rede.
Ocorreu um tempo limite durante A transferência de dados offline, mas ele ainda está em
andamento.
HRESULT 0x80c83085
Cadeia de caracteres de erro ECS_E_DATA_INGESTION_WAIT_TIMEOUT
Esse erro ocorre quando uma operação de ingestão de dados excede o tempo limite. Esse erro poderá ser
ignorado se a sincronização estiver fazendo progressos (AppliedItemCount é maior que 0). Consulte como fazer
monitorar o progresso de uma sessão de sincronização atual?.
Etapas de solução de problemas comuns
Verifique se a conta de armazenamento existe.
Portal
PowerShell
1. Navegue até o grupo de sincronização no Serviço de Sincronização de Armazenamento.
2. Selecione o ponto final da nuvem dentro do grupo de sincronização.
3. Observe o nome do compartilhamento de arquivos do Azure no painel aberto.
4. Selecione a conta de armazenamento vinculada. Se esse link falhar, a conta de armazenamento referenciada
foi removida.
Verifique se o compar tilhamento de arquivos do Azure existe.
Portal
PowerShell
1. Clique em visão geral no sumário à esquerda para retornar à página principal da conta de armazenamento.
2. Selecione arquivos para exibir a lista de compartilhamentos de arquivos.
3. Verifique se o compartilhamento de arquivos referenciado pelo ponto de extremidade da nuvem aparece na
lista de compartilhamentos de arquivos (você deve ter notado isso na etapa 1 acima).
Verifique se Sincronização de Arquivos do Azure tem acesso à conta de armazenamento.
Portal
PowerShell
1. Clique em Controle de acesso (IAM) no sumário à esquerda.
2. Clique na guia Atribuições de função para a lista de usuários e aplicativos (entidades de serviço) que
têm acesso à sua conta de armazenamento.
3. Verifique se o serviço Microsoft. StorageSync ou híbrido sincronização de arquivos (nome do
aplicativo antigo) aparece na lista com a função de acesso de dados e leitor .
Se o serviço Microsoft. StorageSync ou híbrido sincronização de arquivos não aparecer na lista,

execute as seguintes etapas:
Clique em Adicionar .
No campo Função , selecione Leitor e Acesso a Dados .
No campo selecionar , digite Microsoft. StorageSync , selecione a função e clique em salvar .
Como evito que os usuários criem arquivos contendo caracteres não suportados no servidor?
Você pode usar Telas de Arquivos do Gerenciador de Recursos de Servidor de Arquivos (FSRM) para impedir
que arquivos com caracteres não suportados em seus nomes sejam criados no servidor. Pode ser necessário
fazer isso usando o PowerShell, pois a maioria dos caracteres não suportados não pode ser impressa e,
portanto, é necessário converter suas representações hexadecimais como caracteres primeiro.
Primeiro, crie um grupo de arquivos FSRM usando o cmdlet New-FsrmFileGroup. Este exemplo define o grupo
para conter apenas dois dos caracteres não suportados, mas você pode incluir quantos caracteres forem
necessários no seu grupo de arquivos.
New-FsrmFileGroup -Name "Unsupported characters" -IncludePattern @(("*"+[char]0x00000090+"*"),("*"+

[char]0x0000008F+"*"))
Depois de definir um grupo de arquivos do FSRM, você poderá criar uma tela de arquivo do FSRM usando o
cmdlet New-FsrmFileScreen.
New-FsrmFileScreen -Path "E:\AFSdataset" -Description "Filter unsupported characters" -IncludeGroup

"Unsupported characters"
IMPORTANT
Observe que as triagens de arquivo só devem ser usadas para bloquear a criação de caracteres sem suporte pelo
Sincronização de Arquivos do Azure. Se as triagens de arquivo forem usadas em outros cenários, a sincronização tentará
continuamente baixar os arquivos do compartilhamento de arquivos do Azure para o servidor e será bloqueado devido à
tela de arquivos, resultando em alta saída de dados.
Disposição em camadas de nuvem

Há dois caminhos para falhas na definição de camadas de nuvem:
A definição de camadas de arquivos pode falhar, o que significa que a Sincronização de arquivos do Azure
tenta definir camadas de arquivos nos Arquivos do Azure sem sucesso.
Os arquivos podem falhar ao se recuperar, o que significa que o Sincronização de Arquivos do Azure filtro
do sistema de arquivos (StorageSync. sys) falha ao baixar dados quando um usuário tenta acessar um
arquivo que foi colocado em camadas.
Há duas classes principais de falhas que podem ocorrer por meio de um desses caminhos de falha:
Falhas no armazenamento em nuvem
Problemas transitórios de disponibilidade do serviço de armazenamento. Para obter mais
informações, consulte o Contrato de Nível de Serviço (SLA) para o Armazenamento do Azure.
Compartilhamento de arquivos do Azure inacessível. Essa falha geralmente ocorre quando você
exclui o compartilhamento de arquivos do Azure quando ainda é um ponto de extremidade de nuvem
em um grupo de sincronização.
Conta de armazenamento inacessível. Essa falha normalmente acontece quando você exclui a conta
de armazenamento enquanto ela ainda tem um compartilhamento de arquivos do Azure que é um
ponto de extremidade de nuvem em um grupo de sincronização.
Falhas de servidor
O filtro do sistema de arquivos da Sincronização de arquivos do Azure (StorageSync.sys) não está
carregado. Para responder às solicitações de definição de camadas/recuperação, o filtro do sistema de
arquivos da Sincronização de arquivos do Azure deve ser carregado. O filtro pode não ser carregado
por diversos motivos, mas o motivo mais comum é quando um administrador o descarrega
manualmente. O filtro do sistema de arquivos da Sincronização de arquivos do Azure deve ser
carregado sempre para que a Sincronização de arquivos do Azure funcione corretamente.
Ponto de nova análise ausente, corrompido ou desfeito por algum outro motivo. Um ponto de nova
análise é uma estrutura de dados especial em um arquivo que consiste em duas partes:
1. Uma marca de nova análise, que indica para o sistema operacional que o filtro do sistema
de arquivos da Sincronização de arquivos do Azure (StorageSync.sys) pode precisar
executar alguma ação na E/S do arquivo.
2. Dados de nova análise, que indica para o filtro do sistema de arquivos qual é o URI do
arquivo no ponto de extremidade de nuvem associado (o compartilhamento de arquivos
do Azure).
A maneira mais comum de corromper um ponto de nova análise é quando um
administrador tenta modificar a marca ou seus dados.
Problemas de conectividade de rede. Para a definir camadas ou recuperar um arquivo, o servidor
deve ter conectividade com a Internet.
As seções a seguir indicam como solucionar problemas de definição de camadas de nuvem e determinar se o
problema é do armazenamento em nuvem ou do servidor.
Como monitorar a atividade em camadas em um servidor
Para monitorar a atividade em camadas em um servidor, use as identificações de evento 9003, 9016 e 9029 no
log de eventos da Telemetria (localizado no Visualizador de Eventos, em Aplicativos e
Serviços\Microsoft\FileSync\Agent).
A identificação de evento 9003 fornece distribuição de erro para um terminal do servidor. Por exemplo,
contagem total de erros, ErrorCode, etc. Observe que um evento é registrado por código de erro.
A identificação de evento 9016 fornece resultados de fantasma para um volume. Por exemplo, o percentual
de espaço livre é, Número de arquivos fantasmados na sessão, Número de arquivos que falharam no
fantasma etc.
A ID do evento 9029 fornece informações de sessão de conversão em fantasma para um ponto de
extremidade de servidor. Por exemplo, Número de arquivos tentados na sessão, Número de arquivos em
camadas na sessão, Número de arquivos já em camadas, etc.
Como monitorar a atividade de recuperação em um servidor
Para monitorar a atividade de recall em um servidor, use as IDs do evento 9005, 9006, 9009 e 9059 no log de
eventos da Telemetria (localizado no Visualizador de Eventos, em Aplicativos e
Serviços\Microsoft\FileSync\Agent).
A ID de evento 9005 fornece confiabilidade de recall para um ponto de extremidade do servidor. Por
exemplo, Total de arquivos exclusivos acessados, Total de arquivos exclusivos com acesso com falha, etc.
ID do evento 9006 fornece Lembre-se a distribuição de erro para um ponto de extremidade do servidor. Por
exemplo, total de solicitações com falha, ErrorCode, etc. Observe que um evento é registrado por código de
erro.
A ID do evento 9009 fornece informações de sessão de recall para um ponto de extremidade de servidor. Por
exemplo, DurationSeconds, CountFilesRecallSucceeded, CountFilesRecallFailed, etc.
A ID do evento 9059 fornece distribuição de recall do aplicativo para um ponto de extremidade de servidor.
Por exemplo, ShareId, Nome do Aplicativo e TotalEgressNetworkBytes.
Como solucionar problemas de arquivos que falham ao serem dispostos em camadas
Se os arquivos não camada para arquivos do Azure:
1. No Visualizador de Eventos, revise os logs de eventos de telemetria, operacionais e de diagnóstico,
localizados em Aplicativos e Serviços\Microsoft\FileSync\Agent.
a. Verifique se que os arquivos existem no compartilhamento de arquivos do Azure.
NOTE
Um arquivo deve ser sincronizado com um Compartilhamento de Arquivo do Azure antes de poder ser
disposto em camadas.
b. Verifique se o servidor tem conectividade com a Internet.

c. Verifique se que os drivers de filtro de sincronização de arquivos do Azure (storagesync. sys e
storagesyncguard. sys) estão em execução:
Em um prompt de comandos com privilégios elevados, digite fltmc . Verifique se os drivers de
filtro de sistema de arquivos StorageSync.sys e StorageSyncGuard.sys estão listados.
NOTE
Um ID de Evento 9003 é registrada uma vez por hora no log de eventos da Telemetria se um arquivo falhar na camada
(um evento é registrado por código de erro). Verifique a seção erros de camadas e correção para ver se as etapas de
correção estão listadas para o código de erro.
Erros de camadas e correção

C A DEIA DE
C A RA C T ERES DE
0x80c86043 -2134351805 ECS_E_GHOSTING_FI Falha na camada do Nenhuma ação é

LE_IN_USE arquivo porque ele necessária. O arquivo
está em uso. será colocado em
camadas quando não
estiver mais em uso.
0x80c80241 -2134375871 ECS_E_GHOSTING_E Falha na camada do Nenhuma ação é

XCLUDED_BY_SYNC arquivo porque ele necessária. Os
foi excluído pela arquivos na lista de
sincronização. exclusão de
sincronização não
podem ser em
camadas.

LE_NOT_FOUND arquivo porque ele necessária. Se o erro
não foi encontrado persistir, verifique se
no servidor. o arquivo existe no
servidor.
0x80c83053 -2134364077 ECS_E_CREATE_SV_FI Falha na camada do Nenhuma ação é

LE_DELETED arquivo porque ele necessária. O arquivo
foi excluído no deve ser excluído no
compartilhamento de servidor quando a
arquivos do Azure. próxima sessão de
sincronização de
download for
executada.
C A DEIA DE
C A RA C T ERES DE
0x80c8600e -2134351858 ECS_E_AZURE_SERVE Falha na camada do Nenhuma ação é

R_BUSY arquivo devido a um necessária. Se o erro
problema de rede. persistir, verifique a
conectividade de
rede para o
compartilhamento de
arquivos do Azure.
0x80072ee7 -2147012889 WININET_E_NAME_N Falha na camada do Nenhuma ação é

OT_RESOLVED arquivo devido a um necessária. Se o erro
conectividade de
rede para o
compartilhamento de
arquivos do Azure.
0x80070005 -2147024891 ERROR_ACCESS_DEN Falha na camada do A Sincronização de

IED arquivo devido ao Arquivos do Azure
erro de acesso não oferece suporte
negado. Esse erro a pontos de
pode ocorrer se o extremidade de
arquivo estiver servidor em pastas
localizado em uma de replicação
pasta de replicação somente leitura do
somente leitura do DFS-R. Consulte o
DFS-R. Guia de
planejamento para
obter mais
informações.
0x80072efe -2147012866 WININET_E_CONNEC Falha na camada do Nenhuma ação é

TION_ABORTED arquivo devido a um necessária. Se o erro
conectividade de
rede para o
compartilhamento de
arquivos do Azure.
C A DEIA DE
C A RA C T ERES DE
0x80c80261 -2134375839 ECS_E_GHOSTING_M Falha na camada do Se a versão do

IN_FILE_SIZE arquivo porque o agente for menor
tamanho do arquivo que 9,0, o tamanho
é menor que o mínimo de arquivo
tamanho com com suporte é 64 KB.
suporte. Se a versão do
agente for 9,0 e mais
recente, o tamanho
mínimo de arquivo
com suporte é
baseado no tamanho
do cluster do sistema
de arquivos
(tamanho de cluster
de sistema de
arquivos duplo). Por
exemplo, se o
tamanho do cluster
do sistema de
arquivos for 4 KB, o
tamanho mínimo do
arquivo será 8 KB.
0x80c83007 -2134364153 ECS_E_STORAGE_ERR Falha na camada do Se o erro persistir,

OR arquivo devido a um abra uma solicitação
problema de de suporte.
armazenamento do
Azure.
0x800703e3 -2147023901 ERROR_OPERATION_ O arquivo falhou ao Nenhuma ação é

ABORTED ser nivelado porque necessária. O arquivo
foi rechamado ao será colocado em
mesmo tempo. camadas quando a
recuperação for
concluída e o arquivo
não estiver mais em
uso.

LE_NOT_SYNCED arquivo porque ele necessária. O arquivo
não foi sincronizado será nivelado depois
com o de ser sincronizado
compartilhamento de com o
arquivos do Azure. compartilhamento de
arquivos do Azure.
C A DEIA DE
C A RA C T ERES DE
0x80070001 -2147942401 ERROR_INVALID_FU Falha na camada do Para resolver esse

NCTION arquivo porque o problema, abra um
driver de filtro de prompt de comando
camadas de nuvem com privilégios
(storagesync. sys) elevados e execute o
não está em seguinte comando:
execução. fltmc load
storagesync
Se o driver de filtro
storagesync não for
carregado ao
executar o comando
Fltmc, desinstale o
agente de
Sincronização de
Arquivos do Azure,
reinicie o servidor e
reinstale o agente de
Sincronização de
Arquivos do Azure.
0x80070070 -2147024784 ERROR_DISK_FULL Falha na camada do Para resolver esse

arquivo devido a problema, libere pelo
espaço em disco menos 100 MB de
insuficiente no espaço em disco no
volume em que o volume em que o
ponto de ponto de
extremidade do extremidade do
servidor está servidor está
localizado. localizado.
0x80070490 -2147023728 ERROR_NOT_FOUND Falha na camada do Nenhuma ação é

arquivo porque ele necessária. O arquivo
arquivos do Azure.
0x80c80262 -2134375838 ECS_E_GHOSTING_U Falha na camada do Se o arquivo for um

NSUPPORTED_RP arquivo porque ele é ponto de nova
um ponto de nova análise de eliminação
análise sem suporte. de duplicação de
dados, siga as etapas
no Guia de
planejamento para
habilitar o suporte à
eliminação de
duplicação de dados.
Arquivos com pontos
de nova análise que
não sejam a
eliminação de
duplicação de dados
não têm suporte e
não serão em
camadas.
C A DEIA DE
C A RA C T ERES DE
0x80c83052 -2134364078 ECS_E_CREATE_SV_ST Falha na camada do Nenhuma ação é

REAM_ID_MISMATC arquivo porque ele necessária. O arquivo
H foi modificado. será nivelado depois
que o arquivo
modificado tiver sido
sincronizado com o
compartilhamento de
arquivos do Azure.
0x80c80269 -2134375831 ECS_E_GHOSTING_R Falha na camada do Nenhuma ação é

EPLICA_NOT_FOUND arquivo porque ele necessária. O arquivo
arquivos do Azure.
0x80072ee2 -2147012894 WININET_E_TIMEOU Falha na camada do Nenhuma ação é

T arquivo devido a um necessária. Se o erro
conectividade de
rede para o
compartilhamento de
arquivos do Azure.
0x80c80017 -2134376425 ECS_E_SYNC_OPLOC Falha na camada do Nenhuma ação é

K_BROKEN arquivo porque ele necessária. O arquivo
foi modificado. será nivelado depois
que o arquivo
modificado tiver sido
sincronizado com o
compartilhamento de
arquivos do Azure.
0x800705aa -2147023446 ERROR_NO_SYSTEM_ Falha na camada do Se o erro persistir,

RESOURCES arquivo devido a investigue qual driver
recursos insuficientes de modo kernel ou
do sistema. aplicativo está
esgotando os
recursos do sistema.
Como solucionar problemas de arquivos que falham quando seu recall é realizado
Se os arquivos não ser recuperados:
1. No Visualizador de Eventos, revise os logs de eventos de telemetria, operacionais e de diagnóstico,
localizados em Aplicativos e Serviços\Microsoft\FileSync\Agent.
a. Verifique se que os arquivos existem no compartilhamento de arquivos do Azure.
b. Verifique se o servidor tem conectividade com a Internet.
c. Abra o snap-in MMC de serviços e verifique se que o serviço de agente de sincronização de
armazenamento (FileSyncSvc) está em execução.
d. Verifique se que os drivers de filtro de sincronização de arquivos do Azure (storagesync. sys e
Em um prompt de comandos com privilégios elevados, digite fltmc . Verifique se os drivers de
filtro de sistema de arquivos StorageSync.sys e StorageSyncGuard.sys estão listados.
NOTE
Uma ID de Evento 9006 é registrada uma vez por hora no log de eventos de Telemetria se um arquivo não for
recuperado (um evento é registrado por código de erro). Marque a seção erros de recuperação e correção para ver se as
etapas de correção estão listadas para o código de erro.
Recuperar erros e correção

C A DEIA DE
C A RA C T ERES DE
0x80070079 -2147942521 ERROR_SEM_TIMEO Falha ao recuperar o Nenhuma ação é

UT arquivo devido a um necessária. Se o erro
tempo limite de e/s. persistir por várias
Esse problema pode horas, abra um caso
ocorrer por vários de suporte.
motivos: restrições
de recursos de
servidor,
conectividade de
rede deficiente ou
um problema de
armazenamento do
Azure (por exemplo,
limitação).
0x80070036 -2147024842 ERROR_NETWORK_B Falha ao recuperar o Se o erro persistir,

USY arquivo devido a um verifique a
problema de rede. conectividade de
rede para o
compartilhamento de
arquivos do Azure.
0x80c80037 -2134376393 ECS_E_SYNC_SHARE_ Falha ao recuperar o Para resolver esse

NOT_FOUND arquivo porque o problema, consulte
ponto de arquivos em camadas
extremidade do não podem ser
servidor foi excluído. acessados no
servidor após a
exclusão de um
ponto de
extremidade do
servidor.
0x80070005 -2147024891 ERROR_ACCESS_DEN Falha ao recuperar o Para resolver esse

IED arquivo devido a um problema, adicione o
erro de acesso endereço IP do
negado. Esse servidor ou a rede
problema pode virtual seguindo as
ocorrer se as etapas
configurações de documentadas na
firewall e rede virtual seção Configurar o
na conta de firewall e as
armazenamento configurações de
estiverem habilitadas rede virtual no guia
e o servidor não tiver de implantação.
acesso à conta de
armazenamento.
C A DEIA DE
C A RA C T ERES DE
0x80c86002 -2134351870 ECS_E_AZURE_RESO Falha ao recuperar o Para resolver esse

URCE_NOT_FOUND arquivo porque ele problema, verifique
não está acessível no se o arquivo existe
compartilhamento de no
arquivos do Azure. Se
o arquivo existir no
compartilhamento de
arquivos do Azure,
atualize para a versão
mais recente do
agentede
sincronização de
arquivos do Azure.
0x80c8305f -2134364065 ECS_E_EXTERNAL_ST Falha ao recuperar o Para resolver esse

ORAGE_ACCOUNT_A arquivo devido a problema, verifique
UTHORIZATION_FAIL uma falha de se sincronização de
ED autorização na conta arquivos do Azure
de armazenamento. tem acesso à conta
de armazenamento.
0x80c86030 -2134351824 ECS_E_AZURE_FILE_S Falha ao recuperar o Verifique se o

HARE_NOT_FOUND arquivo porque o compartilhamento de
compartilhamento de arquivos existe e está
arquivos do Azure acessível. Se o
não está acessível. compartilhamento de
arquivos foi excluído
e recriado, execute as
etapas
documentadas na
sincronização, pois a
seção
compartilhamento de
arquivos do Azure foi
excluída e recriada
para excluir e recriar
o grupo de
sincronização.
0x800705aa -2147023446 ERROR_NO_SYSTEM_ Falha ao recuperar o Se o erro persistir,

RESOURCES arquivo devido a investigue qual driver
recursos insuficientes de modo kernel ou
do sistema. aplicativo está
esgotando os
recursos do sistema.
0x8007000e -2147024882 ERROR_OUTOFMEM Falha ao recuperar o Se o erro persistir,

ORY arquivo devido a investigue qual driver
memória insuficiente. do modo kernel ou
aplicativo está
causando a condição
de memória
insuficiente.
C A DEIA DE
C A RA C T ERES DE
0x80070070 -2147024784 ERROR_DISK_FULL Falha ao recuperar o Para resolver esse

arquivo devido a problema, libere
espaço em disco espaço no volume
insuficiente. movendo arquivos
para um volume
diferente, aumente o
tamanho do volume
ou Force os arquivos
a serem nivelados
usando o cmdlet
Invoke-
StorageSyncCloudTier
ing.
Arquivos em camadas não podem ser acessados no servidor depois da exclusão de um ponto de
extremidade do servidor
Os arquivos em camadas em um servidor ficarão inacessíveis se os arquivos não forem recuperados antes de
excluir um ponto de extremidade do servidor.
Erros registrados se os arquivos em camadas não estiverem acessíveis
Ao sincronizar um arquivo, o código de erro-2147942467 (0x80070043-ERROR_BAD_NET_NAME) é
registrado no log de eventos do doresults
Ao recuperar um arquivo, o código de erro-2134376393 (0x80c80037-ECS_E_SYNC_SHARE_NOT_FOUND)
é registrado no log de eventos do RecallResults
A restauração do acesso aos arquivos em camadas será possível se as seguintes condições forem atendidas:
O ponto de extremidade do servidor foi excluído nos últimos 30 dias
O ponto de extremidade de nuvem não foi excluído
O compartilhamento de arquivo não foi excluído
O grupo de sincronização não foi excluído
Se as condições acima forem atendidas, você poderá restaurar o acesso aos arquivos no servidor ao recriar o
ponto de extremidade do servidor, no mesmo caminho no servidor dentro do mesmo grupo de sincronização,
dentro de 30 dias.
Se as condições acima não forem atendidas, não será possível restaurar o acesso, pois esses arquivos em
camadas no servidor estarão órfãos. Siga as instruções abaixo para remover os arquivos órfãos em camadas.
Obser vações
Quando arquivos em camadas não estiverem acessíveis no servidor, o arquivo completo ainda deverá estar
acessível se você acessar o compartilhamento de arquivos do Azure diretamente.
Para evitar arquivos em camadas órfãos no futuro, siga as etapas documentadas em remover um ponto de
extremidade do servidor ao excluir um ponto de extremidade do servidor.
Como obter a lista de arquivos órfãos em camadas
1. Verifique se o agente Sincronização de Arquivos do Azure versão v 5.1 ou posterior está instalado.
2. Execute os seguintes comandos do PowerShell para listar arquivos órfãos em camadas:
$orphanFiles = Get-StorageSyncOrphanedTieredFiles -path <server endpoint path>
$orphanFiles.OrphanedTieredFiles > OrphanTieredFiles.txt
3. Salve o arquivo de saída OrphanTieredFiles. txt em caso de arquivos que precisam ser restaurados do
backup após serem excluídos.
Como remover arquivos em camadas órfãos
Opção 1: excluir os arquivos em camadas órfãos
Essa opção exclui os arquivos em camadas órfãos no Windows Server, mas exige a remoção do ponto de
extremidade do servidor, se ele existir devido à recreação após 30 dias ou se estiver conectado a um grupo de
sincronização diferente. Os conflitos de arquivo ocorrerão se os arquivos forem atualizados no Windows Server
ou no compartilhamento de arquivos do Azure antes de o ponto de extremidade do servidor ser recriado.
1. Verifique se o agente Sincronização de Arquivos do Azure versão v 5.1 ou posterior está instalado.
2. Faça backup do compartilhamento de arquivos do Azure e do local do ponto de extremidade do servidor.
3. Remova o ponto de extremidade do servidor no grupo de sincronização (se existir) seguindo as etapas
documentadas em remover um ponto de extremidade do servidor.
WARNING
Se o ponto de extremidade do servidor não for removido antes de usar o cmdlet Remove-
StorageSyncOrphanedTieredFiles, excluir o arquivo em camadas órfãos no servidor excluirá o arquivo completo no

5. Salve o arquivo de saída OrphanTieredFiles. txt em caso de arquivos que precisam ser restaurados do
backup após serem excluídos.
6. Execute os seguintes comandos do PowerShell para excluir arquivos em camadas órfãos:

$orphanFilesRemoved = Remove-StorageSyncOrphanedTieredFiles -Path <folder path containing orphaned tiered
files> -Verbose
$orphanFilesRemoved.OrphanedTieredFiles > DeletedOrphanFiles.txt
Obser vações
Os arquivos em camadas modificados no servidor que não estão sincronizados com o compartilhamento de
arquivos do Azure serão excluídos.
Os arquivos em camadas que são acessíveis (não órfãos) não serão excluídos.
Arquivos não em camadas permanecerão no servidor.
7. Opcional: recrie o ponto de extremidade do servidor se excluído na etapa 3.
Opção 2: montar o compartilhamento de arquivos do Azure e copiar os arquivos localmente que estão órfãos
no servidor
Essa opção não requer a remoção do ponto de extremidade do servidor, mas requer espaço em disco suficiente
para copiar os arquivos completos localmente.
1. Monte o compartilhamento de arquivos do Azure no Windows Server que tem arquivos em camadas órfãos.

3. Use o arquivo de saída OrphanTieredFiles. txt para identificar arquivos em camadas órfãos no servidor.
4. Substitua os arquivos órfãos em camadas copiando o arquivo completo do compartilhamento de arquivos
do Azure para o Windows Server.
Como solucionar problemas de arquivos rechamados inesperadamente em um servidor
Antivírus, backup e outros aplicativos que leem grandes quantidades de arquivos causarão recalls indesejados a
menos que eles respeitem o atributo offline e ignorem a leitura do conteúdo desses arquivos. Ignorar arquivos
off-line de produtos que dão suporte a essa opção ajuda a evitar recuperações não intencionais durante
operações, como verificações antivírus ou trabalhos de backup.
Consulte seu fornecedor de software sobre como configurar sua solução para ignorar a leitura de arquivos
offline.
Recuperações não intencionais também podem ocorrer em outros cenários, como quando você estiver
pesquisando arquivos no Explorador de arquivos. Abrir uma pasta com arquivos de nuvem em camadas no
Explorador de arquivos no servidor pode resultar em recuperações não intencionais. Isso é ainda mais provável
se uma solução antivírus estiver habilitada no servidor.
NOTE
Use a ID de evento 9059 no log de eventos de telemetria para determinar quais aplicativos estão causando os recalls.
Este evento oferece distribuição de recall de aplicativo para um ponto de extremidade do servidor e é registrado uma vez
por hora.
TLS 1,2 necessário para Sincronização de Arquivos do Azure

Você pode exibir as configurações de TLS no servidor examinando as configurações do registro.
Se você estiver usando um proxy, consulte a documentação do proxy e verifique se ele está configurado para
usar o TLS 1.2.
Solução de problemas gerais

Se você encontrar problemas com a Sincronização de arquivos do Azure em um servidor, comece executando o
seguinte:
1. No Visualizador de Eventos, revise os logs de eventos de telemetria, operacionais e de diagnóstico.
Os problemas de sincronização, classificação em camadas e recuperação são registrados nos logs de
eventos de telemetria, diagnóstico e operacional em Aplicativos e Serviços\Microsoft\FileSync\Agent.
Problemas relacionados ao gerenciamento de um servidor (por exemplo, definições de configuração)
são registrados nos logs de eventos operacionais e de diagnóstico em aplicativos e
Services\Microsoft\FileSync\Management.
2. Verifique se o serviço de Sincronização de Arquivo do Azure está em execução no servidor:
Abra o snap-in do MMC de Serviços e verifique se o serviço de Agente de Sincronização de
Armazenamento (FileSyncSvc) está em execução.
3. Verifique se que os drivers de filtro de sincronização de arquivos do Azure (storagesync. sys e
Em um prompt de comandos com privilégios elevados, digite fltmc . Verifique se os drivers de filtro
de sistema de arquivos StorageSync.sys e StorageSyncGuard.sys estão listados.
Se o problema não for resolvido, execute a ferramenta AFSDiag e envie a saída do arquivo. zip para o
engenheiro de suporte atribuído ao seu caso para diagnóstico adicional.
Para a versão do agente v11 e posterior:
1. Abra uma janela do PowerShell com privilégios elevados e execute os seguintes comandos (pressione
Enter depois de cada comando):
NOTE
O AFSDiag criará o diretório de saída e uma pasta temporária dentro dele antes de coletar logs e excluirá a pasta
temporária após a execução. Especifique um local de saída que não contenha dados.
cd "c:\Program Files\Azure\StorageSyncAgent"
Import-Module .\afsdiag.ps1
Debug-AFS -OutputDirectory C:\output -KernelModeTraceLevel Verbose -UserModeTraceLevel Verbose
2. Reproduza o problema. Quando tiver terminado, clique em D .

3. Um arquivo. zip que contém logs e arquivos de rastreamento é salvo no diretório de saída que você
especificou.
Para a versão do agente V10 e anterior:
1. Crie um diretório que será usado para salvar a saída da AFSDiag (por exemplo, C:\Output).
NOTE
AFSDiag excluirá todo o conteúdo do diretório de saída antes de coletar logs. Especifique um local de saída que
não contenha dados.
2. Abra uma janela do PowerShell com privilégios elevados e execute os seguintes comandos (pressione
Enter depois de cada comando):
cd "c:\Program Files\Azure\StorageSyncAgent"
Import-Module .\afsdiag.ps1
Debug-Afs c:\output # Note: Use the path created in step 1.
3. Para o nível de rastreamento do modo de kernel da Sincronização de arquivos do Azure, insira 1 (a

menos que especificado para criar rastreamentos mais detalhados) e pressione Enter.
4. Para o nível de rastreamento do modo de usuário da Sincronização de arquivos do Azure, insira 1 (a
menos que especificado para criar rastreamentos mais detalhados) e pressione Enter.
5. Reproduza o problema. Quando tiver terminado, clique em D .
6. Um arquivo. zip que contém logs e arquivos de rastreamento é salvo no diretório de saída que você
especificou.
Confira também
Perguntas frequentes da Arquivos do Azure
Solucionar problemas de Arquivos do Azure no Windows
Solucionar problemas de Arquivos do Azure no Linux
Compartilhamento de arquivo do Azure – Falha ao
excluir arquivos do compartilhamento de arquivo do
Azure
A falha ao excluir arquivos do compartilhamento de arquivos do Azure pode ter vários sintomas:
Sintoma 1:
Falha ao excluir um arquivo no compartilhamento de arquivos do Azure devido a um dos dois problemas abaixo:
O arquivo marcado para exclusão
O recurso especificado pode estar sendo usado por um cliente SMB
Sintoma 2:
Não há cota suficiente para processar este comando
Causa
O erro 1816 ocorre quando você atinge o limite superior de identificadores abertos simultâneos permitidos para
um arquivo, no computador em que o compartilhamento de arquivos está sendo montado. Para obter mais
informações, consulte a lista de verificação de escalabilidade e desempenho do armazenamento do Azure.
Resolução
Reduza o número de identificadores abertos simultâneos fechando alguns identificadores.
Pré-requisito
Instalar o módulo de Azure PowerShell mais recente
Instalar o módulo Azure PowerShell
Conectar-se ao Azure:
# Connect-AzAccount
Selecione a assinatura da conta de armazenamento de destino:
# Select-AzSubscription -subscriptionid "SubscriptionID"
Criar contexto para a conta de armazenamento de destino:
$Context = New-AzStorageContext -StorageAccountName "StorageAccountName" -StorageAccountKey "StorageAccessKey"
Obtenha os identificadores abertos atuais do compartilhamento de arquivos:
# Get-AzStorageFileHandle -Context $Context -ShareName "FileShareName" -Recursive

Resultado do exemplo:
L A ST REC
IDEN T IF IC C A M IN H C L IEN T P O O P EN T IM O N N EC T T SESSIO N I
A DO RID O C L IEN T IP RT E IM E F IL EID PA REN T ID D
2591012 --- 10.222.10 62758 2019-10- 12:16:50Z 0 0 95077585

29083 .123 05 46259807
489
2591012 --- 10.222.10 62758 2019-10- 12:36:20Z 0 0 95077585

29131 .123 05 46259807
489
2591012 --- 10.222.10 62758 2019-10- 12:36:53Z 0 0 95077585

29137 .123 05 46259807
489
2591012 Nova 10.222.10 62758 2019-10- 12:36:29Z 13835132 92234468 95077585

29136 pasta/Test .123 05 82207285 03645464 46259807
. zip 2480 576 489
2591012 Test. zip 37.222.22 62758 2019-10- 12:36:24Z 11529250 0 95077585

29135 .143 05 23044055 46259807
8592 489
Fechar um identificador aberto:

Para fechar um identificador aberto, use o seguinte comando:
# Close-AzStorageFileHandle -Context $Context -ShareName "FileShareName" -Path 'New folder/test.zip' -CloseAll
Próximas etapas
Solucionar problemas do Arquivos do Azure no Windows
Solucionar problemas do Arquivos do Azure no Linux
Notas de versão para o agente de Sincronização de
Arquivos do Azure
servidor de arquivos local. As instalações do Windows Server são transformadas em um cache rápido do seu
compartilhamento de arquivos do Azure. Use qualquer protocolo disponível no Windows Server para acessar seus
dados localmente (incluindo SMB, NFS e FTPS). Você pode ter tantos caches quantos precisar em todo o mundo.
Este artigo fornece as notas de versão para versões com suporte do agente de Sincronização de arquivos do Azure.
Versões com suporte

As seguintes versões têm suporte pela Sincronização de arquivos do Azure:
N ÚM ERO DE VERSÃ O DO
M A RC O A GEN T E DATA DE L IB ERA Ç Ã O STAT US
Versão V10 – 4522409 10.0.0.0 9 de abril de 2020 Em trânsito
Pacote cumulativo de 9.1.0.0 12 de dezembro de 2019 Com suporte

atualizações de dezembro de
2019 – KB4522360
V9 versão – KB4522359 9.0.0.0 2 de dezembro de 2019 Com suporte
V8 versão – KB4511224 8.0.0.0 8 de outubro de 2019 Com suporte
Pacote cumulativo de 7.2.0.0 24 de julho de 2019 Com suporte

atualizações de julho de
2019- KB4490497
Pacote cumulativo de 7.1.0.0 12 de julho de 2019 Com suporte

atualizações de julho de
2019- KB4490496
Versão v7- KB4490495 7.0.0.0 19 de junho de 2019 Com suporte
Pacote cumulativo de 6.3.0.0 27 de junho de 2019 Com suporte-a versão do

atualizações de junho de agente expirará em 21 de
2019- KB4489739 abril de 2020
Pacote cumulativo de 6.2.0.0 13 de junho de 2019 Com suporte-a versão do

atualizações de junho de agente expirará em 21 de
2019- KB4489738 abril de 2020
Pacote cumulativo de 6.1.0.0 7 de maio de 2019 Com suporte-a versão do

atualizações 2019 de maio- agente expirará em 21 de
KB4489737 abril de 2020
N ÚM ERO DE VERSÃ O DO
M A RC O A GEN T E DATA DE L IB ERA Ç Ã O STAT US
Versão V6- KB4489736 6.0.0.0 21 de abril de 2019 Com suporte-a versão do

agente expirará em 21 de
abril de 2020
Versão V5 5.0.2.0 - 5.2.0.0 N/D Sem suporte-as versões do

agente expiraram em 18 de
março de 2020
Lançamento V4 4.0.1.0 - 4.3.0.0 N/D Sem suporte-as versões do

novembro de 2019
Versão v3 3.1.0.0-3.4.0.0 N/D Sem suporte-as versões do

agosto de 2019
Agentes de pré-lançamento 1.1.0.0 – 3.0.13.0 N/D Sem suporte – versão de

agente expiradas em 1 de
outubro de 2018
Política de atualização do agente de Sincronização de Arquivo do Azure

O agente de Sincronização de arquivos do Azure é atualizado regularmente para adicionar novos recursos e
resolver problemas. Recomendamos que você configure o Microsoft Update para obter atualizações para o agente
de Sincronização de arquivos do Azure à medida que elas ficarem disponíveis.
Versões do agente principal versus secundário
As versões do agente principal geralmente contêm novos recursos e têm um número crescente como a primeira
parte do número da versão. Por exemplo: *2.*.**
As versões do agente secundário também são chamadas de "patches" e são lançadas com mais frequência do
que as versões do principal. Geralmente contêm correções de bug e pequenas melhorias, mas sem novos
recursos. Por exemplo: **.3.**
Caminhos de atualização
Há quatro maneiras aprovadas e testadas para instalar as atualizações do agente de Sincronização de Arquivos do
Azure.
1. (Preferencial) Configure o Microsoft Update para baixar e instalar automaticamente as
atualizações do agente.
É sempre recomendável executar todas as atualizações de Sincronização de arquivos do Azure para garantir que
você tenha acesso às últimas correções para o Server Agent. O Microsoft Update simplifica esse processo,
baixando e instalando atualizações automaticamente para você.
2. Use AfsUpdater.exe para baixar e instalar atualizações de agente.
O AfsUpdater.exe está localizado no diretório de instalação do agente. Clique duas vezes no executável para
baixar e instalar atualizações de agente.
3. Corrija um agente de Sincronização de Arquivos do Azure existente usando um arquivo de patch
Microsoft Update ou um executável. msp. O pacote de atualização mais recente do Sincronização
de Arquivos do Azure pode ser baixado do Catálogo de Microsoft Update .
Executar um executável .msp atualizará a instalação de Sincronização de arquivos do Azure com o mesmo
método usado automaticamente pelo Microsoft Update no caminho de atualização anterior. A aplicação de um
patch do Microsoft Update realizará uma atualização no local de uma instalação e Sincronização de arquivos do
Azure.
4. Baixe o instalador do agente de Sincronização de Arquivos do Azure mais recente no centro de
download da Microsoft .
Para fazer upgrade de uma instalação existente do agente de Sincronização de Arquivos do Azure, desinstale a
versão mais antiga e então instale a última versão do instalador baixado. O registro do servidor, os grupos de
sincronização e outras configurações são mantidos pelo instalador de Sincronização de arquivos do Azure.
Gerenciamento automático do ciclo de vida do agente
Com o Agent versão 6, a equipe de sincronização de arquivos introduziu um recurso de atualização automática de
agente. Você pode selecionar um dos dois modos e especificar uma janela de manutenção na qual a atualização
deve ser tentada no servidor. Esse recurso foi criado para ajudá-lo com o gerenciamento do ciclo de vida do agente,
fornecendo um Guardrail que impede o agente de expiração ou permitindo uma configuração sem complicações,
mantenha-se atualizado.
1. A configuração padrão tentará impedir que o agente expire. Dentro de 21 dias da data de expiração lançada
de um agente, o agente tentará fazer a atualização automática. Ele iniciará uma tentativa de atualizar uma vez
por semana em 21 dias antes da expiração e na janela de manutenção selecionada. Essa opção não elimina a
necessidade de fazer patches de Microsoft Update regulares.
2. Opcionalmente, você pode selecionar se o agente será atualizado automaticamente assim que uma nova versão
do agente se tornar disponível (atualmente não aplicável a servidores clusterizados). Essa atualização ocorrerá
durante a janela de manutenção selecionada e permitirá que o servidor se beneficie dos novos recursos e
aprimoramentos assim que eles forem disponibilizados para o público geral. Essa é a configuração
recomendada e sem preocupações que fornecerá as principais versões do agente, bem como patches de
atualização regulares para o servidor. Cada agente lançado está em qualidade de GA. Se você selecionar essa
opção, a Microsoft irá comprovar a versão mais recente do agente para você. Os servidores clusterizados são
excluídos. Após a conclusão do processamento, o agente também ficará disponível no centro de download da
Microsoft aka.ms/AFS/Agent.
A l t e r a n d o a c o n fi g u r a ç ã o d e a t u a l i z a ç ã o a u t o m á t i c a
As instruções a seguir descrevem como alterar as configurações depois de concluir o instalador, se você precisar
fazer alterações.
Abra um console do PowerShell e navegue até o diretório em que você instalou o agente de sincronização e, em
seguida, importe os cmdlets do servidor. Por padrão, isso seria semelhante a este:
cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll
Você pode executar Get-StorageSyncAgentAutoUpdatePolicy para verificar a configuração de política atual e

determinar se deseja alterá-la.
Para alterar a configuração de política atual para a faixa de atualização atrasada, você pode usar:
Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration
Para alterar a configuração de política atual para a faixa de atualização imediata, você pode usar:
Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest
Garantia de gerenciamento de alterações e ciclo de vida do agente

Sincronização de Arquivos do Azure é um serviço de nuvem, que apresenta continuamente novos recursos e
aprimoramentos. Isso significa que uma versão específica do agente de Sincronização de arquivos do Azure
somente poderá ter suporte por um tempo limitado. Para facilitar sua implantação, as regras a seguir garantem
que você tenha tempo e notificações suficientes para acomodar atualizações/upgrades do agente em seu processo
de gerenciamento de alterações:
As versões do agente principal terão suporte por pelo menos seis meses, a partir da data da versão inicial.
Garantimos que há uma sobreposição de pelo menos três meses entre o suporte das versões do agente
principal.
Avisos para servidores registrados que utilizam um agente que expirará em breve serão emitidos pelo menos
três meses antes da expiração. É possível verificar se um servidor registrado está usando uma versão mais
antiga do agente na seção de servidores registrados de um Serviço de Sincronização de Armazenamento.
O tempo de vida de uma versão do agente secundário está associado à versão principal associada. Por exemplo,
quando a versão do agente 3.0 for lançada, as versões do agente 2.* serão todas definidas para expirar
conjuntamente.
NOTE
A instalação de uma versão do agente com um aviso de expiração exibirá um aviso, porém com êxito. A tentativa de instalar
ou conectar uma versão do agente expirada não tem suporte e será bloqueada.
Versão do agente 10.0.0.0

As notas de versão a seguir são para a versão 10.0.0.0 do agente de Sincronização de Arquivos do Azure (lançada
em 9 de abril de 2020).
Problemas corrigidos e aprimoramentos
Progresso de sincronização aprimorado no portal
Com a versão do agente v10, o portal do Azure em breve começará a mostrar o tipo de sessão de
sincronização em execução. Por ex.: download inicial, download regular, recall em segundo plano (casos
rápidos de recuperação de desastre) e semelhantes.
Experiência aprimorada no portal de camadas de nuvem
Se você tiver arquivos que estão falhando na camada ou no recall, agora você poderá exibir os erros de
camadas nas propriedades do ponto de extremidade do servidor.
Informações de camadas de nuvem adicionais estão disponíveis para um ponto de extremidade do
servidor:
Tamanho do cache local
Eficiência de uso do cache
Detalhes da política de camadas de nuvem: tamanho do volume, espaço livre atual ou a hora do
último acesso do arquivo mais antigo no cache local.
Essas alterações serão fornecidas no portal do Azure logo após a versão inicial do agente v10.
Suporte para mover o serviço de sincronização de armazenamento e/ou a conta de armazenamento para
um locatário Azure Active Directory (AAD) diferente
Sincronização de Arquivos do Azure agora dá suporte à movimentação do serviço de sincronização de
armazenamento e/ou da conta de armazenamento para um grupo de recursos, uma assinatura ou um
locatário do Azure AD diferente.
Melhorias de desempenho e confiabilidade diversas
A detecção de alteração no compartilhamento de arquivos do Azure poderá falhar se a rede virtual
(VNET) e as regras de firewall estiverem configuradas na conta de armazenamento.
Consumo de memória reduzido associado à Recall.
Melhor desempenho ao usar o cmdlet Invoke-AzStorageSyncChangeDetection .
Outros aprimoramentos de confiabilidade diversos.
Ferramenta de avaliação
Antes de implantar a Sincronização de Arquivos do Azure, você precisa avaliar se ela é compatível com seu sistema
usando a ferramenta de avaliação da Sincronização de Arquivos do Azure. Essa ferramenta é um cmdlet do Azure
PowerShell que verifica se há possíveis problemas com seu sistema de arquivos e conjunto de dados, como
caracteres sem suporte ou uma versão do sistema operacional sem suporte. Para obter instruções sobre instalação
e uso, consulte a seção Ferramenta de Avaliação no guia de planejamento.
Instalação do agente e configuração do servidor
Para saber mais sobre como instalar e configurar o agente de Sincronização de Arquivos do Azure com o Windows
Server, confira Planejamento de uma implantação de Sincronização de Arquivos do Azure e Como implantar a
O pacote de instalação do agente deve ser instalado com permissões de privilégios elevados (admin).
Não há suporte para o agente na opção de implantação do nano Server.
O agente tem suporte somente no Windows Server 2019, no Windows Server 2016 e no Windows Server 2012
R2.
O agente requer pelo menos 2 GiB de memória. Se o servidor estiver sendo executado em uma máquina virtual
com memória dinâmica ativada, a VM deverá ser configurada com um mínimo de 2048 MiB de memória.
O serviço Agente de Sincronização de Armazenamento (FileSyncSvc) não dá suporte a pontos de extremidade
do servidor localizados em um volume que tenha o diretório SVI (informações de volume do sistema)
compactado. Essa configuração levará a resultados inesperados.
Interoperabilidade
Antivírus, backup e outros aplicativos que acessam arquivos em camadas podem causar recalls indesejados
quando não respeitam o atributo offline e ignoram a leitura do conteúdo desses arquivos. Para saber mais,
consulte Solução de problemas de Sincronização de Arquivos do Azure.
As triagens de arquivo do FSRM (Gerenciador de Recursos de Servidor de Arquivos) podem causar falhas de
sincronização intermináveis quando os arquivos são bloqueados devido à triagem de arquivo.
Não há suporte para executar o Sysprep em um servidor com o agente de Sincronização de Arquivos do Azure
instalado e isso pode levar a resultados inesperados. O agente de Sincronização de Arquivos do Azure deverá
ser instalado após a implantação da imagem do servidor e a conclusão da mini-instalação do sysprep.
Limitações de sincronização
Os seguintes itens não são sincronizados, mas o restante do sistema continua a operar normalmente:
Arquivos com caracteres sem suporte. Consulte Guia de solução de problemas para obter uma lista de
caracteres sem suporte.
Arquivos ou diretórios que encerram com um período.
Caminhos com mais de 2.048 caracteres.
A parte da SACL (lista de controle de acesso) do sistema de um descritor de segurança que é usada para
fazer a auditoria.
Atributos estendidos.
Fluxos de dados alternativos.
Pontos de nova análise.
Links físicos.
A compactação (se definida em um arquivo do servidor) não é preservada quando as alterações são
sincronizadas para o arquivo de outros pontos de extremidade.
Todos os arquivos criptografados com EFS (ou outra criptografia de modo de usuário) que impedem o
serviço de ler os dados.
NOTE
A Sincronização de arquivos do Azure sempre criptografa os dados em trânsito. Os dados sempre são criptografados
em repouso no Azure.
Ponto de extremidade do servidor

Um ponto de extremidade do servidor só pode ser criado em um volume NTFS. ReFS, FAT, FAT32 e outros
sistemas de arquivos não têm suporte pela Sincronização de arquivos do Azure no momento.
A camada de nuvem não tem suporte no volume do sistema. Para criar um ponto de extremidade do servidor
no volume do sistema, desabilite a disposição em camadas da nuvem ao criar o ponto de extremidade do
servidor.
O Clustering de Failover só tem suporte com discos de cluster, não com CSVs (Volumes Compartilhados
Clusterizados).
Um ponto de extremidade de servidor não pode estar aninhado. Ele pode coexistir no mesmo volume em
paralelo com outro ponto de extremidade.
Não armazene um arquivo de paginação de aplicativo ou SO em um local do ponto de extremidade do servidor.
O nome do servidor no portal não será atualizado se o servidor for renomeado.
Ponto de extremidade da nuvem
A Sincronização de Arquivos do Azure dá suporte a alterações diretamente no compartilhamento de
arquivos do Azure. No entanto, as alterações feitas no compartilhamento de arquivos do Azure precisam
primeiro ser descobertas por um trabalho de detecção de alteração da Sincronização de Arquivos do Azure.
Um trabalho de detecção de alterações é iniciado para um ponto de extremidade da nuvem uma vez a cada
24 horas. Para sincronizar imediatamente os arquivos que são alterados no compartilhamento de arquivos
do Azure, o cmdlet Invoke-AzStorageSyncChangeDetection do PowerShell pode ser usado para iniciar
manualmente a detecção de alterações no compartilhamento de arquivos do Azure. Além disso, as
alterações feitas em um compartilhamento de arquivos do Azure através do protocolo REST não atualizarão
a hora da última modificação do SMB e não serão vistas como uma alteração de sincronização.
O serviço de sincronização de armazenamento e/ou a conta de armazenamento podem ser movidos para
um grupo de recursos ou assinatura diferente dentro do locatário do Azure AD existente. Se a conta de
NOTE
Ao criar o ponto de extremidade de nuvem, o serviço de sincronização de armazenamento e a conta de
armazenamento devem estar no mesmo locatário do Azure AD. Depois que o ponto de extremidade de nuvem é
criado, o serviço de sincronização de armazenamento e a conta de armazenamento podem ser movidos para
diferentes locatários do Azure AD.

Se um arquivo em camadas é copiado em outro local usando o Robocopy, o arquivo resultante não fica em
camadas. O atributo offline pode ser definido porque o Robocopy inclui esse atributo nas operações de cópia
incorretamente.
Ao copiar arquivos usando robocopy, use a opção /MIR para preservar os carimbos de data/hora dos arquivos.
Isso garantirá que os arquivos mais antigos sejam colocados em camadas antes dos arquivos acessados
recentemente.

As notas de versão a seguir são para a versão 9.1.0.0 do agente de Sincronização de Arquivos do Azure lançado em
12 de dezembro de 2019. Essas notas são além das notas de versão listadas para a versão 9.0.0.0.
Problema corrigido nesta versão:
A sincronização falha com um dos seguintes erros após a atualização para o Sincronização de Arquivos do
Azure Agent versão 9,0:
0x8e5e044e (JET_errWriteConflict)
0x8e5e0450 (JET_errInvalidSesid)
0x8e5e0442 (JET_errInstanceUnavailable)

As notas de versão a seguir são para a versão 9.0.0.0 do agente de Sincronização de Arquivos do Azure (lançado
em 2 de dezembro de 2019).
Suporte à restauração de autoatendimento
Os usuários agora podem restaurar seus arquivos usando o recurso de versão anterior. Antes da versão
V9, o recurso de versão anterior não tinha suporte em volumes que tinham camadas de nuvem
habilitadas. Esse recurso deve ser habilitado para cada volume separadamente, no qual um ponto de
extremidade com camada de nuvem habilitada existe. Para obter mais informações, consulte:
Restauração de autoatendimento por meio de versões anteriores e VSS (serviço de cópias de sombra de
volume).
Suporte para tamanhos maiores de compartilhamento de arquivos
Sincronização de Arquivos do Azure agora dá suporte a até 64TiB e 100 milhões arquivos em um único
namespace de sincronização.
Suporte à eliminação de duplicação de dados no servidor 2019
A eliminação de duplicação de dados agora tem suporte com a camada de nuvem habilitada no Windows
Server 2019. Para dar suporte à eliminação de duplicação de dados em volumes com camadas de
nuvem, o Windows Update KB4520062 deve estar instalado.
Tamanho de arquivo mínimo melhorado para um arquivo para a camada
O tamanho mínimo de arquivo para um arquivo para camada agora é baseado no tamanho do cluster do
sistema de arquivos (duplo, o tamanho do cluster do sistema de arquivos). Por exemplo, por padrão, o
tamanho do cluster do sistema de arquivos NTFS é 4 KB, o tamanho mínimo resultante de um arquivo
para a camada é de 8 KB.
Cmdlet de teste de conectividade de rede
Como parte da configuração de Sincronização de Arquivos do Azure, vários pontos de extremidade
de serviço devem ser contatados. Cada um deles tem seu próprio nome DNS que precisa ser
acessível ao servidor. Essas URLs também são específicas para a região em que um servidor está
registrado. Depois que um servidor é registrado, o cmdlet de teste de conectividade (utilitário de
registro do PowerShell e do servidor) pode ser usado para testar as comunicações com todas as URLs
específicas desse servidor. Esse cmdlet pode ajudar a solucionar problemas quando a comunicação
incompleta impede que o servidor trabalhe totalmente com Sincronização de Arquivos do Azure e
pode ser usado para ajustar as configurações de proxy e firewall.
Para executar o teste de conectividade de rede, execute os seguintes comandos do PowerShell:
Import – Module "C:\Program
Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Test-StorageSyncNetworkConnectivity
Remover aprimoramento do ponto de extremidade do servidor quando a disposição em camadas da nuvem
estiver habilitada
Como antes, remover um ponto de extremidade do servidor não resulta na remoção de arquivos no
compartilhamento de arquivos do Azure. No entanto, o comportamento de pontos de nova análise no
servidor local foi alterado. Pontos de nova análise (ponteiros para arquivos que não são locais no
servidor) agora são excluídos durante a remoção de um ponto de extremidade do servidor. Os arquivos
totalmente armazenados em cache permanecerão no servidor. Essa melhoria foi feita para evitar arquivos
em camadas órfãos ao remover um ponto de extremidade do servidor. Se o ponto de extremidade do
servidor for recriado, os pontos de nova análise para os arquivos em camadas serão recriados no
servidor.
Aprimoramento de desempenho e confiabilidade
Falhas de recuperação reduzidas. O tamanho de recall agora é ajustado automaticamente com base na
largura de banda da rede.
Melhor desempenho de download ao adicionar um novo servidor a um grupo de sincronização.
Arquivos reduzidos não sincronizando devido a conflitos de restrição.
Os arquivos falham na camada ou são rechamados inesperadamente em determinados cenários se o
caminho do ponto de extremidade do servidor for um ponto de montagem de volume.
R2.
Interoperabilidade
A parte discricionária da DACL (lista de controle de acesso) de um descritor de segurança se for maior que 2
KB. (Esse problema se aplica somente quando você tem mais de 40 ACEs (entradas de controle de acesso)
em um único item.)
fazer a auditoria.
Links físicos.
NOTE

Os arquivos em camadas ficarão inacessíveis se os arquivos não forem chamados antes da exclusão do ponto
de extremidade do servidor. Para restaurar o acesso aos arquivos, recrie o ponto de extremidade do servidor. Se
30 dias se passaram desde que o ponto de extremidade do servidor foi excluído ou se o ponto de extremidade
da nuvem foi excluído, os arquivos em camadas que não foram recuperados ficarão inutilizáveis. Para saber
mais, consulte arquivos em camadas não podem ser acessados no servidor após a exclusão de um ponto de
servidor.
Clusterizados).
NOTE
diferente.

incorretamente.
recentemente.
Os arquivos podem falhar na camada se o arquivo de paginação. sys estiver localizado em um volume que
tenha a camada de nuvem habilitada. O arquivo de paginação. sys deve estar localizado em um volume que
tenha a camada de nuvem desabilitada.

As notas de versão a seguir são para a versão 8.0.0.0 do agente de Sincronização de Arquivos do Azure (lançado
em 8 de outubro de 2019).
Aprimoramentos de desempenho de restauração
Tempos de recuperação mais rápidos para recuperação feita por meio do backup do Azure. Os arquivos
restaurados serão sincronizados novamente para Sincronização de Arquivos do Azure servidores muito
mais rapidamente.
Experiência aprimorada no portal de camadas de nuvem
Se você tiver arquivos em camadas que estão falhando na recuperação, agora você poderá exibir os erros
de recuperação nas propriedades do ponto de extremidade do servidor. Além disso, a integridade do
ponto de extremidade do servidor agora mostrará um erro e as etapas de mitigação se o driver do filtro
de camadas de nuvem não estiver carregado no servidor.
Instalação do agente mais simples
O módulo do PowerShell do Az\AzureRM não é mais necessário para registrar o servidor, tornando a
instalação mais simples e rápida.
Melhorias de desempenho e confiabilidade diversas
R2.
Interoperabilidade
em um único item.)
fazer a auditoria.
Links físicos.
NOTE

da nuvem foi excluído, os arquivos em camadas que não foram recuperados ficarão inutilizáveis. Para saber
mais, consulte arquivos em camadas não podem ser acessados no servidor após a exclusão de um ponto de
servidor.
Clusterizados).
NOTE
diferente.
incorretamente.
recentemente.

24 de julho de 2019. Essas notas são além das notas de versão listadas para a versão 7.0.0.0.
Lista dos problemas corrigidos nesta versão:
O agente de sincronização de armazenamento (FileSyncSvc) falhará se a configuração de proxy for nula.
O ponto de extremidade do servidor iniciará BCDR (erro 0x80c80257-ECS_E_BCDR_IN_PROGRESS) se vários
pontos de extremidades no servidor tiverem o mesmo nome.
Melhorias de confiabilidade em camadas de nuvem.

12 de julho de 2019. Essas notas são além das notas de versão listadas para a versão 7.0.0.0.
O acesso ou a navegação de um local de ponto de extremidade do servidor sobre o SMB é lento no Windows
Server 2012 R2.
Maior utilização da CPU após a instalação do agente Sincronização de Arquivos do Azure v6.
Aprimoramentos de telemetria em camadas de nuvem.
Diversas melhorias de confiabilidade para camada e sincronização de nuvem.

em 19 de junho de 2019).
Suporte para tamanhos maiores de compartilhamento de arquivos
Com a visualização de grandes compartilhamentos de arquivos do Azure, estamos aumentando nossos
limites de suporte para sincronização de arquivos também. Nesta primeira etapa, Sincronização de
Arquivos do Azure agora dá suporte a até 25 TB e 50 milhões arquivos em um único namespace de
sincronização. Para aplicar a visualização de compartilhamento de arquivo grande, preencha este
formulário https://aka.ms/azurefilesatscalesurvey.
Suporte para configuração de rede virtual e firewall em contas de armazenamento
O Sincronização de Arquivos do Azure agora dá suporte à configuração de firewall e rede virtual em
contas de armazenamento. Para configurar sua implantação para trabalhar com a configuração de rede
virtual e firewall, consulte definir configurações de firewall e rede virtual.
Cmdlet do PowerShell para sincronizar imediatamente os arquivos alterados no compartilhamento de arquivos
do Azure
Para sincronizar imediatamente os arquivos que são alterados no compartilhamento de arquivos do
Azure, o cmdlet Invoke-AzStorageSyncChangeDetection do PowerShell pode ser usado para iniciar
manualmente a detecção de alterações no compartilhamento de arquivos do Azure. Esse cmdlet destina-
se a cenários em que algum tipo de processo automatizado está fazendo alterações no
compartilhamento de arquivos do Azure ou as alterações são feitas por um administrador (como mover
arquivos e diretórios para o compartilhamento). Para alterações do usuário final, a recomendação é
instalar o agente de Sincronização de Arquivos do Azure em uma VM IaaS e fazer com que os usuários
finais acessem o compartilhamento de arquivos por meio da VM IaaS. Dessa forma, todas as alterações
serão rapidamente sincronizadas com outros agentes sem a necessidade de usar o cmdlet Invoke-
AzStorageSyncChangeDetection. Para saber mais, confira a documentação do Invoke-
Experiência de portal aprimorada se você encontrar arquivos que não estão sincronizando
Se você tiver arquivos que estão falhando na sincronização, agora diferenciaremos os erros transitórios e
persistentes no Portal. Normalmente, os erros transitórios se resolvem sem a necessidade de ação de
administrador. Por exemplo, um arquivo que está em uso no momento não será sincronizado até que o
identificador do arquivo seja fechado. Para erros persistentes, agora mostramos o número de arquivos
afetados por cada erro. A contagem de erros persistentes também é exibida na coluna arquivos não
Sincronizando de todos os pontos de extremidade do servidor em um grupo de sincronização.
Restauração em nível de arquivo de backup do Azure aprimorada
Arquivos individuais restaurados usando o backup do Azure agora são detectados e sincronizados com o
ponto de extremidade do servidor mais rapidamente.
Melhoria na confiabilidade do cmdlet de recuperação de camadas de nuvem
O cmdlet Invoke-StorageSyncFileRecall agora permite que os clientes especifiquem a contagem de
repetições por arquivo e o atraso de repetição de arquivo semelhante ao Robocopy. Anteriormente, esse
cmdlet rechamaria todos os arquivos em camadas em um determinado caminho em ordem aleatória.
Com o novo parâmetro de ordem, esse cmdlet rechamará os dados mais interessantes primeiro e
honrará a política de camadas de nuvem (Pare de se rechamar se a política de data for atendida ou se o
espaço livre do volume for atendido; o que acontecer primeiro).
Suporte para TLS 1,2 somente (o TLS 1,0 e 1,1 está desabilitado)
Sincronização de Arquivos do Azure agora dá suporte ao uso do TLS 1,2 somente em servidores com TLS
1,0 e 1,1 desabilitados. Antes dessa melhoria, o registro do servidor falharia se o TLS 1,0 e o 1,1 estivesse
desabilitado no servidor.
Melhorias de desempenho e confiabilidade diversas para a sincronização e a disposição em camadas de nuvem
Há várias melhorias de confiabilidade e desempenho nesta versão. Algumas delas são destinadas a
tornar a camada de nuvem mais eficiente e Sincronização de Arquivos do Azure como um trabalho
completo nessas situações quando você tem um agendamento de limitação de largura de banda
definido.
R2.
Interoperabilidade
em um único item.)
fazer a auditoria.
Links físicos.
NOTE

da nuvem foi excluído, os arquivos em camadas que não foram recuperados ficarão inutilizáveis.
servidor.
Clusterizados).
24 horas. Além disso, as alterações feitas em um compartilhamento de arquivos do Azure através do
protocolo REST não atualizarão a hora da última modificação do SMB e não serão vistas como uma
alteração de sincronização.
NOTE
diferente.

incorretamente.
recentemente.

As notas de versão a seguir são para a versão 6.3.0.0 do agente de Sincronização de Arquivos do Azure lançada em
27 de junho de 2019. Essas notas são além das notas de versão listadas para a versão 6.0.0.0.
O acesso ou a navegação em um local de ponto de extremidade do servidor sobre o SMB é lento no Windows
Server 2012 R2
Maior utilização da CPU após a instalação do agente Sincronização de Arquivos do Azure V6
Aprimoramentos de telemetria em camadas de nuvem
13 de junho de 2019. Essas notas são além das notas de versão listadas para a versão 6.0.0.0.
Depois de criar um ponto de extremidade do servidor, o alto uso da CPU pode ocorrer quando o recall em
segundo plano está baixando arquivos para o servidor
As operações de camadas de sincronização e de nuvem podem falhar com o erro
ECS_E_SERVER_CREDENTIAL_NEEDED devido à expiração do token
A rechamada de um arquivo poderá falhar se a URL para baixar o arquivo contiver caracteres reservados

6 de maio de 2019. Essas notas são além das notas de versão listadas para a versão 6.0.0.0.
O centro de administração do Windows falha ao exibir a versão do agente e a configuração do ponto de
extremidade do servidor em servidores que têm o agente Sincronização de Arquivos do Azure versão 6,0
instalado.

em 22 de abril de 2019).
Suporte à atualização automática do agente
Nós ouvimos seus comentários e adicionamos um recurso de atualização automática no agente do
Sincronização de Arquivos do Azure Server. Para obter mais informações, consulte sincronização de
arquivos do Azure política de atualização do agente.
Suporte para ACLs de compartilhamento de arquivos do Azure
O Sincronização de Arquivos do Azure sempre tem suporte para sincronizar ACLs entre os pontos de
extremidade do servidor, mas as ACLs não foram sincronizadas com o ponto final da nuvem
(compartilhamento de arquivos do Azure). Esta versão adiciona suporte para a sincronização de ACLs
entre servidores e pontos de extremidade de nuvem.
Fazer upload paralelo e baixar sessões de sincronização para um ponto de extremidade do servidor
Os pontos de extremidade do servidor agora dão suporte ao carregamento e ao download de arquivos
ao mesmo tempo. Não está mais aguardando a conclusão de um download para que os arquivos possam
ser carregados no compartilhamento de arquivos do Azure.
Novos cmdlets de camadas de nuvem para obter o volume e o status de camadas
Dois novos cmdlets do PowerShell de servidor local agora podem ser usados para obter informações
sobre camadas de nuvem e recuperação de arquivos. Eles disponibilizam informações de log de dois
canais de eventos no servidor disponíveis:
Get-StorageSyncFileTieringResult listará todos os arquivos e seus caminhos que não estão em
camadas e que se relatam sobre o motivo.
Get-StorageSyncFileRecallResult relata todos os eventos de recuperação de arquivo. Ele lista todos
os arquivos recuperados e seu caminho, bem como êxito ou erro para essa recuperação.
Por padrão, ambos os canais de eventos podem armazenar até 1 MB cada – você pode aumentar a
quantidade de arquivos relatados aumentando o tamanho do canal de evento.
Suporte para o modo FIPS
O Sincronização de Arquivos do Azure agora dá suporte à habilitação do modo FIPS em servidores que
têm o agente de Sincronização de Arquivos do Azure instalado.
Antes de habilitar o modo FIPS no seu servidor, instale o agente de Sincronização de Arquivos do
Azure e o módulo PackageManagement no servidor. Se o FIPS já estiver habilitado no servidor,
Baixe manualmente o módulo PackageManagement para o servidor.
Aprimoramentos de confiabilidade diversos para a nuvem e a sincronização em camadas
R2.
Interoperabilidade
Não há suporte à execução de sysprep em um servidor que possua o agente Sincronização de Arquivos do
Azure instalado e isso pode levar a resultados inesperados. O agente de Sincronização de Arquivos do Azure
deverá ser instalado após a implantação da imagem do servidor e a conclusão da mini-instalação do sysprep.
em um único item.)
fazer a auditoria.
Links físicos.
NOTE

servidor.
Clusterizados).
NOTE
diferente.

incorretamente.
recentemente.
Ao exibir as propriedades de arquivo de um cliente SMB, o atributo offline poderá parecer estar definido
incorretamente devido ao cache SMB de metadados do arquivo.

4 de abril de 2019. Essas notas são além das notas de versão listadas para a versão 5.0.2.0.
Aprimoramentos de confiabilidade para transferência de dados offline e recursos de retomada de transferência
de dados
Aprimoramentos de telemetria de sincronização

7 de março de 2019. Essas notas são além das notas de versão listadas para a versão 5.0.2.0.
Os arquivos podem falhar ao serem sincronizados com o erro 0x80c8031d
(ECS_E_CONCURRENCY_CHECK_FAILED) se a enumeração de alteração estiver falhando no servidor
Se uma sessão ou arquivo de sincronização receber um erro 0x80072F78
(WININET_E_INVALID_SERVER_RESPONSE), a sincronização tentará agora a operação novamente
Os arquivos podem falhar ao serem sincronizados com o erro 0x80c80203
(ECS_E_SYNC_INVALID_STAGED_FILE)
O uso de memória alta pode ocorrer ao rechamar arquivos
Aprimoramentos de telemetria em camadas de nuvem

As notas sobre a versão a seguir são para a versão 5.0.2.0 do agente de Sincronização de Arquivos do Azure
(lançada em 12 de fevereiro de 2019).
Suporte para a nuvem do Azure Governamental
Adicionamos suporte à versão prévia para a nuvem do Azure Governamental. Isso exige uma assinatura
inclusa na lista de permissão e download do agente especial da Microsoft. Para obter acesso à versão
prévia, envie um email para nós AzureFiles@microsoft.comdiretamente.
Suporte para Eliminação de Duplicação de Dados
A Eliminação de Duplicação de Dados tem suporte completo com a camada de nuvem habilitada no
Windows Server 2016 e no Windows Server 2019. Habilitar a eliminação de duplicação em um volume
com camada de nuvem habilitada permite armazenar em cache mais arquivos localmente sem ter que
provisionar mais armazenamento.
Suporte para transferência de dados offline (por exemplo, por meio do Data Box)
Migre facilmente grandes quantidades de dados para a Sincronização de Arquivos do Azure do modo
que escolher. Você pode escolher Azure Data Box, AzCopy e até mesmo serviços de migração de terceiros.
Não é necessário usar grandes quantidades de largura de banda para colocar seus dados no Azure. No
caso do Data Box, simplesmente envie-os por ele. Para obter mais informações, confira Documentos de
transferência de dados offline.
Desempenho de sincronização aprimorado
Os clientes com vários pontos de extremidade do servidor no mesmo volume podem ter passado por
sincronização lenta antes dessa versão. O Azure File Sync cria um instantâneo temporário do VSS uma
vez por dia no servidor para sincronizar arquivos que tenham identificadores abertos. A Sincronização
agora dá suporte a vários pontos de extremidade de servidor sincronizando em um volume quando uma
sessão de sincronização do VSS estiver ativa. Não é mais necessário esperar a conclusão de uma sessão
de sincronização do VSS para retomar a sincronização em outros pontos de extremidade do servidor no
volume.
Monitoramento aprimorado no portal
Gráficos foram adicionados no portal do Serviço de Sincronização de Armazenamento para exibir:
Número de arquivos sincronizados
Tamanho dos dados transferidos
Número de arquivos não sincronizados
Tamanho dos dados em recall
Status da conectividade do servidor
Para saber mais, confira Monitorar a Sincronização de Arquivos do Azure.
Confiabilidade e escalabilidade aprimoradas
O número máximo de objetos do sistema de arquivos (diretórios e arquivos) em um diretório aumentou
para 1 milhão. O limite anterior era de 200.000.
A Sincronização tentará retomar a transferência de dados em vez de retransmitir quando uma
transferência for interrompida para arquivos grandes
O agente não tem suporte nas opções de implantação do Windows Server Core ou Nano Server.
R2.
O modo FIPS não tem suporte e deve ser desabilitado.
Interoperabilidade
Não há suporte à execução de sysprep em um servidor que possua o agente Sincronização de Arquivos do
Azure instalado e isso pode levar a resultados inesperados. O agente de Sincronização de Arquivos do Azure
deverá ser instalado após a implantação da imagem do servidor e a conclusão da mini-instalação do sysprep.
em um único item.)
fazer a auditoria.
Links físicos.
NOTE

servidor.
Clusterizados).
NOTE
diferente.

incorretamente.
recentemente.
Ao exibir as propriedades de arquivo de um cliente SMB, o atributo offline poderá parecer estar definido
incorretamente devido ao cache SMB de metadados do arquivo.

Arquivos Do Azure

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Arquivos Do Azure

Enviado por

Direitos autorais:

Formatos disponíveis

Contents

Documentação dos Arquivos do Azure

Os Arquivos do Azure oferecem compartilhamentos de arquivos totalmente gerenciados na nuvem,

Por que o serviço Arquivos do Azure é útil

Prepare o seu ambiente

Modelo de implantação Gerenciador de Recursos

Tipo de conta StorageV2 (uso geral v2)

Replicação Armazenamento com redundância geográfica com acesso

Camada de acesso Dinâmica

Mapeie o compartilhamento de arquivo do Azure para uma unidade do

Criar um instantâneo de compartilhamento

Procurar um instantâneo de compartilhamento

3. No painel do instantâneo, selecione qsTestFile.txt.

3. Na VM, abra o arquivo. A versão não modificada foi restaurada.

Excluir um instantâneo de compartilhamento

Arquivos do Azure é o sistema de arquivos de nuvem fácil de usar da Microsoft. Os compartilhamentos de

Criar uma conta de armazenamento

Criar um compartilhamento de arquivos do Azure

Usar o compartilhamento de arquivos do Azure

Usar o Azure Cloud Shell

Selecione Experimente no canto superior direito de um

Acesse https://shell.azure.com ou selecione o botão Iniciar o

Selecione o botão Cloud Shell na barra de menus no canto

Para executar o código neste artigo no Azure Cloud Shell:

Criar uma conta de armazenamento

Criar um compartilhamento de arquivos do Azure

Usar o compartilhamento de arquivos do Azure

Get-ChildItem | Where-Object { $_.Name -eq "SampleDownload.txt" }

Criar e gerenciar instantâneos de compartilhamento

$share = Get-AzStorageShare -Context $storageAcct.Context -Name $shareName

Procurar instantâneos de compartilhamento

Get-AzStorageFile -Share $snapshot

Restaurar de um instantâneo de compartilhamento

# Restore SampleUpload.txt from the share snapshot

Excluir um instantâneo de compartilhamento

Remove-AzResourceGroup -Name myResourceGroup

Como alternativa, você pode remover recursos individualmente:

Get-AzRmStorageShare -StorageAccount $storageAcct | Remove-AzRmStorageShare -Force

Usar o Azure Cloud Shell

Selecione Experimente no canto superior direito de um

Acesse https://shell.azure.com ou selecione o botão Iniciar o

Selecione o botão Cloud Shell na barra de menus no canto

Para executar o código neste artigo no Azure Cloud Shell:

Criar um grupo de recursos

Criar uma conta de armazenamento

az storage account create \

Obter a chave da conta de armazenamento

Criar um compartilhamento de arquivos do Azure

az storage share create \

Usar o compartilhamento de arquivos do Azure

az storage directory create \

az storage file upload \

az storage file list \

az storage file download \

az storage share create \

az storage directory create \

az storage file copy start \

az storage file list \

Criar e gerenciar instantâneos de compartilhamento

Procurar conteúdo do instantâneo de compartilhamento

az storage file list \

Listar instantâneos de compartilhamento