Criar um endpoint de servidor Azure File Sync

Os pontos finais de servidor representam uma localização específica num servidor registado, como uma pasta num volume do servidor. Um ponto de extremidade de servidor deve atender às seguintes condições:

Um ponto de extremidade de servidor deve ser um caminho num servidor registado (ao invés de uma partilha montada). O armazenamento conectado à rede (NAS) não é suportado.
Embora o ponto de extremidade do servidor possa estar no volume do sistema, os pontos de extremidade do servidor no volume do sistema não podem usar a hierarquização na nuvem.
Um servidor registado pode suportar vários pontos de extremidade de servidor, no entanto, um grupo de sincronização só pode ter um ponto de extremidade de servidor por servidor registado em qualquer momento dado. Outros pontos finais de servidor dentro do grupo de sincronização devem estar em diferentes servidores registados.
Vários pontos de extremidade de servidor podem existir no mesmo volume se seus namespaces não estiverem sobrepostos (por exemplo, F:\sync1 e F:\sync2) e cada ponto de extremidade estiver sincronizando com um grupo de sincronização exclusivo.

Este artigo ajuda-o a compreender as opções e decisões necessárias para criar um novo endpoint de servidor e iniciar a sincronização. Para que isto funcione, tens de ter terminado o planeamento para a tua implementação Azure File Sync e também ter implementado recursos necessários em etapas anteriores para criar um endpoint de servidor.

Prerequisites

Para criar um endpoint de servidor, certifique-se de que os seguintes critérios são cumpridos:

Instala o agente Azure File Sync no servidor e regista-o. Veja Registar/desregistar um servidor com o Azure File Sync para mais detalhes.
Implementar um serviço de sincronização de armazenamento. Veja Como implementar o Azure File Sync para mais detalhes.
Crie um grupo de sincronização. Consulte Criar um grupo de sincronização para mais detalhes.
Ligue o servidor à internet para que o Azure fique acessível. O Azure File Sync utiliza a porta 443 para toda a comunicação entre o servidor e o serviço cloud.
Verifica se estás dentro dos limites permitidos para criar pontos finais. Consulte os alvos de escala do Azure File Sync para mais detalhes.
Escolha um caminho permanente para o endpoint do servidor. Alterar o caminho ou a letra da unidade após a criação não é suportado.

Criar um ponto final de servidor

Portal
PowerShell
CLI do Azure

Vá para o grupo de sincronização recém-criado.
Em Pontos de extremidade do servidor, selecione +Adicionar ponto de extremidade do servidor.
No painel Adicionar ponto de extremidade do servidor , insira as seguintes informações:
- Servidor Registrado: Selecione o nome do servidor ou cluster onde você deseja criar o ponto de extremidade do servidor.
- Path: Introduza o caminho na instância do Windows Server a ser sincronizado com a partilha de ficheiros Azure. O caminho pode ser uma pasta (por exemplo, D:\Data), raiz do volume (por exemplo, D:\) ou ponto de montagem do volume (por exemplo, D:\Mount).
- Hierarquia na nuvem: esta seção inclui uma opção para habilitar ou desabilitar a hierarquização na nuvem. Com o cloud tiering, ficheiros pouco usados ou acedidos podem ser escalonados para o Ficheiros do Azure. Quando ativas o tiering na cloud, existem duas políticas que podes definir para informar o Azure File Sync quando deves escalonar ficheiros inativos.
  - Política de Espaço Livre de 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 no volume for definido para 50% num volume que tem apenas um endpoint de servidor, cerca de metade da quantidade de dados é transferida para os Ficheiros do Azure. Independentemente de a hierarquização na nuvem estar ativada, a partilha de ficheiros do Azure tem sempre uma cópia completa dos dados no grupo de sincronização.
  - Política de data: os arquivos são hierarquizados na nuvem se não forem acessados (ou seja, lidos ou gravados) pelo número de dias especificado. Por exemplo, se você notar que os arquivos que passam mais de 15 dias sem serem acessados são normalmente arquivos de arquivamento, você deve definir sua política de data para 15 dias.
