¿Y si el servidor se cae mañana? El plan de recuperación que sí funciona
La mayoría de las PyMEs tiene "backups" que jamás se han probado. El día que falla el disco descubren que no se puede restaurar nada. Aquí está el plan que usamos nosotros, en lenguaje simple, para volver a producción en horas — no en días.
Casi todos los negocios que dependen de un servidor en internet tienen una conversación incómoda pendiente: "¿qué pasa si esto se cae mañana y no vuelve?"
La mayoría responde con una mezcla de "tenemos backups" y "el proveedor seguro tiene algo". Cuando se rasca un poco, aparece la realidad: nadie ha probado los backups, no se sabe dónde están guardados, y no hay un orden para restaurarlos. Eso no es un plan. Es una esperanza.
Qué es un plan de recuperación de verdad
Un plan de recuperación responde tres preguntas concretas, antes de que ocurra el problema:
- ¿Qué tenemos que recuperar? No todo es igual. La base de datos del e-commerce vale más que las imágenes de tu blog.
- ¿Cuánto puedes perder? Si el último backup fue hace 24 horas, perdiste un día de ventas. Esa cifra debe ser una decisión, no un accidente.
- ¿Cuánto tarda volver a producción? Si la respuesta es "no sé", ya tienes un problema. Si es "una semana", también.
En la industria a esos dos números se les llama RPO (cuánto puedes perder) y RTO (cuánto tarda volver). Tú no necesitas saber los acrónimos. Necesitas que alguien los haya pensado por tu negocio.
El plan que usamos en los servidores que administramos
No es teoría. Es lo que corre todos los días, automáticamente, sin que nadie tenga que acordarse:
1. Backup de bases de datos — todos los días
A las 2 de la mañana, un proceso automático copia todas las bases de datos del servidor (las que guardan tus clientes, pedidos, productos, lo que sea). Esa copia se guarda primero en el mismo servidor con 7 días de retención.
2. Copia fuera del servidor — todos los días
Inmediatamente después, esa copia se sube a un almacenamiento externo (en nuestro caso, S3 de Amazon). Si el servidor entero deja de existir, los datos siguen vivos en otro lado, con 30 días de retención.
3. Backup de configuraciones — todos los días
A las 3 de la mañana, otro proceso copia las configuraciones del servidor: archivos .env con credenciales, archivos de Docker, scripts, certificados. Esto es lo que la gente olvida. Si pierdes esto, tienes que reinstalar todo desde cero a mano.
4. Backup de volúmenes críticos — los domingos
Una vez por semana se respalda lo más pesado: archivos subidos por los usuarios, índices de búsqueda, paneles de monitoreo con su histórico. Lo guardamos por 60 días fuera del servidor.
5. El runbook escrito
Aquí está el detalle que casi nadie tiene: un documento paso a paso de qué hacer si todo se cae. Desde "levanta un servidor nuevo en este proveedor con esta imagen" hasta "ejecuta este comando para restaurar la base de datos del último backup". Sin ese documento, en plena emergencia, nadie sabe por dónde empezar.
Cuánto tarda volver a producción
En la práctica: 2 a 4 horas, dependiendo del tamaño de los datos a descargar. La mayor parte del tiempo no es "configurar de nuevo" — eso ya está automatizado. El tiempo se va en transferir los archivos del backup al servidor nuevo.
Cuatro horas suena largo si nunca te ha pasado. Es excelente si lo comparas con los negocios que descubren a media crisis que su único backup era el respaldo de hace seis meses que el ex-administrador hizo en una USB.
Lo que pasa cuando NO tienes este plan
Hemos visto los tres escenarios típicos:
- "Tenemos backups" → resulta que el script falló hace 4 meses sin que nadie se enterara, porque nadie revisaba los logs.
- "El proveedor tiene snapshots" → resulta que el último snapshot fue antes del último cambio importante en la base de datos. Restauras, pero pierdes 2 semanas de pedidos.
- "Tengo todo en mi computadora" → la computadora se daña el mismo día que el servidor (o se la roban, o el disco muere). Adiós.
En los tres casos el negocio se detiene varios días. Y en muchos casos se pierde data definitivamente.
Lo mínimo que tu negocio debería tener
Si tu sitio o tu app vive de los datos —y casi todos viven de los datos— deberías poder responder hoy estas preguntas:
- ¿Cuándo fue el último backup que se probó restaurando?
- ¿Dónde están guardados los backups? ¿En el mismo servidor o fuera?
- Si el servidor desaparece ahora mismo, ¿quién y cómo lo levanta de nuevo?
- ¿Cuánto tiempo te toma volver a vender?
- ¿Cuántos días de información puedes permitirte perder?
Si no tienes respuesta clara para alguna, tu negocio está más expuesto de lo que crees.
La parte que sí o sí debes probar
Probar el backup no es opcional. Es parte del plan. Cada cierto tiempo —en nuestros servidores, una vez al mes— hacemos un simulacro: levantamos un servidor nuevo desde cero, descargamos el backup más reciente, lo restauramos, y confirmamos que la aplicación arranca y funciona. Si algo falla, lo arreglamos antes de que lo necesites de verdad.
Un backup que jamás se restauró no sabes si funciona. Es un papel guardado en un cajón que dice "rompe el cristal en caso de emergencia" y nadie ha verificado que el martillo sirva.
En ServerStack Solutions
En todos los servidores que administramos, este plan viene configurado desde el primer día: backups automatizados, copia fuera del servidor, runbook escrito y simulacros periódicos de restauración. Tú no tienes que recordar nada. Si ocurre lo peor, sabemos exactamente qué hacer.
Solicita una evaluación de tu plan actual de backups. En 30 minutos te decimos qué tienes, qué te falta y cuánto cuesta cerrar las brechas. Sin tecnicismos.
Relacionado: Caso real: servidor blindado sin puertos expuestos · Arquitectura segura completa · SSH cerrado sin perder deploys.
Preguntas frecuentes
¿Qué tan seguido deberían hacerse los backups?
Depende de cuánta data puedes perder. Para la mayoría de PyMEs, backup diario de base de datos es el mínimo razonable. Si manejas pedidos en línea con alto volumen, puede convenir cada hora. Lo importante es que sea automático y que la frecuencia sea una decisión consciente, no un accidente.
¿Es suficiente con los snapshots del proveedor?
No, no son suficientes por sí solos. Un snapshot del proveedor te protege contra un fallo de hardware del servidor, pero no contra un borrado accidental, un ataque de ransomware o un error humano que ya se replicó al snapshot. Necesitas backups en un sistema separado y, sobre todo, que se prueben restaurándolos.
¿Cuánto cuesta tener backups en S3 u otro almacenamiento externo?
Para la mayoría de PyMEs, el costo de almacenamiento externo es entre 1 y 5 USD al mes. La parte cara nunca es el almacenamiento — es no tenerlo cuando lo necesitas. Si tu negocio depende del servidor, este es de los gastos de mejor relación costo-beneficio que existen.
¿Puedo probar el backup sin afectar producción?
Sí, y así debe hacerse. La prueba se levanta en un servidor temporal aparte, sin tocar el sitio que está vivo. Se restaura el backup ahí, se valida que la aplicación arranca y que los datos están completos, y se apaga ese servidor temporal. Si algo falla, lo arreglas antes de que lo necesites de verdad. Lo recomendamos al menos una vez al mes.