En muchos departamentos de sistemas se vive siempre la misma escena: antes de aplicar un cambio delicado en producción alguien crea un snapshot de la máquina virtual “por si acaso” y se queda tan tranquilo. La falsa sensación de seguridad que dan estas instantáneas hace que se acumulen durante meses… Hasta que un día el datastore se llena, el rendimiento cae o directamente el almacenamiento se corrompe.
La pregunta que sobrevuela a muchos equipos es clara: ¿es buena práctica conservar snapshots indefinidamente “porque no molestan”? ¿O deberíamos borrarlos en cuanto dejan de ser necesarios? Para responder con criterio hay que entender muy bien qué es un snapshot, cómo funciona por debajo, qué impacto real tiene en rendimiento, almacenamiento, seguridad (incluido ransomware) y por qué nunca, pero nunca, debe confundirse con una copia de seguridad.
Qué es un snapshot y qué NO es
Un snapshot (o copia instantánea, punto de control, checkpoint…) es, en esencia, una fotografía del estado de una máquina virtual en un instante concreto. Captura el contenido de sus discos virtuales, su configuración y, si así lo eliges, incluso el estado de la memoria y de la CPU.
Desde el punto de vista del hipervisor (VMware, Hyper-V, KVM, Proxmox, etc.), al crear un snapshot se congela el disco base en modo solo lectura y se crea un nuevo disco diferencial (delta) al que se redirigen todas las escrituras posteriores. El snapshot no duplica todo el disco. Solo marca un punto a partir del cual se separan los cambios.
Por eso la creación y la reversión de un snapshot suelen ser casi inmediatas. No se copian gigas de datos, se reubican punteros y metadatos. Esta rapidez lleva a mucha gente a pensar que “es lo mismo que un backup, pero más cómodo”, cuando en realidad son conceptos radicalmente distintos.
Un backup, ya sea a nivel de fichero o de imagen de VM, implica generar una copia completa o incremental de los datos en otro soporte físico (cabina distinta, repositorio de backup, cinta, nube, etc.). En entornos Linux, es habitual automatizar copias de seguridad con rsync. El snapshot, en cambio, sigue dependiendo del mismo almacenamiento que la máquina original; si ese almacenamiento falla, la instantánea cae con él.
Anatomía de un snapshot: bloques, cadenas y consumo de espacio
Para ver el problema de fondo, imaginemos una VM con un solo disco virtual formado por varios bloques de datos A, B, C, D, E. Mientras no haya snapshots, cualquier cambio se escribe directamente en ese disco base: si se modifica A y se añade F, el disco “real” pasa a contener A’, B, C, D, E, F.
Cuando se crea el primer snapshot, el disco original se pone en solo lectura y el hipervisor genera un disco diferencial. A partir de ese momento, todas las escrituras (por ejemplo cambios en A’ y B o la aparición de G) se guardan en ese disco nuevo. Pero el disco base mantiene intacto su contenido previo.
En términos lógicos, la VM parece tener un solo disco, pero físicamente ya tienes dos: el disco base con los datos “antiguos” y el disco delta con los cambios. El tamaño “real” de lo que debería ocupar la VM puede ser, por ejemplo, 7 bloques, pero debido a la duplicidad parcial acabas consumiendo 9 bloques en el datastore.
Si repites la operación y creas un segundo snapshot encima del primero, el delta anterior pasa también a solo lectura y se crea un tercer disco diferencial. Los cambios sucesivos (A’’, D, E, H, etc.) van engordando esa cadena de discos hasta que, en muchos casos, el volumen ocupado por los snapshots supera con creces el tamaño original de la máquina virtual.
En casos reales no es raro encontrar VMs con discos base de 2 TB que, por culpa de uno o varios snapshots olvidados durante años, llegan a ocupar 4 o 5 TB en el datastore, con el correspondiente impacto en coste y rendimiento. Y lo peor: todo ello apoyado en una cadena de dependencias muy frágil.
Impacto de las cadenas de snapshots en rendimiento y fiabilidad
Cuando una VM necesita leer un bloque de datos, el hipervisor no sabe de antemano en qué disco de la cadena está la versión vigente de ese bloque. Primero consulta el último disco diferencial. Si no lo encuentra, baja al anterior y así sucesivamente hasta llegar al disco base. Cada eslabón extra supone más saltos de lectura.
En un laboratorio con poco I/O quizá no notes nada, pero en un servidor con miles o millones de bloques y varias instantáneas antiguas, cada operación de lectura y escritura se vuelve más costosa. La latencia sube, las aplicaciones se vuelven perezosas y los usuarios empiezan a quejarse de lentitud “sin motivo aparente”.
El otro gran riesgo es estructural. Cada snapshot es un disco dependiente del anterior. Si se corrompe uno de los discos en medio de la cadena, toda la VM puede quedar inutilizable porque el hipervisor ya no es capaz de reconstruir la secuencia completa de estados.
Además, cuanto más tiempo se deja crecer un snapshot (especialmente en máquinas muy activas, como bases de datos), más engorroso y lento será el proceso de consolidación. Al eliminar la cadena, el sistema debe fusionar los cambios de cada delta con su padre, uno a uno, lo que dispara las operaciones de lectura/escritura y aumenta el riesgo de problemas si algo se interrumpe a mitad.
Por todo esto, la recomendación unánime de fabricantes y expertos es clara: los snapshots son herramientas temporales, no sistemas de almacenamiento permanente. Sirven para cubrirte durante un cambio, no para convivir años en producción.
Tipos de snapshots y particularidades según plataforma
Según la plataforma de virtualización y el nivel al que trabajes, no todos los snapshots son iguales ni se comportan igual. Conviene diferenciarlos porque tienen implicaciones distintas en consistencia de datos y casos de uso.
En VMware, por ejemplo, puedes crear instantáneas con estado de memoria o “silenciadas” (quiesced). La instantánea de memoria captura exactamente lo que hay en RAM y CPU en ese instante. Muy útil para volver atrás tras una actualización de sistema o una instalación complicada.
La instantánea silenciada, por su parte, se usa mucho como apoyo a las copias de seguridad. Requiere VMware Tools en la VM para congelar el sistema de archivos invitado y asegurar que el disco de snapshot refleja un estado consistente (evitando transacciones a medias, ficheros abiertos, etc.).
En Hyper-V, el concepto es el mismo, aunque Microsoft popularizó el término “punto de control” (checkpoint). Técnicamente es un snapshot que pone el disco VHD/VHDX original en solo lectura y crea uno o varios discos de diferenciación encadenados.
En el mundo del almacenamiento, más allá del hipervisor, también existen snapshots a nivel de cabina o sistema de ficheros (ZFS, sistemas NAS, SAN, etc.). Estos snapshots trabajan sobre bloques de almacenamiento, no sobre VMs concretas, y suelen implementarse usando dos enfoques principales: Copy-On-Write (COW) y Redirect-On-Write (ROW).
En COW, cuando un bloque va a modificarse, se copia primero el bloque “viejo” al área reservada de snapshots y luego se sobrescribe el original. Esto hace que leer datos viejos sea rápido, pero penaliza las escrituras (cada cambio implica leer-copiar-escribir).
En ROW, muy usado en sistemas modernos como ZFS y cabinas All-Flash, los datos nuevos se escriben directamente en otra ubicación física y se actualizan los punteros, mientras el snapshot mantiene las referencias a los bloques antiguos. La creación de snapshots y las escrituras apenas afectan al rendimiento, a cambio de una mayor fragmentación que puede ser problemática en HDD tradicionales.
Snapshots vs copias de seguridad: por qué no son intercambiables
Uno de los errores más extendidos en TI es asumir que, porque puedes volver a un punto anterior en pocos segundos, el snapshot ya cumple el papel de backup. Es una trampa conceptual peligrosa.
El snapshot, tanto a nivel de hipervisor como de almacenamiento, depende siempre del sistema donde reside el dato original. Si falla la cabina, se corrompe el datastore, se pierde el host o alguien destruye el volumen, tus snapshots desaparecen con él. No hay “copia fuera”.
Una copia de seguridad de verdad implica seguir principios como la regla 3-2-1: tener al menos 3 copias de los datos, en 2 soportes distintos, con 1 de ellas fuera del sitio principal. Eso suele traducirse en un repositorio de backup dedicado, otra sede, cinta, nube o una combinación de ellos, muchas veces con capas de inmutabilidad.
Además, los snapshots no están pensados para recuperaciones granulares. Te permiten revertir la VM completa o el volumen a un estado anterior, pero no restaurar fácilmente un único archivo, una base de datos específica o un buzón de correo sin afectar al resto del sistema.
Las soluciones de backup para entornos virtuales (Veeam, Vinchin Backup & Recovery, etc.) se integran con el hipervisor para orquestar snapshots temporales, extraer de ellos una copia consistente hacia un repositorio independiente y luego borrar esas instantáneas. El snapshot es solo una herramienta transitoria dentro del proceso de copia; el seguro de vida está en el backup externo.
Por si fuera poco, un snapshot no te protege de desastres físicos o lógicos severos: incendios, inundaciones, robo de hardware, fallo masivo de discos, corrupción generalizada de un volumen… en todos esos casos necesitas una copia que viva en otro sitio y que puedas montar en un entorno limpio.
Buenas prácticas para usar snapshots sin corromper máquinas
Una vez claro qué son y qué no son, la siguiente cuestión es cómo manejarlos sin comprometer tu infraestructura. Aquí es donde entra la disciplina de uso y limpieza que muchos equipos descuidan por pura comodidad.
La primera regla, simple pero crítica, es el tiempo: no deberías mantener un snapshot de producción más de unas 24-72 horas. VMware, por ejemplo, desaconseja expresamente dejar una sola instantánea activa más allá de ese plazo, porque su tamaño seguirá creciendo y el datastore sufrirá.
También importa la cantidad. Aunque técnicamente puedas encadenar hasta 32 snapshots por VM, en entornos reales se recomienda no pasar de 2 o 3 como máximo para minimizar latencia y complejidad de consolidación. Cada disco extra es una capa más que leer y fusionar.
En cuanto al momento de creación, conviene tomar instantáneas cuando la VM no esté bajo una carga intensa de entrada/salida. Si pillas al sistema en plena tormenta de I/O (backup interno, reindexado, cargas masivas), la creación de la instantánea puede fallar o generar estados inconsistentes.
A nivel de procedimiento, es fundamental que el equipo adopte políticas claras: crear snapshot antes de cambios delicados, validar que todo funciona y borrarlo en cuanto se confirme la estabilidad. Nada de “lo dejo por si acaso” durante meses. Documentar quién lo creó y por qué ayuda mucho a que no se olviden.
Y, muy importante, no mezclar snapshots con la política de cumplimiento y copias de seguridad. En auditorías de ISO 27001, ENS, PCI-DSS o similares, los snapshots no cuentan como backup ni como retención histórica válida. Son un mecanismo operativo, no un control de continuidad del negocio.
Snapshots y ransomware: la ‘máquina del tiempo’… con matices
En los últimos años, el ransomware ha pasado de ser una molestia a convertirse en una de las amenazas más críticas para cualquier organización. No se limita a cifrar ficheros: busca conscientemente atacar el dato, incluidas las copias de seguridad, y borrar cualquier rastro que permita una recuperación fácil.
En este escenario, los snapshots a nivel de almacenamiento se han vendido muchas veces como una “máquina del tiempo” para deshacer el cifrado al instante. Su capacidad para restaurar un volumen en segundos a un punto anterior a la infección es, efectivamente, una ventaja enorme frente a restauraciones completas muy lentas.
Pero hay que diferenciar bien entre snapshots del sistema operativo (como VSS en Windows) y snapshots de cabina. La mayoría del ransomware moderno ejecuta comandos para eliminar VSS nada más entrar. Y lo hace precisamente para impedir al usuario usar los puntos de restauración locales del sistema.
Los snapshots en la capa de almacenamiento juegan aquí un papel clave: se gestionan fuera del sistema operativo y no son accesibles mediante las credenciales habituales de Windows o Linux. Aunque el atacante consiga privilegios de administrador en el servidor, no puede borrar directamente esas instantáneas de la cabina con un simple comando.
Al detectar un incidente, el procedimiento típico consiste en elegir un snapshot anterior al inicio del cifrado y montar o revertir el volumen a ese punto. Da igual que el dataset sea de 1 TB o 100 TB: como solo se reorientan punteros hacia bloques antiguos, el RTO (tiempo de recuperación) es muy pequeño comparado con un restore completo.
De hecho, muchas soluciones modernas usan los snapshots no solo de manera pasiva sino como mecanismo de defensa proactiva. Analizan en tiempo real la entropía de los bloques escritos (un archivo cifrado se parece mucho a datos aleatorios) y, ante picos de entropía anómalos y escrituras masivas, disparan automáticamente snapshots inmutables o cortan las conexiones de escritura (SMB/NFS) sospechosas.
Snapshots inmutables, WORM y gestión segura de privilegios
El ransomware de nueva generación no se conforma con cifrar datos. También intenta escalar privilegios hasta la consola de administración de la cabina para destruir snapshots y copias. Para aguantar ese tipo de ataque necesitas algo más que snapshots “normales”.
Ahí entran en juego los snapshots inmutables o tecnologías WORM (Write Once, Read Many). Una vez bloqueado un snapshot durante un periodo (por ejemplo, 7 días), nadie —ni siquiera un administrador con permisos máximos— puede modificarlo o borrarlo hasta que expire ese plazo.
Estos mecanismos convierten los snapshots en una especie de caja fuerte con temporizador: aunque el atacante robe credenciales de alto nivel, se encuentra con copias que no puede tocar. Esto garantiza al menos algunos puntos limpios de recuperación.
Junto a la inmutabilidad, las buenas prácticas de gestión exigen añadir capas como la autenticación multifactor (MFA) y el principio de doble control. Para acceder a la consola de administración o borrar snapshots debería requerirse al menos una verificación adicional (OTP en el móvil, token, etc.).
Para operaciones especialmente destructivas —eliminar snapshots críticos, formatear volúmenes, vaciar repositorios— lo ideal es aplicar el llamado “four-eyes principle”: exigir que dos cuentas de administrador diferentes confirmen la acción. Así se reduce tanto el riesgo de abuso interno como el impacto de una credencial comprometida.
Aun con todo esto, conviene insistir en un matiz vital: los snapshots, por muy avanzados o inmutables que sean, no sustituyen a una estrategia completa de backup. Siguen dependiendo de la salud de la cabina o del sistema donde viven, y no te protegen si el hardware se destruye o queda inaccesible.
Además, en la era del “doble ransomware”, donde el atacante primero exfiltra datos sensibles y luego los cifra, los snapshots solo resuelven la parte de disponibilidad: puedes recuperar los ficheros, pero la filtración ya se ha producido. Ahí entran en juego otros controles como DLP, cifrado de datos en tránsito y en reposo, y políticas estrictas de gobierno del dato.
Cuándo usar snapshots y cuándo tirar de backup
En la práctica, snapshots y backups no compiten, se complementan. La clave está en usar cada herramienta para lo que está diseñada y no invertir los papeles por comodidad o desconocimiento.
Los snapshots encajan como anillo al dedo en situaciones como: preparar una actualización de sistema operativo, instalar una nueva versión de una aplicación crítica o cambiar configuraciones de red delicadas. Permiten probar, validar y, si algo sale mal, regresar al estado anterior en segundos.
Eso sí, con disciplina: se crea el snapshot justo antes del cambio, se comprueba que todo va bien y se borra en cuanto se da por bueno. Nada de dejarlo indefinidamente “por si acaso”.
El backup entra en juego cuando hablamos de continuidad de negocio de verdad:
- Recuperar VMs tras la pérdida de un host, un clúster o un CPD completo.
- Restaurar ficheros concretos que un usuario ha borrado por error.
- Volver a una versión de base de datos de hace semanas.
- Demostrar retención de datos por motivos legales o regulatorios.
Una solución de copia moderna para entornos virtuales ofrece, además, ventajas adicionales: copias incrementales, verificación de integridad, compresión, deduplicación, backup sin pasar por LAN, recuperación instantánea montando directamente las copias, migración entre plataformas de virtualización, etc.
En muchos casos, el procedimiento ideal combina ambas cosas. El software de backup apalanca snapshots de hipervisor o de cabina para generar copias consistentes sin ventanas de parada, pero esas instantáneas son efímeras y se eliminan tras completarse la transferencia al repositorio externo.
Sea cual sea la herramienta, hay una máxima que no conviene olvidar: no existe copia de seguridad hasta que se ha probado la restauración. Hacer backups sin testear restores periódicos es jugar a la ruleta rusa con los datos, y el día que haya un incidente serio es cuando se descubre que la política de copias era papel mojado.
