Continuidad de negocio
La pregunta no es si hay copia de seguridad, sino cuánto tarda su empresa en volver a trabajar y cuánta información pierde por el camino.
Tres capas que resuelven problemas distintos
Se habla de continuidad como si fuera una sola cosa. En realidad son tres mecanismos complementarios, y confundirlos es la causa más frecuente de que un incidente acabe mal.
La alta disponibilidad evita que el fallo de un componente pare el servicio: un nodo que cae, un disco que muere, una fuente de alimentación que se pierde. No protege frente a un borrado ni frente a un cifrado malicioso, porque ese daño se replica.
El backup permite volver atrás en el tiempo. Es lo que salva ante un error humano, una corrupción o un ransomware, siempre que la copia esté fuera del alcance del entorno comprometido.
El Disaster Recovery es la capacidad de levantar la plataforma en otro sitio cuando el emplazamiento principal ya no está disponible. Requiere infraestructura alternativa, procedimientos escritos y, sobre todo, haberlo probado.
Qué le protege de qué
| Incidente | Alta disponibilidad | Backup externo e inmutable | Disaster Recovery |
|---|---|---|---|
| Fallo de un disco o de un nodo | Sí | No aplica | No aplica |
| Borrado accidental de información | No | Sí | No aplica |
| Cifrado por ransomware | No: el daño se replica | Sí, si la copia es inmutable | Sí, si el entorno alternativo está aislado |
| Corrupción lógica de una base de datos | No | Sí | Parcialmente |
| Pérdida completa del centro de datos | No | Permite reconstruir, con tiempo | Sí |
RTO y RPO: las dos cifras que hay que decidir
El RTO (Recovery Time Objective) es el tiempo máximo aceptable hasta que el servicio vuelve a estar disponible. El RPO (Recovery Point Objective) es la cantidad máxima de información que la organización acepta perder, medida en tiempo.
Ambas cifras son decisiones de negocio, no parámetros técnicos. Determinan la arquitectura y determinan el coste: un RPO de quince minutos y un RTO de una hora exigen replicación continua e infraestructura alternativa encendida; un RPO de veinticuatro horas y un RTO de dos días se resuelven con una copia diaria bien hecha.
Por eso no publicamos RTO ni RPO estándar. Se definen por proyecto, servicio a servicio, y se contrastan con lo que la infraestructura puede sostener realmente.
Fallos que encontramos con más frecuencia
La copia está en la misma infraestructura
Un cifrado o un incidente en el almacenamiento se lleva por delante los datos y sus copias a la vez.
Nunca se ha restaurado nada
El trabajo de copia termina en verde cada noche, pero nadie ha comprobado que lo copiado sirva para reconstruir un sistema.
Las credenciales de backup son las del dominio
Quien compromete el directorio compromete también el repositorio de copias.
El plan existe pero nadie lo ha ejecutado
Un procedimiento no probado contiene siempre dependencias no documentadas que aparecen en el peor momento.
Se protegen los servidores, no los servicios
Se recuperan las máquinas pero falta el DNS, el certificado, la publicación o la integración con un tercero.
Microsoft 365 se da por cubierto
La retención nativa de un servicio SaaS no es una copia de seguridad bajo control del cliente.
Preguntas frecuentes sobre continuidad
¿Cada cuánto conviene probar la recuperación?
Depende de la criticidad, pero una prueba al año es el mínimo razonable y en plataformas críticas trabajamos con pruebas semestrales. Lo importante no es la frecuencia sino que la prueba sea real: restaurar de verdad y comprobar que el servicio funciona, no revisar que el trabajo de copia terminó bien.
¿Es imprescindible tener un segundo centro de datos?
No siempre. Si el RTO admite varias horas o días, se puede reconstruir sobre infraestructura contratada en el momento del incidente. Un segundo emplazamiento permanente se justifica cuando el RTO es corto o cuando existe una obligación contractual o normativa.
¿Esto sirve para cumplir con una auditoría o con un cliente que nos lo exige?
Los entregables (diseño, procedimientos, informes de prueba de restauración y registro de incidentes) son los que habitualmente se piden en auditorías y en cuestionarios de proveedores. No certificamos normas, pero producimos la evidencia técnica que sustenta esas respuestas.
Servicios de continuidad
Disaster Recovery
Infraestructura alternativa, runbooks, orquestación y pruebas reales de recuperación.
Ver servicioBackup en cloud y copia externa
Copia fuera del centro de datos principal, cifrada, monitorizada y verificada mediante restauraciones.
Ver servicioBackup inmutable anti-ransomware
Repositorios inmutables, Object Lock, air-gap lógico y separación de credenciales.
Ver servicioAlta disponibilidad (HA)
Clustering, redundancia, quorum y eliminación de puntos únicos de fallo.
Ver servicioOtras áreas de servicio
Ciberseguridad
Protección, hardening, auditoría, perímetro, identidad y respuesta.
Ver servicioCloud y centros de datos
Cloud privado, cloud público, virtualización y operación de centros de datos.
Ver servicioAuditoría y consultoría TI
Diagnóstico independiente de infraestructura, centro de datos y arquitectura.
Ver servicioDiseñemos su plan de recuperación
Empezamos por lo básico: qué servicios son críticos y cuánto tiempo puede estar sin ellos.