El Escenario Que Nadie Planifica
La recuperación ante desastres en software empresarial significa clústeres de conmutación por error, bases de datos replicadas y equipos de operaciones 24/7. Asume que usted cuenta con centros de datos, ingenieros de red y presupuesto.
Ahora elimine todo eso. Usted está operando una estación médica con una Raspberry Pi en una zona de desastre. El adaptador de corriente fue pateado. La tarjeta SD se corrompió. El dispositivo cayó de una mesa plegable durante una réplica. El equipo está muerto.
Cada registro de paciente de las últimas 72 horas estaba en ese dispositivo. Clasificaciones de triaje. Bitácoras de dispensación de medicamentos. Cadenas de custodia de productos sanguíneos. Casos quirúrgicos activos. Todo.
La recuperación ante desastres tradicional dice: restaurar desde la copia de seguridad. Pero el servidor de respaldo es el mismo dispositivo que acaba de fallar. No hay nube. No hay un segundo centro de datos. No hay equipo de TI.
Lo que sí hay: una enfermera con un teléfono que ha estado sincronizando datos en segundo plano cada cinco minutos.
El Protocolo Bote Salvavidas
Lo llamamos Protocolo Bote Salvavidas porque la metáfora es precisa. Cuando el barco se hunde, los botes salvavidas llevan a los pasajeros. Cuando el servidor cae, los teléfonos llevan los datos.
Cada PWA (Aplicación Web Progresiva) en la flota xGrid ejecuta un proceso en segundo plano llamado Lifeboat Client. Cada cinco minutos, extrae silenciosamente datos nuevos del Raspberry Pi y los almacena localmente en IndexedDB del navegador -- una base de datos persistente que sobrevive a reinicios de la aplicación, reinicios del teléfono e incluso el modo avión.
La copia de seguridad no es un archivo. Es un almacén de eventos estructurado con cada cambio que ha ocurrido en el servidor, más instantáneas periódicas del estado actual de todas las tablas críticas -- registros de pacientes, productos sanguíneos, casos quirúrgicos, horarios de medicación, planes de atención.
Cuando el servidor muere, el teléfono ni siquiera lo sabe inmediatamente. La próxima vez que intenta sincronizar, nota que el servidor ha desaparecido. Cuando un Raspberry Pi nuevo aparece en la red, el teléfono lo detecta automáticamente: la identidad del servidor ha cambiado y la base de datos está vacía.
Eso activa la restauración.
Tres Minutos Hasta la Recuperación Completa
El flujo de recuperación está diseñado para una enfermera, no para un ingeniero:
Paso 1
Detectar
El telefono ve un servidor nuevo con base de datos vacia. Aparece un banner: "Servidor nuevo detectado. Restaurar datos?"
Paso 2
Autenticar
La enfermera ingresa el PIN de administrador. Esto previene restauraciones no autorizadas -- no se puede sobrescribir los datos de un servidor sin el codigo.
Paso 3
Restaurar
El telefono envia todos los eventos e instantaneas en lotes. El servidor los procesa en transacciones. Restauracion tipica: menos de 3 minutos.
La instantánea restaura el estado actual inmediatamente -- el tablero se vuelve utilizable en segundos. Los eventos reproducen el historial completo, asegurando que cada pista de auditoría permanezca intacta.
Por Qué Eventos, No Solo Instantáneas
Una instantánea le dice dónde están las cosas ahora. Los eventos le dicen cómo llegaron ahí.
Si solo restaura una instantánea, usted sabe que el Paciente A tiene dos unidades de sangre asignadas. Pero no sabe quién las asignó, cuándo, ni por qué. No sabe que la asignación fue una autorización de emergencia a las 2 de la madrugada porque el paciente estaba en hemorragia y el médico estaba en cirugía con otro paciente.
xGrid registra cada cambio de estado como un evento inmutable: quién lo hizo, cuándo, en qué dispositivo, con qué justificación. El almacén de eventos es de solo adición -- los eventos nunca se eliminan ni se modifican. Cada evento lleva un hash criptográfico de su contenido.
Cuando el teléfono restaura hacia un servidor nuevo, envía la cadena completa de eventos. El servidor puede reconstruir no solo el estado actual, sino el historial completo de cada decisión, cada autorización de emergencia, cada traspaso.
Verificación de Cadena de Hash
¿Cómo sabe que los datos restaurados están completos y no fueron alterados?
Cada tipo de entidad (productos sanguíneos, casos quirúrgicos, registros de pacientes) mantiene un hash de cadena continuo:
chain[i] = SHA-256(chain[i-1] + event_id + payload_hash)
Conceptualmente similar a una blockchain, pero sin la sobrecarga. Si el servidor original tenía 500 eventos de productos sanguíneos produciendo el hash de cadena a3f2..., y el servidor restaurado procesa esos mismos 500 eventos, debe producir el hash de cadena idéntico a3f2....
Si algún evento falta, fue modificado o está fuera de orden, el hash de cadena diverge. El sistema lo señala. Usted sabe que algo anda mal antes de que alguien comience a usar los datos.
Idempotencia: La Red de Seguridad para Redes Poco Confiables
¿Qué sucede si el teléfono de la enfermera pierde WiFi a mitad de la restauración? Se reconecta y presiona "Restaurar" de nuevo. ¿Se duplicará todo?
No. Cada evento tiene un ID único y un hash de contenido. Cuando el servidor recibe un evento que ya procesó, verifica:
- Mismo ID, mismo hash: Ya presente. Omitir. Sin duplicación.
- Mismo ID, hash diferente: Conflicto. Rechazar y registrar para investigación.
- ID nuevo: Insertar normalmente.
La enfermera puede presionar "Restaurar" diez veces. El resultado es idéntico a presionarlo una vez. Esta no es una función de conveniencia -- es una propiedad de seguridad crítica. En un entorno estresante con conectividad poco confiable, las personas reintentarán. El sistema debe manejar los reintentos con gracia.
Qué Se Restaura
La instantánea Lifeboat cubre 20 tablas críticas:
Medicina Central
Casos de anestesia, estado de equipos, unidades de sangre y cadenas de custodia
Modulos LSCO
Planes de atencion PFC, signos vitales, intervenciones, horarios de medicacion, alertas clinicas
Operaciones de Campo
Tarjetas de baja TCCC, solicitudes MEDEVAC, registros de fases DCS, procedimientos diferidos
Gobernanza
Solicitudes de aprobacion, votos, registros de escalamiento, modos de permisos, preautorizaciones
Cada tabla que importa para la seguridad del paciente está incluida. Si afecta decisiones clínicas, sobrevive a la restauración.
La Realidad de la Tarjeta SD
Los dispositivos Raspberry Pi usan tarjetas SD para almacenamiento. Las tarjetas SD se desgastan. No están diseñadas para los patrones de escritura de un servidor de bases de datos. En un despliegue de campo operando 24/7, la falla de la tarjeta SD no es cuestión de si ocurrirá, sino de cuándo.
Por eso existe el Protocolo Bote Salvavidas. No como una póliza de seguro para eventos improbables, sino como una parte rutinaria de los supuestos operativos del sistema. El sistema está diseñado para la falla del hardware.
El proceso de restauración también protege la nueva tarjeta SD. En lugar de escribir miles de operaciones individuales de base de datos, cada lote de eventos se procesa en una sola transacción. Menos operaciones de escritura significa menos desgaste de la tarjeta SD, extendiendo la vida del dispositivo de reemplazo.
La Validación de 12 Pasos
Nuestra prueba de DR de extremo a extremo ejecuta 12 pasos:
- Inicializar el servidor original con pacientes, productos sanguíneos, casos quirúrgicos y datos LSCO
- Crear planes de atención PFC con signos vitales, tarjetas de baja TCCC y solicitudes MEDEVAC
- Exportar todos los eventos e instantáneas (paginadas, basadas en cursor)
- Registrar la huella digital de hash de cadena del servidor original
- Iniciar un servidor nuevo con base de datos vacía
- Restaurar lote 1: instantánea + primer lote de eventos
- Restaurar lotes restantes
- Comparar hashes de cadena entre servidor original y restaurado
- Reenviar todos los eventos (prueba de idempotencia) -- verificar cero duplicados
- Verificar que todos los datos LSCO sobrevivieron: planes PFC, tarjetas TCCC, solicitudes MEDEVAC
- Revisar historial de restauración: cero eventos rechazados
- Confirmar integridad completa de la pista de auditoría
Los 12 pasos pasan. El servidor restaurado es indistinguible del original -- mismos datos, mismo historial, mismos hashes de cadena.
Lo Que Esto Significa en la Práctica
Un equipo de hospital de campo se despliega con dos dispositivos Raspberry Pi y una caja de repuestos. Cuando un dispositivo falla -- y fallará -- la secuencia de reemplazo toma minutos, no horas. No se requiere ingeniero. No se necesita acceso por línea de comandos. No se necesita capacitación especial más allá de "ingrese el PIN cuando el teléfono lo solicite."
Los datos no viven en el servidor. Viven en todas partes -- en cada teléfono y tableta que se ha conectado al servidor. El servidor no es la fuente de verdad. Es un punto de agregación conveniente. Los teléfonos son los botes salvavidas, y siempre están listos.
Esto es lo que Walkaway significa en la práctica. No solo que los desarrolladores pueden irse (pueden -- vea The Walkaway Test). Sino que el hardware también puede irse. Caer de una mesa. Ser pisado. Incendiarse en una réplica. Los datos sobreviven porque nunca estuvieron en un solo lugar.
Relacionado: The Walkaway Test · SQLite in the Battlefield · Hub-and-Spoke: Network Architecture for Disconnected Operations