En este post vamos a ver como configurar la replicación de máquinas virtuales con ZFS local en cada nodo para tener alta disponibilidad (HA) en un cluster proxmox.

La topología utilizada sería la siguiente:

• Para configurar las réplicas de las máquinas virtuales, accedemos a la máquina que queremos replicar, que en este caso esta en el nodo pvelab02, y nos vamos a Replicación > Agregar:

• Le indicamos el nodo, en este caso, pvelab01, al que la queremos replicar, que se replique cada 15 minutos, la primera réplica es una copia completa, las siguientes son copias diferenciales, Crear:

• Y aquí vemos la tarea de replicación creada:

• Ahora, para el nodo pvelab03, agregamos otra tarea de replicación con las mismas características:

• Como podemos ver aquí, ya se ha realizado correctamente la replicación en cada uno de los nodos que le hemos indicado:

• Si accedemos a los nodos pvelab01 y pvelab03, podemos ver, que en sus datastores ZFS locales se han replicado los discos virtuales de la máquina:

• Una vez que ya tenemos las réplicas configuradas para cada nodo, ya podemos habilitar la alta disponibilidad HA para estas máquinas que se encuentran en almacenamiento local ZFS, para ello, accedemos a Centro de datos > HA > Agregar:

• Le indicamos el ID de la máquina que queremos proteger, marcar el chek de Failback y en Estado de la solicitud le indicamos que la máquina se inicie en el host al que se migre, Agregar:

• Como podemos ver, ya tenemos la máquina protegida con HA:

• Si accedemos al resumen de la máquina, podemos ver, que el Estado de HA está en started:

• Ahora, para verificar que el HA está funcionando correctamente, vamos a simular el nodo pvelab02 se nos ha caído, y que esta máquina virtual protegida por HA que está corriendo en ese nodo se migra a otro nodo del clúster:

• Como vemos, el nodo pvelab02, ya no está disponible y la máquina se ha migrado e iniciado automáticamente en otro nodo, concretamente en el nodo pvelab01:

• Aquí vemos que la máquina virtual, ahora está en el nodo pvelab01, y si nos vamos a su configuración de replicación, vemos que automáticamente, empieza a replicar en los otros nodos del clúster, tal y como estaba en el nodo pvelab02:

• Para terminar, hacemos una migración en vivo de la máquina, desde el nodo pvelab01 al nodo pvelab03, y una vez que termine, accedemos a su configuración de replicación, y vemos que automáticamente, empieza a replicar en los otros nodos del clúster:

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo realizar una conmutación por error de prueba y una conmutación por error en las réplicas de máquinas virtuales que hemos configurado entre las distintas regiones de Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a ver, es como se realiza una Conmutación por error de prueba, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error de prueba:

• Le indicamos la dirección de conmutación por error, el punto de recuperación y la red virtual, clic sobre Conmutación por error de prueba:

• Aquí vemos como se está realizando el trabajo:

• Una vez terminada la conmutación por error de prueba, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Si accedemos al Diagnóstico de arranque, podemos ver la máquina levantada:

• Una vez realizada la prueba, vamos a proceder a realizar la limpieza de la conmutación por error de prueba, para ello, accedemos al elemento replicado y sobre Información general, damos a Limpiar conmutación por error de prueba:

• Le ponemos una nota y marcamos el check de que la prueba está completa, Aceptar:

• Como vemos, la limpieza de la conmutación por error de prueba se ha realizado correctamente:

• Ahora vamos a realizar una Conmutación por error, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error:

• Nos indica la dirección de conmutación por error y el punto de recuperación, clic sobre Conmutación por error:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error:

• Como podemos ver, la conmutación por error se ha realizado correctamente:

• Una vez terminada la conmutación por error, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Si accedemos al Diagnóstico de arranque, podemos ver la máquina levantada:

• Si accedemos al almacén de recovery services > Elementos protegidos > Elementos replicados, podmeos ver que la conmutación por error está completa:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error, Confirmación:

• Aquí vemos que la confirmación ha sido correcta:

Saludos y espero que os sea de ayuda

En este post vamos a ver, cómo replicar máquinas virtuales entre dos regiones de Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vemos que tenemos en nuestro entorno cloud de Azure esta máquina virtual con dos discos, uno de sistema y otro de datos, en la región de West Europe:

• Esta máquina virtual pertenece a esta red virtual ubicada también en la región de West Europe:

• Ahora nos vamos a crear un grupo de recursos llamado replicas-az-rg, ubicado en una región diferente de dónde se encuentre la máquina virtual a replicar, en nuestro caso North Europe, en este grupo de recursos vamos a ubicar todo lo necesario para realizar las réplicas de las máquinas virtuales de Azure entre regiones:

• También nos debemos de crear una red virtual con su espacio de direcciones y con una subred en la misma región del grupo de recursos, North Europe, para cuando realicemos una conmutación por error de la réplica, podamos levantar la máquina virtual:

• Ahora nos creamos una cuenta de almacenamiento, para ello, nos vamos a Cuentas de almacenamiento > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el Grupo de recursos, el nombre de la cuenta, la Región, el Rendimiento que es nuestro caso será Estándar y la Redundancia que en nuestro caso será Almacenamiento con redundancia local (LRS):

• Sobre Avanzado, lo dejaremos todo por defecto:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Protección de datos, debemos de deshabilitar, la eliminación temporal para blobs, la eliminación temporal para contenedores y la eliminación temporal para recursos compartidos de archivos, ya que si no, cuando configuremos el almacén de recovery services nos dará error:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya la tenemos creada:

• Ahora vamos a crear un almacén de recovery services, en este mismo grupo de recursos y en la región North Europe, que se va a encargar de gestionar los puntos de recuperación y las réplicas de las máquinas virtuales, para ello, accedemos a Almacénes de Recovery Services > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el grupo de recursos, le asignamos un nombre y la región:

• Sobre Redundancia, le indicamos Redundancia local:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Propiedades del almacén, lo dejamos tal cual está, no habilitamos la inmutabilidad:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya tenemos creado este almacén de recovery services:

• Ahora accedemos al almacén de recovery services y nos vamos a Infraestructura de Site Recovery:

• Como podemos ver, tenemos para configurar todo tipo de infraestructuras, Para máquinas virtuales de Azure, que en este caso es la que nos interesa, para máquinas físicas y VMware, para System Center VMM y para sitios de Hyper-V:

• Lo primero que vamos a realizar será la Asignación de red, dónde configuraremos el origen y destino:

• Así nos quedaría:

• Ahora vamos a crear las directivas de replicación, para ello, nos vamos a Infraestructura de Site Recovery > Para máquinas físicas y VMware > Directivas de replicación > + Directiva de replicación:

• Le indicamos un Nombre y el Periodo de retención en días:

• Aquí vemos las directivas de replicación que nos hemos creado:

• Una vez definida la infraestructura de Site Recovery para máquinas virtuales de Azure, vamos a proceder a configurar las réplicas de nuestras máquinas virtuales, ara ello, accedemos a nuestro Almacén de recovery services > Elementos protegidos > Elementos replicados > Replicar > Azure Virtual Machines:

• Le indicamos el origen de la máquina virtual que queremos replicar:

• Seleccionamos la máquina virtual:

• Sobre Configuración de replicación, seleccionamos la Ubicación y grupo de recursos el grupo de recursos, la Red y subred dónde se va a ubicar la máquina virtual en caso de que tengamos que levantarla al hacer la conmutación por error, editamos la configuración del almacenamiento y las opciones de disponibilidad:

• Sobre Administrar, le indicamos la directiva de replicación, permitimos la administración por parte de ASR y no va a crear una cuenta de Automation para el proceso:

• En Revisar, nos muestra un resumen de todo lo configurado, damos a Habilitar replicación:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, podemos ver, todo lo que se ha implementado:

• Sobre el almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el Estado del proceso está en curso, en este caso, habilitando la protección, luego pasa a crear la réplica inicial, % sincronizado, esperando para el primer punto de recuperación:

• Esperamos a que el proceso termine y nos muestre el Estado como Protected, esto quiere decir, que la réplica ya la tenemos hecha y que disponemos de puntos de recuperación, para levantar la máquina virtual en Azure:

• Si accedemos al elemento replicado, información general, Puntos de recuperación más recientes, vemos que ya nos muestra los últimos cinco puntos de recuperación, también nos muestra el estado y una vista de la infraestructura de replicación:

• Sobre General > Propiedades, podemos ver, todas las propiedades del proceso de replicación configurado:

• Sobre General > Proceso, nos muestra la configuración de origen y de destino:

• Sobre General > Red, nos muestra la red de origen y de destino:

• Sobre General > Discos, vemos los discos que estamos replicando de la máquina virtual:

• Si accedemos al grupo de recursos que creamos anteriormente, podemos ver, los dos discos de réplica que se han creado:

• Sobre el grupo de recursos para las réplicas que creamos anteriormente, podemos ver la cuenta de Automation que también creamos en un paso anterior:

• Sobre el almacén de recovery services > Infraestructura de Site Recovery > Para Azure máquinas virtuales > Asignación de red, vemos las dos asignaciones que se han creado:

• Con esto, ya tendríamos configuradas las réplicas de máquinas virtuales entre distintas regiones de Azure, en el próximo post veremos cómo realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error.

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo realizar una conmutación por error de prueba y una conmutación por error en las réplicas de máquinas virtuales que hemos mandado desde VMware vSphere a Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a ver, es como se realiza una Conmutación por error de prueba, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error de prueba:

• Le indicamos la dirección de conmutación por error, el punto de recuperación y la red virtual, clic sobre Conmutación por error de prueba:

• Aquí vemos como se está realizando el trabajo:

• Una vez terminada la conmutación por error de prueba, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina levantada:

• Una vez realizada la prueba, vamos a proceder a realizar la limpieza de la conmutación por error de prueba, para ello, accedemos al elemento replicado y sobre Información general, damos a Limpiar conmutación por error de prueba:

• Le ponemos una nota y marcamos el check de que la prueba está completa, Aceptar:

• Como vemos, la limpieza de la conmutación por error de prueba se ha realizado correctamente:

• Ahora vamos a realizar una Conmutación por error, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error:

• Nos indica la dirección de conmutación por error y el punto de recuperación, clic sobre Conmutación por error:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error:

• Como podemos ver, la conmutación por error se ha realizado correctamente:

• Una vez terminada la conmutación por error, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de VMware vSphere On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error, Confirmación:

• Aquí vemos que la confirmación ha sido correcta:

• Una vez realizada la conmutación por error y confirmada, ya no vamos a poder replicar de nuevo desde VMware a Azure, para volver a proteger la máquina virtual, sobre Información general, damos a Volver a proteger, pero la protección será solo a nivel de Azure:

• Clic sobre Volver a proteger:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir para volver a proteger:

• Como podemos ver, ya la hemos vuelto a proteger:

• Y así nos quedaría, permitiéndonos sólo hacer una Conmutación por error planeada, a través de la cuál vamos a poder replicar desde Azure a nuestro entorno de VMware:

• Le indicamos que realice una Conmutación por error planeada desde Azure a VMware, Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Como podemos ver, se ha realizado correctamente:

• Ya tenemos la máquina virtual levantada en nuestro entorno on-premise de VMware:

• Y desconectada en Azure:

• Para dejarlo todo como estaba originalmente, es decir, replicando desde VMware a Azure, deshabilitamos la replicación, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Aquí deshabilitamos la replicación:

• Le indicamos el motivo y Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir al deshabilitar la réplica:

• Aquí vemos que ha finalizado correctamente:

• Si accedemos de nuevo al almacén de recovery services > Elementos protegidos > Elementos replicados vemos que ya no tenemos ninguna máquina virtual replicada:

• Si quisiéramos volver a replicarla, debemos de configurarlo todo de nuevo:

Saludos y espero que os sea de ayuda

En este post vamos a ver, cómo replicar máquinas virtuales desde un entorno on-premise con VMware vSphere a un entorno cloud con Microsoft Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vemos que tenemos nuestro servidor vCenter con dos hipervisores ESXi configurados en un cluster HA-DRS, con la máquina virtual que vamos a replicar a Azure, esta máquina tiene dos discos, uno de sistema y otro de datos:

• En Azure vamos a crear un grupo de recursos llamado replicas-vw-rg, dónde vamos a ubicar todo lo necesario para realizar las réplicas de las máquinas virtuales de VMware vSphere, en este link de este mismo blog podemos ver como se crea un grupo de recursos:

• También nos debemos de crear una red virtual con su espacio de direcciones y con una subred, para cuando realicemos una conmutación por error de la réplica, podamos levantar la máquina virtual en Azure, en este link de este mismo blog podemos ver como se crea una red virtual:

• Ahora nos creamos una cuenta de almacenamiento, para ello, nos vamos a Cuentas de almacenamiento > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el Grupo de recursos, el nombre de la cuenta, la Región, el Rendimiento que es nuestro caso será Estándar y la Redundancia que en nuestro caso será Almacenamiento con redundancia local (LRS):

• Sobre Avanzado, lo dejaremos todo por defecto:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Protección de datos, debemos de deshabilitar, la eliminación temporal para blobs, la eliminación temporal para contenedores y la eliminación temporal para recursos compartidos de archivos, ya que si no, cuando configuremos el almacén de recovery services nos dará error:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya la tenemos creada, esta cuenta de almacenamiento será usada para almacenar los datos de las réplicas y los puntos de recuperación de las máquinas virtuales:

• Ahora vamos a crear un almacén de recovery services, que se va a encargar de gestionar los puntos de recuperación y las réplicas de las máquinas virtuales, para ello, accedemos a Almacénes de Recovery Services > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el grupo de recursos, le asignamos un nombre y la región:

• Sobre Redundancia, le indicamos Redundancia local:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Propiedades del almacén, lo dejamos tal cual está, no habilitamos la inmutabilidad:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya tenemos creado este almacén de recovery services:

• Ahora accedemos al almacén de recovery services y nos vamos a Infraestructura de Site Recovery:

• Como podemos ver, tenemos para configurar todo tipo de infraestructuras, para máquinas virtuales de Azure, Para máquinas físicas y VMware, que en este caso es la que nos interesa, para System Center VMM y para sitios de Hyper-V, que ya lo vimos en un post anterior:

• Lo primero que vamos a realizar será crearnos un Dispositivo de replicación de ASR:

• Para Agregar nuevo dispositivo de replicación, vamos a elegir la opción 1, dónde nos vamos a Descargar una OVA preparada para desplegarla en nuestro vCenter:

• Como podemos ver, aquí la tenemos descargada:

• Ahora vamos a proceder a implementarla en nuestro vCenter, para ello, sobre una de nuestras carpetas de máquinas virtuales, hacemos un clic derecho e Implementar plantilla de OVF:

• Sobre Seleccione una plantilla de OVF, vamos a seleccionar el OVA de MicrosoftDRAppliance que nos hemos descargado:

• Le indicamos el nombre a la máquina virtual que va a crear:

• Seleccionamos el hipervisor dónde se va a ejecutar la máquina virtual:

• Nos muestra un resumen del despliegue que se va a realizar, ahora cambiaremos algunas cosas, como el disco de 700 GB en modo Thick Provision, que lo pasaremos a Thin Provision, para que no nos ocupe esos 700 GB en nuestra cabina de discos:

• Seleccionamos nuestro datastore en modo Thin Provision:

• Seleccionamos la red virtual dónde vamos a desplegar la máquina:

• Nos muestra un resumen de todo lo configurado y finalizamos:

• Como podemos ver en nuestro vCenter, aquí comienza el despliegue:

• Una vez finalizado el despliegue de la OVA, iniciamos la máquina virtual y accedemos por consola:

• Aceptamos el EULA:

• Introducimos las credenciales del administrador de la máquina:

• Iniciamos sesión:

• Una vez iniciada la sesión, se nos va a abrir el navegador Edge con el acceso directamente a la web del appliance para ASR Replication, como podemos ver es un Windows Server 2019 Standard, sobre la primera parte Set up prerequisites, vemos que todo está correcto, clic en Continue:

• Sobre Appliance components, vemos que todo está actualizado y no hay actualizaciones disponibles, clic en Continue:

• Sobre Select Replication appliance connectivity, salvamos la configuración, y Continue:

• Sobre Register with Recovery Services vault, le indicamos un nombre y copiamos el ASR replication appliance key de nuestro portal de Azure, clic en Login y Continue:

• Copiamos el código e iniciamos sesión en nuestro tenant de Azure:

• Nos indica que todo está correcto y podemos cerrar esta ventana:

• Como podemos ver, comienza a registrar con el almacén de recovery services:

• Aquí vemos que el registro ha sido correcto, clic en Continue:

• El siguiente paso, será añadir nuestro servidor de vCenter y las credenciales para instalar el agente de Site Recovery en las máquinas que queramos replicar:

• Añadimos nuestro servidor vCenter:

• Aquí vemos nuestro vCenter añadido:

• Ahora añadimos las credenciales para instalar el agente de Site Recovery en las máquinas que queramos replicar:

• Aquí vemos las credenciales añadidas, clic en Continue:

• Sobre Provide physical server details, no vamos a configurar nada, ya que no vamos a configurar ni replicar ningún servidor físico, clic en Continue:

• Empieza a registrar todo lo configurado:

• Como podemos ver, ya se ha completado correctamente, ya podemos administrar el appliance de ASR:

• Ahora si accedemos a nuestro portal de Azure, Almacénes de Recovery Services > replicas-vm-vault > Infraestructura de Site recovery:

• Nos vamos a Para máquinas físicas y VMware > Dispositivos de replicación de ASR, y podemos ver que ya tenemos nuestro appliance de ASR añadido:

• Y en Elementos detectados, podemos ver, que ya reconoce a nuestro vCenter de VMware:

• Sobre Directivas de replicación, nos ha creado una por defecto, luego podemos añadir y configurar las que nos interesen:

• Ahora vamos a crear una directiva de replicación, para ello, nos vamos a Infraestructura de Site Recovery > Para máquinas físicas y VMware > Directivas de replicación > + Directiva de replicación:

• Le indicamos un Nombre y el Periodo de retención en días:

• Aquí vemos la directiva de replicación creada:

• Nos vamos a crear algunas políticas más, modificando el periodo de retención, estas políticas las usaremos posteriormente sobre las réplicas de las máquinas virtuales, según el periodo de retención en días que nos interese darle:

• Una vez definida la infraestructura de Site Recovery para VMware, vamos a proceder a configurar las réplicas de nuestras máquinas virtuales de VMware, para ello, accedemos a nuestro Almacén de recovery services > Elementos protegidos > Elementos replicados > Replicar > Máquinas físicas y VMware a Azure:

• Sobre Selección de origen, seleccionamos el Tipo de máquina, el Host de vCenter y las máquinas que queremos replicar:

• Sobre Configuración de origen, seleccionamos el dispositivo de replicación, las credenciales de acceso a la máquina virtual y los discos que se van a replicar:

• Sobre Propiedades de destino, seleccionamos la suscripción, el grupo de recursos, la red y subred dónde se va a ubicar la máquina virtual en caso de que tengamos que levantarla en Azure al hacer la conmutación por error, seleccionamos la cuenta de almacenamiento en caché, los discos administrados de destino (en este caso HDD Standard) y la política de replicación:

• En Revisar, nos muestra un resumen de todo lo configurado, damos a Habilitar replicación:

• Sobre el almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el proceso está en curso:

• Si clicamos sobre el proceso, en Información general, podemos ver el estado y una vista de la infraestructura de replicación:

• Aquí podemos ver el progreso de todo el proceso:

• Accedemos de nuevo a almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el Estado se encuentra en progreso de hacer la replicación inicial:

• Como podemos ver, todo se ha ejecutado de forma correcta:

• Sobre los elementos replicados, podemos ver, que los discos empiezan a sincronizarse:

• Pasados unos minutos, podemos ver, que el Estado se encuentra en Protected, esto quiere decir que la réplica ya la tenemos hecha y que disponemos de puntos de recuperación, para levantar la máquina virtual en Azure:

• Si accedemos al elemento replicado, información general, Puntos de recuperación más recientes, vemos que ya nos muestra los últimos cinco puntos de recuperación:

• Sobre General > Propiedades, podemos ver, todas las propiedades del proceso de replicación configurado:

• Sobre General > Proceso y red, vemos las propiedades de la máquina virtual en Azure:

• Sobre General > Discos, vemos los discos que estamos replicando de la máquina virtual de VMware:

• Si accedemos al grupo de recursos que nos configuramos anteriormente, podemos ver, los dos discos de réplica que se han creado:

• Con esto, ya tendríamos configuradas las réplicas desde un entorno on-premise con VMware vSphere hacia un entorno cloud en Azure, en el próximo post veremos como realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error.

Saludos y espero que os sea de ayuda

En este post vamos a ver, cómo realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error en las réplicas de máquinas virtuales que hemos mandado desde Hyper-V a Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a ver, es como se realiza una Conmutación por error de prueba, para ello, accedemos a almacén de recovery service > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error de prueba:

• Le indicamos la dirección de conmutación por error y la red virtual, clic sobre Aceptar:

• Aquí vemos como se está realizando el trabajo:

• Una vez terminada la conmutación por error de prueba, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina levantada:

• Una vez realizada la prueba, vamos a proceder a realizar la limpieza de la conmutación por error de prueba, para ello, accedemos al elemento replicado y sobre Información general, damos a Limpiar conmutación por error de prueba:

• Le ponemos una nota y marcamos el check de que la prueba está completa, Aceptar:

• Como vemos, la limpieza de la conmutación por error de prueba se ha realizado correctamente:

• Ahora vamos a realizar una Conmutación por error planeada, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Como podemos ver, la conmutación por error planeada, se ha realizado correctamente:

• Una vez terminada la conmutación por error planeada, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de Hyper-V On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Ahora, para volver a dejar todo como estaba, es decir, que la máquina virtual replique desde el entorno on-premise de Hyper-V a Azure, debemos de hacer otra conmutación por error planeada, para ello, en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, que ahora es al contrario que antes, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, como se está realizando la conmutación por error en sentido inverso, y todos los cambios que se hayan hecho en la máquina virtual levantada en Azure, se van a aplicar a la máquina virtual on-premise:

• Cuando nos salga este aviso, debemos de Completar la conmutación por error:

• Le indicamos que Sí:

• Como podemos ver, la conmutación por error planeada en el sentido inverso, se ha realizado correctamente:

• Vemos que la máquina virtual en Azure se ha detenido:

• Y se está ejecutando de nuevo, en nuestro entorno on-premise de Hyper-V:

• Para terminar, en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Como podemos ver, si accedemos al grupo de recursos donde se ubicaba la máquina virtual que habíamos levantado en Azure tras la conmutación por error planeada, esta máquina ha desaparecido, tras la confirmación:

• Una vez confirmada, debemos de habilitar la replicación inversa, para ello, nos vamos al Elemento replicado > Información general > … > Replicación inversa y Aceptar:

• Como podemos ver, todo nos ha quedado como estaba originalmente en Azure:

• Como podemos ver, todo nos ha quedado como estaba originalmente en on-premise Hyper-V:

• Ahora vamos a suponer, que nuestra máquina virtual principal en el servidor on-premise de Hyper-V, no nos inicia, por el motivo que sea, vemos que esta apagada:

• Vamos a realizar entonces una Conmutación por error, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error:

• Nos indica la dirección de conmutación por error, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error:

• Como podemos ver, la conmutación por error se ha realizado correctamente:

• Una vez terminada la conmutación por error, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de Hyper-V On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Ahora, para volver a dejar todo como estaba, es decir, que la máquina virtual replique desde el entorno on-premise de Hyper-V a Azure, debemos de hacer otra conmutación por error planeada, para ello, en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, que ahora es al contrario que antes, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, como se está realizando la conmutación por error en sentido inverso, y todos los cambios que se hayan hecho en la máquina virtual levantada en Azure, se van a aplicar a la máquina virtual on-premise:

• Cuando nos salga este aviso, debemos de Completar la conmutación por error:

• Le indicamos que Sí:

• Como podemos ver, la conmutación por error planeada en el sentido inverso, se ha realizado correctamente:

• Vemos que la máquina virtual en Azure se ha detenido:

• Y se está ejecutando de nuevo, en nuestro entorno on-premise de Hyper-V:

