Una copia de seguridad no garantiza la continuidad. Puede estar incompleta, ser inaccesible durante un ataque, tardar demasiado en restaurarse o depender de un servicio que a su vez no esté disponible. El plan de recuperación de actividad convierte los objetivos empresariales en procedimientos, medios técnicos y ejercicios medibles.
El PCA, plan de continuidad de la actividad, busca mantener un nivel de servicio durante la perturbación. El PRA, plan de recuperación de la actividad, organiza la restauración después de una interrupción. Para una aplicación web, ambos cubren el código, los datos, la infraestructura, los servicios de terceros, los equipos y la validación de negocios.
Partir del impacto empresarial
La pregunta inicial no es "¿cuántas copias de seguridad queremos?", sino "¿qué sucede si este proceso no está disponible o si sus últimos datos desaparecen?". Los impactos pueden ser financieros, operativos, contractuales, regulatorios o reputacionales.
Cada capacidad está clasificada: consulta, entrada, pago, cálculo, importación, notificación, administración. Algunas pueden funcionar en modo degradado; otras requieren un apagado para proteger la integridad.
Este análisis define las prioridades de recuperación. Restaurar todo el sitio antes de la función que recibe los pedidos puede ser técnicamente cómodo pero incorrecto desde el punto de vista del negocio.
Comprender RTO, RPO, MTPD y WRT
El RTO es el tiempo objetivo entre la interrupción y la restauración del servicio técnico aceptable. El RPO representa la cantidad máxima de datos que la organización acepta perder, expresada en tiempo.
El MTPD se refiere a la duración máxima tolerable de la perturbación antes de que las consecuencias se vuelvan inaceptables. El WRT, o tiempo de reanudación del trabajo, cubre lo que los equipos de negocio deben hacer después del regreso técnico: controles, conciliaciones, recuperación y comunicación.
Se impone una coherencia simple: el RTO más el WRT debe permanecer por debajo del plazo máximo tolerable. El RPO debe ser compatible con la frecuencia de respaldo o replicación realmente obtenida.
La cronología parte de las copias de seguridad disponibles antes del incidente. El período entre el último punto recuperable y el incidente representa la pérdida de datos enmarcada por el RPO. Después del incidente, el RTO cubre la decisión, la reconstrucción y la restauración hasta el retorno de un servicio técnico aceptable. El WRT prolonga esta duración hasta la validación y la reanudación completa del trabajo por los equipos de negocio. El conjunto RTO más WRT debe mantenerse por debajo del MTPD, la duración máxima tolerable de interrupción.
Una estrategia de copia de seguridad completa
Una estrategia precisa:
- los datos cubiertos ;
- la frecuencia ;
- la retención;
- las copias fuera de línea o inmutables;
- la separación de cuentas y derechos;
- el cifrado;
- la supervisión de los fracasos;
- el procedimiento de restauración;
- las pruebas de test.
La regla llamada 3-2-1 — varias copias, en soportes distintos, de las cuales una separada — constituye un punto de partida, no una garantía universal. Las copias de seguridad deben incluir bases, archivos, configuraciones, claves necesarias y versiones de código compatibles.
Restaurar el conjunto coherente
Una base restaurada sin los archivos asociados, o un código reciente con un esquema antiguo, puede hacer que la aplicación sea incoherente. El PRA define un punto de coherencia y el orden: infraestructura, secretos, base, almacenamiento, índices, trabajadores, cachés y servicios.
Las migraciones y los scripts deben estar versionados. Las claves de cifrado y los certificados necesarios para la lectura de los datos están protegidos por separado pero disponibles durante la crisis.
Elegir el nivel de rescate
Copia de seguridad y reconstrucción
Adaptada cuando el RTO se cuenta en horas o días. La infraestructura se vuelve a crear y luego se restauran los datos. Este enfoque es económico pero depende de la automatización y de la disponibilidad de los componentes.
Entorno de respaldo frío o templado
Se preparan recursos, con parte de la infraestructura o de los datos ya disponible. El costo aumenta, el tiempo de recuperación disminuye.
Rescate caliente y replicación
Una infraestructura lista recibe los datos de manera continua o casi continua. El cambio puede ser rápido, pero es necesario controlar la replicación de errores, los conflictos y las pruebas de retorno.
Continuidad activa
Varias zonas o sitios sirven al tráfico. Esta arquitectura busca una alta disponibilidad, sin eliminar la necesidad de copias de seguridad: una eliminación lógica o una compromisión puede propagarse por todas partes.
Cartografiar las dependencias
La aplicación depende a menudo de DNS, identidad, correo electrónico, pago, almacenamiento, API de negocio y proveedores. El PRA debe precisar el comportamiento de cada uno: espera, en cola, modo degradado, otro proveedor o suspensión controlada.
Una arquitectura redundante pierde su interés si la cuenta DNS, el proveedor de identidad o una clave única sigue siendo un punto de falla. Las dependencias organizacionales también cuentan: ¿quién puede acceder a las cuentas, tomar una decisión y comunicarse?
Definir los escenarios de crisis
Un plan genérico no es suficiente. Prueben escenarios:
- supresión o corrupción de datos;
- indisponibilidad de una región en la nube ;
- compromiso de cuentas de administradores;
- software de rescate ;
- certificado o dominio vencido;
- despliegue defectuoso;
- fallo de un servicio tercero;
- indisponibilidad de una persona clave.
Cada escenario especifica desencadenante, alcance, decisión, aislamiento, restauración, validación y salida de la crisis.
Escribir un runbook utilizable bajo presión
El runbook debe ser corto, versionado y accesible incluso si el sistema principal está indisponible. Indica los contactos, los prerrequisitos, los comandos, los resultados esperados y los puntos de detención. Los secretos no se escriben en claro; su caja fuerte y su procedimiento de acceso son probados.
Los roles están separados: dirección de crisis, intervención técnica, validación de negocio, comunicación y enlace con los proveedores. Una misma persona puede acumular roles en una estructura pequeña, pero la responsabilidad sigue siendo explícita.
Probar la restauración
Una prueba de respaldo verifica que un archivo existe. Una prueba de restauración demuestra que puede ser utilizado. El ejercicio debe medir:
- tiempo de recuperación de los accesos;
- tiempo de reconstrucción ;
- tiempo de transferencia y de restauración;
- controles de integridad;
- validación de los recorridos;
- desviaciones al RTO/RPO;
- operaciones manuales y errores.
Los ejercicios pueden comenzar con una mesa, luego un entorno aislado, y luego una repetición completa. Deben producir acciones con plazo.
Preparar la comunicación
La continuidad incluye a los usuarios, socios y equipos. Modelos de mensajes explican lo que se conoce, el impacto, las medidas y la próxima actualización. Se debe evitar las promesas de plazos no confirmados y proteger la información de seguridad.
Un diario de crisis con sello de hora conserva decisiones, acciones y pruebas. Facilita la retroalimentación y las posibles obligaciones de notificación.
Mantener el plan vivo
El PRA se revisa cuando cambian la arquitectura, los volúmenes, los proveedores o la organización. Los contactos expiran, los pedidos evolucionan y los objetivos empresariales se endurecen. Una revisión anual es un mínimo para una plataforma importante; las pruebas pueden ser más frecuentes según la criticidad.
Los indicadores siguen la tasa de éxito de las copias de seguridad, la antigüedad de la última prueba, el tiempo medido de recuperación, las desviaciones y las acciones no cerradas.
Una capacidad, no un documento
El nivel de continuidad debe ser proporcional. Un RTO de unos minutos implica una arquitectura y una organización costosas. Un objetivo de varias horas puede ser perfectamente aceptable si se asume y se prueba.
Partitech asegura el alojamiento, la gestión informática, la supervisión y el mantenimiento de plataformas digitales. Podemos mapear las dependencias, definir los objetivos, automatizar la restauración y llevar a cabo ejercicios para que el PRA corresponda a una capacidad real.
Para profundizar en el enfoque, enmarquen los niveles de servicio y el mantenimiento de aplicaciones, empieza por un auditoría técnica de la aplicación y preparen los estrategias de conmutación de una aplicación. Descubra también la oferta Mantenimiento, evoluciones, alojamiento y gestión externalizada de Partitech.
Referencias oficiales
Referencias consultadas el 17 de agosto de 2026: