Nesta publicação, gostaria de explicar um pouco mais sobre os instantâneos do Active Directory e como pode ou não utilizá-los.

Antes de mais, é preciso deixar uma coisa bem clara: os instantâneos de VM dos controladores de domínio não são suportados!

Repito, se tiver um controlador de domínio virtualizado e estiver a planear tirar um instantâneo dessa VM a partir do seu anfitrião (Hyper-V, VMWare ou qualquer fornecedor de nuvem pública), pare!

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 tirar nem utilizar um instantâneo 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 discutir 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!

Assim, digamos que o nosso DC1 tem um USN mais elevado de 5000 e o DC2 tem um USN mais elevado de 6000. (voltando ao exemplo dos guardas de segurança, o guarda de segurança n.º 1 contou 5000 pessoas a entrar e o guarda de 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, eles telefonam um ao outro a dizer "Ei, contei até 5000 pessoas", aqui estão os seus nomes, e o outro diz: Óptimo, contei até 6000, aqui estão os seus nomes.

Vejamos agora o que acontece durante a recuperação de um instantâneo (retroceder o servidor no tempo).

Digamos que recuperamos DC1 para um ponto no tempo em que seu USN mais alto comprometido era 3000. Agora lembre-se, a tabela de vectores UTD em DC2 ainda armazena o valor do USN mais elevado de DC1 como 5000. Quando tentam replicar, DC1 diz: "Tenho alterações até 3000". DC2 "olha para ele de forma estranha" e diz "mas da última vez que replicámos tinhas alterações até 5000′ o que se passa?

Exemplo dos seguranças? Depois desse primeiro telefonema, vem outro telefonema em que o segurança n.º 1 diz: "Ei, eu contei até 3000 pessoas.", resposta do segurança n.º 2? "Da última vez que falámos, disseste que tinhas contado até 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 restaura utilizando um método suportado, o processo de restauro altera efectivamente a forma como o Controlador de Domínio aparece na tabela do vector de actualidade, alterando o GUID da base de dados (também designado por InvocationID). As entradas no vector de actualidade não são realmente nomes de DC, mas sim os GUIDs da base 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 é restaurado utilizando um método suportado, o GUID da base de dados é alterado, pelo que o DC2 sabe que agora não é replicado com o DC1, mas sim com o DC1a (que ainda tem o mesmo nome de computador, GUID de servidor, etc., mas tem uma base de dados 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 da USN.

Esta é a explicação completa para o facto de os instantâneos 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.