Copias de seguridad de datos de laboratorio: restauración y completitud

«Copia de seguridad completada» describe una actividad técnica. Por sí sola no demuestra que el laboratorio pueda recuperar una secuencia, abrir los datos nativos y reconstruir cómo se aprobó un resultado. Esta diferencia suele aparecer durante una avería, cuando encontrar los componentes que faltan resulta más difícil.

Un plan útil relaciona lo que debe protegerse con la prueba de su recuperación. El alcance incluye datos y dependencias, punto temporal de la copia, responsabilidades y criterios para declarar el sistema nuevamente utilizable. Las pruebas descritas son ejemplos para entornos separados y autorizados.

1. Definir el conjunto completo que debe recuperarse

Partir de una actividad representativa del laboratorio y seguir sus objetos: muestra, secuencia, archivos instrumentales, métodos y versiones, procesamientos, audit trails, firmas y resultado transferido. Identificar la ubicación de cada componente y la relación que permite localizarlo. El informe final puede no contener todo lo necesario para la revisión.

Añadir configuraciones, versiones de aplicación, componentes compatibles, permisos y dependencias necesarias para la lectura. Considerar licencias y disponibilidad de claves de descifrado mediante procedimientos de custodia adecuados: no incluir secretos en un informe de prueba ordinario.

La gestión SDMS de datos y metadatos ayuda a definir el alcance, pero la centralización no demuestra automáticamente que todas las fuentes estén incluidas en el backup.

2. Conservar un punto de recuperación coherente

La base de datos y los archivos vinculados pueden copiarse en momentos diferentes. Si la base incluye una adquisición nueva pero la copia de archivos termina antes, la restauración puede mostrar un registro sin su señal. La arquitectura debe admitir una estrategia que garantice coherencia entre componentes.

Documentar límites de la copia, tratamiento de actividades en curso, dependencias entre copias completas e incrementales y conciliación. La simultaneidad nominal de las tareas no demuestra consistencia de la aplicación. Verificar el comportamiento esperado en la documentación de la versión utilizada y mediante una prueba representativa.

En interfaces, considerar mensajes pendientes, confirmaciones de recepción y estado de importación. Tras la recuperación deben distinguirse los registros ya transferidos de los pendientes, evitando pérdidas o duplicaciones silenciosas. El control de transferencias entre instrumento y LIMS sigue formando parte de la recuperación del proceso.

3. Convertir el alcance en criterios verificables

La siguiente matriz original es un ejemplo adaptable. Indicar también responsable, copia utilizada y versión del sistema de prueba para cada fila. «No aplicable» exige una justificación, no una casilla vacía.

4. Justificar frecuencia, protección y objetivos

El objetivo de punto de recuperación, RPO, identifica el punto temporal al que los datos deben poder recuperarse; se relaciona con la pérdida de datos tolerable. El objetivo de tiempo de recuperación, RTO, considera cuánto puede permanecer indisponible un recurso antes de un impacto inaceptable. Son objetivos justificados por el proceso, no valores universales prescritos para empresas farmacéuticas.

Un RPO no autoriza perder registros NCF requeridos. Si la arquitectura deja un intervalo sin cubrir, evaluar cómo protegerlo y las consecuencias de una pérdida. La frecuencia real debe considerar copias fallidas, retrasos y disponibilidad de soportes; una programación teórica no demuestra el objetivo alcanzado.

Proteger las copias frente a acceso, alteración y eliminación no autorizados. Evaluar riesgos comunes al original y la copia: mismo local, credenciales compartidas o la misma infraestructura comprometida. Separar los riesgos de forma justificada, controlar accesos y verificar que copias y dependencias estén disponibles cuando la fuente no lo esté.

5. Caso simulado: la base funciona, faltan las señales

En una prueba aislada se restaura el CDS y permite iniciar sesión. La secuencia S24 aparece con sus resultados, pero tres inyecciones no abren las señales nativas: su ruta estaba excluida de la tarea. El número de registros y el arranque eran correctos, pero la recuperación incumple el criterio de completitud.

El equipo registra la desviación, conserva evidencias y comprueba si existe una copia coherente de los archivos ausentes. No recrea señales desde informes ni cambia vínculos para ocultar la ausencia. Corrige el alcance del backup, evalúa el período afectado y repite las pruebas pertinentes sobre una nueva copia representativa.

El cierre exige abrir señales, comprobar identificadores y versiones, acceder a audit trails y firmas, y conciliar excepciones. Un archivo presente pero no interpretable por la aplicación no basta.

6. Mantener el plan utilizable con el tiempo

La prueba parte de criterios aprobados y registra copia seleccionada, condiciones iniciales, tiempos reales, actividades, resultados y decisión. Incluir muestras representativas de la complejidad real y funciones necesarias para la revisión; evitar pruebas destructivas en el sistema en uso. Distinguir recuperación técnica y autorización de vuelta al servicio.

Asignar la ejecución técnica a informática y la verificación del significado de los datos al laboratorio, con responsabilidades de calidad definidas localmente. Vigilar tareas omitidas, errores, capacidad y accesibilidad de las copias. Cambios de versión, nuevas rutas o interfaces deben desencadenar una evaluación del plan y de las pruebas que repetir.

El backup apoya la recuperación operativa; el archivo apoya conservación y localización durante el período requerido. Rotar copias eliminando el historial no resuelve por sí solo las necesidades de conservación. Coordinar ambas finalidades y verificarlas por separado.

Fuentes y estado — verificación: 2 de octubre de 2026. Anexo 11 de las NCF UE, revisión de enero de 2011, §§7.2 y 16; EMA GMP/GDP Q&A, integridad de datos, Q10; PIC/S PI 041-1, 1 de julio de 2021, §9.9, guía de inspección NCF/BPD; NIST SP 800-34 Rev. 1, mayo de 2010, actualización de noviembre de 2010, §§3.2.1 y 5.1.2: referencia técnica para sistemas federales, no requisito NCF universal. Matriz y caso son ejemplos editoriales.