Los snapshots son una de esas herramientas que todos los administradores agradecen cuando toca hacer una actualización delicada, cambiar una configuración o probar algo que puede salir mal. Permiten guardar un punto de estado de una máquina virtual y volver atrás si la intervención falla. Bien usados, son rápidos, cómodos y muy útiles. Mal gestionados, pueden convertirse en una fuente de problemas de rendimiento, consumo de almacenamiento y riesgo operativo.
El caso se repite más de lo que parece: alguien crea un snapshot antes de una actualización «por si acaso», la tarea termina, la máquina sigue funcionando y nadie vuelve a acordarse de él. Semanas después, meses después o incluso años después, el entorno empieza a ir lento, el almacenamiento crece sin explicación aparente y las consolidaciones se vuelven delicadas. El problema no suele ser el snapshot en sí. El problema es olvidarse de él.
El ejemplo compartido por el equipo de Stackscale (Aire) Infraestructura IT lo resume con claridad: un cliente llegó con problemas de rendimiento en varias máquinas virtuales y, al revisar el entorno, aparecieron snapshots acumulados desde hacía casi tres años. No es un caso extremo imposible. Es el tipo de descuido que puede aparecer en entornos donde no existe una política clara de revisión, caducidad y eliminación de snapshots.
Una herramienta temporal, no una copia de seguridad
La confusión más peligrosa es pensar que un snapshot equivale a un backup. No lo es. Un snapshot depende del disco original y del estado de la máquina virtual en el momento en que se crea. Sirve para volver atrás ante un cambio reciente, pero no protege de la misma forma que una copia de seguridad almacenada de forma separada, verificable y recuperable.
Broadcom, en su documentación de buenas prácticas para VMware, lo expresa de forma directa: no se deben usar snapshots como backups. También recomienda no mantener un snapshot durante más de 72 horas y limitar el número de snapshots en una cadena, aunque técnicamente vSphere soporte hasta 32. La razón es sencilla: cuanto más tiempo permanece activo, más crecen los archivos delta y más impacto puede tener sobre el rendimiento y el almacenamiento.
En Proxmox VE, los snapshots también son útiles para preservar el estado de una máquina virtual y poder volver a un punto anterior, pero las copias de seguridad se gestionan por otra vía. La documentación de Proxmox explica que los backups contienen la configuración de la VM o contenedor y todos sus datos, y pueden iniciarse desde la interfaz gráfica o mediante vzdump. Es una lógica distinta a la del snapshot operativo de una VM.
| Concepto | Snapshot | Backup |
|---|---|---|
| Objetivo | Volver atrás tras un cambio puntual | Recuperar datos o sistemas ante pérdida, fallo o desastre |
| Duración recomendada | Temporal, normalmente horas o pocos días | Retención definida por política |
| Dependencia del disco original | Alta | Debe ser recuperable de forma independiente |
| Uso habitual | Actualizaciones, mantenimiento, pruebas controladas | Continuidad, recuperación, cumplimiento y protección ante ransomware |
| Riesgo si se olvida | Crecimiento, lentitud, consolidaciones complejas | Depende de política, verificación y almacenamiento |
| Dónde debe estar | En el mismo entorno de la VM | Idealmente separado, protegido e incluso inmutable |
Qué ocurre cuando un snapshot se queda demasiado tiempo
Cuando se crea un snapshot, la máquina virtual deja de escribir directamente sobre el disco base como lo hacía antes y empieza a registrar cambios en archivos o volúmenes asociados al snapshot. El sistema mantiene la posibilidad de volver al punto inicial, pero a cambio introduce una capa adicional de gestión. Esa capa no es problemática durante una ventana corta. Se vuelve peligrosa cuando se acumula.
Con el paso del tiempo, los cambios crecen. Si la máquina tiene mucha actividad de disco, los delta pueden ocupar grandes cantidades de almacenamiento. Si además hay varios snapshots encadenados, cada lectura o escritura puede implicar más trabajo. En entornos con bases de datos, servidores de ficheros, ERPs o máquinas con alto I/O, el impacto puede ser mayor.
VMware ha publicado análisis específicos sobre el impacto de los snapshots en el rendimiento de aplicaciones invitadas y operaciones de aprovisionamiento. La conclusión práctica para los administradores es que los snapshots deben gestionarse con cuidado, especialmente en cargas intensivas y entornos donde la consolidación puede afectar a ventanas de mantenimiento o capacidad de almacenamiento.
| Riesgo | Cómo aparece |
|---|---|
| Degradación de rendimiento | La VM trabaja con capas adicionales de disco |
| Crecimiento del storage | Los cambios se acumulan en archivos delta o volúmenes asociados |
| Consolidaciones lentas | Eliminar el snapshot exige fusionar cambios acumulados |
| Ventanas de mantenimiento más largas | La consolidación puede tardar mucho si el snapshot ha crecido demasiado |
| Riesgo operativo | Si falla el almacenamiento durante una consolidación delicada, el impacto puede ser serio |
| Falsa sensación de seguridad | Se cree que existe un backup cuando solo hay un punto temporal dependiente del disco base |
El problema se agrava cuando se mezclan snapshots manuales con snapshots creados por software de backup. Muchas herramientas de copia usan snapshots temporales para capturar una VM en ejecución, pero deben eliminarlos al finalizar. Si algo falla en ese proceso, pueden quedar snapshots huérfanos que no siempre son visibles de forma evidente en la consola principal. Por eso las revisiones periódicas no son un detalle menor.
Buenas prácticas para VMware, Proxmox y entornos mixtos
VMware y Proxmox resuelven los snapshots de forma distinta, pero la disciplina operativa es parecida: crear solo cuando hace falta, documentar el motivo, poner fecha de caducidad y eliminar cuando termina la intervención. En producción, un snapshot sin dueño y sin fecha es una deuda técnica.
La primera norma debería ser sencilla: todo snapshot debe tener un motivo y un responsable. Si se crea antes de actualizar un ERP, cambiar una aplicación o tocar la configuración de red de una VM, debe quedar indicado quién lo creó y cuándo se revisará. En equipos con varias personas, esa trazabilidad evita que una medida temporal se convierta en un problema crónico.
La segunda norma es no usar snapshots como sustituto de backup. Para recuperación real hacen falta copias programadas, almacenadas en repositorios adecuados, verificadas, con retención definida y, cuando el riesgo lo justifique, protegidas frente a borrado o ransomware. En entornos Proxmox, Proxmox Backup Server permite gestionar repositorios de backup con deduplicación y estructura específica para copias. En VMware, las plataformas de backup se integran con APIs y procesos propios, pero el principio es el mismo: el backup debe sobrevivir a un problema del entorno primario.
La tercera norma es revisar. Un informe semanal o mensual de snapshots activos puede evitar muchos incidentes. En entornos grandes, esta revisión debería automatizarse con alertas por antigüedad, tamaño y número de snapshots por VM. No hace falta esperar a que el almacenamiento se llene para descubrir que una máquina lleva dos años acumulando cambios.
| Buena práctica | Aplicación práctica |
|---|---|
| Definir una vida máxima | Establecer caducidad, por ejemplo 24-72 horas salvo excepción documentada |
| Nombrar correctamente | Incluir motivo, fecha y responsable |
| Revisar periódicamente | Informes automáticos de snapshots por antigüedad y tamaño |
| No encadenar sin control | Evitar varias capas salvo necesidad justificada |
| Verificar backups reales | Probar restauraciones, no solo comprobar que la tarea termina |
| Consolidar en ventanas controladas | Planificar eliminación de snapshots grandes para evitar impacto |
| Formar al equipo | Dejar claro que snapshot no significa backup |
El error no es crear snapshots, es no gobernarlos
Los snapshots tienen mala fama en algunos departamentos precisamente porque se han usado mal. Pero prohibirlos por completo tampoco tiene sentido. Son una herramienta muy valiosa cuando se aplican en tareas controladas: actualizaciones del sistema operativo, cambios de aplicación, pruebas de configuración, intervenciones de mantenimiento o validaciones previas a despliegues.
El equilibrio está en tratarlos como lo que son: una herramienta temporal de reversión. Igual que nadie dejaría un andamio instalado indefinidamente en medio de una oficina después de terminar una obra, tampoco debería dejarse un snapshot activo meses después de cerrar una intervención.
En plataformas como VMware o Proxmox funcionan muy bien si se respetan sus límites. El problema aparece cuando se convierten en una práctica informal, sin inventario, sin política y sin supervisión. Ahí dejan de ser una red de seguridad y pasan a ser una carga invisible para el entorno.
La virtualización ha permitido que los equipos de IT ganen flexibilidad, pero también ha hecho más fácil acumular pequeñas decisiones olvidadas: discos temporales, plantillas antiguas, VMs apagadas, snapshots sin uso y configuraciones pendientes. Cada una parece menor. Juntas pueden explicar buena parte de los problemas de rendimiento y capacidad.
La recomendación final es simple: revisar los snapshots debería formar parte de la higiene básica de cualquier entorno virtualizado. Igual que se revisan backups, parches, alertas de hardware o capacidad de almacenamiento, también hay que revisar qué snapshots existen, por qué existen y cuándo desaparecerán.
Un snapshot puede salvar una intervención. Un snapshot olvidado puede complicar todo un entorno.
Preguntas frecuentes
¿Un snapshot sirve como backup?
No. Un snapshot es un punto temporal de reversión y depende del entorno original. Un backup debe estar diseñado para recuperación, con retención, verificación y almacenamiento adecuado.
¿Cuánto tiempo debería mantenerse un snapshot?
En VMware, Broadcom recomienda no mantener snapshots más de 72 horas. En cualquier plataforma, lo prudente es que sean temporales y tengan una fecha de eliminación definida.
¿Qué problemas causa un snapshot antiguo?
Puede degradar el rendimiento, consumir mucho almacenamiento, complicar la consolidación y generar una falsa sensación de seguridad.
¿Es malo usar snapshots en VMware o Proxmox?
No. Son útiles para mantenimiento, actualizaciones y cambios controlados. El problema aparece cuando se dejan activos demasiado tiempo o se usan como sustituto de una copia de seguridad.
