Hola que tal?
Parece que nos hemos puesto de acuerdo en hablar del tema “Backup”. Pues vamos a ello.
Veeam Backup usa la técnica de Backup sintético, permitiendo tras efectuar un backup completo, efectuar backup tan sólo de los cambios incrementalmente. La técnica habitual que usan los productos similares es crear un fichero “grande” con el “full backup” para posteriormente ir creando ficheros “delta” con los cambios incrementales una vez vamos ejecutando el job.
Una vez alguien dijo “El problema no es el Backup, es el Restore”. Cuanta razón tenía, recuerdo cuando trabajaba con Mainframes y teníamos que “tirar” de cinta (si, aquellos armarios increíbles con cintas más grandes que los magnetófonos) y oía al técnico de sistemas “no lee, no restaura”. Un sudor frío pasaba por nuestra espalda hasta que al fin el milagro se producía y restauraba.
La premisa es la siguiente. Si vas a restaurar, estadísticamente lo que vas a buscar en primera instancia para cubrir el RTO es la última copia que hemos hecho. Si ésta es completa en lugar de sintética, siempre nos dará más facilidades (rapidez, consistencia, etc.)
Es por ello que Veeam usa la particularidad de copia “reverse” o decremental, por la cual, el primer backup completo nos creará el fichero principal pero cuando ejecute la primera incremental nos encontraremos con que el fichero perteneciente a la primera ejecución tiene sólo las diferencias, mientras que el último que hemos efectuado está “completo”.
Como trabaja Veeam? Curiosamente de una forma muy parecida a como gestiona los snapshots Datacore.
Tras la generación del fichero .vbk en la primera ejecución, cuando se ejecuta la primera copia incremental, Veeam actualiza los cambios que han habido en el sistema en explotación en el fichero .vbk, guardando todos los datos antiguos que han sido actualizados en un fichero .vrb para esta ocasión.
El fichero .vbk tendra como nombre de fichero el que le hemos asignado al hacer el job, mientras que el .vrb, además del nombre llevará concatenado el “timestamp” del dia y la hora en que se inició el job.
De esta forma podremos identificar los ficheros que tenemos en nuestros directorios ya que tendremos un fichero copia.vbk y tantos .vrb como rollbacks hayamos parametrizado, que se denominarán copiayyyy-mm-ddThhmmss.vrb.
Mecanismo parecido pasa con las réplicas, pero con diferencias, ya que una réplica en el fondo es una vm preparada para ponerse en marcha asap, entonces el fichero .vbk es substituido por el .vmdk de la VM, trabajando los vrb de igual forma que el Backup. Podéis obtener un resumen y más información en www.veammeup.com, blog que mantienen los chicos de ingeniería de Veeam de San Petersburgo, desde aquí un saludo.
Especial cuidado si estáis corto de espacio en el espacio smb que contiene estos ficheros y los movéis. A partir de la versión 4.0, Veeam Backup cuando editas el job, y en la ejecución del mismo hace ciertas verificaciones de la existencia de los ficheros destino. Hablaremos otro día de este tema y de como cumplir con las normas de seguridad y auditoría haciendo servir discos intercambiables y jobs alternados de copia.
Como anécdota, en orden interno VBK ha quedado como una acepción de “Hacer un Veeam Backup”, de esta forma, en slang podemos oír “el cliente VBKs tres servidores”
La próxima semana hablaremos de como efectuar un fine tuning de nuestro sistema detectando cuellos de botella y dimensionamientos no adecuados.
Los lectores que leyeron este post, también leyeron:
Estupendo articulo José María y muy bien explicado.
No sabia lo del slang
rgds,
J.
Jose Mª, gran aarticulo.
Creo que falta una e en la web de los de Veeam: http://veeammeup.com/
Gracias por el post.
Me gustaría saber, en el caso de hacer un Fail Over, : ¿Como hacer un Fail Back? ¿Es decir cómo volver al centro primario?
Si vuelves con el boton Fail Back al centro primario, todos los cambios que hayas hecho en el centro secundario no se guardarán porque la VM volverá al estado en el que estaba cuando se hizo el Fail Over.
Pero si no deseas eso (que creo que ninguno deseamos eso)…?
Por la doc de Veeam creo que se deberia volver a crear la replica en el sentido inverso(del secundario al primario) y esperar que se haga la replica y hacer un fail over en el sentido inverso al que se hizo.
Lo malo de esto es que, si quieres hacer una prueba de desastre, tendrias que hacer el fail over, borrar las VMs del origen, hacer la replica del secundario al primario y hacer fail over del secundario al primario. Vamos, una gran Prueba!
Estoy en lo cierto?
Un saludo y gracias! (Ya sé que esto da para otro post seguramente,
)
Gracias Pk.
Casi que te contestas todo por tí solo. Hasta en lo de proponer el proximo post, asi me aseguras el empleo con Chema!
Casi de acuerdo con todo lo que dices. Cuidado, hablas de volver al “Centro primario”, yo hablaría en estos momentos de VM Original. Creo que estamos hablando de lo mismo pero deseo matizarlo porque hablaremos de Centros Primarios en otro post.
En efecto, no hay Fail back. Bajo mi conocimiento tan sólo Datacore tiene el Fail over/Fail back. No es mi fuerte, pero creo que SRM tampoco tiene el Fail back.
Lo he tenido que usar, pero con la diferencia de que he usado una clonación de vCenter Server en lugar de una réplica, más rápido y más sencillo, aunque estoy de acuerdo contigo que el fondo es el mismo. Recuerda hacer el “undo” y reprogramar la replica contra la vm nueva “source”.
Un cliente me comentaba: “Tengo un plan de contingencia, pero si me da miedo activarlo, el Fail back me da pánico”.
Estos temas son muy delicados y hay que tener muy bien testeado el sistema.
Sugerencia. Usa un laboratorio y pruébalo (en casa y con gaseosa), de hecho me estas dando la idea de hacer un par de laboratorios y postearlos.
Chema, le añades una “e” más al enlace por favor?
Saludos
Hola José María
Solo un apunte. La ultima versión de Site Recovery Manger, version 4, si incluye la opción de fail back automática, aunque por razones obvias yo no lo recomiendo.
rgds,
J.
Gracias José María por la información.
jm
Gracias a ti por compartir con todos nosotros tus conocimientos, es realmente un placer.
rgds,
J.
Gracias a ambos.
Efectivamente me referia a la VM original.
El tener que hacer un fail over , trabajar en la VM “destino” y para volver atrás tener que hacer una replica de la VM “destino” a una nueva VM es normal que nos de miedo.
(Es lo que tiene la replica por sofware de Veeam)
Respecto a lo que comentabas del SRM, cuando se trabaja con replicacion a nivel de bloque (SAN), existe una “relación” entre las luns o los volumenes(que estan formateados en VMFS). En esa relación se establece el role: qué lun es la primaria y cual es la secundaria(read only). Cuando se hace el fail over , lo normal es que la lun que estaba en R.O se ponga en escritura y la que estaba en escritura se ponga en R.O, de forma que los cambios de los datos van en sentido contrario y el fail back es realizar lo mismo que el fail over pero en el otro sentido. En definitiva es cambiar el role de una Lun/volumen.
SRM trabaja con luns (y hace grupor protegidos) que replica y se habla con la cabina para hacer ese cambio de roles.
Por ello me resultaba extraño que Veeam no hiciese una especie de “relacion” entre las VMs y que al hacer el fail over , inmediatamente se haga replica en el otro sentido, para tenerlo a punto cuando se vuelva.
El que no sea asi dificulta las pruebas y hace el fail over fail back mas lento…pero bueno , por ese precio…
Segun Veeam: “Any changes made to a replicated VM will not be committed to the original VM when undo failover operation is performed.”
Failover
In order to diminish the risk of failure and make the work process seamless, Veeam Backup & Replication 4.1 provides a possibility to failover a virtual machine to its replicated version. In case of software or hardware malfunction, you can recover a corrupted virtual machine by failing over to its replica or its last known good point-in-time incremental.
At replica failover, the Veeam Agent is started on the target ESX server where a replicated virtual machine resides. A snapshot of a replica is created to protect a replicated VM from user’s changes, and the replica is started on the target host.
In case the undo failover operation is performed, the replica reverts to the created snapshot. Any changes made to a replicated VM will not be committed to the original VM when undo failover operation is performed.
At performing failover, the original VM should be stopped.
Important! If possible, avoid powering on a replica manually in case its original has failed. Use the Perform failover option in the Restore wizard instead. Otherwise, the subsequent replication sessions will be failing.
Muchas gracias a ambos,
Gracis Pk, estupendo feedback.
Si quieres profundizar mas con VMware Site Recovery Manager, no olvides registrarte en mi blog para que puedas bajarte una copia totalmente gratuita del libro Administrando VMware Site Recovery Manger by Mike Laverick & José María González
rgds,
J.
El manual lo deja claro.
Creo que la frase clave es “claro que por ese precio”.
Recordemos que productos de la competencia hacen Backup y no réplicas, mientras que Veeam sí que las hace. Llegamos donde llegamos.
Gracias por tu participación