• Para terminar, en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Como podemos ver, si accedemos al grupo de recursos donde se ubicaba la máquina virtual que habíamos levantado en Azure tras la conmutación por error planeada, esta máquina ha desaparecido, tras la confirmación:

• Una vez confirmada, debemos de habilitar la replicación inversa, para ello, nos vamos al Elemento replicado > Información general > … > Replicación inversa y Aceptar:

• Como podemos ver, todo nos ha quedado como estaba originalmente en Azure:

• Como podemos ver, todo nos ha quedado como estaba originalmente en on-premise Hyper-V:

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo replicar máquinas virtuales desde un entorno on-premise con Hyper-V a un entorno cloud con Microsoft Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vemos que tenemos nuestro servidor de Hyper-V con la máquina virtual que vamos a replicar a Azure, esta máquina tiene dos discos, uno de sistema y otro de datos:

• En Azure vamos a crear un grupo de recursos llamado replicas-hv-rg, dónde vamos a ubicar todo lo necesario para realizar las réplicas de las máquinas virtuales de Hyper-V, en este link de este mismo blog, podemos ver como se crea un grupo de recursos:

• También nos debemos de crear una red virtual con su espacio de direcciones y con una subred, para cuando realicemos una conmutación por error de la réplica, podamos levantar la máquina virtual en Azure, en este link de este mismo blog, podemos ver como se crea una red virtual:

• Ahora nos creamos una cuenta de almacenamiento, para ello, nos vamos a Cuentas de almacenamiento > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el Grupo de recursos, el nombre de la cuenta, la Región, el Rendimiento que es nuestro caso será Estándar y la Redundancia que en nuestro caso será Almacenamiento con redundancia local (LRS):

• Sobre Avanzado, lo dejaremos todo por defecto:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Protección de datos, debemos de deshabilitar, la eliminación temporal para blobs, la eliminación temporal para contenedores y la eliminación temporal para recursos compartidos de archivos, ya que si no, cuando configuremos el almacén de recovery services nos dará error:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya la tenemos creada, esta cuenta de almacenamiento será usada para almacenar los datos de las réplicas y los puntos de recuperación de las máquinas virtuales:

• Ahora vamos a crear un almacén de recovery services, que se va a encargar de gestionar los puntos de recuperación y las réplicas de las máquinas virtuales, para ello, accedemos a Almacénes de Recovery Services > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el grupo de recursos, le asignamos un nombre y la región:

• Sobre Redundancia, le indicamos Redundancia local:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Propiedades del almacén, lo dejamos tal cual está, no habilitamos la inmutabilidad:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya tenemos creado este almacén de recovery services:

• Ahora accedemos al almacén de recovery services y nos vamos a Infraestructura de Site Recovery:

• Como podemos ver, tenemos para configurar todo tipo de infraestructuras, para máquinas virtuales de Azure, máquinas físicas, máquinas de VMware (que lo vamos a ver en otro post), para System Center VMM, y la que nos interesa a nosotros en estos momentos que son Para sitios de Hyper-V:

• Lo primero que vamos a realizar será crearnos un Sitio de Hyper-V, donde le indicamos un nombre:

• Como vemos, ya tenemos creado el sitio:

• Lo siguiente será, agregar un host de Hyper-V, para ello nos vamos a Hosts de Hyper-V > Agregar servidor:

• Aquí se nos muestran todos los pasos para agregar el host de Hyper-V:

• Los dos primeros pasos, los cumplimos, procedemos por tanto a descargar el instalador del proveedor de Microsoft Azure Site Recovery (paso 3) y a descargar la clave de registro del almacén para registrar el host en un sitio de Hyper-V (paso 4):

• Una vez descargados, sobre nuestro servidor de Hyper-V vamos a proceder a instalar el proveedor de Microsoft Azure Site Recovery usando la clave de registro del almacén para registrar el servidor en el almacén (paso 5).
• Activamos las actualizaciones de Microsoft update:

• Damos a instalar:

• Comienza el proceso de instalación:

• Aquí vemos que ha finalizado correctamente, ahora procedemos a registrar el servidor en el almacén de recovery services de Azure, clic en Registrarse:

• Sobre Configuración del almacén, añadimos el Archivo de clave:

• Sobre Configuración de proxy, le indicamos que nos vamos a conectar directamente con Azure Site Recovery sin un servidor proxy:

• Comienza con el registro:

• Pasados unos minutos, ya tenemos nuestro servidor de Hyper-V registrado en nuestro almacén de recovery services de Azure, finalizamos:

• Para verificar que todo está correcto, nos vamos a nuestro almacén de recovery services en Azure, a la parte de Infraestructura de Site Recovery > Hosts de Hyper-V, y vemos que nos aparece como un servidor registrado y en estado Conectado:

• Ahora vamos a crear una directiva de replicación, para ello, nos vamos a Infraestructura de Site Recovery > Directivas de replicación > + Directiva de replicación:

• Le indicamos un Nombre, el tipo de origen que será Hyper-V, el tipo de destino que será Azure, la frecuencia de copia, retención de puntos de recuperación en horas, la frecuencia de instantáneas coherentes a nivel de aplicación y la hora de inicio de la replicación inicial:

• Aquí vemos la directiva de replicación creada:

• Una vez creada, la tenemos que asociar al sitio de Hyper-V:

• Como podemos ver, ya está asociada:

• Una vez definida la infraestructura de Site Recovery para Hyper-V, vamos a proceder a configurar las réplicas de nuestras máquinas virtuales de HyperV, para ello, accedemos a nuestro Almacén de recovery services > Elementos protegidos > Elementos replicados > Replicar > Máquinas de Hyper-V a Azure:

• Sobre Entorno de origen, seleccionamos el sitio de Hyper-V que nos creamos anteriormente:

• Sobre Entorno de destino, seleccionamos la suscripción, el grupo de recursos, el modelo de implementación, el tipo de almacenamiento y la red dónde se va a ubicar la máquina virtual en caso de que tengamos que levantarla en Azure al hacer la conmutación por error:

• Sobre el Tipo de almacenamiento debemos de hacer una aclaración, ya que vamos a usar un disco administrado (esta opción es nueva), esto no era posible usarlo antes, y teníamos que hacerlo con una cuenta de almacenamiento, de ahí que anteriormente nos creásemos esa cuenta, si usamos un discos administrados no hace falta crearnos la cuenta de almacenamiento:

• Sobre Selección de la máquina virtual, seleccionamos las máquinas que nos interesen:

• Sobre Configuración de replicación, seleccionamos el tipo de sistema operativo, el disco del sistema operativo, los discos a replicar, en este caso replicamos los dos discos que tiene la máquina virtual, le indicamos el tipo de disco administrado y la cuenta de almacenamiento en caché:

• En Directiva de replicación, seleccionamos la directiva que nos creamos anteriormente:

• En Revisar, nos muestra un resumen de todo lo configurado, damos a Habilitar replicación:

• Sobre el almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el proceso está en curso:

• Si clicamos sobre el proceso, en Información general, podemos ver el estado y una vista de la infraestructura de replicación:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver que la réplica inicial está en proceso:

• Sobre el servidor de Hyper-V, y la máquina virtual a replicar > Replicación > Ver mantenimiento de la replicación, podemos ver, que la réplica se está realizando correctamente:

• Accedemos de nuevo a almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el Estado se encuentra esperando el primer punto de recuperación:

• Pasados unos minutos, podemos ver, que el Estado se encuentra en Protected, esto quiere decir que la réplica ya la tenemos hecha y que disponemos de puntos de recuperación, para levantar la máquina virtual en Azure:

• Si accedemos al elemento replicado, información general, Puntos de recuperación más recientes, vemos que ya nos muestra los últimos cinco puntos de recuperación:

• Sobre General > Propiedades, podemos ver, todas las propiedades del proceso de replicación configurado:

• Sobre General > Proceso y red, vemos las propiedades de la máquina virtual en Azure:

• Sobre General > Discos, vemos los discos que estamos replicando de la máquina virtual de Hyper-V:

• Si accedemos al grupo de recursos que nos configuramos anteriormente, podemos ver, los dos discos de réplica que se han creado:

