¿Piensas que una instantánea de una máquina virtual es lo mismo que un backup o una copia del disco? Entonces este post es para ti.
Antes de nada, vamos a dar respuesta a la pregunta principal. ¿Qué es realmente un snapshot? Como su nombre indica, un snapshot es una instantánea del estado de una máquina virtual (VM) en un momento concreto. Es decir, una foto que se puede usar para restaurar dicha VM a ese punto en ese instante. Y precisamente ahí está el origen del error: muchos creen que esto lo convierte en un backup… pero no es así.
El siguiente diagrama, muestra un ejemplo de una VM de un solo disco con 5 bloques de datos:
¿Qué sucede si vamos a modificar el bloque A y vamos a añadir el bloque F? Al estar la VM sin snapshots, directamente modificará su Disco 1, alterando el bloque A por A’ y ampliando su tamaño a 6 con el bloque F:
Llegamos al punto crucial en el que creamos un snapshot… ¿qué le ocurre realmente a la VM a nivel lógico? Al generar un snapshot, le indicamos a la máquina virtual que congele su disco actual (Disco 1) en modo de solo lectura, de este modo, si en algún momento necesitamos revertir, podremos regresar exactamente a ese estado. A partir de aquí, la VM crea un nuevo disco (Disco 1’) donde se registrarán todos los cambios posteriores, es decir, el snapshot no duplica toda la información, sino que actúa como un punto de restauración rápido:
Y aquí está la primera pista de por qué un snapshot no es un backup: tanto la creación como la reversión de un snapshot ocurren en cuestión de pocos segundos, algo muy distinto al tiempo que requiere generar y restaurar una copia de seguridad completa.
En este caso, tras la creación del primer snapshot, se modifican los bloques A’ y B, y se añade un nuevo bloque G. Como se puede apreciar en el siguiente diagrama, esos cambios se almacenan en el Disco 1’, el cual ahora tiene un tamaño de 3 bloques, mientras que el Disco 1 se mantiene inalterado con sus 6 bloques intactos:
Un detalle importante que no debemos pasar por alto. El tamaño real que debería tener la VM es de 7 bloques, pero, debido a la forma en que funcionan los snapshots, actualmente está ocupando 9 bloques al tener el Disco 1’ versiones modificadas de bloques que ya existen.
Ahora creamos un segundo snapshot, y el proceso es similar al anterior. El Disco 1’, que hasta ahora estaba registrando los cambios, pasa a congelarse en modo solo lectura, y la máquina virtual genera un nuevo disco Disco 1’’. En este punto llegan modificaciones de los bloques A’’, D y E, y aparece un nuevo bloque H:
Después de este segundo snapshot anidado, llegamos a uno de los principales problemas que surgen al mantener snapshots antiguos en una máquina virtual. En este momento, el Disco 1 original ocupa 6 bloques, mientras que los discos correspondientes a los snapshots ya suman 7 bloques, haciendo un total de 13 bloques. ¿El resultado? La VM está consumiendo más espacio en el datastore por los snapshots que por su propio tamaño original. Este es un riesgo poco evidente, pero crítico. Los snapshots no solo generan dependencia entre discos, también pueden provocar un crecimiento descontrolado del almacenamiento, afectando el rendimiento e incluso comprometiendo la capacidad del sistema.
Además, como se ha podido observar, este mecanismo demuestra que los snapshots no son copias completas, sino dependencias encadenadas. Cada nueva instantánea se apoya en la anterior. Y aquí surge un riesgo importante que a menudo se pasa por alto: si uno de estos discos falla, toda la cadena puede quedar inutilizable, dejando a la VM en un estado de inconsistencia.
En cuanto al rendimiento, imaginemos que necesitamos acceder al bloque C. La VM inicia la búsqueda en el Disco 1’’ (el más reciente) por si el bloque hubiese sido modificado. Como no está ahí, pasa al siguiente disco en la cadena: Disco 1’. Tampoco lo encuentra. Finalmente, llega al Disco 1 original, donde reside el bloque intacto desde el inicio. Este recorrido implica que la lectura ha tenido que atravesar toda la cadena de snapshots para localizar el dato, lo que convierte la operación en un proceso ineficiente y lento.
Ahora extrapolemos este escenario a un entorno real de un servidor virtual con un disco con miles o millones de bloques y con múltiples snapshots antiguos. Cada operación de lectura o escritura que implique recorrer la cadena completa de discos incrementará el tiempo de acceso de forma considerable. Si esta situación se replica en múltiples consultas y sobre un sistema crítico, el impacto en el rendimiento global será evidente: mayor latencia, operaciones más lentas y degradación del servicio garantizado.
¿Te parece exagerado todo lo que hemos explicado? Te dejo un caso real: una empresa tenía su BBDD principal alojada en un servidor virtual con un disco de 2 TB, sin embargo, en el datastore, esa VM ocupaba casi 5 TB. El motivo era un snapshot que llevaba más de 3 años sin eliminarse, en un servidor que procesaba miles de cambios y peticiones diarias. El resultado fue un crecimiento descontrolado del almacenamiento y una degradación del servicio hasta el punto de tener quejas diarias de clientes por lentitud y malfuncionamiento.
Este es el gran riesgo de tratar los snapshots como si fueran backups y de acumularlos por miedo a “perder algo”. La realidad es que ocurre justo lo contrario: cuantos más snapshots antiguos conserves, mayor será el riesgo para tu infraestructura.
Hay una regla básica que nunca falla: si un snapshot es antiguo, elimínalo. Piénsalo bien ¿realmente restaurarías un servidor en producción desde un snapshot que tiene meses… o incluso años? Si la respuesta es no, entonces ese snapshot no tiene ningún sentido.
Los snapshots son muy útiles para cambios puntuales y operaciones temporales, pero no son un sustituto de un backup. Para proteger tus datos, necesitas copias de seguridad completas, externas y verificadas.
Y para finalizar… ¿Qué ocurre cuando eliminamos la cadena de snapshots y consolidamos el disco de la VM? El proceso consiste en fusionar todos los cambios acumulados en los snapshots con su disco anterior, uno por uno, hasta que la cadena queda completamente integrada en el disco base. Solo entonces la máquina virtual recupera su tamaño real, eliminando los discos diferenciales que se habían ido creando:
Este procedimiento es muy lento y delicado, especialmente si se disponen de snapshots antiguos con tamaños completamente descontrolados, ya que implica operaciones intensivas de lectura y escritura. Por eso, mantener snapshots antiguos no solo consume espacio y afecta al rendimiento, sino que también complica y prolonga cualquier tarea de consolidación.
Daniel Calzada, Responsable IT de Zerolynx by Cybertix