Continuidad operativa: respaldo y recuperación de captura de datos

RPO y RTO como preguntas de negocio

El RPO (objetivo de punto de recuperación) responde: ¿hasta cuántos minutos u horas de datos podemos permitir perder? El RTO (objetivo de tiempo de recuperación) responde: ¿cuánto tiempo podemos estar sin operar este proceso antes de que el daño sea inaceptable? Ninguno es una promesa del proveedor ni un valor técnico mágico; son necesidades que fija el negocio y que luego se comparan con lo que la solución puede ofrecer.

Una forma de calcularlos con realismo es partir de un caso: si el sistema de recepciones queda caído una hora al inicio del turno, ¿cuántos camiones esperan?, ¿qué se hace con la mercancía?, ¿cuántos registros habría que capturar después? Las respuestas orientan la inversión en continuidad mejor que cualquier plantilla.

Qué capturas cubrir y con qué prioridad

No todos requieren el mismo nivel de protección. Prioriza por impacto, y justifica por escrito por qué algunos procesos aceptan un RTO mayor.

Respaldo no es lo mismo que recuperación

Un respaldo existe; una recuperación se prueba. Para cada sistema define qué se respalda (configuración, datos maestros, eventos, claves de idempotencia), con qué frecuencia, dónde se guarda y quién puede restaurarlo. La hoja de OWASP sobre registros recuerda que los datos de logs también aparecen en respaldos y archivos, por lo que deben protegerse igual que los originales; apunta lo mismo para cualquier copia con datos sensibles. Consulta la hoja de OWASP sobre logging para los criterios de protección en reposo y en tránsito.

La restauración también puede crear duplicados o perder claves: si se restaura una base antigua, los eventos reenviados podrían registrarse otra vez. Por eso la continuidad debe diseñarse junto con la idempotencia de los eventos.

Modo local y sincronización posterior

Para PDA y lectores, el mejor seguro frente a una caída de red es capturar localmente y sincronizar después. Eso requiere almacenamiento suficiente, un identificador único por operación, reglas claras de conflicto (qué pasa si dos dispositivos modifican el mismo registro) y un límite de tiempo sin sincronizar. Los reintentos hacia el servidor, como explica RFC 9110 al definir la idempotencia de los métodos HTTP, pueden duplicar efectos si el receptor no se protege; planéalo antes de que ocurra una caída larga.

En ESL, el comportamiento de la etiqueta cuando la plataforma no responde depende del fabricante y del modelo; no asumas que mostrará un precio nuevo sin conexión. Pide el comportamiento documentado y pruébalo.

Ejemplo hipotético: recepción durante una caída de dos horas

Ejemplo ilustrativo. Una bodega define que puede tolerar perder como máximo los eventos de los últimos 15 minutos y que la recepción no debe detenerse más de 30 minutos sin un modo alterno. Esos valores son decisiones de la empresa, no referencias del sector. Cuando falla la conectividad, las PDA siguen capturando localmente. El supervisor activa el procedimiento: los camiones descargan, las PDA acumulan eventos con clave única y, tras 30 minutos sin conexión, comienzan a usarse listas impresas de contingencia para lo que no se pueda capturar.

Al volver la red, el middleware envía los eventos acumulados en orden. El WMS reconoce las claves y no duplica. Un responsable concilia las listas de papel con lo capturado y anota diferencias. El incidente termina con un breve informe de causas y mejoras.

Ensayos y mantenimiento del plan

• Simulacro de caída de red en horario controlado y con el personal real.
• Restauración de un respaldo en un entorno de prueba y verificación de los datos recuperados.
• Revisión del directorio de contactos de proveedores y del procedimiento de escalamiento.
• Actualización del plan cuando cambian sistemas, turnos o contratos.
• Registro de aprendizajes y cambios tras cada incidente o ensayo.

Anota cada ensayo con fecha, resultado y acciones pendientes. Un plan sin ensayo envejece sin que nadie lo note.

Roles durante una contingencia

Una contingencia fracasa más por confusión de roles que por falta de tecnología. Antes de un incidente, nombra a quién declara el modo de contingencia, quién avisa a operaciones, quién habla con el proveedor y quién autoriza el regreso a la normalidad. Cada rol debe tener un suplente, porque los incidentes no esperan al turno de quien conoce el procedimiento.

• Un responsable de decisión, con autoridad para activar el procedimiento alterno.
• Un responsable técnico, que diagnostica y coordina con el proveedor.
• Un responsable de operación en piso, que dirige al personal y valida la conciliación.
• Un responsable de comunicación, que informa a las áreas afectadas.

Imprime el procedimiento y colócalo donde pueda consultarse sin sistema. Revisa los datos de contacto cada trimestre, porque la lista desactualizada es una de las fallas más comunes en un ensayo real.

Siguiente paso

Define, con operaciones, el RPO y RTO tentativos de tus tres procesos más críticos y compáralos con lo que hoy puede hacer tu solución. Las diferencias son tu lista de trabajo. Para revisar el caso con ARKCOM, puedes escribir desde garkcom.com/contact.