- Sincronização inicial: esta seção está disponível apenas para o primeiro ponto de extremidade do servidor em um grupo de sincronização. (A seção muda para Download Inicial quando estiver a criar mais do que um endpoint de servidor num grupo de sincronização.) Pode selecionar o comportamento seguinte:
  - Upload Inicial: Como o servidor inicialmente carrega os dados para a Azure partilha de ficheiros. Estão disponíveis duas opções:
    - Mescle o conteúdo deste caminho de servidor com o conteúdo da partilha de ficheiros do Azure. Arquivos com o mesmo nome e caminho levarão a conflitos se seu conteúdo for diferente. Ambas as versões desses arquivos são armazenadas uma ao lado da outra. Se o caminho do teu servidor ou partilha de ficheiros do Azure estiver vazia, escolhe sempre esta opção.
    - Sobrescreva autoritativamente ficheiros e pastas no compartilhamento de arquivos do Azure com o conteúdo no caminho deste servidor. Esta opção evita conflitos de ficheiros.
  Para saber mais, consulte Sincronização inicial.
  - Initial Download: Como o servidor descarrega inicialmente os dados Azure partilha de ficheiros. Esta configuração é importante quando o servidor está a ligar-se a uma partilha de ficheiros do Azure que contém ficheiros. Três opções estão disponíveis:
    - Baixe o namespace primeiro e, em seguida, recupere o conteúdo do arquivo, tanto quanto você pode caber no disco local. Namespace significa a estrutura de arquivos e pastas sem o conteúdo do arquivo.
    - Baixe somente o namespace. O conteúdo do arquivo é recuperado quando é acessado.
    - Evite arquivos hierárquicos. Os ficheiros só aparecem no servidor depois de serem totalmente transferidos. O acesso local ou a política definida recupera os conteúdos dos ficheiros hierarquizados da nuvem para o servidor.
  Para saber mais, consulte Download inicial.
Para concluir a adição do servidor endpoint, selecione Criar. Os seus ficheiros são agora mantidos sincronizados entre a sua partilha de ficheiros do Azure e a instância do Windows Server.

Nota

O Azure File Sync tira um snapshot da partilha de ficheiros do Azure como backup antes de criar o endpoint do servidor. Você pode usar este instantâneo para restaurar o compartilhamento ao estado anterior à criação do ponto final do servidor.

O instantâneo não é removido automaticamente após a criação do endpoint do servidor. Você pode excluí-lo manualmente se não precisar dele.

Pode encontrar os instantâneos que a Azure File Sync criou ao visualizar os instantâneos da partilha de ficheiros Azure e verificar AzureFileSync na coluna Initiator.

Execute os seguintes comandos do PowerShell para criar o endpoint do servidor. Substitui <your-server-endpoint-path> e <your-volume-free-space> pelos valores que queres. Verifique as configurações para as políticas opcionais de download inicial e upload inicial.

$serverEndpointPath = "<your-server-endpoint-path>"
$cloudTieringDesired = $true
$volumeFreeSpacePercentage = <your-volume-free-space>
# Optional property. Choose from: [NamespaceOnly], the default when cloud tiering is enabled. [NamespaceThenModifiedFiles], the default when cloud tiering is disabled. [AvoidTieredFiles], available only when cloud tiering is disabled.
$initialDownloadPolicy = "NamespaceOnly"
$initialUploadPolicy = "Merge"
# Optional property. Choose from: [Merge], the default for all new server endpoints. Content is from the server and the cloud merge. This is the right choice if one location is empty or other server endpoints already exist in the sync group. [ServerAuthoritative], the right choice when you seeded the Azure file share (for example, with Azure Data Box) and you're connecting the server location that you seeded from. It enables you to catch up the Azure file share with the changes that happened on the local server since the seeding.

