Tus copias de seguridad: ¿de verdad funcionan cuando las necesitas?

"Tenemos copias de seguridad" es una frase que muchos gerentes dicen con confianza total. Pero cuando llega el momento de usar esas copias porque el servidor ha fallado, porque el ransomware ha cifrado todo, o porque alguien ha borrado la base de datos equivocada, a menudo descubren que la copia no funciona, está incompleta, lleva semanas sin actualizarse, o es de un sistema que ya no se usa mientras los datos críticos actuales nunca se incluyeron. Tener backups y poder restaurar son dos cosas muy distintas, y la diferencia entre ellas puede ser la diferencia entre una tarde de trabajo perdida y una semana de crisis empresarial.

Por qué los backups fallan cuando más se necesitan

Los errores más comunes que encontramos en auditorías de sistemas de backup:

• El backup lleva semanas fallando en silencio. Si nadie revisa los logs o las alertas de fallo, el proceso puede estar fallando desde hace tiempo sin que nadie lo sepa. El log dice "completado" si el proceso terminó, aunque haya terminado con errores parciales. Hay que revisar los detalles, no solo el estado general.
• Se hace copia de lo incorrecto. Se hace copia de la carpeta de documentos pero no de la base de datos del ERP, que es lo que realmente importa. O se hace copia del directorio de instalación de la aplicación pero no de los datos que genera. El inventario de qué hay que copiar y dónde están esos datos es previo al sistema de backup.
• La copia está en el mismo sitio que los datos. Una copia en el mismo servidor que va a fallar no sirve de nada. Una copia en el mismo edificio que puede incendiarse tampoco. Una copia en la misma red que el ransomware va a cifrar también, a menos que sea inmutable.
• El ransomware la ha eliminado. Los ataques modernos localizan y eliminan o cifran los sistemas de backup antes de ejecutar el cifrado de los datos principales. Si tu backup puede ser borrado por el mismo usuario que tiene acceso al servidor, el ransomware que comprometa esa cuenta también puede borrarlo.
• Nunca se ha probado la restauración. La prueba definitiva de un backup es restaurar datos reales en un entorno de trabajo y verificar que son accesibles, completos y coherentes. Si nunca se hace, no se sabe si funciona hasta que es imprescindible.
• Las bases de datos se copian en caliente sin agente específico. Copiar el fichero de una base de datos mientras está en uso puede generar una copia en estado inconsistente. Los agentes de backup específicos para SQL Server, MySQL, PostgreSQL u Oracle gestionan esto correctamente; una copia de fichero directa no.

Cómo verificar que tus copias funcionan: proceso práctico

Un proceso de verificación básico que cualquier empresa puede implementar:

• Revisión diaria de logs de backup. No solo el estado (completado/fallido), sino los detalles: cuántos ficheros, cuánto espacio, si hay errores específicos registrados. Esta revisión debería tomar menos de 5 minutos y debería generarse un alerta automática cuando algo no está bien.
• Comprobación semanal del tamaño de las copias. Si una copia que normalmente ocupa 50 GB de repente ocupa 2 GB, algo ha fallado en el proceso. Un cambio significativo en el tamaño es una señal de alerta que no requiere entender los logs técnicos para detectar.
• Restauraciones de prueba trimestrales. Al menos una vez cada tres meses, restaurar un conjunto de datos reales (la base de datos del ERP de la semana anterior, por ejemplo) en un entorno de test separado. Verificar que los datos son accesibles, que la aplicación puede leerlos y que son coherentes con lo que se esperaba en esa fecha.
• Verificación de la copia offsite mensual. Si tienes replicación a nube u otra ubicación, comprobar que el último envío completó, que el acceso a la copia funciona con las credenciales actuales, y que los datos del mes anterior están accesibles.

El servicio de servidores NAS y copias de seguridad incluye este proceso de verificación como parte del mantenimiento regular: no solo que el sistema esté configurado, sino que alguien con criterio técnico revisa y actúa sobre los resultados de cada ciclo de backup.

Qué datos son realmente críticos: prioriza antes de copiar todo

