Casi todo el mundo tiene algo configurado para hacer copias de seguridad. El problema es que «tener una copia» y «poder restaurar en un momento crítico» son dos cosas muy distintas. Una copia que nunca se ha probado no es una copia: es una esperanza.
El principio 3-2-1 es el punto de partida: 3 copias, en 2 soportes distintos, con 1 copia fuera del sitio. Y a eso hay que añadir lo que pocas veces se dice: las copias tienen que estar cifradas, tiene que haber un periodo de retención definido, y hay que probar la restauración de forma periódica, no el día que hace falta.
Me encargo de diseñar, implementar y mantener la estrategia de backup de tu infraestructura, sin depender de lo que ofrezca el hosting como copia de seguridad incluida.
Problemas habituales
- La copia está en el mismo servidor. Si el servidor muere, el disco falla o hay un ransomware, te llevas la copia por delante también. Una copia en el mismo sitio no es una copia de seguridad real.
- Las copias del hosting. Los backups que incluye el hosting suelen estar en la misma infraestructura, con retención corta y sin cifrado. Funcionan para errores menores; para desastres reales, no son suficientes.
- Sin cifrado. Las copias contienen datos de clientes, pedidos, credenciales. Si se almacenan en texto claro en un bucket externo, es un problema de seguridad y de cumplimiento normativo.
- Nadie ha probado restaurar nunca. La copia existe, pero el proceso de restauración no se ha ejecutado en condiciones reales. Cuando hay que usarla con urgencia es el peor momento para descubrir que falla.
- Retención insuficiente. Un error que pasa desapercibido varios días necesita poder volver atrás más de 24 horas. Sin retención suficiente, algunos escenarios son irrecuperables.
Cómo lo planteo
El diseño de la estrategia parte de las necesidades reales: qué hay que proteger, con qué frecuencia cambian los datos, cuanto tiempo se puede permitir estar sin servicio (RTO) y hasta qué punto en el tiempo se puede recuperar (RPO). No hay una solución igual para todos los proyectos.
A partir de ahí, la implementación incluye automatización, verificación de integridad, rotación de backups y documentación del proceso de restauración, que es lo que de verdad importa cuando hay que usarla.
Qué incluye
Diseño de la estrategia
- Definición de RPO (cuanta información te puedes permitir perder) y RTO (en cuanto tiempo necesitas estar operativo).
- Identificación de que hay que proteger: base de datos, ficheros, configuraciones, volúmenes de datos.
- Selección de destinos externos: almacenamiento en la nube (S3, Backblaze B2, Hetzner Storage Box u otros), servidor de backup propio u offsite.
Implementación
- Copias automatizadas con frecuencia adecuada al ritmo de cambio de los datos (por hora, diaria, semanal).
- Cifrado de las copias en origen antes de salir del servidor (GPG, restic, duplicati u otros).
- Transferencia segura al destino externo con verificación de integridad.
- Rotación y retención configuradas: copias diarias, semanales y mensuales según el caso.
- Alertas si una copia falla o no se ejecuta en el tiempo esperado.
Verificacion y pruebas
- Prueba de restauración periódica en entorno de staging para confirmar que la copia es utilizable.
- Verificación de integridad automática de los ficheros de backup.
- Documentación del proceso de restauración paso a paso, para que cualquiera del equipo pueda ejecutarlo bajo presión.