El día que un servidor deja de responder, el problema no es técnico: es operativo. Facturas que no se emiten, pedidos que no salen, expedientes inaccesibles y equipos esperando una respuesta. Un esquema de respaldo local y nube no consiste en guardar archivos en dos lugares por precaución. Debe permitir recuperar la información correcta, en el orden necesario y dentro del tiempo que la empresa puede asumir sin comprometer clientes, ingresos o reputación.
Para Dirección, la pregunta relevante no es cuántos terabytes se copian cada noche. Es cuánto tiempo puede funcionar la empresa sin su ERP, correo, máquinas virtuales, archivos comerciales o entorno Microsoft 365. Para TI, el reto es traducir esa respuesta en una arquitectura verificable, protegida ante ransomware y documentada para actuar bajo presión.
El riesgo no es perder datos: es no poder operar
Una copia de seguridad puede existir y, aun así, no resolver una incidencia. Ocurre cuando el respaldo está incompleto, no incluye las configuraciones necesarias, tarda demasiado en restaurarse o ha sido cifrado por el mismo ataque que afectó al entorno productivo.
El ransomware ha convertido esta diferencia en una cuestión crítica. Los atacantes ya no se limitan a cifrar servidores y estaciones de trabajo. Buscan credenciales administrativas, borran puntos de restauración, desactivan servicios de copia y alcanzan repositorios que permanecen conectados de forma permanente. Si la única copia accesible está en la misma red, el respaldo puede convertirse en otra víctima.
También existen incidentes menos visibles, pero igual de costosos: una eliminación accidental en Microsoft 365, una base de datos dañada tras una actualización, el fallo de un almacenamiento local o un error de configuración que se detecta semanas después. En esos casos, restaurar el último archivo disponible no siempre basta. Puede ser necesario volver a un punto específico en el tiempo.
Respaldo local y nube: por qué conviene combinar ambos
El respaldo local aporta velocidad. Cuando se necesita recuperar un archivo, una máquina virtual o una aplicación desde una copia ubicada en la propia oficina o centro de datos, se evita depender de la conexión a internet y del tiempo de descarga. Esto es especialmente útil para restauraciones de gran volumen y para sistemas que no pueden permanecer detenidos durante horas.
La nube aporta aislamiento geográfico. Si hay un incendio, robo, fallo eléctrico prolongado, daño físico en el almacenamiento o un incidente que compromete toda la red local, una copia fuera de las instalaciones preserva una vía alternativa de recuperación. Además, permite proteger sedes distribuidas bajo una política centralizada.
La combinación responde a dos necesidades diferentes: restaurar rápido y sobrevivir a un incidente mayor. No obstante, no todas las empresas requieren la misma proporción de almacenamiento local y externo. Una organización con máquinas virtuales pesadas puede priorizar una copia local para acelerar la recuperación. Una empresa con varias oficinas, personal remoto y fuerte dependencia de Microsoft 365 puede necesitar mayor cobertura en nube y controles de acceso más estrictos.
La regla 3-2-1-1-0 como base práctica
Una referencia útil es la regla 3-2-1-1-0. Significa mantener al menos tres copias de los datos, en dos tipos de soporte distintos, con una copia fuera de la ubicación principal, otra inmutable o aislada, y cero errores verificados en las copias.
La última parte es la que suele olvidarse. Cero errores no significa confiar en el panel de una herramienta que indica “copia completada”. Significa revisar alertas, comprobar la integridad de los datos y realizar restauraciones de prueba. Una copia no probada es una hipótesis, no un plan de continuidad.
La copia inmutable marca una diferencia real
La inmutabilidad impide modificar o eliminar una copia durante un periodo definido. Bien configurada, reduce la posibilidad de que un atacante con acceso administrativo borre los respaldos para presionar a la empresa a pagar un rescate.
Este control debe acompañarse de cifrado, preferiblemente AES-256, autenticación multifactor para las cuentas administrativas, segregación de credenciales y retención acorde al negocio. La tecnología protege, pero la configuración y el gobierno determinan si esa protección funciona cuando más se necesita.
Qué debe incluir una política de copias de seguridad
El primer paso no es elegir una plataforma. Es elaborar un inventario de activos críticos y clasificarlos según su impacto operativo. No todos los datos tienen el mismo valor ni requieren la misma frecuencia de respaldo.
Una política completa suele contemplar, como mínimo:
- Servidores físicos, máquinas virtuales y configuraciones de aplicaciones críticas.
- Bases de datos de ERP, CRM, contabilidad, producción o gestión de clientes.
- Archivos compartidos, repositorios documentales y equipos de usuarios clave.
- Correo, OneDrive, SharePoint y Teams en Microsoft 365.
- Configuraciones de firewall, dispositivos de red y sistemas de seguridad.
La inclusión de Microsoft 365 merece atención especial. Que los datos estén en una plataforma cloud no elimina la responsabilidad de protegerlos. Las opciones de retención estándar no sustituyen una estrategia de respaldo diseñada para recuperar buzones, archivos, sitios o elementos eliminados según las necesidades de la empresa.
También es fundamental definir cuánto histórico conservar. Un periodo demasiado corto puede impedir recuperar información dañada de forma silenciosa. Uno excesivo puede incrementar el coste y complejidad sin aportar valor. La decisión debe responder a requisitos legales, operativos y comerciales, no a una cifra arbitraria.
RPO y RTO: las dos cifras que Dirección debe conocer
El RPO, u objetivo de punto de recuperación, define cuánta información está dispuesta a perder la organización. Si una base de datos se respalda una vez al día, un incidente a última hora puede implicar perder hasta una jornada completa de movimientos. Si esa pérdida es inaceptable, habrá que aumentar la frecuencia de las copias o utilizar mecanismos de replicación adecuados.
El RTO, u objetivo de tiempo de recuperación, define cuánto puede tardar el servicio en volver a funcionar. Recuperar varios terabytes desde nube puede ser viable, pero quizá no cumpla un RTO de cuatro horas. En ese escenario, una copia local, una infraestructura de recuperación ante desastres o máquinas virtuales preparadas para contingencia pueden ser más adecuadas.
Estas métricas deben establecerse por servicio. El correo puede admitir un RTO distinto al ERP. Un archivo histórico puede recuperarse en días, mientras que la aplicación que procesa ventas o producción puede requerir recuperación prioritaria. Tratar todo igual lleva a pagar de más o a proteger de menos.
Validar la recuperación antes de necesitarla
Las pruebas de restauración son el momento de comprobar si la estrategia coincide con la realidad. No deben limitarse a recuperar un archivo aislado. Conviene verificar bases de datos, máquinas virtuales, permisos, dependencias de aplicaciones y acceso de usuarios.
Una prueba útil plantea escenarios concretos: un servidor cifrado por ransomware, la eliminación accidental de una carpeta comercial, la pérdida de un buzón ejecutivo o la caída del almacenamiento de una sede. Para cada escenario debe existir un responsable, un orden de recuperación, un tiempo objetivo y un registro del resultado.
Los informes ejecutivos ayudan a mantener el control. Dirección no necesita revisar cada tarea técnica, pero sí conocer el porcentaje de copias correctas, los sistemas sin protección, la antigüedad del último respaldo válido, los resultados de restauraciones de prueba y las acciones pendientes. La continuidad operativa mejora cuando el riesgo se mide y se revisa de forma periódica.
Errores que dejan expuestas a muchas empresas
El más común es pensar que sincronizar archivos equivale a respaldarlos. Si un archivo se cifra, se borra o se corrompe y esa modificación se sincroniza, el problema se replica. La sincronización facilita el acceso; el respaldo conserva versiones recuperables.
Otro error es mantener todas las copias conectadas al mismo dominio, con las mismas credenciales y sin segmentación. Esta configuración simplifica la administración diaria, pero también puede simplificar el trabajo de un atacante. La seguridad del respaldo exige tratar su infraestructura como un activo crítico, no como un disco adicional.
También falla la falta de responsables. Si nadie revisa alertas, valida capacidad, actualiza el inventario y autoriza cambios en retención, la estrategia se degrada con el tiempo. Nuevos servidores, aplicaciones SaaS, cuentas de usuario y sedes pueden quedar fuera sin que la empresa lo advierta.
Cómo decidir el modelo adecuado para su empresa
Empiece por identificar los procesos que no pueden detenerse: ventas, facturación, producción, atención al cliente, logística o gestión financiera. Después, relacione cada proceso con los datos, aplicaciones e infraestructuras que lo sostienen. Este ejercicio revela dependencias que suelen pasar desapercibidas hasta que ocurre un incidente.
A partir de ahí, defina RPO y RTO, diseñe la combinación de copia local, nube e inmutabilidad, y establezca pruebas periódicas. Si el equipo interno no dispone de tiempo o especialización para supervisar el ciclo completo, un servicio administrado puede aportar monitorización, revisión de alertas, acompañamiento de recuperación y reportes claros para TI y Dirección.
RealNet trabaja este tipo de decisiones desde el diagnóstico de activos y riesgos hasta la implementación, verificación y revisión continua. El objetivo no es acumular herramientas, sino asegurar que cada copia tenga una función definida en la continuidad del negocio.
La mejor señal de que un respaldo está bien diseñado no es la cantidad de almacenamiento contratado. Es que, ante una pregunta incómoda como “¿podemos recuperar el ERP antes de que empiece la jornada?”, la empresa pueda responder con evidencia, responsables y un procedimiento ya probado.