No hace falta hacer copia de todo con la misma frecuencia ni con el mismo nivel de redundancia. El punto de partida es una clasificación de datos por criticidad para el negocio. Hay tres categorías relevantes: datos críticos operativos (si se pierden, la empresa no puede operar), datos importantes pero recuperables (si se pierden, hay trabajo y coste pero la empresa puede seguir), y datos históricos o de referencia (si se pierden, hay una pérdida de información pero no impacta la operativa inmediata).

Los datos críticos operativos típicos en una pyme: base de datos del ERP o sistema de gestión, base de datos de clientes y CRM, contabilidad y datos fiscales del ejercicio en curso, contratos vigentes y documentos con valor legal. Estos necesitan backup diario, verificado, en al menos dos ubicaciones, con inmutabilidad o protección equivalente. Los demás pueden tener cadencias menos exigentes.

Un despacho de arquitectura de Málaga con 9 empleados descubrió en una auditoría que tenía un sistema de backup robusto para los proyectos en curso, pero que la base de datos de presupuestos y clientes de la aplicación de gestión de proyectos se almacenaba en un directorio diferente al que se estaba copiando, porque nadie actualizó la configuración de backup cuando migraron a la nueva aplicación hace tres años. Esos datos existían desde 2021 sin ningún tipo de copia. La revisión del alcance del backup es tan importante como la verificación del proceso.

RPO y RTO: los dos números que definen tu estrategia de backup

El RPO (Recovery Point Objective) define cuánta antigüedad de datos puedes permitirte perder en caso de necesitar restaurar. Si el RPO es de 24 horas, el backup tiene que ser al menos diario. Si el RPO es de 4 horas, necesitas backup cada 4 horas o algún tipo de replicación continua. El RPO no es un número técnico: es una decisión de negocio. ¿Cuántos datos puede permitirse perder tu empresa? ¿Puedes reconstruir las transacciones del día anterior si las perdes? ¿O cada hora de datos perdida supone un impacto económico directo?

El RTO (Recovery Time Objective) define cuánto tiempo puede estar la empresa sin operar hasta recuperar los sistemas críticos. Si el RTO es de 4 horas, el sistema de backup tiene que permitir una restauración completa en menos de 4 horas. Si el sistema actual tarda 3 días en restaurar porque la copia está en cinta física en un almacén, y el negocio no puede estar 3 días parado, hay una discrepancia entre la realidad y los objetivos que necesita resolverse antes de que sea una emergencia.

Consulta también el artículo sobre las señales de que tu sistema de backups es inseguro para un diagnóstico más completo del estado de tu estrategia de copias. Y si quieres entender el contexto más amplio de continuidad de negocio, el servicio de servidores NAS y copias incluye el diseño de una estrategia adaptada a tu RPO y RTO específicos.

Tabla: verificación de backup por frecuencia

Por dónde empezar mañana

1. Abre los logs de tu sistema de backup y revisa los últimos 30 días. ¿Hay errores? ¿Ha habido algún día sin copia? ¿El tamaño de las copias es consistente? Si no tienes acceso a los logs o no sabes dónde están, ese es el primer problema a resolver.
2. Define tu RPO y RTO antes de cualquier otra cosa. ¿Cuántas horas de datos puede perder tu empresa? ¿Cuánto tiempo puede estar parada? Esas dos preguntas definen qué tipo de sistema de backup necesitas. Si el sistema actual no cumple esos objetivos, hay que rediseñarlo.
3. Intenta restaurar un fichero de la copia de ayer. No un fichero completo del servidor: solo un documento o una tabla de la base de datos, en un equipo alternativo. Si no puedes hacerlo en menos de 30 minutos, el proceso de restauración tiene un problema que necesitas conocer antes de una emergencia real.
4. Comprueba que todos los sistemas críticos están en el alcance del backup. Haz una lista de todas las aplicaciones que generan datos importantes para el negocio y verifica que cada una está explícitamente incluida en la configuración de backup. Ningún sistema debería estar protegido "por defecto" sin verificación explícita.