Hay una frase que da una falsa tranquilidad enorme en entornos virtualizados: "tengo snapshots, estoy cubierto". No lo estás, o no como crees. Un snapshot y un backup se parecen lo suficiente para confundirlos, y esa confusión se paga el día —siempre el peor— en que muere un disco. Pero para entender por qué no protegen, y por qué además pueden causar el problema, hay que ver qué ocurre por debajo.
Qué es un snapshot y cómo funciona de verdad
Cuando tomas un snapshot, no se copia nada. Lo que pasa es más sutil: el disco actual de la VM se congela en solo lectura, y a partir de ese instante todas las escrituras nuevas se desvían a un archivo aparte —el delta—. Esto se llama copy-on-write (o redo log): el estado "congelado" queda intacto para poder volver a él, y lo nuevo se acumula en el delta. Por eso un snapshot es instantáneo y ocupa casi nada al crearse: no ha copiado datos, solo ha desviado el flujo de escritura.
La consecuencia decisiva es la misma de siempre: ese delta vive en el mismo almacenamiento que la VM. No es una copia aparte; es una capa encima del mismo disco.
Deltas y cadenas: lo que crece bajo la alfombra
Aquí empieza lo que casi nadie explica. Cada snapshot adicional que tomas apila otro delta encima del anterior, formando una cadena. Y esos deltas no son estáticos: crecen con cada bloque que la VM modifica. Una máquina tranquila genera deltas pequeños; una base de datos ocupada puede engordar un delta a un ritmo alarmante, porque cada escritura queda registrada ahí.
El disco base queda congelado; cada escritura se acumula en el último delta, y cada lectura recorre la cadena hasta encontrar el bloque vigente.
El comportamiento exacto depende del backend de almacenamiento, y conviene ser honesto sobre eso:
- Basado en archivo / redo log (los deltas de VMware, o qcow2 con overlays externos): además de crecer, forman una cadena que hay que recorrer para leer. Cuanto más profunda la cadena, más trabajo por cada lectura.
- Block-level copy-on-write (ZFS, LVM-thin, Ceph RBD): no arrastran la misma penalización de recorrer una cadena de archivos, pero el snapshot fija los bloques antiguos para no perderlos, así que el espacio consumido crece a medida que los datos divergen del punto congelado —y puede llenar el pool igual.
En ambos casos la moraleja es la misma: un snapshot que dejas "un rato" sobre una VM que trabaja no se queda quieto. Engorda.
Por qué el rendimiento se degrada
Mientras el snapshot existe, cada escritura paga un sobrecosto —va al delta, no al disco base— y, en los esquemas de cadena, cada lectura puede tener que atravesar varias capas para reconstruir el bloque vigente. Con uno o dos snapshots recientes casi no se nota; con una cadena larga o snapshots viejos sobre una VM con mucha actividad de disco, la latencia sube y la VM se siente pesada. La causa no es "la VM"; es la pila de deltas que arrastra.
Cómo un snapshot olvidado tumba el datastore
Este es el incidente clásico, y es peor de lo que suena. Un snapshot que nadie borró sigue creciendo con cada cambio hasta que, sumado al resto, llena el datastore. Y cuando un datastore se queda sin espacio, no falla solo la VM del snapshot: se pueden congelar todas las VMs que viven en ese almacenamiento. El thin provisioning amplifica el riesgo, porque el espacio "disponible" era una promesa, no una reserva. Un delta que nadie vigiló pasa de ser un descuido a ser una caída generalizada.
Consolidación: el momento delicado de borrarlo
Quitar un snapshot no es gratis ni instantáneo. Hay que consolidar: fusionar (commit) todo lo acumulado en el delta de vuelta al disco base. Esa operación es intensiva en I/O, compite con la carga normal de la VM y, en algunas plataformas, puede provocar un breve "stun" —la VM se pausa unos instantes mientras se completa—. Y hay una trampa: consolidar un delta grande necesita espacio libre para trabajar; si el datastore ya está apretado, la consolidación puede fallar o dejar a la VM en un estado incómodo. Cuanto más dejas crecer un snapshot, más caro y arriesgado es deshacerte de él. En VMware verás la advertencia "consolidation needed"; ignorarla es dejar la bomba armada.
Los artefactos que nadie mira
- Snapshots huérfanos: deltas o volúmenes que quedaron tras una operación fallida y ya no aparecen en el árbol de snapshots de la interfaz. Nadie los ve, pero consumen espacio real. Se acumulan en silencio.
- El snapshot del backup que no se borró: las herramientas de respaldo (incluida Veeam) toman un snapshot temporal para leer una imagen consistente y lo eliminan al terminar, apoyándose en el rastreo de bloques cambiados (CBT). Si el job se cae o la remoción falla, ese snapshot "temporal" se queda —y crece—. Es una de las causas más comunes de datastores que se llenan de la nada.
- Snapshots con memoria: si incluyes el estado de RAM, el snapshot es bastante más pesado y su creación/consolidación, más costosa.
Por qué, con todo esto, un snapshot no es un backup
Recapitulando la razón de fondo: si el almacenamiento donde vive la VM se corrompe, muere el host o un ransomware cifra ese disco, los snapshots se van con la VM —estaban en el mismo lugar que lo que debían proteger—. Un backup es una copia independiente: en otro medio, fuera de sitio, verificable. Esa independencia es exactamente lo que un snapshot no tiene, por diseño.
Cómo se usan bien (cada uno para lo suyo)
- Snapshot: punto de retorno de corta vida antes de un cambio arriesgado —una actualización, un parche—. Se toma, se valida el cambio, y se borra en horas, no en semanas. Y se vigila que no queden huérfanos.
- Backup: copia independiente, verificada y fuera de sitio para sobrevivir a un desastre real. Y como ya escribimos, un backup que nunca se probó no es un backup.
La pregunta que conviene hacerse
Son dos, en realidad. La de fondo: si el almacenamiento de mis VMs muriera ahora, ¿tengo una copia que viva en otro lado —o se iría todo junto? Y la operativa, que casi nadie se hace a tiempo: ¿cuántos snapshots llevo abiertos ahora mismo, desde cuándo, y cuánto han crecido? Diseñar la copia independiente —y vigilar que los snapshots no se vuelvan un problema— es parte de nuestra protección de datos.