Análisis de la evidencia existente de respaldo y restauración (sesión 2026-10-10-7)

Fuente: pruebas/evidencia/2026-10-10-4/respaldos/ (registro.csv, restauracion.json, restauracion_alinear.json), herramientas/qa/laboratorio/respaldo_cada_2_5h.ps1, restaurar_local.js, datos/base_local/scripts/respaldo.js, _resumen.json de cada respaldo en datos/respaldos_db/, docs/trl/runbooks/03_restauracion_respaldo.md. No se hizo ningún respaldo ni restauración nuevos.

Frecuencia real (registro.csv)

#	Inicio (-05:00)	Fin	Duración	Intervalo desde el anterior	Documentos	Bytes	Resultado	Origen
1	03:06:03	03:06:11	8,0 s	—	2036	2.058.848	ok	Manual (la tarea arranca a las 05:36)
2	05:36:01	05:36:39	38,2 s	2 h 29 min 58 s	2037	2.059.386	ok	Tarea
3	08:06:03	08:06:34	31,2 s	2 h 30 min 02 s	2042	2.066.387	ok	Tarea
4	10:36:02	10:36:30	28,0 s	2 h 29 min 59 s	2048	2.082.700	ok	Tarea

Desde que arrancó la tarea (05:36), 3 de 3 ejecuciones a tiempo (desvío ≤ 3 s). Próxima: 13:06. Ejecuciones perdidas: 0.
Hubo además un respaldo manual a las 08:42 (nara_2026-10-10-13-42, 33 colecciones, 2043 documentos) que no está en el registro.
Cada respaldo lee colección por colección (find({})), sin instantánea ni readConcern: snapshot: no es un punto en el tiempo consistente entre colecciones (ventana de 8 a 38 s).

Pérdida de datos posible (RPO 2,5 h)

Intervalo = 2 h 30 min, igual al RPO: margen 0. Peor caso ≈ 2 h 30 min + duración del respaldo (hasta 38 s) > 2,5 h.
A las 12:02 la base en línea tenía 2077 documentos; el último respaldo (10:36) tiene 2048. No respaldados en ese momento: access_log 25 (0 en el respaldo) y login_attempts 4 (1 → 5). 2048 + 25 + 4 = 2077.
La tarea no corre con el portátil en batería, suspendido, apagado o con la sesión cerrada, y no recupera ejecuciones perdidas (tarea_programada.txt). En esos casos el RPO no se cumple y nada avisa.

Restauración probada

Archivo	Respaldo	Destino	Restaurado	Segundos	Colecciones	Documentos	Diferencias
restauracion.json	nara_2026-10-10-08-06 (03:06 local)	127.0.0.1/nara_restore_rto (Mongo local del portátil)	05:39 local	1,63	33	2036	0
restauracion_alinear.json	nara_2026-10-10-13-06 (08:06 local)	127.0.0.1/nara_alinear	08:30 local	1,564	33	2042	0

Observaciones:

segundos mide solo la inserción en el Mongo local (desde el primer insertMany hasta el último índice). No incluye: detectar la falla, decidir, conseguir la credencial, restaurar en Atlas (o en otro clúster), apuntar MONGODB_URI de Render a la base restaurada, redesplegar y verificar con la app. Ese tiempo total (el RTO real) no está medido.
La comparación es solo de conteos por colección contra el _resumen.json del mismo respaldo, que respaldo.js escribe con docs.length de lo que él mismo exportó. Comprueba que el archivo se reinsertó completo, pero no que el respaldo coincida con la base en línea a la hora del respaldo, ni el contenido documento por documento. El runbook pide comparar_db.js documento por documento; no se usó.
No se hizo el paso 2 de 5.17/R-06 (crear 3 registros nuevos y borrar 1 después del respaldo, y verificar que lo restaurado no tiene los 3 y sí tiene el borrado).
«Entorno limpio»: base vacía en el Mongo local del mismo portátil que hace el respaldo. Es una base separada de producción, pero no un entorno separado de la máquina que guarda el respaldo; no se probó restaurar en Atlas ni que la app funcione contra la base restaurada.
Los respaldos restaurados tenían 33 colecciones; desde el respaldo de las 10:36 hay 34 (aparece login_attempts). No se ha probado restaurar un respaldo con las 34 colecciones.

Dónde se guarda el respaldo

Solo en D:\WORK\NARA\datos\respaldos_db\ del portátil (ignorado por git por la regla /* de .gitignore). No hay evidencia de copia fuera del portátil (otra región, otro proveedor, almacenamiento de objetos). No se pudo verificar si el disco D: está cifrado (Get-BitLockerVolume sin acceso).
Los archivos son EJSON en claro con datos reales de salud mental (people, patients, clin_citas, teo_conversations).
En el clúster Atlas polaria hay 7 bases nara_restore_* (alinear, claves, prueba1, prueba1b, soak, subida, test): copias en el mismo clúster que producción, no un respaldo independiente. La skill mongo-acceso-nara solo reconoce nara_restore_test.

Respaldo nativo de Atlas

No verificado: no hay acceso a Atlas Admin. pruebas/entornos.md deja el plan del clúster como PENDIENTE.

Procedimiento escrito

docs/trl/runbooks/03_restauracion_respaldo.md v0.1 (2026-10-09) está desactualizado: dice que los respaldos son manuales y el RPO 24 h; usa restaurar.js + comparar_db.js (no restaurar_local.js); la restauración real en producción está «No definida»; «Ejecutado por alguien distinto del autor: PENDIENTE».
pruebas/autorizaciones.md dice que la tarea corre «desde las 05:36»; el registro empieza a las 03:06 (respaldo manual).