if ($cloudTieringDesired) {
    # Ensure that the endpoint path is not the system volume
    $directoryRoot = [System.IO.Directory]::GetDirectoryRoot($serverEndpointPath)
    $osVolume = "$($env:SystemDrive)\"
    if ($directoryRoot -eq $osVolume) {
        throw [System.Exception]::new("Cloud tiering cannot be enabled on the system volume")
    }

    # Create the server endpoint
    New-AzStorageSyncServerEndpoint `
        -Name $registeredServer.FriendlyName `
        -SyncGroup $syncGroup `
        -ServerResourceId $registeredServer.ResourceId `
        -ServerLocalPath $serverEndpointPath `
        -CloudTiering `
        -VolumeFreeSpacePercent $volumeFreeSpacePercentage `
        -InitialDownloadPolicy $initialDownloadPolicy `
        -InitialUploadPolicy $initialUploadPolicy
} else {
    # Create the server endpoint
    New-AzStorageSyncServerEndpoint `
        -Name $registeredServer.FriendlyName `
        -SyncGroup $syncGroup `
        -ServerResourceId $registeredServer.ResourceId `
        -ServerLocalPath $serverEndpointPath `
        -InitialDownloadPolicy $initialDownloadPolicy
}

Use o comando az storagesync sync-group server-endpoint para criar um novo ponto de extremidade do servidor:

# Create a new sync group server endpoint 
az storagesync sync-group server-endpoint create --resource-group myResourceGroupName \
                                                 --name myNewServerEndpointName
                                                 --registered-server-id 91beed22-7e9e-4bda-9313-fec96c286e0
                                                 --server-local-path d:\myPath
                                                 --storage-sync-service myStorageSyncServiceNAme
                                                 --sync-group-name mySyncGroupName

# Create a new sync group server endpoint with additional optional parameters
az storagesync sync-group server-endpoint create --resource-group myResourceGroupName \
                                                 --storage-sync-service myStorageSyncServiceName \
                                                 --sync-group-name mySyncGroupName \
                                                 --name myNewServerEndpointName \
                                                 --registered-server-id 91beed22-7e9e-4bda-9313-fec96c286e0 \
                                                 --server-local-path d:\myPath \
                                                 --cloud-tiering on \
                                                 --volume-free-space-percent 85 \
                                                 --tier-files-older-than-days 15 \
                                                 --initial-download-policy NamespaceOnly [OR] NamespaceThenModifiedFiles [OR] AvoidTieredFiles
                                                 --initial-upload-policy Merge [OR] ServerAuthoritative

Tierização na nuvem

Ao criar um novo ponto final de servidor, pode optar pela funcionalidade de escalonamento para a cloud do Azure File Sync. Pode alterar as opções mais tarde na secção Escalonamento para a cloud. No entanto, estão disponíveis diferentes opções na secção seguinte, consoante ative ou não o escalonamento na cloud para o seu novo endpoint de servidor.

Para mais informações, consulte a visão geral de tiering na nuvem e as políticas de tiering na nuvem.

Sincronização inicial

A seção Sincronização inicial está disponível apenas para o primeiro ponto de extremidade do servidor em um grupo de sincronização. Para qualquer endpoint adicional de servidor, consulte o download inicial.

Estão disponíveis dois comportamentos iniciais de sincronização:

Merge

Merge é a opção padrão e é selecionada por predefinição. Mantém a seleção em Merge , a menos que tenhas certos cenários de migração.

Quando adere a uma localização de servidor, na maioria dos cenários, ou a localização do servidor ou a partilha de ficheiros do Azure está vazia. Nestes casos, o Merge é o comportamento correto e conduz aos resultados esperados.
Quando ambos os locais contêm ficheiros e pastas, os espaços de nomes fundem-se. Se existirem ficheiros ou nomes de pastas no servidor que também existam na partilha de ficheiros do Azure, ocorre um conflito de sincronização. Os conflitos são resolvidos automaticamente.

Dentro da opção Merge, pode selecionar como o conteúdo da partilha de ficheiros do Azure chega inicialmente ao servidor. Esta seleção não tem impacto se a partilha de ficheiros do Azure estiver vazia. Pode encontrar mais detalhes no download inicial.

Carregamento autoritativo

O carregamento autoritativo é uma opção de sincronização inicial reservada para um cenário de migração específico. Sincroniza o mesmo caminho do servidor que também usaste para iniciar a partilha de ficheiros do Azure, por exemplo, usando o Azure Data Box. Neste caso, a nuvem e os locais do servidor têm basicamente os mesmos dados, mas o servidor é um pouco mais novo. Os utilizadores continuam a fazer alterações enquanto o Data Box está em transporte. Esse cenário de migração exige a atualização da nuvem de forma transparente com as alterações recentes no servidor, sem produzir conflitos. Assim, o servidor é a autoridade sobre a estrutura do namespace e o Data Box foi usado para evitar um grande carregamento inicial para o servidor. O carregamento autorizado do servidor permite uma adoção da nuvem sem interrupções, mesmo quando um mecanismo de transporte de dados fora de linha foi usado para iniciar o armazenamento em nuvem.

Um endpoint do servidor só pode concluir o aprovisionamento com êxito com a opção de carregamento autoritativo quando a localização do servidor contém dados. Este bloco protege contra configurações erradas acidentais. O upload autoritativo funciona como o Robocopy / MIR. Este modo espelha a origem para o destino. A origem é o servidor Azure File Sync e o destino é a partilha de ficheiros Azure. O upload autoritativo molda o alvo na imagem da fonte.

Ficheiros e pastas novos ou atualizados são carregados a partir do servidor.
Ficheiros e pastas que já não existem no servidor são eliminados da partilha de ficheiros do Azure.
Alterações apenas de metadados em ficheiros e pastas no servidor são transferidas de forma eficiente para a partilha de ficheiros do Azure como atualizações apenas de metadados.
Podem existir ficheiros e pastas no servidor e na partilha de ficheiros do Azure. Mas alguns ficheiros ou pastas podem ter mudado o diretório principal no servidor desde a criação da partilha de ficheiros do Azure. Estes ficheiros e pastas são eliminados da partilha de ficheiros do Azure e carregados novamente. Por isso, é melhor evitar a reestruturação do namespace em uma escala maior durante uma migração.

Download inicial

A secção de download inicial está disponível para o segundo e quaisquer endpoints adicionais de servidor num grupo sincronizado. O primeiro servidor endpoint num grupo de sincronização tem opções extra relacionadas com a migração para Azure Data Box. Essas opções não se aplicam se esse ponto de extremidade do servidor não for o primeiro do seu grupo de sincronização.

Nota

Selecionar uma opção de download inicial não tem impacto se a partilha de ficheiros do Azure estiver vazia.

Como parte desta secção, escolhe como o conteúdo da partilha de ficheiros do Azure chegará inicialmente ao servidor.

	Baixe o namespace primeiro	Baixe somente o namespace	Evite arquivos hierárquicos
Descrição	Baixa o namespace inteiro primeiro. O conteúdo dos ficheiros é recuperado da cloud como atividade em segundo plano para o servidor, com base no heat map (um registo da frequência de acesso recente aos ficheiros), que recupera mais cedo os dados acedidos recentemente. Se o espaço livre no volume do servidor for inferior a 10%, os ficheiros restantes permanecem como ficheiros em níveis.	Somente o namespace (estrutura de arquivos e pastas) é baixado. Nenhum conteúdo de arquivo é trazido para o servidor.	Baixa cada arquivo em sua totalidade antes que o arquivo apareça na pasta no servidor. Essa opção evita que um arquivo hierárquico exista no servidor. Um item de namespace e o conteúdo do arquivo estão sempre presentes ao mesmo tempo.
Configurações padrão	Padrão se a hierarquização na nuvem não estiver ativada para este endpoint de servidor.	Padrão se a hierarquização na nuvem estiver habilitada para esse ponto de extremidade do servidor.	Não selecionado como uma opção padrão. Esta opção só está disponível quando a hierarquização na nuvem não está ativada.
Comportamento quando a hierarquização está habilitada	Quando a hierarquização na nuvem estiver ativada, a recuperação em segundo plano dos arquivos hierárquicos será interrompida assim que atender aos critérios da política de hierarquização de nuvem especificada (respeita a política livre de volume e a política de data também, se houver).	Somente o namespace (estrutura de arquivos e pastas) é baixado. Nenhum conteúdo de arquivo é trazido para o servidor.	Opção não disponível.
Comportamento quando a hierarquização não está habilitada	Quando a hierarquização na nuvem não está habilitada, a intenção é recuperar todos os dados para o ponto de extremidade do servidor por meio da recuperação em segundo plano. Você precisaria provisionar um volume grande o suficiente para acomodar todos os dados. Se o volume não tiver espaço livre suficiente, alguns arquivos serão deixados como hierárquicos mesmo quando a hierarquização na nuvem estiver desativada.	Somente o namespace (estrutura de arquivos e pastas) é baixado. Nenhum conteúdo de arquivo é trazido para o servidor.	Baixa cada arquivo em sua totalidade antes que o arquivo apareça na pasta no servidor.
Quando utilizar	Quando os utilizadores precisam de acesso rápido a ficheiros recentes logo após o namespace ser descarregado, e a maioria dos dados está presente na partilha de ficheiros do Azure no momento do provisionamento. Clientes com baixa largura de banda também podem beneficiar do recall em segundo plano após o provisionamento inicial. Para mais detalhes sobre a recuperação de ficheiros em camadas, veja How to manage Azure File Sync layered files. Mais indicado para cenários de recuperação de desastres do lado do servidor Azure File Sync, onde o caminho do servidor começa como uma pasta vazia, por exemplo, um novo endpoint de servidor numa agência filial.	Ideal para aplicativos que precisam recuperar dados com menos frequência ou apenas uma pequena quantidade de dados sob demanda.	Quando todos os dados devem estar sempre disponíveis localmente sem depender de hierarquização. Ideal para aplicações que requerem acesso a todos os ficheiros em todos os momentos. Útil em servidores de baixa largura de banda onde não se querem ficheiros escalonados para problemas de desempenho de acesso a dados.
Implicações	A CPU/memória deve ser dimensionada com base na escala do namespace e no recurso necessário para evitar problemas de desempenho de E/S. Para detalhes, veja Recursos do Sistema Recomendados para Azure File Sync	-	O volume deve ter espaço suficiente para armazenar todos os dados. O download inicial provavelmente levará muito mais tempo devido à necessidade de baixar todo o conteúdo do arquivo. Não é adequado para recuperação rápida de desastres, pois é mais lento do que as duas primeiras opções.

Depois de selecionar uma opção de download inicial, não é possível alterá-la depois de confirmar a criação do ponto de extremidade do servidor.

Nota

Ao adicionar um endpoint servidor e os ficheiros existem na partilha de ficheiros do Azure, se optar por descarregar primeiro o namespace, os ficheiros aparecerão como escalonados até serem descarregados localmente. Os arquivos são baixados usando um único thread por padrão para limitar o uso da largura de banda da rede. Para melhorar o desempenho do download de arquivos, use o cmdlet Invoke-StorageSyncFileRecall com uma contagem de threads maior que 1.

Comportamento do download de ficheiros após o término do download inicial

A forma como os ficheiros aparecem no servidor após o download inicial terminar depende da sua utilização da funcionalidade de escalonamento na nuvem e se opta por recordar proativamente alterações na nuvem (descarregar automaticamente ficheiros novos e alterados de outros endpoints do servidor antes de os utilizadores aceder a eles). Esta funcionalidade é útil para sincronizar grupos com múltiplos endpoints de servidor em diferentes localizações geográficas.

O armazenamento por camadas na nuvem está ativado

Ficheiros novos e alterados de outros endpoints de servidor aparecem como ficheiros escalonados neste endpoint de servidor. Estas alterações só são consideradas ficheiros completos se optares por uma recordação proativa das alterações na partilha de ficheiros do Azure por outros endpoints do servidor.
A estratificação na nuvem está desativada

Ficheiros novos e alterados de outros endpoints de servidor aparecem como ficheiros completos neste endpoint de servidor. Eles não aparecem primeiro como ficheiros armazenados em camadas e só depois restaurados. Os arquivos hierárquicos com hierarquização na nuvem são um recurso rápido de recuperação de desastres e aparecem apenas durante o provisionamento inicial.

Etapas de provisionamento

Quando crias um novo endpoint de servidor usando o portal ou PowerShell, o endpoint do servidor não está pronto a ser usado imediatamente. Dependendo da quantidade de dados presentes na partilha de ficheiros correspondente na cloud, pode demorar de alguns minutos a horas até que o endpoint do servidor se torne funcional e pronto a usar.

Anteriormente, se quisesses verificar o estado do provisionamento do endpoint do servidor e se o servidor está pronto para os utilizadores acedirem aos dados, tinhas de iniciar sessão no endpoint do servidor e verificar se todos os dados tinham sido descarregados. Ao usar passos de provisionamento, pode perceber se um endpoint servidor está pronto a usar ou não e se a sincronização está totalmente funcional diretamente a partir do portal Azure, na visão geral do endpoint do servidor.

Para cenários com suporte, a guia Etapas de provisionamento fornece informações sobre o que está acontecendo no ponto de extremidade do servidor, incluindo quando o ponto de extremidade do servidor está pronto para acesso do usuário.

Cenários suportados

Atualmente, as etapas de provisionamento só são exibidas quando o novo ponto de extremidade do servidor adicionado não possui dados no caminho selecionado para esse ponto de extremidade. Em outros cenários, a guia Etapas de provisionamento não está disponível.

Status de provisionamento

Aqui estão os diferentes estados que são apresentados quando o provisionamento do endpoint do servidor está em andamento e qual o seu significado:

Em progresso: o ponto de extremidade do servidor não está pronto para acesso do usuário.
Pronto (sincronização não funcional): Os utilizadores podem aceder aos dados, mas as alterações não sincronizam com a partilha de ficheiros na cloud.
Pronto (funcional de sincronização): Os utilizadores podem aceder aos dados e as alterações são sincronizadas com a partilha na cloud, tornando o endpoint totalmente funcional.
Falha: Falha no provisionamento devido a um erro.

O portal Azure mostra o separador de passos de provisionamento apenas para cenários suportados. Se não vires o separador, o teu cenário não está atualmente suportado.

Consulte também

Os artigos seguintes ajudam-no a compreender opções avançadas, boas práticas e resolução de problemas para Ficheiros do Azure e Azure File Sync.

Comentários

Esta página foi útil?

Last updated on 2026-07-29

Criar um endpoint de servidor Azure File Sync

Prerequisites

Criar um ponto final de servidor

Tierização na nuvem

Sincronização inicial

Merge

Carregamento autoritativo

Download inicial

Comportamento do download de ficheiros após o término do download inicial

Etapas de provisionamento

Cenários suportados

Status de provisionamento

Consulte também

Comentários

Recursos adicionais