• Con esto, ya tendríamos configuradas las réplicas desde un entorno on-premise con Hyper-V hacia un entorno cloud en Azure, en el próximo post veremos como realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error.

Saludos y espero que os sea de ayuda

En este post vamos a ver como iniciar la conmutación por error en las réplicas de nuestras máquinas virtuales en caso de fallo crítico en uno de nuestros hypervisores de Hyper-V.

• Tenemos dos hipervisores de Hyper-V con la replicación habilitada en ambos sentidos:

• Vamos a suponer que nos falla el Servidor Principal, por ejemplo, por un fallo de RAM o CPU y no podemos levantar la máquina virtual, entonces nos debemos de ir al Servidor de Réplicas y habilitar la Conmutación por error:

• Le indicamos el punto de restauración que vamos a utilizar y pulsamos sobre Conmutación por error:

• Una vez aplicada la conmutación por error, podemos ver que la máquina se inicia sin problemas, crea un punto de control que eliminará cuando invirtamos la replicación y el estado de la replicación nos muestra que ha completado la conmutación por error:

• Ahora se supone que estamos trabajando sobre el Servidor principal para solucionar nuestros problemas con el hardware y una vez solucionado iniciamos nuestro hypervisor y nos encontramos la máquina en el siguiente estado, la máquina apagada y con errores en el estado de la replicación:

• Lo que vamos a realizar ahora será irnos al Servidor de réplicas e invertir la replicación, lo que conseguimos con este proceso es que todos los cambios que se han realizado en la máquina virtual durante la conmutación por error, se le van a pasar a la máquina que se encuentra en el servidor principal y una vez terminado el proceso los hypervisores van a intercambiar sus roles, es decir, el que era servidor de réplicas se va a convertir en el servidor principal y el principal pasará ahora a ser el de réplicas:

• Se nos abrirá, este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor que va a pasar a ser el servidor de réplicas:

• Especificamos los parámetros de conexión, en este caso, los dos servidores de réplicas autentican por Kerberos ya que estas dos máquinas pertenecen al mismo dominio de Active Directory, si estuviésemos en un grupo de trabajo utilizando certificados, entonces seleccionamos la opción basada en certificados:

• Configuramos la frecuencia de la replicación:

• Le indicamos los puntos de control que queremos mantener:

• Sobre el método de replicación inicial, seleccionamos la opción que Use una máquina virtual existente en el servidor de réplicas como copia inicial:

• Nos muestra un resumen y finalizamos:

• Como podemos ver, comienza a enviar la réplica inicial y los servidores han intercambiado los roles:

• Una vez finalizada la replicación inicial, podemos ver que todo está correcto:

• Ahora si queremos dejar todo como estaba al principio, es decir, el servidor Hyperv03 como principal y el servidor Hyperv04 como réplicas, lo primero que tenemos que hacer es Apagar la máquina virtual en el servidor principal, en este caso, HyperV04:

• Y volvemos a repetir todo el proceso ya explicado de conmutación por error:

• Una vez finalizado, podemos ver que ya está todo como lo teníamos al principio:

Saludos y espero que os sea de ayuda

En este post vamos a ver como se crean y configuran los trabajos de réplicas en Veeam Backup & Replication 10a, vamos a explicar un poco la infraestructura que tenemos y cómo vamos a configurar las réplicas de las máquinas virtuales.

• Tenemos dos hosts ESXi en producción configurados en Cluster HA y DRS, dónde se alojan y ejecutan nuestras máquinas virtuales, las réplicas que configuremos con el Veeam Backup & Replication las vamos a mandar a un host esxi independiente, está dentro de nuestro datacenter, pero fuera del clúster de producción:

• El host esxi independiente tiene montado un datastore que solo puede ser visualizado por él, en este datastore vamos a alojar las réplicas de las máquinas virtuales:

• Tenemos una máquina virtual con Windows Server 2019 Standard y con el Veeam Backup & Replication instalado, dónde vamos a configurar las réplicas de las máquinas virtuales:

• Ahora vamos a acceder a nuestra consola de Veeam Backup & Replication, y empezaremos creando un trabajo de réplicas para los controladores de dominio, para ello, nos vamos a HOME > Replication Job > Virtual Machine:

• Se nos abre el siguiente asistente, y sobre Name le damos un nombre, una descripción y habilitamos el check para separar la red virtual de producción de la red virtual de replicación:

• Sobre Virtual Machines, añadimos las máquinas virtuales que queremos replicar:

• En Destination, escogemos el destino y el datastore donde se ubicarán las réplicas, en este caso, hemos escogido el host esxi y el datastore que hemos montado y configurado para alojar las réplicas de nuestra infraestructura:

• En Network, añadimos la red de origen y la red de destino, en mi caso es la misma red:

• Sobre Job Settings, seleccionamos el repositorio para los metadatos de la réplica, le indicamos un sufijo para el nombre de la máquina virtual replicada, los puntos de restauración que vamos a mantener, y en opciones avanzadas, sobre Traffic vamos a optimizar el almacenamiento como local, ya que el repositorio para los metadatos está ubicado en la propia máquina del Veeam:

• Sobre Data Transfer, lo dejamos por defecto:

• En la opción Guest Processing, podemos habilitar el check Enable application-aware processing, que preparará las aplicaciones para un backup consistente y procesará los logs de transacciones para servidores MS Exchange, MS SQL y Oracle, en nuestro caso no habilitamos esta opción:

• En la opción Schedule, vamos a programar la tarea para este trabajo de réplica, hemos programado esta tarea para que la realice una vez a la semana (sábado a las 17:00), y si falla la tarea que realice tres intentos esperando 10 minutos entre cada intento, aplicamos los cambios:

• En Summary, nos muestra un resumen de todas las opciones que hemos configurado, clic sobre finalizar:

• Como podemos ver ya tenemos el Replication Job creado y configurado:

• Para los demás Replications Jobs realizaremos las mismas configuraciones que para este último, y cómo podemos ver ya tenemos tres trabajos creados y configurados:

• Aquí vemos que todos los Replication Jobs se han realizado correctamente:

• Y aquí vemos las réplicas realizadas con sus puntos de restauración:

• Sobre nuestro vCenter podemos ver las réplicas creadas:

Saludos y espero que os resulte de ayuda

En los próximos posts vamos a ver una serie dedicada al magnífico producto Veeam ONE en su última versión 10a.

Veeam ONE forma parte de Veeam Availability Suite junto con Veeam Backup & Replication, y nos proporciona una solución integral para monitorizar y analizar nuestro entorno de virtualización, ya sea VMware vSphere o Microsoft Hyper-V configurado con Veeam Backup & Replication (Veeam ONE Monitor), junto con una solución para obtener reportes e informes bastante completos sobre el estado de nuestra infraestructura (Veeam ONE Reporter).

Estos post los vamos a dividir en:

• Veeam ONE 10a – Instalación
• Veeam ONE 10a – Añadir un entorno VMware vSphere 6.7
• Veeam ONE 10a – Configuración de opciones y notificaciones
• Veeam ONE 10a – Añadir un entorno Veeam Backup & Replication v10a
• Veeam ONE 10a – Veeam ONE Reporter

Saludos.

Hyper-V Réplicas es una opción del rol de Hyper-V para replicar máquinas virtuales de un Servidor a otro Servidor.

El principal uso que se le da es para la recuperación rápida ante desastres, como puede ser el fallo de un servidor, de forma que el sistema pueda volver a ponerse en funcionamiento de forma rápida en el entorno de respaldo.

No proporciona una solución de alta disponibilidad, dado que ante una caída de los servidores de producción:

• Se perderán los últimos datos almacenados, dependiendo de la frecuencia de replicación asíncrona y su duración
• La reactivación del sistema en los servidores de respaldo se realizará de forma manual por parte de un operador

Tampoco es una solución de backup, dado que no protege de corrupción de datos, fallos en actualizaciones, o errores humanos, que se distribuirán también a las réplicas.

CARACTERÍSTICAS

Las principales características de Hyper-V Replicas son:

• Replica asíncrona de máquinas virtuales entre servidores Hyper-V
  • Frecuencia programable
  • Soporta la exclusión de discos (VHDX)
  • Replica extendida (a un tercer nivel de respaldo)
  • Soporte de VSS para la consistencia de los datos de aplicaciones
  • Almacenamiento de múltiples puntos de recuperación
  • Varios mecanismos para la primera réplica
