LAS IDEAS CLAVE
- 01
La prueba debe identificar una operación concreta y quién acepta su recuperación.
- 02
RTO y RPO son objetivos: compara con ellos el tiempo y la brecha de datos observados.
- 03
Registra los resultados parciales y las correcciones pendientes antes de reanudar automatizaciones.
Del plan de crisis a una operación que vuelve a funcionar
Para comprobar un respaldo, proponemos recuperar una operación acotada en un entorno de prueba, verificar sus datos y medir cuánto tarda en quedar utilizable. El resultado debería permitir responder una pregunta concreta: ¿podríamos volver a atender, vender o despachar con lo recuperado? Un reporte que confirma la ejecución de una copia es un antecedente; la aceptación del proceso requiere otra evidencia.
El 11 de septiembre de 2026, ANCI informó que una submesa del Gobierno Central realizó un ejercicio de mesa que simulaba un incidente de ransomware. La actividad ensayó decisiones y coordinación; la noticia no documenta una restauración técnica ni tiempos de recuperación. Es un contexto reciente para discutir preparación, sin confundir ambos tipos de prueba. ANCI, simulacro de gestión de crisis.
Elegir una operación y un responsable de aceptarla
La orientación de ANCI sobre respaldos recomienda priorizar aplicaciones críticas, planificar y probar las restauraciones, y definir la frecuencia de las copias según la información que se podría perder. También pide restringir el acceso, la modificación y el borrado de los respaldos. La página es una guía técnica sin fecha visible de publicación. ANCI, respaldar periódicamente la información.
Para convertir esa orientación en un encargo manejable, sugerimos elegir una operación: consultar los pedidos pendientes y preparar una orden de despacho, por ejemplo. La persona responsable de logística debería definir qué necesita ver para aceptar el resultado. Tecnología identifica qué recuperará; el área usuaria comprueba que le sirve. Conviene anotar también qué queda fuera: recuperar pedidos no acredita por sí solo que pagos, facturación o atención estén disponibles.
Acordar cuánto tiempo y cuántos datos se pueden perder
Microsoft distingue dos objetivos de recuperación. El RTO expresa el tiempo máximo de interrupción aceptable; el RPO, el período máximo de datos cuya pérdida se toleraría. Ambos deben definirse para el proceso y discutirse entre negocio y tecnología. Son objetivos, no resultados demostrados ni compromisos universales de un proveedor. Microsoft, continuidad y recuperación ante desastres.
Un ejemplo hipotético: una distribuidora acuerda un RTO de cuatro horas y un RPO de una hora para consultar pedidos. En el ensayo se simula una interrupción a las 10:00 y se recupera una copia consistente hasta las 09:30. La brecha de datos es de treinta minutos. Si la operación queda validada a las 13:00, el tiempo transcurrido es de tres horas. Ambos quedarían dentro de esos objetivos ficticios; las cifras no son una recomendación para todas las empresas ni una medición de Digital Dev.
Restaurar en un entorno separado y comprobar el trabajo completo
La guía de pruebas de confiabilidad de Microsoft recomienda validar las restauraciones fuera de producción, revisar integridad y completitud de los datos y evaluar el flujo completo. Advierte que recuperar un componente puede tomar menos tiempo que recuperar sus dependencias. Es documentación de arquitectura para Azure; aquí usamos esos criterios como referencia para diseñar el ensayo, sin atribuir capacidades de Azure a otros productos. Microsoft, estrategia de pruebas de confiabilidad.
Para la distribuidora del ejemplo, prepararíamos una lista de pedidos de referencia y sus estados esperados. En el entorno recuperado se revisaría una muestra acordada, sus líneas de producto y los documentos asociados. Después, una persona de logística intentaría completar una orden de prueba. Los envíos de correo, cobros y conexiones de despacho deben quedar deshabilitados o sustituidos por destinos de ensayo. La prueba necesita un responsable que confirme ese aislamiento antes de comenzar.
Pedir respuestas precisas cuando el respaldo depende de terceros
Si parte de la operación utiliza un CRM, una plataforma de ventas o almacenamiento contratado, proponemos enviar al proveedor preguntas concretas: ¿qué elementos pueden recuperarse?, ¿hasta qué antigüedad?, ¿quién solicita la recuperación?, ¿qué costo tiene?, ¿cómo se obtiene evidencia de que terminó? Registrar la respuesta por servicio evita que una explicación comercial general se convierta en una suposición sobre todo el negocio.
También conviene revisar quién conserva los accesos necesarios cuando falta la persona habitual. Para nuestro ejemplo, el responsable alterno podría demostrar que sabe localizar el procedimiento y abrir una solicitud de soporte autorizada. No hace falta compartir contraseñas en el acta: bastan el rol responsable, el mecanismo de acceso y el resultado de la comprobación. Si algo depende de una conversación informal, queda como una tarea por resolver.
Cerrar el ensayo con evidencia y una decisión
Proponemos un acta breve con seis datos: operación examinada, punto de recuperación utilizado, hora inicial y final, comprobaciones realizadas, limitaciones detectadas y responsable de cada corrección. La conclusión puede ser más precisa que aprobado o rechazado: pedidos consultables, documentos incompletos, despacho todavía bloqueado. Eso permite priorizar el siguiente trabajo y evita presentar una recuperación parcial como continuidad de toda la empresa.
Cuando esa operación incorpora agentes de IA, sugerimos añadir una pregunta al cierre: ¿qué acciones pueden reanudarse con la información recuperada? Por ejemplo, un agente comercial no debería retomar seguimientos sin comprobar el estado de las oportunidades. Esta revisión conecta la continuidad con el grado de autonomía de los agentes y con el diseño de cloud e infraestructura. El siguiente paso útil es acordar qué falla se corregirá y qué evidencia deberá entregar el próximo ensayo.
CON TEXTO Y CONTEXTO
Fuentes y referencias
- Submesa de Ciberseguridad del Gobierno Central pone a prueba sus planes de gestión de crisis a través de simulacroAgencia Nacional de Ciberseguridad de Chile · 2026-09-11
- Respaldar periódicamente la informaciónAgencia Nacional de Ciberseguridad de Chile
- What are Business Continuity, High Availability, and Disaster Recovery?Microsoft Learn
- Architecture strategies for reliability testingMicrosoft Learn
Contenido elaborado con asistencia de IA a partir de las fuentes enlazadas. Las recomendaciones corresponden al análisis editorial de Digital Dev. Cómo elaboramos y corregimos nuestros artículos.