Copias de seguridad y recuperación que funcionan: RTO/RPO para negocio y pruebas de restauración realistas

Una interrupción no impacta solo a TI. Puede traducirse en ventas no realizadas, facturación bloqueada, producción detenida, incumplimientos contractuales, saturación de atención al cliente y daño reputacional. Por eso, hablar de recuperación no es un asunto puramente técnico.

Coste de parada

Cada proceso crítico tiene un coste distinto cuando no está disponible. No hace falta fijar una cifra exacta para empezar, pero sí identificar qué ocurre si el servicio falla durante horas o durante un día completo:

• ¿Se dejan de cerrar ventas?
• ¿Se acumulan pedidos sin procesar?
• ¿Se retrasa la facturación y el cobro?
• ¿Se detiene la operativa interna?
• ¿Se incumplen plazos con clientes o proveedores?

Este análisis ayuda a decidir dónde invertir más protección y más capacidad de recuperación.

Reputación y servicio

No todos los impactos son financieros de forma inmediata. A veces el mayor daño aparece en la experiencia del cliente: pedidos que no avanzan, información inconsistente, comunicación deficiente o tiempos de respuesta inciertos. Recuperar tarde o recuperar mal también erosiona confianza.

Obligaciones contractuales y de cumplimiento

En algunos casos, los contratos con clientes o socios establecen niveles de servicio, tiempos de respuesta o responsabilidades ante interrupciones. También puede haber requisitos internos de auditoría o de gestión del riesgo. Si existen implicaciones regulatorias o contractuales, deben verificarse con las fuentes oficiales y con el área jurídica o de cumplimiento.

Acciones recomendadas

1. Definir entre 3 y 5 servicios críticos con un RTO y un RPO aprobados por negocio, no solo por TI.
2. Documentar dependencias y orden de recuperación: aplicaciones, bases de datos, identidad, red, integraciones, SaaS y proveedores.
3. Diseñar una estrategia de copias de seguridad proporcional al impacto, con frecuencia, retención y niveles de protección coherentes con cada servicio.
4. Separar accesos y credenciales del sistema de copias de seguridad del entorno habitual, aplicando mínimo privilegio y autenticación multifactor (MFA) cuando corresponda.
5. Preparar una guía operativa de recuperación (runbook) con responsables, pasos, decisiones y criterios de escalado.
6. Realizar pruebas periódicas de restauración con objetivos medibles: tiempo, integridad de datos y operatividad del servicio.
7. Registrar evidencias y lecciones aprendidas para corregir fallos y mejorar el plan en cada ciclo.

RTO y RPO explicados sin jerga

Tener copias de seguridad no equivale a poder recuperarse de una caída. En continuidad, la pregunta útil no es si “hay copia”, sino si el negocio puede restaurar lo importante dentro del tiempo que necesita y con una pérdida de datos asumible.

Por eso conviene traducir la conversación técnica a términos de negocio: qué servicios son críticos, cuánto tiempo pueden estar parados, cuánta información se puede perder sin comprometer operaciones, ingresos o compromisos con clientes, y qué evidencia existe de que la recuperación funciona de verdad.

RTO y RPO son dos decisiones de negocio con implicaciones técnicas.

RTO: cuánto tiempo puede estar parado un servicio

El RTO es el tiempo máximo aceptable para recuperar un servicio desde que deja de estar disponible.

Dicho de forma simple: cuánto tiempo puede soportar el negocio que algo no funcione.

RPO: cuántos datos se pueden perder

El RPO es la pérdida máxima de datos que el negocio está dispuesto a asumir entre la última copia válida y el momento del incidente.

Dicho de forma simple: hasta qué punto sería tolerable “volver atrás” en la información.

Ejemplos por tipo de proceso

Ventas

Si un sistema de ventas deja de estar disponible, el impacto puede ser inmediato. El negocio debe decidir si puede operar manualmente durante un tiempo o si la caída bloquea ingresos desde el primer momento. Eso define un RTO más o menos exigente. El RPO dependerá de si perder transacciones recientes es asumible o no.

Facturación

En facturación, quizá una parada breve sea manejable si existe margen operativo, pero perder datos emitidos o pendientes de cobro puede tener consecuencias mayores. Aquí el RPO suele ser especialmente sensible porque afecta a trazabilidad y conciliación.

Producción u operaciones

En entornos productivos, una aplicación puede no generar ingresos directamente y aun así ser crítica para la operación. Si su caída detiene la planificación, la logística o la ejecución, el RTO debe reflejar ese impacto real. El RPO dependerá de si los datos se pueden reconstruir o si su pérdida obliga a rehacer trabajo.

La clave es que no existe un RTO o RPO “correcto” por defecto. Deben acordarse según el proceso, el impacto y la capacidad real de recuperación.

Paso 0: identificar servicios críticos y dependencias

Antes de hablar de tecnología, hay que saber qué hay que salvar primero.

Qué es un servicio crítico

