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.
Take care.
José María
Primer Post sobre Datacore. En cualquier sistema de storage que trabaje con “Thin Provisioning”, debes estar vigilante para recuperar el espacio usado y no borrado. Es decir, puedes borrar con vCenter Server una VM de un Datastore pero el NMV no lo liberará.
