¿Qué es exactamente un snapshot?
Para entender por qué no sustituye a un backup, primero hay que ver qué es y qué hace bien. Un snapshot, o instantánea, es una imagen del estado de un volumen o de una máquina virtual en un momento preciso. Técnicamente es un mecanismo de registro de cambios que se apoya en los discos originales: en lugar de copiar todo, anota las diferencias respecto al punto en que se creó. Eso lo hace casi mágico para ciertas tareas: se crea en segundos, ocupa poco al principio y permite revertir a un estado anterior muy rápido. Por eso es tan popular en los departamentos de sistemas: antes de aplicar una actualización delicada, desplegar una nueva versión de una aplicación o tocar la configuración de red, alguien crea un snapshot «por si acaso», y si algo sale mal, vuelve atrás en un instante.
¿Por qué un snapshot no es un backup?
La diferencia es de fondo y tiene consecuencias graves cuando se ignora. Un snapshot no es una copia autónoma: se apoya en los discos originales. Si pierdes el datastore, el host o el disco base se corrompe gravemente, los snapshots dejan de servir, porque dependen de ese mismo almacenamiento subyacente. Dicho claro: si la cabina o el RAID que aloja tus datos sufre una avería crítica, todo el almacenamiento queda comprometido, incluidos los snapshots, al estar ligados al mismo sistema. A eso se suman dos limitaciones igual de serias. La primera: los snapshots no protegen contra ransomware; es más, el ransomware moderno ejecuta comandos para borrar las copias sombra (VSS) y las instantáneas nada más entrar, precisamente para impedirte usar esos puntos de restauración. La segunda: no sirven para retención larga, porque acumularlos genera cadenas de archivos delta que consumen espacio y degradan el rendimiento; por eso VMware recomienda no mantener un snapshot más de 72 horas.
Entonces, ¿para qué sirven los snapshots?
Nada de esto significa que los snapshots sean inútiles; al contrario, son valiosos cuando se usan para lo suyo. Su gran virtud es ser una red de seguridad temporal e inmediata: justo antes de una actualización, una migración o un cambio de configuración, creas un snapshot y trabajas con la tranquilidad de poder deshacer el cambio en segundos si algo se tuerce. También son útiles para recuperarse de fallos lógicos menores —un error reciente, un archivo que se corrompió— sin tener que restaurar de una copia más lenta. Y cumplen un papel valioso en la propia estrategia de respaldo: un snapshot puede ser el punto consistente desde el que se toma un backup, garantizando que la copia capture un estado estable de los datos. La regla de oro es usarlos de forma temporal, con una fecha de eliminación definida, y no dejar que se conviertan, por inercia, en la única red que crees tener.
¿Qué sí es un backup?
Frente a esa instantánea atada al entorno, un backup es otra cosa: una copia consistente e independiente de los datos o de la máquina completa, almacenada fuera del ciclo de vida inmediato de la máquina original. ¿Dónde? En otra cabina o servidor distinto, en un segundo centro de datos o proveedor, o en un servicio en la nube. ¿Con qué disciplina? Con una política de retención e histórico —copias diarias, semanales, mensuales— y, cada vez más, con una copia inmutable que resista al ransomware. Hay una prueba de fuego muy simple para distinguirlos: si la supuesta copia depende del mismo almacenamiento y del mismo hipervisor, no es un backup; si puedes perder por completo el host o la cabina y aun así restaurar desde otro lugar, eso sí lo es. Esa independencia es justo lo que ordena la regla 3-2-1-1-0, y es la misma razón por la que sincronizar a la nube tampoco equivale a respaldar.
El error que se paga caro: confiar solo en snapshots
El escenario se repite con una frecuencia que asusta. Una empresa genera snapshots diarios de su servidor «para la recuperación rápida» y se queda tranquila, convencida de estar protegida. Hasta que un día la unidad física sufre una avería crítica de hardware, o entra un ransomware, y todo el almacenamiento queda comprometido: los datos y, con ellos, todos los snapshots. Por eso conviene ser tajante: los snapshots y los backups se complementan, no compiten, y cada uno cumple un papel. El snapshot te da agilidad para el día a día; el backup te da supervivencia ante el desastre. Confiar únicamente en snapshots es, como se suele decir, jugar con fuego, y es justo el tipo de confianza no probada que advertimos en un respaldo no probado no es un respaldo.
Agilidad y supervivencia, cada una en su sitio
La conclusión es sencilla de recordar: usa snapshots para moverte rápido y sin miedo en las operaciones del día a día, y backups para garantizar que, pase lo que pase con tu almacenamiento, tus datos sobrevivan en otro lugar. No es elegir entre uno y otro, es entender que resuelven problemas distintos. En Data Recovery Panama ayudamos a las empresas a montar esa arquitectura completa —snapshots para la agilidad, copias independientes e inmutables para la continuidad— y a comprobar que de verdad protege. Porque cuando llega el incidente, lo que cuenta no es cuántas instantáneas tenías, sino cuántas copias seguían vivas fuera del sistema que falló. Porque el laboratorio que recupera también protege.
Preguntas frecuentes
No. Un snapshot es un punto de reversión rápido que depende del almacenamiento y del entorno originales. Sirve para volver atrás ante un cambio reciente, pero no protege como una copia de seguridad almacenada de forma separada, verificable y recuperable. La prueba: si la supuesta copia depende del mismo disco o cabina que los datos, no es un backup.
Porque no es una copia autónoma: se apoya en los discos originales. Si el datastore, el host o el disco base falla o se corrompe, los snapshots se pierden junto con los datos. Además, no protegen frente a ransomware —que suele borrar las instantáneas al entrar— ni sirven para retención larga, porque acumularlos crea cadenas que consumen espacio y degradan el rendimiento.
Son excelentes como red de seguridad temporal: antes de una actualización, un despliegue o un cambio de configuración, creas un snapshot y, si algo sale mal, vuelves al estado anterior en segundos. También sirven para recuperarse de fallos lógicos menores y como punto consistente desde el que tomar un backup. Lo prudente es usarlos de forma temporal, con fecha de eliminación.
Una copia consistente e independiente de los datos o de la máquina completa, almacenada en otra cabina, otro centro de datos o la nube, con una política de retención y, idealmente, una copia inmutable. La clave es la independencia: si puedes perder por completo el host o la cabina originales y aun así restaurar desde otro lugar, eso es un backup.
Poco. Los fabricantes recomiendan que sean temporales: en VMware, no más de 72 horas. Un snapshot antiguo hace crecer los archivos delta, consume almacenamiento, degrada el rendimiento y genera una falsa sensación de seguridad. Lo correcto es darle una fecha de eliminación y apoyarse en una estrategia de backup probada para la protección real.