En esta entrada me gustaría explicar un poco más sobre las instantáneas de Active Directory y cómo se pueden o no se pueden utilizar.

«En primer lugar, dejemos una cosa muy clara: ¡las instantáneas de máquinas virtuales de los controladores de dominio no son compatibles!

Déjame repetirlo: si tienes un controlador de dominio virtualizado y estás pensando en hacer una instantánea de esa máquina virtual desde tu host (Hyper-V, VMware o cualquier proveedor de nube pública), ¡no lo hagas!

Puede leer aquí, según lo declarado oficialmente por Microsoft http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(WS.10).aspx

«No realices ni utilices una instantánea de un controlador de dominio virtual».

Lo mismo ocurre con la copia del disco duro virtual de un controlador de dominio, el uso de discos de diferenciación o cualquier otra función aún no inventada de retroceder en el tiempo la propia máquina virtual sin utilizar un método de copia de seguridad y restauración compatible.

Ahora, hablemos un poco sobre el porqué.

Cuando los Controladores de Dominio replican utilizan un mecanismo llamado vector de actualización para rastrear los cambios replicados.

Digamos que tenemos dos controladores de dominio DC1 y DC2, ambos DCs en el dominio corp.contoso.com. Cada uno de estos controladores de dominio tendrá un número de secuencia de actualización local (USN) que rastrea los cambios realizados en la base de datos local. Estos USN son locales y no se replican (de ahí que sean diferentes entre los dos controladores de dominio).

Piense en los USN como contadores que cuentan los cambios realizados en cada DC localmente, un ejemplo de la vida real podría ser un guardia de seguridad a la entrada de un concierto contando la gente que entra. Ahora piense que este concierto tiene dos puertas, con dos guardias de seguridad. ¿Sería el mismo número? Seguro que no.

Supongamos, pues, que nuestro DC1 tiene un USN máximo comprometido de 5.000 y que el DC2 tiene un USN máximo comprometido de 6.000. (Volviendo al ejemplo de los guardias de seguridad: el guardia n.º 1 ha contado 5.000 personas que han entrado y el guardia n.º 2 ha contado 6.000 personas que han entrado).

Entonces, ¿qué tiene que ver con el vector up to dateness? Bueno, el vector UTD mantiene una lista local en cada DC de cuál fue el USN comprometido más alto en el intento de replicación anterior. Por lo tanto, si activamos la replicación en el estado actual, después de que termine con éxito el vector UTD en DC1 mostraría:

DC2 6000

Y el Vector UTD en el DC2 se mostraría:

DC1 5000

Nota: puede visualizar el vector de actualización utilizando el comando repadmin:

Repadmin /showutdvec DCName PartitionDN

Así que, si volvemos al ejemplo de los guardias de seguridad, eso significa que, en algún momento, se llaman entre ellos y uno dice: «Oye, he contado 5.000 personas; aquí tienes sus nombres», y el otro responde: «Genial, yo he contado 6.000; aquí tienes sus nombres».

Ahora veamos qué ocurre durante una recuperación a partir de una instantánea (retroceder el servidor en el tiempo).

Supongamos que recuperamos el DC1 hasta un momento en el que su USN máximo confirmado era 3000. Ahora bien, recuerda que la tabla de vectores UTD del DC2 sigue almacenando el valor del USN máximo confirmado del DC1 como 5000. Cuando intentan replicar, el DC1 dice: «Oye, tengo cambios hasta el 3000». DC2 «lo mira con extrañeza» y dice: «Pero la última vez que replicamos, tenías cambios hasta el 5000. ¿Qué pasa?».

¿Un ejemplo con guardias de seguridad? Tras esa primera llamada, llega otra en la que el guardia de seguridad n.º 1 dice: «Oye, he contado 3.000 personas». ¿Y qué responde el guardia de seguridad n.º 2? «La última vez que hablamos dijiste que habías contado 5.000. ¿Qué pasa?».

¿Ves el problema?

Esta situación se denomina USN rollback, y en ese momento los DC dejaron de hablar entre sí y de replicar cualquier información.

¿Cómo se soluciona esto?

Cuando se realiza una restauración mediante un método compatible, el proceso de restauración modifica, de hecho, la forma en que el controlador de dominio aparece en la tabla del vector de actualidad, al cambiar el GUID de la base de datos (también denominado «InvocationID»). Las entradas del vector de actualidad no son, en realidad, nombres de controladores de dominio, sino los GUID de las bases de datos de los controladores de dominio que se están replicando para ese contexto de nomenclatura específico.

Nota: al ejecutar Repadmin /showutdvec DCName PartitionDN /nocache se mostrarán los GUIDs mencionados.

Así pues, cuando se restablece un controlador de dominio (DC) mediante un método compatible, se modifica el GUID de la base de datos; por lo tanto, el DC2 sabe que ahora ya no se replica con el DC1, sino con el DC1a (que sigue teniendo el mismo nombre de equipo, el mismo GUID de servidor, etc., pero cuenta con una base de datos de Active Directory diferente, que es lo que importa para la replicación).

Así pues, en ese caso es como si DC2 hubiera empezado a replicarse con un controlador de dominio totalmente nuevo, por lo que no se produce ninguna reversión del USN.

¡Esa es la explicación completa de por qué no se admiten las instantáneas!

Una vez aclarado esto, ¿qué son unas buenas instantáneas?

Las buenas instantáneas son las que se hacen usando el comando ntdsutil, que usa VSS bajo las capuchas para crear una instantánea de la base de datos de Active Directory. Estas instantáneas no se pueden utilizar para restaurar la base de datos (exactamente por la misma razón que se explicó anteriormente), pero se pueden montar, inspeccionar, y alguna información se puede extraer de ellos, y se inserta en la base de datos de producción por herramientas como ldifde.exe y otros, pero más en instantáneas AD en posts posteriores.

Una lección importante de este artículo. Utilice la copia de seguridad del estado del sistema para realizar copias de seguridad de los controladores de dominio y asegúrese de saber cómo restaurarlas en todos los casos posibles.