• Almacenamiento
  • No requiere almacenamiento compartido ni hardware especial
• Comunicaciones
  • Comunicación a nivel IP entre servidores
  • Se puede realizar réplicas a través de LAN o WAN
  • Permite el cifrado y compresión de las comunicaciones
• Requisitos Windows
  • Mínimo Windows server 2012 R2
  • No es necesario que los equipos estén dentro de un dominio o cluster, pero pueden formar parte de dominios distintos
  • Soporte de broker de réplica si se usa cluster

• Lo primero que vamos a realizar será empezar a preparar nuestras máquinas, esta parte de la preparación ya la hemos visto en un post anterior, por lo tanto, podemos seguir este enlace.
• Hemos preparado en ambos servidores.
• El rol de Hyper-V:

• NIC Teaming para la red LAN:

• Configuramos los conmutadores virtuales en ambas máquinas:

• Asignación de direccionamiento IP a la red LAN:

• Una vez que tenemos nuestros servidores preparados con las configuraciones iniciales, vamos a habilitar la siguiente regla en el firewall de Windows de ambos servidores de Hyper-V:

• Los dos equipos Hyper-V deberán tener un nombre DNS que se pueda resolver desde el otro servidor, y no debe cambiarse tras la generación de los certificados autofirmados, que los vamos a generar en un paso posterior, para ello, será necesario añadir en cada servidor su IP y su nombre completo; y los del otro servidor, mediante el fichero hosts ubicado en C:\Windows\System32\Drivers\etc\hosts:

• Una vez configurado confirmar que se pueden hacer ping el uno al otro usando el nombre:

• Como estamos trabajando en un entorno de trabajo en grupo, hay que configurar las credenciales de autenticación y certificados digitales.
• Para establecer las credenciales, desde la consola de sistema con privilegios de administrador, ejecutamos el comando siguiente, sustituyendo el nombre del servidor y el usuario por el que corresponda en cada caso.
• Para el servidor Hyperv01, cmdkey /add:hyperv02 /user:hyperv02\administrador /pass:mipassword

• Para el servidor Hyperv02, cmdkey /add:hyperv01 /user:hyperv01\administrador /pass:mipassword

• Ahora vamos a generar los certificados autofirmados para ambos servidores de Hyper-V.
• Lo primero que debemos hacer es obtener la herramienta makecert que viene incluida en «Windows Software Development Kit (SDK) for Windows 8», pero para facilitaros este tema y no tener que descargar el paquete completo y su posterior despliegue en un equipo, en este link os dejo el makecert.
• Nos creamos el directorio C:\PKI en ambos servidores e incluimos el ejecutable makecert que nos hemos descargado:

• En el primer servidor llamado hyperv01 vamos a lanzar una consola CMD como administrador y ejecutaremos los siguientes comandos:
  • cd C:\PKI
  • .\makecert -pe -n «CN=PrimaryRootCA» -ss root -sr LocalMachine -sky signature -r «PrimaryRootCA.cer»
  • .\makecert -pe -n «CN=hyperv01» -ss my -sr LocalMachine -sky exchange -eku «1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2» -in «PrimaryRootCA» -is root -ir LocalMachine -sp «Microsoft RSA SChannel Cryptographic Provider» -sy 12 PrimaryCert.cer

• De igual forma, pero en el segundo servidor llamado hyperv02:
  • cd C:\PKI
  • .\makecert -pe -n «CN=ReplicaRootCA» -ss root -sr LocalMachine -sky signature -r «ReplicaRootCA.cer»
  • .\makecert -pe -n «CN=hyperv02» -ss my -sr LocalMachine -sky exchange -eku «1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2» -in «ReplicaRootCA» -is root -ir LocalMachine -sp «Microsoft RSA SChannel Cryptographic Provider» -sy 12 ReplicaCert.cer

• Copiar desde el servidor hyperv02 al servidor hyperv01 el archivo «ReplicaRootCA.cer» ubicado en C:\PKI, copiarlo en la misma ruta:

• En el servidor hyperv01 ejecutamos el siguiente comando, certutil -addstore -f root ReplicaRootCA.cer:

• Copiar desde el servidor hyperv01 al servidor hyperv02 el archivo «PrimaryRootCA.cer» ubicado en C:\PKI, copiarlo en la misma ruta:

• En el servidor hyperv02 ejecutamos el siguiente comando, certutil -addstore -f root PrimaryRootCA.cer:

• Para terminar con el tema de los certificados autofirmados, en ambos servidores desactivamos la comprobación de certificados revocados, ejecutando, reg add «HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication» /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

• Ahora vamos a configurar nuestros servidores Hyper-V Replicas, en este caso, vamos a configurar los dos servidores con la función de Réplicas, así vamos a poder replicar nuestras máquinas virtuales en ambos sentidos, para ello editamos la configuración de Hyper-V:

• Sobre la configuración de Hyper-V en ambos servidores, nos vamos a la opción de Configuración de replicación Habilitado como servidor de réplicas, marcamos el check para habilitarlo y usamos Usar autenticación basada en certificados (HTTPS) sobre el puerto 10443, no utilizamos el puerto 443 ya que si tenemos otro servicio corriendo en este mismo puerto, como pudiera ser un IIS, las réplicas no se van a poder configurar, seleccionamos los certificados autofirmados que hemos generado anteriormente y permitimos la replicación desde cualquier servidor autenticado:

• Aquí nos indica que debemos tener configurado en el firewall de Windows la siguiente regla de entrada:

• Con esto ya tendríamos configurado nuestros dos servidores para replicar máquinas virtuales entre sí.
• Ahora vamos a ver como replicar las máquinas virtuales desde el servidor HYPERV01 al servidor HYPERV02, para ello, desde la consola de Hyper-V, damos clic derecho sobre la máquina que queremos replicar, y Habilitar replicación:

• Se nos abrirá este asistente, clic en siguiente para continuar:

• Especificamos el servidor de réplicas:

• Especificamos los parámetros de conexión:

• Seleccionamos los discos duros virtuales que vamos a replicar:

• Configuramos la frecuencia de la replicación:

• Configuramos el punto de recuperación más reciente:

• Elegimos el método de replicación inicial:

• Nos muestra un resumen y finalizamos:

• Sobre la pestaña replicación de la máquina virtual tenemos todos los datos del estado de la réplica:

• Aquí tenemos la máquina replicada en el servidor HYPERV02, la máquina virtual replicada no la podemos iniciar, pero si podemos exportarla y crear una nueva máquina:

• Sobre la máquina virtual replicada, si damos botón derecho Replicación, tenemos distintas opciones para trabajar con nuestras réplicas:

• Conmutación por error, nos indica que no debemos de realizar esta tarea a menos que se produzca un error en la máquina virtual principal, si realizamos una conmutación por error planeada, debemos cancelar y usar la tarea de conmutación por error planeada en la máquina virtual principal, y si no es planeada, porque ya tengamos la máquina virtual principal averiada, podemos proseguir con el proceso.

• Conmutación por error planeada, esta opción sólo está disponible en el servidor que alberga la máquina virtual principal, y debe estar apagada, esta opción va a iniciar la réplica en el otro servidor, si marcamos el check Invertir la dirección de la replicación después de la conmutación por error, todos los cambios realizados en la máquina de réplicas se van a replicar a la máquina principal:

• Probar conmutación por error, nos va a crear una nueva máquina virtual a partir de la réplica que tenemos realizada y así podemos verificar que la réplica es correcta:

• Pausar replicación, podemos para momentáneamente la réplica.
• Extender replicación, podemos replicar la réplica en otro servidor de réplicas:

• Ver mantenimiento de la replicación, podemos ver las estadísticas y estado de la réplica:

• Quitar replicación, le indicamos que esta réplica se va a convertir en una máquina principal y se eliminará la replicación desde la máquina original o principal.

Saludos y espero que os sea de ayuda

Hyper-V Réplicas es una opción del rol de Hyper-V para replicar máquinas virtuales de un Servidor a otro Servidor.

El principal uso que se le da es para la recuperación rápida ante desastres, como puede ser el fallo de un servidor, de forma que el sistema pueda volver a ponerse en funcionamiento de forma rápida en el entorno de respaldo.

