La mayoría de los tickets de recuperación que atendemos en Cybeward empiezan igual: un cambio salió mal y el cliente desearía haber tomado un snapshot antes. Casi siempre habrían podido hacerlo —toma segundos—, pero el hábito todavía no estaba ahí. Esta guía trata sobre construir ese hábito y sobre entender exactamente qué hace un snapshot por ti, para que no te apoyes en él para la tarea equivocada.
Cada plan de Santiago incluye dos slots de snapshot de fábrica. No pagas extra por usarlos, y puedes conservarlos, reemplazarlos o eliminarlos como prefieras.
Qué es realmente un snapshot
Un snapshot es una imagen en un instante determinado del disco de tu VDS. En el momento en que lo tomas, Cybeward registra el estado exacto del disco —archivos, paquetes, configuración, todo— y lo almacena en el mismo almacenamiento NVMe-on-Ceph que respalda tu servidor. Si un cambio posterior sale mal, reviertes y el disco vuelve a ese estado registrado.
Lo que no es: un respaldo externo. La imagen vive en el mismo clúster de almacenamiento que tu disco en vivo. Ceph mantiene múltiples réplicas, así que sobrevive a la falla de una unidad sin inmutarse, pero sigue estando operativamente cerca de tu VDS. Un snapshot te protege frente a tus propios cambios. No está diseñado para protegerte de una catástrofe que se lleve por delante todo el entorno, ni de una pérdida de datos que se acumula lentamente y que solo notas semanas después.
Un snapshot responde una sola pregunta: “¿puedo deshacer lo que acabo de hacer?”. Si tu pregunta es “¿puedo recuperarme de un desastre dentro de tres meses?”, necesitas un respaldo.
Cuándo tomar uno
La regla general es simple: toma un snapshot antes de cualquier cambio que odiarías tener que rehacer a mano. En la práctica eso significa:
- Antes de actualizaciones del sistema operativo — una actualización de kernel o librería que rompe el arranque es el caso clásico.
- Antes de cambios de configuración — editar
sshd_config, los vhosts del servidor web, reglas de firewall, cualquier cosa donde un error de tipeo te deje fuera. - Antes de despliegues de aplicaciones — una nueva versión que no arranca, o una migración que deja el estado hecho un desastre.
- Antes de migraciones — avanzar el esquema de una base de datos, o mover datos entre servicios.
El hilo común es que todos estos son reversibles en teoría pero dolorosos en la práctica. Un snapshot convierte “pasar la tarde reconstruyendo” en “hacer clic en revertir y volver a intentar”.
Atención. Un snapshot congela el disco, no el reloj. Todo lo que se escriba en disco después de tomarlo —nuevos pedidos, archivos subidos, entradas de log— se pierde si reviertes. Planifica considerando eso, especialmente en sistemas con mucho tráfico.
Cómo crear y revertir
Ambas acciones están en tu portal de Cybeward, en el área de snapshots de tu servidor. Crear uno es rápido:
1. Abre tu servidor en el portal 2. Ve a la pestaña Snapshots 3. Haz clic en "Crear snapshot" y dale un nombre claro 4. Espera a que el estado cambie a "listo"
Ponle un nombre acorde a lo que estás por hacer: before-php8.3-upgrade es mejor que snapshot-1 cuando vuelves en pánico. La imagen está lista en instantes; sobre NVMe-on-Ceph la captura es casi instantánea para tamaños de disco típicos.
Revertir es igual de directo:
1. Abre la pestaña Snapshots 2. Selecciona el snapshot que quieres 3. Haz clic en "Revertir" y confirma
El servidor vuelve al estado registrado. Recomendamos apagar el VDS (o al menos detener temporalmente tu base de datos) antes de una reversión, para que la imagen de disco a la que vuelves sea limpia y consistente.
Dónde los snapshots dejan de ser suficientes
Esta es la parte que la gente aprende por las malas, así que seremos directos: un snapshot no sustituye a los respaldos reales, especialmente para bases de datos.
Dos razones. Primero, la ubicación: los snapshots están en el mismo almacenamiento que tu disco en vivo. Los respaldos reales deberían estar en algún lugar que tu servidor no pueda arrastrar consigo. Segundo, la consistencia en un instante determinado. Una base de datos a la que se le toma un snapshot mientras está escribiendo puede revertir a una transacción a medio terminar. Para cualquier cosa con base de datos, ejecuta un respaldo lógico o físico apropiado (un pg_dump, un mysqldump, un stream de WAL) de forma programada, y mantenlo fuera de la máquina.
Los snapshots son tu botón rápido de deshacer para el cambio que estás haciendo ahora mismo. Los respaldos son tu red de seguridad para el futuro. Quieres ambos.
Comprar slots adicionales
Dos slots cubren la mayoría de los flujos de trabajo: una línea base “buena conocida” y otro que vas reciclando antes de cada cambio arriesgado. Pero si corres varios entornos en un solo servidor, haces despliegues por etapas, o quieres conservar un historial más largo, puedes comprar slots de snapshot adicionales desde el portal. Los slots de respaldo dedicados están disponibles de la misma forma, para esa protección externa y programada que los snapshots no pueden darte. Agrega lo que necesites, suéltalo cuando no, sin compromisos largos.
Toma un snapshot antes de…
Mantén esta lista en algún lugar visible. Si estás por hacer cualquiera de estas cosas, dedica diez segundos primero:
- ejecutar
apt upgradeo cualquier actualización de kernel - editar
sshd_config, reglas de firewall o redes - desplegar una nueva versión de la aplicación
- ejecutar una migración de base de datos
- cambiar cualquier cosa que no puedas reproducir fácilmente a mano
Construye el hábito y la mayoría de los momentos de “ayuda, lo rompí” se convierten en una reversión de treinta segundos. Y cuando realmente necesites recuperar datos de hace días, te alegrará haber configurado respaldos reales también, pero esa es una guía para otro día.
