Quem administra Active Directory há mais de uma década sabe que a frase "Restaurei um snapshot do Domain Controller" sempre foi encarada com grande receio e preocupação.
Antigamente (pré-Windows Server 2012), essa ação era praticamente uma sentença de morte para o domínio. O resultado era o temido USN Rollback, um estado de inconsistência que corrompia a replicação silenciosamente.
Mas os tempos mudaram. A Microsoft introduziu proteções nativas contra isso. A pergunta é: podemos finalmente confiar nos snapshots? A resposta é sim, mas não está livre de riscos.
Neste artigo, vamos revisitar o conceito de USN Rollback e explicar como a tecnologia moderna de virtualização tenta nos salvar desse problema.
O Fantasma: O que é o USN Rollback?
Para quem não leu os clássicos manuais da Microsoft, aqui vai o resumo:
Cada Controlador de Domínio (DC) mantém um contador sequencial chamado USN (Update Sequence Number). Toda vez que você cria um usuário, muda uma senha ou altera um grupo, esse número sobe (ex: 100, 101, 102...). Os outros DCs usam esse número para saber o que precisam replicar.
O Problema Clássico: Se você tira um snapshot quando o contador está em 100, continua trabalhando até o 200, e depois reverte o snapshot:
- O servidor volta para o número 100.
- Ele não sabe que já usou os números de 101 a 200.
- Ele começa a reutilizar esses números para novas alterações.
- Os outros DCs, que já receberam as alterações antigas (101-200), ignoram as novas porque pensam: "Já tenho o ticket 101".
Resultado: Objetos somem, senhas não replicam e você tem dois objetos diferentes com a mesma "identidade" no banco de dados.
A Solução: VM-Generation ID
A partir do Windows Server 2012, a Microsoft introduziu um recurso chamado Virtualization Safeguards.
O funcionamento depende de uma cooperação entre o Hypervisor (Hyper-V ou VMware vSphere 5.0u2+) e o Sistema Operacional da VM. Funciona assim:
- A VM possui um identificador único chamado VM-Generation ID.
- Quando você aplica um snapshot (volta no tempo), o Hypervisor muda esse ID na memória da VM.
- O serviço do Active Directory detecta essa mudança imediatamente.
- O DC "entende" que viajou no tempo e aciona um protocolo de emergência:
- Descarta o Pool de RID: Joga fora os identificadores de segurança pré-alocados para evitar SIDs duplicados.
- Muda o Invocation ID: Troca a identidade do banco de dados.
Para os outros DCs da rede, é como se esse servidor tivesse sido formatado e promovido novamente. A replicação é reiniciada de forma segura (Invocação de Reparo), evitando o USN Rollback.
O Perigo Oculto: Onde a proteção falha?
É aqui que muitos administradores caem. A proteção do VM-Generation ID não é mágica. Ela precisa que o Hypervisor avise o Windows que o snapshot foi restaurado.
Existem cenários onde esse aviso não chega, e o USN Rollback ainda acontece:
- Snapshots de Storage (LUN): Se você reverte o LUN inteiro pelo storage (SAN), o Hypervisor muitas vezes nem percebe que o disco mudou. O Windows acorda com o banco de dados antigo, mas com o mesmo Generation-ID. Resultado: USN Rollback.
- Snapshot com Memória (Saved State): Se você salvar o estado da memória RAM no snapshot, a VM "acorda" pensando que nada aconteceu. Embora o Windows tente detectar a mudança de ID, a chance de falha é maior do que em um boot limpo.
- Versões Antigas: Hypervisors desatualizados ou sem os Integration Services/VMware Tools em dia podem não conseguir comunicar a troca de ID.
Boas Práticas: Como fazer do jeito certo
Se você precisa fazer uma manutenção crítica e quer usar o snapshot como uma "rede de segurança rápida", siga estas regras:
- Prefira o Backup Oficial: Ferramentas como Veeam ou Commvault são sempre mais seguras que snapshots. Elas garantem a integridade do banco via VSS/VSA.
- Configuração do Snapshot:
- Hyper-V: Use "Production Checkpoints". Eles usam VSS e não salvam o estado da memória, garantindo um boot limpo.
- VMware: Desmarque a opção "Snapshot virtual machine's memory" e marque "Quiesce guest file system".
- Validação: Após restaurar, verifique o Event Viewer (Logs de Directory Service). Procure pelo Event ID 2170 ou 1109. Eles confirmam que a proteção foi ativada e o Pool de RID foi resetado com sucesso.
Conclusão
O snapshot de DC deixou de ser proibido para se tornar uma ferramenta útil, desde que usada com conhecimento. A tecnologia evoluiu para nos proteger, mas não substitui a estratégia correta de backup e disaster recovery.
Na dúvida: se você tem outros controladores de domínio saudáveis e um deles falhou após um restore, não lute contra a maré. Delete o servidor problemático, limpe os metadados e promova um novo. É mais rápido, mais limpo e mais seguro.