No proporciona una solución de alta disponibilidad, dado que ante una caída de los servidores de producción:

• Se perderán los últimos datos almacenados, dependiendo de la frecuencia de replicación asíncrona y su duración
• La reactivación del sistema en los servidores de respaldo se realizará de forma manual por parte de un operador

Tampoco es una solución de backup, dado que no protege de corrupción de datos, fallos en actualizaciones, o errores humanos, que se distribuirán también a las réplicas.

CARACTERÍSTICAS

Las principales características de Hyper-V Replicas son:

• Replica asíncrona de máquinas virtuales entre servidores Hyper-V
  • Frecuencia programable
  • Soporta la exclusión de discos (VHDX)
  • Replica extendida (a un tercer nivel de respaldo)
  • Soporte de VSS para la consistencia de los datos de aplicaciones
  • Almacenamiento de múltiples puntos de recuperación
  • Varios mecanismos para la primera réplica
• Almacenamiento
  • No requiere almacenamiento compartido ni hardware especial
• Comunicaciones
  • Comunicación a nivel IP entre servidores
  • Se puede realizar réplicas a través de LAN o WAN
  • Permite el cifrado y compresión de las comunicaciones
• Requisitos Windows
  • Mínimo Windows server 2012 R2
  • No es necesario que los equipos estén dentro de un dominio o cluster, pero pueden formar parte de dominios distintos
  • Soporte de broker de réplica si se usa cluster

TOPOLOGÍA

• Lo primero que vamos a realizar será empezar a preparar nuestras máquinas, esta parte de la preparación ya la hemos visto en un post anterior, por lo tanto, podemos seguir este enlace.
• Hemos preparado en ambos servidores.
• El rol de Hyper-V:

• NIC Teaming para la red LAN:

• Configuramos los conmutadores virtuales en ambas máquinas:

• Asignación de direccionamiento IP a la red LAN:

• Unimos las dos máquinas a nuestro dominio de Active Directory:

• Una vez que tenemos nuestros servidores preparados con las configuraciones iniciales, vamos a configurar nuestros servidores Hyper-V Replicas, en este caso, vamos a configurar los dos servidores con la función de Réplicas, así vamos a poder replicar nuestras máquinas virtuales en ambos sentidos, para ello editamos la configuración de Hyper-V:

• Sobre la configuración de Hyper-V, nos vamos a la opción de Configuración de replicación Habilitado como servidor de réplicas, marcamos el check para habilitarlo y usamos el protocolo de autenticación de red Kerberos sobre HTTP puerto 80, utilizamos Kerberos ya que estos dos servidores están unidos a un dominio de Active Directory, los datos enviados a través de la red no se cifrarán, si estuviésemos trabajando sobre un entorno de Grupo de trabajo, la única forma de poder replicar las máquinas, es usando la autenticación basada en certificados HTTPS puerto 443, dónde los datos enviados a través de la red se cifrarán:

• También debemos agregar el servidor o los servidores autorizados para enviar las réplicas de las máquinas virtuales:

• Aplicamos y Aceptamos los cambios:

• Aquí nos indica que debemos tener configurado en el firewall de Windows la siguiente regla de entrada:

• Configuramos el firewall de nuestros servidores de Hyper-V, con las reglas que nos ha indicado la advertencia al habilitar el servidor de réplicas:

• Con esto ya tendríamos configurado nuestros dos servidores para replicar máquinas virtuales entre sí.
• Desde el servidor HYPERV03, vamos a ejecutar este comando Test-VMReplicationConnection Hyperv04 80 Kerberos para verificar que podemos enviar réplicas al servidor HYPERV04:

• Desde el servidor HYPERV04, vamos a ejecutar este comando Test-VMReplicationConnection Hyperv03 80 Kerberos para verificar que podemos enviar réplicas al servidor HYPERV03:

• Ahora vamos a ver como replicar las máquinas virtuales desde el servidor HYPERV03 al servidor HYPERV04, para ello, desde la consola de Hyper-V, damos clic derecho sobre la máquina que queremos replicar, y Habilitar replicación:

• Se nos abrirá este asistente, clic en siguiente para continuar:

• Especificamos el servidor de réplicas:

• Especificamos los parámetros de conexión:

• Seleccionamos los discos duros virtuales que vamos a replicar:

• Configuramos la frecuencia de la replicación:

• Configuramos el punto de recuperación más reciente:

• Elegimos el método de replicación inicial:

• Nos muestra un resumen y finalizamos:

• Aquí podemos ver cómo está enviando la réplica y el porcentaje del trabajo:

• Sobre la pestaña replicación de la máquina virtual tenemos todos los datos del estado de la réplica:

• Aquí tenemos la máquina replicada en el servidor HYPERV04, la máquina virtual replicada no la podemos iniciar, pero si podemos exportarla y crear una nueva máquina:

• Sobre la máquina virtual replicada, si damos botón derecho Replicación, tenemos distintas opciones para trabajar con nuestras réplicas:

• Conmutación por error, nos indica que no debemos de realizar esta tarea a menos que se produzca un error en la máquina virtual principal, si realizamos una conmutación por error planeada, debemos cancelar y usar la tarea de conmutación por error planeada en la máquina virtual principal, y si no es planeada, porque ya tengamos la máquina virtual principal averiada, podemos proseguir con el proceso.

• Conmutación por error planeada, esta opción sólo está disponible en el servidor que alberga la máquina virtual principal, y debe estar apagada, esta opción va a iniciar la réplica en el otro servidor, si marcamos el check Invertir la dirección de la replicación después de la conmutación por error, todos los cambios realizados en la máquina de réplicas se van a replicar a la máquina principal:

• Probar conmutación por error, nos va a crear una nueva máquina virtual a partir de la réplica que tenemos realizada y así podemos verificar que la réplica es correcta:

• Pausar replicación, podemos parar momentáneamente la réplica.
• Extender replicación, podemos replicar la réplica en otro servidor de réplicas:

• Ver mantenimiento de la replicación, podemos ver las estadísticas y estado de la réplica:

• Quitar replicación, le indicamos que esta réplica se va a convertir en una máquina principal y se eliminará la replicación desde la máquina original o principal.

Saludos y espero que os sea de ayuda

En este post vamos a ver como actualizar nuestro software de backup y replicación Vembu BDR Suite de la versión 4.0 a la nueva release, v4.0.1, en este link podemos encontrar toda la información sobre esta nueva versión.

• Lo primero que vamos a realizar será descargarnos la nueva release Vembu BDR Suite 4.0.1 desde la web oficial de Vembu:

• Como podemos ver ya la tenemos descargada:

• Damos doble clic sobre el “.exe” descargado y se nos abre el siguiente asistente de instalación, clic sobre “siguiente”:

• Aceptamos los términos de licencia:

• Clic sobre instalar:

• Nos indica que tenemos corriendo otra versión de Vembu BDR y que el proceso de instalación la va a parar para comenzar con el upgrade, le indicamos que “Sí”:

• Como podemos ver la actualización ha comenzado:

• Aquí vemos que el upgrade ha finalizado correctamente, clic en “finalizar”:

• Como podemos ver el servidor Vembu BDR está en ejecución:

• Accedemos a la consola web, con las credenciales que ya teníamos configurada:

• Como podemos ver ya tenemos actualizada la Suite de Vembu con las mismas configuraciones que teníamos en la anterior versión, listos para seguir con las tareas programadas:

• Desde el portal web para clientes de Vembu, podemos ver que la suite está actualizada a la versión 4.0.1:

Post sponsorizado por Vembu Technologies

En este post vamos a ver como solucionar el error 9061 que tiene como ID de evento 4012, este error se produce ya que la carpeta SYSVOL, no se está replicando entre los controladores de dominio de la infraestructura, debido a que han pasado más de 60 días desde la última vez que esta carpeta de SYSVOL se replicó entre los controladores.

• En el visor de eventos de los controladores de dominio, sobre “Registro de aplicaciones y servicios > Replicación DFS” veremos este error:

• Para solucionar este error nos abrimos un cmd con permisos de administrador en cada controlador de domino de nuestra infraestructura e introducimos el siguiente comando “wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=365”, con este comando se ponen los contadores a cero y aumentamos a 365 días el tiempo que pueden estar sin conexión los controladores de domino:

