Vamos a hablar sobre cómo construir un “near CDP” con Veeam Backup. Veeam Backup, como sabéis tiene dos funcionalidades, Backup Sintético Reverso (otro día hablaremos de él) y la funcionalidad de efectuar Réplicas.
La Réplica no es un concepto que substituye al Backup, sino que lo complementa. El punto fuerte de la Réplica es que el RTO (Recovery Time Objetive) es mucho menor que el de un backup, porque sencillamente obviamos el tiempo preciso para recuperar desde los ficheros de Backup, el punto débil es que precisamos espacio en SAN en vez de en NAS, que es más económico.
Entendemos por CDP “Continuous data protection” como la funcionalidad de capturar y efectuar Backup de todas las versiones de toda la información que exista en origen. Veeam Backup no es un CDP, por eso estamos hablando de un “near CDP” ya que si usamos todas las posibilidades que nos ofrece el producto, efectuar una réplica será un suspiro y con ello podremos ir haciendo réplicas que nos permitirán hacer el versionado de los cambios de la información.
En primer lugar, tras la instalación del Veeam Backup y su enlace con nuestra infraestructura instalaremos una nic que trabaje con la red de Storage, donde tenemos nuestras LUNs con una IP de su rango. A continuación, instalaremos en nuestra máquina que tiene instalado VB un iniciador iSCSI (el de MS mismo) y configuraremos éste versus la SAN, para que Windows pueda ver los volúmenes. Sobre todo, no los inicialicéis con Windows ….
Comprobamos que todo funciona bien haciendo un ping a la SAN y un ping al NAS o recurso compartido que contendrá nuestros ficheros de Backup (el NAS nos interesa para hacer backup, aunque este post versa sobre réplicas). Como último paso antes de empezar a configurar verificaremos que la LUN donde vamos a alojar las réplicas tiene suficiente espacio para alojar nuestras VM más las retenciones que deseemos.
Si todo es OK, tan sólo nos queda configurar el Job. Replication, damos de alta un nombre para este Job y en “Replication Mode” escogemos VMware vStorage API Mode SAN only, al menos para el momento de prueba y ver que efectivamente funciona.
En “Virtual Machines” efectuaremos “Add” y seleccionaremos la VM que queremos replicar y en “Replica Destination” seleccionaremos el Host que albergará la Réplica y el Datastore. En esta pantalla en “Advanced” marcaremos que deseamos recibir un Mail como notificación (recordad efectuar setup del SMTP en Tools), la verificación de la integridad de las réplicas, sobre todo, la deduplicación y el “Change block tracking” de vSphere (todo lo que estamos comentando se hace asumiendo que estamos en un entorno vSphere).
En la pestaña Backup indicaremos cuantos puntos de rollback o versiones deseamos. Si tenemos espacio y por la noche se han hecho backup, teniendo los rollback del dia ya será buena cosa, si hacemos una Réplica cada hora desde las 9 de la mañana hasta las 9 de la noche, con 12 rollback tendremos suficiente.
En “Replica Consistency” habilitaremos Veeam VSS si se trata de un DC o bien de un SQL (hablaremos sobre ello), especificando usuario y password de Administrador de la VM.
Al final, en “Job Schedule”, lo habilitaremos para que ejecute las programaciones y lo habilitaremos con un job periódico, por ejemplo, como hemos dicho antes, cada hora.
Cuidado. Cuando un Job de Backup o de Réplica se inicia, efectúa un Snapshot temporal marcado como “Veeam”. Tan sólo puede existir un Snapshot, si se encuentran dos nos encontraremos muy posiblemente con un “Consolidate helper”.
Es por ello que es una Buena Práctica declarar una ventana de Backup (por ejemplo de 21 horas a 9 de la mañana) y una ventana de réplica (de 9 de la mañana a 21 horas), así no se cruzarán los Jobs.
Para programar los jobs de réplica dentro de esta ventana, iremos al botón “Schedule” de la ventana “Job Schedule” y en un formato muy parecido al de MS, indicaremos que el Job queda habilitado de 9 a 21, mientras que la franja nocturna la dejamos para los Backups. Finalizamos el Wizard.
Con ello tendremos un espléndido Job que desde las 9 de la mañana a las 21 horas nos irá haciendo réplicas de nuestras VM, las cuáles, usando el modo SAN y deduplicación consumirán poco tiempo y recursos a la vez que van versionando nuestra información en franjas de 1 hora. Haced la prueba, os sorprenderá.
Si tenemos una corrupción o pérdida de la VM original, no uséis el vCenter server para poner en marcha nuestra vm_replica. Iremos a nuestro Veeam Backup, efectuaremos Restore e indicaremos “Perform failover” (el gráfico animado es bastante explicativo), indicaremos el Job del que queremos hacer “failover” y la VM en particular, seguidamente nos mostrará los rollback de los que disponemos para recuperar. (fijaros en que siempre el último es el Synthetic full y los más antiguos son Rollback, hablaremos de ello otro dia), efectuando Finish tendremos nuestra vm_replica en marcha sustituyendo a la que ha caído.
Eso es todo por hoy. Probadlo, primero con una réplica o dos (aprovechando la hora de la comida), para ir evolucionando hasta la velocidad y número de Rollbacks que os convenga. Os sorprenderá.
Me acaban de llegar a las manos las hojas técnicas de los nuevos servidores de Cisco.
![warrior02[1]](http://lh4.ggpht.com/_Z4xLRoFNHJQ/S1OPX1tVN7I/AAAAAAAACzc/PxdBag6ON9g/s1600-h/warrior02%5B1%5D%5B4%5D.jpg "warrior02[1]")
