Eu recomendaria restaurar/anexar o banco de dados ao nó primário no servidor SQL. A partir daí, você pode adicioná-lo ao AG, mas não replicá-lo. Em última análise, para obtê-lo no 3º nó (remoto) - você provavelmente teria que quebrar o AG e adicionar novamente o banco de dados (se você tiver tempo de inatividade) depois que ele já estiver copiado para o nó remoto. Isso permitiria a sincronização.

Portanto, essa abordagem significaria que você teria 3 estágios :

• Estágio 1: banco de dados de 10 TB no nó primário restaurado/anexado - não no AG
• Estágio 2: Banco de dados de 10 TB adicionado ao AG. Remova o nó remoto do AG.
• Estágio 3: Copie 10 TB no nó remoto. Reconstrua o AG para incluir o nó remoto. Permita que o AG sincronize e acompanhe os dados.

Se isso não estiver claro, deixe-me saber mais para que eu possa ajudá-lo (como a versão do OS/SQL).

Este é um cenário com suporte? Em caso afirmativo... Qual seria a abordagem recomendada?

Sim, você pode fazer isso, uma das maneiras criando um novo grupo de disponibilidade para que os bancos de dados AG de saída não sejam interrompidos, um grupo de disponibilidade pode ser criado sem adicionar banco de dados e réplicas adicionais nele.

No seu caso, você pode seguir a mesma abordagem, a seguir estão as etapas que você pode seguir:

Etapas resumidas:

1. Crie um AG sem adicionar banco de dados e réplicas secundárias
2. Adicione o banco de dados desejado no AG
3. Restaurar o banco de dados na opção de réplica secundária WITH NORECOVERY (que está na mesma LAN)
4. Adicione a réplica secundária ao AG
5. Junte-se à réplica secundária (adicionada na etapa 4)
6. Defina o HADR do banco de dados secundário (restaurado na etapa:3) para adicionar ao AG

As etapas 3,4,5 e 6 podem ser repetidas para a 3ª réplica assim que estiver pronta.

Etapas detalhadas:

Para criar um Grupo de Disponibilidade vazio, selecione a opção Novo Grupo de Disponibilidade via
SSMS → Always On High Availability → Grupos de Disponibilidade (clique com o botão direito)

Depois que um Grupo de Disponibilidade vazio é criado, você pode aplicar os seguintes comandos de acordo (Primário e Secundário), as mesmas etapas podem ser feitas usando o SSMS (GUI).

na réplica PRIMÁRIA

ALTER DATABASE Test_2RepAG SET RECOVERY FULL; 
BACKUP DATABASE Test_2RepAG TO DISK = '\\Shared\SQL-Backups\TestDB.bak'; 
GO

USE MASTER;
ALTER AVAILABILITY GROUP [2RepAG] MODIFY REPLICA ON 'PrimaryRep\SQL1' with
    (ENDPOINT_URL = 'TCP://PrimaryRep.Domain.LOCAL:5023'); ---- Just to be safe-side as it it might add default port via wizard 

ALTER AVAILABILITY GROUP [2RepAG] ADD DATABASE Test_2RepAG;

ALTER AVAILABILITY GROUP [2RepAG] ADD REPLICA ON 'Secondary1\SQL1' with
    (  
       ENDPOINT_URL = 'TCP://Secondary1.Domain.LOCAL:5023',  
       AVAILABILITY_MODE =  SYNCHRONOUS_COMMIT, --{SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY },  
       FAILOVER_MODE = AUTOMATIC --{ AUTOMATIC | MANUAL }   
    );
GO 

na réplica SECUNDÁRIA

RESTORE DATABASE Test_2RepAG FROM DISK = '\\Shared\SQL-Backups\TestDB.bak' with stats, replace, NORECOVERY;
GO

ALTER AVAILABILITY GROUP [2RepAG] JOIN;
ALTER DATABASE Test_2RepAG set HADR AVAILABILITY GROUP = [2RepAG];

Você pode usar os seguintes comandos quando decidir adicionar a 3ª réplica, restaurar o banco de dados desejado na 3ª réplica com a opção de backups recentes COM NORECOVERY.

em PRIMARY para 3ª réplica

USER master;
ALTER AVAILABILITY GROUP [2RepAG] ADD REPLICA ON 'Secondary2\SQL1' with
    (  
       ENDPOINT_URL = 'TCP://Secondary2.Domain.LOCAL:5023',  
       AVAILABILITY_MODE =  ASYNCHRONOUS_COMMIT, --{SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT | CONFIGURATION_ONLY },  
       FAILOVER_MODE = MANUAL --{ AUTOMATIC | MANUAL }   
    );

na 3ª réplica

RESTORE DATABASE Test_2RepAG FROM DISK = '\\Shared\SQL-Backups\TestDB.bak' with stats, replace, NORECOVERY;
GO

ALTER AVAILABILITY GROUP [2RepAG] JOIN;
ALTER DATABASE Test_2RepAG set HADR AVAILABILITY GROUP = [2RepAG];

Embora um AG possa ser criado usando 2 réplicas enquanto o WSFC tem 3 réplicas (nós), a integridade do AG e seu ouvinte são decididas por 3 nós no WSFC, a menos que nenhum voto de quorum seja contado do 3º nó no WSFC. Para mais detalhes..

Se eu entendi a pergunta, sim, este é um cenário com suporte e pode ser feito com bastante facilidade, sem tanto trabalho quanto as outras respostas. Você não precisa remover o nó remoto do AG ou criar um novo AG para fazer isso. Etapas de alto nível seriam passar pelo assistente do SSMS para adicionar o banco de dados ao AG e, no final, pressionar o botão para criar os scripts e cancelar o assistente. Use as partes do script que sincronizam e unem o banco de dados no secundário local. Então, quando estiver pronto para fazer o secundário remoto, restaure o banco de dados nele, sincronize-o com o backup de log mais recente e junte-o com:

ALTER DATABASE <database_name> SET HADR AVAILABILITY GROUP = <AG_name>

Você pode até salvar as partes do script gerado pelo SSMS que são relevantes para o servidor remoto para fazer isso e você verá o comando acima nele.

Eu escrevi um processo semelhante em Como remover um banco de dados secundário de um grupo de disponibilidade e reingressar nele .

Há separação da associação do AG e da propriedade da réplica do banco de dados. A replicação de cada banco de dados no AG é tratada separadamente, então você pode ter um banco de dados sendo replicado para 2 outros nós e outro banco de dados sendo replicado apenas para 1 outro nó. Tem que funcionar assim porque a replicação não pode ser iniciada até que a réplica esteja sincronizada com o último backup de log. Bancos de dados pequenos podem levar apenas alguns segundos, mas bancos de dados grandes, principalmente em locais remotos, podem levar horas ou dias para serem sincronizados, portanto, o SQL Server não forçará você a ter logs de transações gigantescos cheios de dados que são enfileirados para replicação para um site remoto que ainda não pode ser enviado porque o banco de dados remoto não está atualizado com o LSN atual.