• A partir de la aplicación del comando, la carpeta SYSVOL empezará a replicar entre los controladores de dominio, como bien podemos ver aquí, en el visor de eventos:

Saludos y espero que os sea de ayuda

En este post vamos a ver como actualizar nuestro software de backup y replicación Vembu BDR Suite de la versión 3.9.1 Update1 a la nueva release, liberada en diciembre de 2018, v4.0, en este link podemos encontrar toda la información sobre esta nueva versión.

Recordemos la topología configurada:

• Lo primero que vamos a realizar será descargarnos la nueva release Vembu BDR Suite 4.0 desde la web oficial de Vembu:

• Como podemos ver ya la tenemos descargada:

• Damos doble clic sobre el “.exe” descargado y se nos abre el siguiente asistente de instalación, clic sobre “siguiente”:

• Aceptamos los términos de licencia:

• Aquí nos indica que vamos a realizar un upgrade y el sistema va a realizar algunas modificaciones sobre los trabajos de backups, le indicamos que “Sí”:

• Clic sobre instalar:

• Nos indica que tenemos corriendo otra versión de Vembu BDR y que el proceso de instalación la va a parar para comenzar con el upgrade, le indicamos que “Sí”:

• Como podemos ver la actualización ha comenzado:

• Aquí vemos que el upgrade ha finalizado correctamente, clic en “finalizar”:

• Como podemos ver el servidor Vembu BDR está en ejecución:

• Accedemos a la consola web, con las credenciales que ya teníamos configurada:

• Como podemos ver ya tenemos actualizada la Suite de Vembu, y todas las configuraciones y trabajos de backups y réplicas están tal y como lo configuramos con la anterior versión, listos para seguir con las tareas programadas:

• Desde el portal web para clientes de Vembu, podemos ver que la suite está actualizada a la versión 4.0:

Saludos y espero que os sea de ayuda

Post sponsorizado por Vembu Technologies

Desde el blog Ragasys Sistemas, queremos anunciaros, que en Vembu Technologies, están en constante evolución y trabajando para mejorar Vembu BDR Suite y poder así satisfacer las necesidades cada vez mayores de los usuarios, ya que cada vez son más variados los usos de nuestra suite de copias de seguridad para entornos virtualizados y físicos.

En esta encuesta, buscamos conocer las expectativas de un software de edición gratuita, para que en Vembu Technologies podamos estar al día sobre las necesidades de nuestros usuarios.

Además, estamos regalando tarjetas de regalo de Amazon a través de un sorteo para aquellos que participen en la encuesta.

Pinchando aquí podrán realizar la encuesta.

Post sponsorizado por Vembu Technologies

Desde Vembu Technologies queremos anunciaros el evento del Día de la Privacidad de Datos, que será celebrado el día 28 de Enero.

Vembu está llevando a cabo una encuesta de 40 segundos para ayudar a personas y empresas, a entender la importancia de la privacidad del usuario y también la protección de datos.

Post sponsorizado por Vembu Technologies

Desde Vembu Technologies queremos anunciaros que comenzamos el año con un webinar sobre uno de los temas más interesantes, actuales y buscados sobre las TICs: «Cloud Computing en 2019«

Además, desde el blog Ragasys Sistemas, os queremos hacer saber sobre esta gran OPORTUNIDAD, y es que Vembu está dando FREE NFR KEY de su última versión Vembu BDR Suite v4.0 exclusivamente para SpiceHeads.

Post sponsorizado por Vembu Technologies

En los próximos post vamos a ver como montar una infraestructura de Backup y Disaster Recovery con Vembu BDR Suite 4.0, en un entorno de virtualización Miccrosoft Hyper-V y de servidores físicos.

La topología que hemos configurado y desarrollado sería la siguiente:

Explicaremos un poco esta topología, tendremos una oficina central situada en Madrid y cuatro oficinas remotas (Barcelona, Valencia, Bilbao y Sevilla) que conectamos a través de VPN con la sede central en Madrid.

El direccionamiento IP utilizado será el siguiente:

• Para la sede principal en Madrid: 192.168.5.0/24 (Inside), 192.168.14.0/24 (Outside), 192.168.3.0/24 (DMZ)
• Para la sede remota en Barcelona: 192.168.6.0/24
• Para la sede remota en Valencia: 192.168.7.0/24
• Para la sede remota en Bilbao: 192.168.8.0/24
• Para la sede remota en Sevilla: 192.168.9.0/24

En este router también tenemos configuradas reglas de firewall, enrutamiento, DNS caché, Proxy transparente, etc…, pero bueno esta parte queda fuera de esta serie de post.

Este post lo vamos a dividir en: (en esta parte iremos añadiendo los artículos a medida que los vayamos realizando)

• Instalación de Vembu BDR Suite 4.0 en MS Windows Server 2016.
• Configuración inicial de Vembu BDR Suite 4.0.
• Configuración de backups con Vembu BDR Suite 4.0 en un entorno Microsoft Hyper-V.
• Restauración de máquinas virtuales completas con Vembu BDR Suite 4.0 en un entorno Microsoft Hyper-V.
• Restauración de ficheros ubicados dentro del sistema operativo de una máquina virtual con Vembu BDR Suite 4.0 en un entorno Microsoft Hyper-V.
• Restauración rápida de máquinas virtuales con Vembu BDR Suite 4.0 en un entorno Microsoft Hyper-V.
• Restauración instantánea de archivos con Vembu BDR Suite 4.0 en un entorno Microsoft Hyper-V.
• Restauración de backups de máquinas virtuales a nivel de disco con Vembu BDR Suite 4.0 en un entorno Microsoft Hyper-V.
• Restauración multiformato de máquinas virtuales con Vembu BDR Suite 4.0 en un entorno Microsoft Hyper-V.
• Configuración de réplicas de máquinas virtuales con Vembu BDR Suite 4.0 en un entorno Microsoft Hyper-V.
• Reportes generados por Vembu BDR Suite 4.0 en un entorno Microsoft Hyper-V.
• Configuración de Vembu CloudDR Server.
• Configuración de backups con Vembu BDR Suite 4.0 en servidores físicos Windows.
• Restauración de Servidores físicos Windows con Vembu BDR Suite 4.0 modo “Quick VM Recovery”.
• Restauración de Servidores físicos Windows con Vembu BDR Suite 4.0 modo “File Level Recovery”.
• Restauración de Servidores físicos Windows con Vembu BDR Suite 4.0 modo “Download Multiformat”.

Post sponsorizado por Vembu Technologies

Desde Ragasys Sistemas queremos anunciar que Vembu dispone de tres nuevas actualizaciones importantes para compartir:

• En primer lugar, Vembu Technologies está introduciendo Vembu BDR Essentials – Exclusivamente empaquetado y a un precio muy asequible para pequeñas empresas, que tienen hasta 6 zócalos de CPU o 50 VMs.
  Vembu BDR Essentials proporciona a los clientes funcionalidades de nivel empresarial y escalabilidad para proteger su centro de datos virtualizado contra la pérdida de datos, a la mitad del precio de Vembu BDR Suite.
• En segundo lugar, Vembu Technologies está participando en el evento VMworld que tendrá lugar en Las Vegas. Estará en el stand #2133 del 26 al 30 de agosto en el Mandalay Bay Hotel Convention Center, Las Vegas, Nevada.
• Y finalmente, se trata de nuestro Webinar – Plan todo incluido de BC/DR con Vembu BDR Suite 4.0!  

Regístrese ahora para este seminario web que le guiará a través de las mejores prácticas para implementar una solución de copia de seguridad rentable en su entorno de TI heterogéneo utilizando nuestra próxima versión de Vembu BDR Suite v4.0!
Esto son los puntos que trataremos en el Webinar:
– Qué hay bajo el software Vembu BDR Suite con la v4.0
– Nuevas funcionalidades- ¿Cómo resuelve los problemas de TI?
– Mejores prácticas para lograr una alta disponibilidad con v4.0

Además, aproveche la oportunidad de ganar un cupón de regalo de Amazon de $100*, registrándose en este Webinar

Post sponsorizado por Vembu Technologies