No es solo un servidor o una aplicación. Es una capacidad de negocio que debe seguir disponible o recuperarse con prioridad. Por ejemplo:

• recepción de pedidos
• emisión de facturas
• acceso a expedientes o documentación operativa
• planificación de producción
• atención al cliente

Pensar en servicios evita diseñar copias de seguridad por silos técnicos sin conexión con la operativa real.

Mapear dependencias

Cada servicio crítico suele depender de varias piezas:

• aplicaciones
• bases de datos
• almacenamiento
• identidad y accesos
• red y conectividad
• integraciones con terceros
• correo o notificaciones
• proveedores cloud o SaaS
• personas concretas que saben ejecutar la recuperación

Si estas dependencias no están documentadas, la restauración puede retrasarse aunque existan copias válidas.

Priorizar el orden de recuperación

Recuperar “todo” al mismo tiempo rara vez funciona bien. Es más útil responder a esta secuencia:

1. ¿Qué servicio debe volver primero?
2. ¿Qué componentes necesita para operar?
3. ¿Qué datos son imprescindibles para ponerlo en marcha?
4. ¿Qué puede esperar?

Esta priorización debe estar aprobada por negocio, porque implica aceptar que algunos servicios volverán después.

Paso 1: diseñar una estrategia de copias de seguridad proporcional

La estrategia de copias de seguridad debe corresponderse con los objetivos de recuperación. No todos los sistemas necesitan el mismo tratamiento.

Frecuencia

La frecuencia de copia influye en el RPO. Si un proceso no tolera perder muchas horas de datos, la política de copia debe reflejarlo. Si un sistema cambia poco y su impacto es menor, puede requerir menos frecuencia.

Retención

No basta con copiar; hay que decidir cuánto tiempo se conservan las copias. La retención debe servir tanto para incidentes recientes como para detectar problemas que aparecen más tarde, como borrados accidentales o corrupción no descubierta de inmediato.

Separación

El sistema de copias de seguridad debe resistir el mismo incidente que afecta al entorno principal. Si las copias, las credenciales y la consola de administración están demasiado cerca del sistema protegido, un fallo de seguridad o un error operativo puede comprometerlo todo.

Conviene revisar, al menos, estas separaciones:

• accesos administrativos distintos
• credenciales específicas
• redes o ubicaciones diferenciadas cuando aplique
• limitación de privilegios
• procedimientos de acceso excepcionales para recuperación

Inmutabilidad y protección frente al propio incidente

Si el riesgo incluye borrado malicioso, cifrado por ataque o manipulación de copias, la estrategia debe contemplar mecanismos que dificulten la alteración de las copias de seguridad durante un periodo definido. El principio es simple: las copias de seguridad tienen que sobrevivir al incidente, no acompañarlo.

Paso 2: plan de recuperación con responsables y orden claro

Las copias son solo una parte. La otra es el plan para usarlas.

Qué debe incluir una guía operativa

Una guía operativa de recuperación debería responder, de forma práctica, a preguntas como estas:

• qué activa el plan
• quién decide iniciar la restauración
• quién ejecuta cada paso
• qué sistemas van primero
• qué dependencias deben estar operativas antes
• cómo se valida que el servicio funciona
• cuándo se comunica a negocio y a usuarios
• qué hacer si la restauración falla

No hace falta un documento perfecto para empezar, pero sí uno utilizable bajo presión.

Roles y toma de decisiones

En una incidencia importante, perder tiempo discutiendo quién autoriza o quién ejecuta es un fallo de diseño. Debe quedar claro:

• responsable de negocio que prioriza
• responsable técnico que coordina
• equipos que restauran infraestructura, datos y aplicaciones
• contacto con proveedores si intervienen servicios externos
• responsable de comunicación interna y externa, si aplica

Orden de restauración

Un error habitual es restaurar componentes aislados sin considerar dependencias. Por ejemplo, recuperar una aplicación sin identidad, sin base de datos o sin conectividad no devuelve el servicio. La guía operativa debe reflejar la secuencia real de recuperación.

Paso 3: pruebas de restauración realistas

El indicador “copia completada” no demuestra que el servicio se pueda recuperar. Solo indica que una tarea terminó sin errores aparentes.

Qué significa probar de verdad

Una prueba útil verifica al menos tres cosas:

• que los datos pueden restaurarse
• que el tiempo de recuperación encaja con el objetivo marcado
• que el servicio queda operativo para el usuario o el proceso

Si falta cualquiera de esas tres, la prueba es parcial.

Tipos de pruebas

Verificación básica de restauración

Consiste en comprobar que los datos o sistemas pueden recuperarse técnicamente. Es el nivel mínimo y no debería confundirse con una prueba de continuidad completa.

Restauración funcional

Se recupera un sistema o conjunto de datos y se valida que la aplicación arranca, responde y permite ejecutar tareas básicas del proceso.

Prueba de servicio completo

