“Tenemos backup”. Esa frase la he escuchado cientos de veces, y no la discuto: muchas veces el hosting hace copias automáticas. El problema es que, en una pyme, el día que pasa algo (una actualización que rompe, un borrado accidental, un fallo de proveedor), lo que te salva no es tener copias, sino poder restaurar sin improvisar.

Esto es un plan de 90 minutos para dejar una base decente. No es arquitectura avanzada: es orden operativo. Si tu web es WordPress, Laravel, Django o similar, el patrón es el mismo: archivos + base de datos, guardados fuera del servidor, y una prueba mínima de recuperación.

Paso 1 (10–15 min): aclara qué web tienes y dónde vive. Apunta: proveedor (hosting/VPS/cloud), dominio, acceso al panel, y dónde está la base de datos (suele ser MySQL/PostgreSQL). Parece obvio, pero el error típico es que solo una persona sabe “dónde se toca”. Si no encuentras esta info rápido, ya tienes una tarea pendiente.

Paso 2 (20–30 min): saca una copia manual de base de datos y archivos. La base de datos es lo que más duele perder (pedidos, formularios, usuarios). Los archivos suelen ser el código, imágenes y subidas. Hazlo con las herramientas del hosting (panel) o con tu proveedor. Mi criterio: si no puedes obtener ambos en un zip/descarga, no lo consideres un backup “tuyo”.

Paso 3 (10–15 min): guarda una copia fuera del servidor. Si la copia vive en el mismo hosting, no es una red de seguridad; es una comodidad. Guárdala en un almacenamiento externo (por ejemplo, Drive/Dropbox/S3) con una carpeta clara por fecha. Trade-off: tener copias fuera cuesta algo (dinero u organización), pero es lo que te permite sobrevivir a fallos del proveedor o a accesos comprometidos.

Paso 4 (20–25 min): prueba una restauración mínima. No hace falta montar una infraestructura completa. Lo mínimo: crea un entorno de prueba (staging) si lo tienes, o un subdominio temporal, o una instalación local si tienes alguien técnico. El objetivo es comprobar dos cosas: que la base de datos se importa y que la web “arranca”. Si no puedes probarlo, al menos documenta el paso a paso y quién lo ejecutaría. Una copia que no has probado es una apuesta.

Paso 5 (10–15 min): define frecuencia y responsable. ¿Cada cuánto cambia tu web? Si es un e-commerce, diario. Si es corporativa con pocas ediciones, semanal puede bastar. Nombra a un responsable (persona, no “la empresa”) y pon un recordatorio mensual para verificar que el backup sigue generándose y que el acceso al almacenamiento externo funciona.

Errores comunes (y cómo detectarlos): 1) Backup sin base de datos. Lo detectas porque solo tienes un zip de “archivos” y, al restaurar, faltan pedidos o formularios. 2) Copias en el mismo servidor. Lo detectas porque todo está “en el panel del hosting” y no existe fuera. 3) No saber restaurar. Lo detectas porque nadie puede describir el proceso en 5 pasos y 10 minutos. Si pasa eso, en un incidente vas a perder horas.

Cómo medir si lo has hecho bien: (1) tiempo que tardas en localizar la última copia (objetivo: menos de 2 minutos), (2) tiempo estimado de recuperación (aunque sea una aproximación), y (3) pérdida máxima de datos aceptable: ¿puedes permitirte perder 24h de pedidos? Si no, sube frecuencia.

Cuándo compensa delegar: si tu web factura, capta leads a diario o está integrada con pagos/CRM, delegaría cuando no tengas staging o cuando la restauración te parezca “un misterio”. Ahí merece la pena montar un sistema automático y probado (copias programadas, retención, alertas de fallo y una restauración ensayada). El coste de una mañana de web caída suele ser mayor que hacerlo bien.