Neste artigo, gostaria de explicar um pouco mais sobre os instantâneos do Active Directory e como os pode ou não utilizar.

«Em primeiro lugar, vamos deixar uma coisa bem clara: os instantâneos de máquinas virtuais (VM Snapshots) de controladores de domínio não são suportados!

Deixa-me repetir: se tiveres um controlador de domínio virtualizado e estiveres a planear criar um instantâneo dessa máquina virtual a partir do teu anfitrião (Hyper-V, VMware ou qualquer fornecedor de nuvem pública), pára já!

Pode ler aqui, conforme declarado oficialmente pela Microsoft http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(WS.10).aspx

«Não crie nem utilize um Snapshot de um controlador de domínio virtual.»

O mesmo se aplica à cópia do disco rígido virtual de um controlador de domínio, à utilização de discos diferentes ou a qualquer outra funcionalidade ainda não inventada de retroceder a própria VM no tempo sem utilizar um método de cópia de segurança e restauro suportado.

Agora, vamos falar um pouco sobre o porquê.

Quando os controladores de domínio replicam, utilizam um mecanismo denominado vector de actualidade para controlar as alterações replicadas.

Digamos que temos dois controladores de domínio DC1 e DC2, ambos DCs no domínio corp.contoso.com. Cada um desses controladores de domínio terá um número de sequência de actualização local (USN) que rastreia as alterações efectuadas na base de dados local. Esses USNs são locais e não são replicados (por isso são diferentes entre os dois controladores de domínio).

Pense nas USN como contadores que contam as alterações efectuadas em cada CD localmente. Um exemplo da vida real poderia ser um segurança à entrada de um concerto a contar as pessoas que entram. Agora pense que este concerto tem duas portas, com dois seguranças. O número seria o mesmo? De certeza que não!

Digamos, então, que o nosso DC1 tenha um USN máximo comprometido de 5000 e que o DC2 tenha um USN máximo comprometido de 6000. (Voltando ao exemplo dos seguranças: o segurança n.º 1 contou 5000 pessoas a entrar e o segurança n.º 2 contou 6000 pessoas a entrar).

O que é que isto tem a ver com o vector up to dateness? Bem, o vector UTD mantém uma lista local em cada DC de qual foi o USN mais elevado na tentativa de replicação anterior. Portanto, se acionarmos a replicação no estado atual, depois que ela terminar com sucesso, o vetor UTD no DC1 mostrará:

DC2 6000

E o vector UTD no DC2 seria exibido:

DC1 5000

Nota: é possível visualizar o vector de actualidade utilizando o comando repadmin:

Repadmin /showutdvec DCName PartitionDN

Portanto, se voltarmos ao exemplo dos seguranças, isso significa que, a dada altura, um liga ao outro a dizer: «Olá, contei 5 000 pessoas; aqui estão os nomes delas», e o outro responde: «Ótimo, eu contei 6 000; aqui estão os nomes delas.»

Vamos agora ver o que acontece durante uma recuperação a partir de um instantâneo (revertendo o servidor para um momento anterior).

Suponhamos que recuperemos o DC1 para um momento em que o seu USN mais elevado confirmado era 3000. Agora, lembrem-se de que a tabela de vetores UTD no DC2 ainda armazena o valor do USN mais elevado confirmado do DC1 como 5000. Quando tentam replicar, o DC1 diz: «Tenho alterações até ao 3000.» O DC2 «olha para ele com ar estranho» e diz: «Mas da última vez que replicámos, tinhas alterações até ao 5000. O que se passa?».

Um exemplo com seguranças? Depois daquela primeira chamada, segue-se outra chamada em que o segurança n.º 1 diz: «Olá, contei 3000 pessoas.» Qual é a resposta do segurança n.º 2? «Da última vez que falámos, disseste que tinhas contado 5000. O que se passa?»

Vê o problema nisto?

Esta situação é designada por USN rollback e, nessa altura, os DC deixaram de comunicar entre si e de replicar qualquer informação.

Então, como é que isto se resolve?

Quando se efetua uma restauração utilizando um método suportado, o processo de restauração altera, na verdade, a forma como o Controlador de Domínio aparece na tabela do vetor de atualização, alterando o GUID da base de dados (também designado por InvocationID). As entradas no vetor de atualização não são, na verdade, nomes de Controladores de Domínio, mas sim os GUIDs das bases de dados dos controladores de domínio que estão a ser replicados para o contexto de nomenclatura específico.

Nota: a execução de Repadmin /showutdvec DCName PartitionDN /nocache apresentará os GUIDs mencionados.

Assim, quando um DC é restabelecido utilizando um método compatível, o GUID da base de dados é alterado; por isso, o DC2 sabe que agora já não está a ser replicado com o DC1, mas sim com o DC1a (que continua a ter o mesmo nome de computador, GUID do servidor, etc., mas possui uma base de dados do AD diferente, que é o que importa para a replicação).

Assim, nesse cenário, é como se o DC2 tivesse começado a replicar com um controlador de domínio totalmente novo, pelo que não ocorre qualquer reversão do USN.

Essa é a explicação completa para o facto de os Snapshots não serem suportados!

Agora, com isso claramente fora do caminho , o que são bons instantâneos?

Bons snapshots são aqueles feitos usando o comando ntdsutil, que usa o VSS sob os capuzes para criar um snapshot da base de dados do Active Directory. Esses snapshots não podem ser usados para restaurar o banco de dados (exatamente pelo mesmo motivo explicado acima), mas podem ser montados, inspecionados e algumas informações podem ser extraídas deles e inseridas no banco de dados de produção por ferramentas como ldifde.exe e outras, mas mais sobre snapshots do AD em posts posteriores.

Uma conclusão importante deste artigo. Utilize a cópia de segurança do estado do sistema para efectuar a cópia de segurança dos controladores de domínio e certifique-se de que sabe como efectuar o restauro a partir da mesma em todos os cenários possíveis.