Se simula la recuperación de un servicio crítico con sus dependencias principales y se mide el tiempo real. Es la forma más cercana a validar el RTO.

Prueba de mesa

Los responsables repasan la guía operativa y las decisiones sin ejecutar la restauración completa. No sustituye a una prueba real, pero sirve para detectar huecos de coordinación o documentación.

Cadencia y criterio de éxito

La frecuencia de prueba depende de la criticidad y del cambio del entorno. Lo importante es que exista una cadencia definida y sostenible. Cada prueba debe tener criterios de éxito previos, por ejemplo:

• tiempo máximo de recuperación observado
• integridad de los datos restaurados
• capacidad de uso por parte del proceso
• incidencias detectadas y acciones correctoras

Registrar evidencias

Si una prueba no deja evidencia, el aprendizaje se pierde. Conviene registrar:

• fecha y alcance de la prueba
• sistemas incluidos
• tiempos reales
• incidencias encontradas
• decisiones tomadas
• mejoras requeridas
• responsables y próxima revisión

Qué mirar en proveedores y SaaS

La continuidad no termina en el perímetro propio. Si un servicio SaaS o un proveedor externo participa en un proceso crítico, también debe formar parte del plan.

Preguntas clave

• ¿Qué datos se pueden exportar y en qué formato?
• ¿Con qué frecuencia pueden extraerse?
• ¿Qué opciones de recuperación ofrece el servicio?
• ¿Qué parte depende del proveedor y cuál del cliente?
• ¿Existen límites, ventanas o condiciones para restaurar?
• ¿Cómo se solicita soporte en una incidencia grave?
• ¿Qué contactos y procedimientos hay fuera del horario habitual?

Expectativas realistas

Un error común es asumir que porque un proveedor opera una plataforma, también cubre toda necesidad de recuperación del cliente. No siempre es así. Alta disponibilidad, retención, exportación y recuperación son cuestiones distintas. Conviene revisar contratos y documentación oficial del servicio para entender qué cubre realmente y qué no.

Errores comunes

Confundir copias de seguridad con recuperación

Hacer copias no garantiza restauración dentro del tiempo necesario ni con la integridad requerida.

No probar

Es un fallo frecuente y a menudo costoso cuando llega una crisis. Lo que no se prueba, en continuidad, no existe.

Querer recuperar todo a la vez

Sin priorización, se consumen recursos donde no más valor aportan y se retrasa lo crítico.

Dejar las copias de seguridad demasiado expuestas

Si las copias comparten accesos, privilegios o entornos con los sistemas productivos, pueden quedar comprometidas por el mismo incidente.

No incluir SaaS y proveedores

La continuidad real incluye integraciones, datos alojados fuera y procedimientos con terceros.

No definir responsables

Un buen diseño técnico pierde eficacia si nadie sabe quién decide, quién ejecuta y a quién se informa.

No revisar tras cambios

Cada cambio relevante en aplicaciones, arquitectura, procesos o proveedores puede invalidar parte del plan si no se actualiza.

Plantilla: matriz servicio → RTO/RPO

Una forma práctica de empezar es construir una matriz sencilla como esta:

Esta matriz obliga a conectar impacto, responsables y dependencias en una única vista.

Plantilla: checklist de prueba de restauración

Puede usarse como base mínima para formalizar pruebas:

Antes de la prueba

• [ ] Servicio y alcance definidos
• [ ] Objetivo de la prueba documentado
• [ ] RTO/RPO de referencia identificados
• [ ] Responsables asignados
• [ ] Dependencias conocidas
• [ ] Criterios de éxito acordados
• [ ] Ventana de prueba aprobada
• [ ] Contactos de proveedores disponibles, si aplica

Durante la prueba

• [ ] Hora de inicio registrada
• [ ] Pasos de la guía operativa seguidos
• [ ] Incidencias anotadas
• [ ] Tiempos por fase registrados
• [ ] Datos restaurados validados
• [ ] Aplicación o servicio verificado funcionalmente
• [ ] Dependencias comprobadas

Después de la prueba

• [ ] Hora de cierre registrada
• [ ] Tiempo total comparado con el RTO
• [ ] Pérdida de datos observada comparada con el RPO
• [ ] Resultado: éxito, parcial o no superado
• [ ] Problemas detectados clasificados
• [ ] Acciones correctoras asignadas
• [ ] Fecha de próxima prueba definida
• [ ] Evidencias archivadas

Cierre

Una estrategia de copias de seguridad madura no se mide por cuántas copias se generan, sino por la capacidad de recuperar lo importante a tiempo, en el orden correcto y con evidencia de que el proceso funciona.

La conversación útil para dirección y operaciones no es “tenemos copias de seguridad”, sino esta: qué servicios sostienen el negocio, cuánto tiempo pueden caer, cuántos datos pueden perderse, quién responde y cuándo fue la última vez que se demostró la recuperación en una prueba realista. Esa es la diferencia entre un ritual técnico y una capacidad de continuidad.