Dos herramientas que no hacen la misma promesa
Un snapshot congela el estado de un disco en un instante para poder volver a él rápido. Una copia de seguridad guarda los datos en otro sitio, con un historial, para poder reconstruir tras una pérdida. En los paneles de alojamiento las dos palabras circulan como sinónimos, y de ahí nace el malentendido: el botón de snapshot tranquiliza, aunque solo responde a una parte de los siniestros.
Para una agencia que aloja sitios de clientes en VPS, el matiz tiene un coste directo. El día que una máquina desaparece, el cliente no pregunta si existía un snapshot: pregunta cuándo vuelve su sitio y con qué datos. Este artículo ofrece un criterio sencillo para elegir, VPS por VPS, entre volver atrás y reconstruir, y una forma de escribirlo en el contrato.
Lo que un snapshot hace muy bien
- Vuelta atrás en minutos — antes de una actualización de versión, un cambio de configuración o una migración, regresar al estado anterior es rápido.
- Un punto de referencia con fecha — se sabe exactamente a qué instante se vuelve, lo que simplifica el diagnóstico tras un incidente.
- Sin reconstrucción que hacer — la máquina arranca tal como estaba, con los ajustes del sistema incluidos.
- Un gesto accesible — un clic o un comando en el panel, sin herramienta que instalar ni repositorio que configurar.
- Adecuado para pruebas — probar una actualización en el sitio de un cliente conservando una salida de emergencia.
- Útil antes de una intervención humana — un error de administración se corrige sin una restauración larga.
La objeción: «ya tengo snapshots»
Un snapshot suele vivir en el mismo proveedor, en el mismo almacenamiento y bajo la misma cuenta que la máquina. Por tanto comparte sus averías. Si la VM se elimina, por error o por un impago, los snapshots asociados pueden desaparecer con ella según el proveedor. Si la cuenta de alojamiento se ve comprometida, quien entra puede borrar la máquina y sus snapshots de un solo gesto. Si el almacenamiento subyacente sufre un incidente, la copia y el original caen juntos.
Se suman dos límites. Un snapshot es coherente a nivel de disco, no a nivel de aplicación: una base de datos en plena escritura puede aparecer en un estado inacabado. Y un snapshot nunca es una prueba de restauración: mientras no se haya releído, es una hipótesis.
Contraobjeción honesta: nada de esto vuelve inútil al snapshot. Sigue siendo la herramienta más rápida para volver atrás antes de una operación arriesgada. No hay que tirarlo; hay que dejar de pedirle lo que no sabe hacer.
Snapshot y copia de seguridad fuera de la máquina, criterio por criterio
Desplace la tabla
| Criterio | Snapshot | Copia fuera de la máquina |
|---|---|---|
| Ubicación | Casi siempre en el mismo proveedor, en el mismo almacenamiento | Fuera del proveedor de la VM, en un almacenamiento distinto |
| Sobrevive a la eliminación de la VM | Depende: según la oferta, puede desaparecer con la máquina | Sí, la copia existe con independencia de la máquina |
| Sobrevive a la compromisión de la cuenta de alojamiento | No, mismas credenciales que la VM | Sí, si los accesos al repositorio están separados de la cuenta de alojamiento |
| Coherencia de la aplicación | Solo coherencia del disco | Posible con una exportación de la aplicación hecha antes de copiar |
| Duración de conservación | Corta, a menudo unos pocos puntos recientes | Larga, con historial y una retención elegida |
| Velocidad de vuelta atrás | Muy rápida | Más lenta: hay que volver a copiar los datos |
| Cifrado antes de la transferencia | Rara vez bajo su control | Posible, con una clave que usted conserva |
| Prueba de restauración | Ninguna hasta que se prueba | Ninguna hasta que se prueba, de ahí la prueba programada |
Coherencia de la aplicación: la trampa de la base de datos
Copiar un disco mientras una base de datos escribe es como fotografiar una página mientras se pasa. El sistema de archivos está sano, pero la base puede contener una transacción a medias, y a veces se recupera tras una fase de reparación y a veces no. El remedio es generar una exportación coherente de la base antes del snapshot o de la copia, y luego incluirla en lo que se respalda.
En PostgreSQL, el comando documentado es pg_dump, que genera una exportación coherente incluso mientras la base atiende consultas. En MySQL y MariaDB con tablas InnoDB, mysqldump --single-transaction lee un estado coherente sin bloquear las escrituras. En ambos casos el archivo de exportación se une a la copia, y es el que se restaura primero. Esto vale tanto para un snapshot como para una copia de archivos: el disco por sí solo no garantiza nada sobre el estado lógico de la base.
Cuatro siniestros, cuatro protecciones
Desplace la tabla
| Siniestro | Qué protege | Por qué |
|---|---|---|
| Una actualización rompe el sistema | Un snapshot tomado justo antes | Vuelta atrás rápida a un estado conocido |
| Un archivo o una tabla borrados por error, descubiertos varios días después | Una copia con historial | El snapshot reciente ya contiene el error: hace falta un punto más antiguo |
| VM eliminada o cuenta de alojamiento comprometida | Una copia fuera del proveedor | La copia no depende ni de la máquina ni de la cuenta |
| Corrupción silenciosa descubierta tarde | Una copia con retención larga | Hay que remontarse a antes de la fecha en que los datos empezaron a degradarse |
La regla de decisión en una frase
Snapshot: vuelta atrás corta antes de una operación arriesgada. Copia de seguridad: capacidad de reconstruir tras perder la máquina o la cuenta.
Si la pregunta es «¿puedo deshacer lo que voy a hacer en la próxima hora?», responde el snapshot. Si la pregunta es «¿qué queda si esta máquina o esta cuenta ya no existen mañana?», solo responde la copia fuera de la máquina. Un VPS de cliente serio tiene por tanto ambos, con funciones que no se solapan.
Los dos no compiten. El snapshot se toma antes de la intervención y se elimina una vez validado el resultado, mientras que la copia se ejecuta según un calendario fijo, sin que nadie tenga que lanzarla a mano. Confundir estos ritmos causa la mayoría de las malas sorpresas: un snapshot olvidado durante semanas ocupa espacio y protege muy poco, y una copia lanzada solo antes de las grandes obras deja huecos en el historial.
Aplicar la regla a cada VPS de cliente
Inventariar los VPS y lo que alojan
Para cada máquina, anote los sitios, las bases de datos, los archivos subidos y la criticidad para el cliente.
Fijar la pérdida de datos aceptable
Pregunte cuántas horas de datos puede perder el cliente. Ese valor es el RPO: dicta la frecuencia de la copia.
Fijar el plazo de recuperación aceptable
Pregunte cuánto tiempo puede estar el sitio fuera de línea. Ese valor es el RTO: dicta el método de reconstrucción.
Colocar la copia fuera del proveedor de la VM
Use un almacenamiento distinto, con credenciales diferentes de las de la cuenta de alojamiento, y cifre antes de enviar con una clave que conserve.
Añadir la exportación de la base antes de cada copia
Ejecute
pg_dumpomysqldump --single-transactionsegún el motor, e incluya el archivo resultante en el conjunto respaldado.Reservar el snapshot para operaciones arriesgadas
Tome un snapshot antes de cada actualización de versión o cambio importante y elimínelo una vez validado el resultado.
Probar la restauración: sin prueba, una hipótesis
Una copia que nunca se ha restaurado en una prueba es solo una hipótesis. La diferencia entre snapshot y copia de seguridad también se juega en la prueba: solo un ejercicio de restauración cronometrado dice si el sitio arranca y cuánto tarda.
Nuestra guía sobre el procedimiento de prueba de restauración para una agencia detalla el ejercicio trimestral en un VPS desechable, la medición del RTO y el RPO observados y el registro que se entrega al cliente. No lo repetimos aquí. Quédese con el principio: programar la prueba, fecharla y corregir lo que revela, ya sean accesos que faltan, secretos ausentes o una versión de software distinta.
Para la puesta en marcha de una herramienta, la guía sobre la estrategia 3-2-1 con Restic y S3 resume en un párrafo lo que un snapshot del proveedor no garantiza y luego muestra una copia fuera del proveedor en la práctica. Este artículo se mantiene conceptual a propósito: sirve para decidir, no para instalar.
Escribir la regla en el contrato
El contrato de una agencia gana si dice qué se protege, con qué mecanismo y con qué objetivo, en lugar de prometer «copias de seguridad». Bastan tres elementos: el RPO, es decir la pérdida máxima de datos aceptada; el RTO, es decir el plazo previsto para restablecer el servicio; y el mecanismo que sostiene ambos valores.
Ejemplo ficticio, para adaptar y no copiar tal cual: «Los datos del sitio se copian cada noche a un almacenamiento situado fuera del alojamiento de la máquina, con una conservación de varios meses. El prestador se compromete a un RPO de 24 horas y a un RTO de 8 horas tras la decisión de restaurar. Se toma un snapshot antes de cada actualización importante y se elimina tras la validación. Se realiza una restauración de prueba cada trimestre y su registro se entrega al cliente.»
Estas cifras son inventadas para ilustrar. Las suyas deben salir de sus propias mediciones de restauración, no de una intención.
Antes de la operación arriesgada: snapshot y copia verificada
Antes de una actualización de versión, tome el snapshot, pero compruebe también que la última copia fuera de la máquina es reciente y legible. El snapshot sirve si la operación falla enseguida. La copia sirve si el problema aparece tres días después, cuando el snapshot ya se ha eliminado.
Una política por cliente y lo que ServOrbit pone a su alcance
Una agencia puede llevar su política de copias en una tabla: una línea por cliente, con el RPO, el RTO, el mecanismo y la fecha de la última prueba.
En alojamiento web, las copias son semanales en la gama de entrada, diarias en la oferta Pro y en todas las ofertas de revendedor, con una copia diaria premium disponible como opción. En un VPS, la existencia y las condiciones de los snapshots dependen de la oferta de su proveedor: compruébelas en la documentación del panel antes de escribirlas en un contrato y no las cuente nunca como su única copia.
