PHARMA LAB · PL-06-019
Backup dei dati di laboratorio: ripristino e completezza

In questo articolo
Il messaggio “backup completato” descrive un’attività tecnica. Non dimostra, da solo, che il laboratorio possa recuperare una sequenza, riaprire i dati nativi e ricostruire come è stato approvato un risultato. Questa differenza emerge spesso solo durante un guasto, quando recuperare i pezzi mancanti è più difficile.
Un piano utile collega ciò che deve essere protetto alla prova del suo recupero. Il perimetro comprende dati e dipendenze, il punto temporale della copia, le responsabilità e i criteri per dichiarare nuovamente utilizzabile il sistema. Le prove qui descritte sono esempi per ambienti separati e autorizzati.
1. Definisci il dataset completo da recuperare
Parti da un’attività di laboratorio rappresentativa e segui i suoi oggetti: campione, sequenza, file strumentali, metodi e versioni, elaborazioni, audit trail, firme e risultato trasferito. Identifica dove risiede ciascun componente e quale relazione consente di ritrovarlo. Il solo rapporto finale può non contenere quanto serve per una revisione.
Aggiungi configurazioni, versioni applicative, componenti compatibili, autorizzazioni e dipendenze necessarie alla lettura. Considera licenze e disponibilità delle chiavi di decifratura attraverso procedure di custodia appropriate: non inserire segreti in un normale rapporto di test.
La gestione SDMS di dati e metadati aiuta a individuare il perimetro, ma la centralizzazione non dimostra automaticamente che tutte le sorgenti siano incluse nel backup.
2. Conserva un punto di recupero coerente
Database e file collegati possono essere copiati in momenti diversi. Se il database include una nuova acquisizione mentre la copia dei file si ferma prima, il recupero può mostrare un record senza segnale. Occorre una strategia supportata dall’architettura che garantisca coerenza tra le componenti.
Documenta confini della copia, gestione delle attività in corso, dipendenze tra copie complete e incrementali e modalità di riconciliazione. La semplice contemporaneità nominale dei job non prova la consistenza applicativa. Verifica il comportamento previsto nella documentazione della versione utilizzata e con una prova rappresentativa.
Per le interfacce considera messaggi in attesa, ricevute e stato dell’importazione. Dopo il recupero devono essere riconoscibili record già trasferiti e record ancora da gestire, evitando perdite o duplicazioni silenziose. Il controllo dei passaggi tra strumento e LIMS resta parte del recupero del processo.
3. Traduci il perimetro in criteri verificabili
La matrice seguente è un esempio originale da adattare. Per ogni riga indica anche proprietario, copia utilizzata e versione del sistema di prova. Un controllo dichiarato “non applicabile” richiede una motivazione, non una casella vuota.
| Dataset o dipendenza | Protezione prevista | Prova di recupero | Criterio | Evidenza |
|---|---|---|---|---|
| Database e file nativi | Copia coordinata delle componenti | Aprire una sequenza con segnali | Tutti gli oggetti attesi collegati | Inventario riconciliato e apertura documentata |
| Metodi e versioni | Versioni collegate alle elaborazioni | Richiamare il metodo usato | Versione e parametri corretti | Confronto con riferimento controllato |
| Audit trail e firme | Copia con relazioni conservate | Ricostruire una decisione | Identità, evento e record interpretabili | Percorso di revisione registrato |
| Configurazione e accessi | Baseline e configurazione protette | Avviare e verificare ruoli di test | Funzioni richieste e restrizioni efficaci | Versioni, esiti positivi e negativi |
| Cifratura e lettura | Dipendenze recuperabili e custodite | Leggere la copia protetta | Accesso autorizzato riuscito | Esito senza esposizione di segreti |
| Interfacce | Stati e messaggi necessari | Riconciliare il punto di ripartenza | Nessuna perdita o duplicazione inspiegata | Elenco delle eccezioni e decisioni |
4. Motiva frequenza, protezione e obiettivi
Il recovery point objective, RPO, identifica il punto temporale al quale occorre poter recuperare i dati: si collega alla perdita di dati tollerabile. Il recovery time objective, RTO, riguarda quanto a lungo la risorsa può restare indisponibile prima di un impatto inaccettabile. Sono obiettivi motivati dal processo, non valori universali prescritti alle aziende farmaceutiche.
Un RPO non autorizza a perdere record GMP richiesti. Se l’architettura lascia un intervallo scoperto, valuta come proteggerlo e quali conseguenze avrebbe una perdita. La frequenza effettiva deve considerare copie fallite, ritardi e disponibilità dei supporti; una pianificazione teorica non prova l’obiettivo raggiunto.
Proteggi le copie da accesso, alterazione e cancellazione non autorizzati. Valuta rischi comuni tra originale e copia: stesso locale, credenziali condivise o stessa infrastruttura compromessa. Separa i rischi in modo motivato, controlla gli accessi e verifica che copie e dipendenze restino disponibili quando la sorgente non lo è.
5. Caso simulato: il database funziona, i segnali mancano
In una prova isolata il CDS viene ripristinato e permette l’accesso. La sequenza S24 compare con i risultati, ma tre iniezioni non aprono i segnali nativi: il percorso dei file era escluso dal job. Il conteggio dei record e l’avvio dell’applicazione erano corretti, ma il recupero non soddisfa il criterio di completezza.
Il team registra la deviazione, conserva le evidenze e verifica se esiste una copia coerente dei file mancanti. Non ricrea segnali da rapporti né modifica collegamenti per nascondere l’assenza. Corregge il perimetro del backup, valuta il periodo interessato e ripete le prove pertinenti su una nuova copia rappresentativa.
La chiusura richiede apertura dei segnali, corrispondenza di identificativi e versioni, accesso ad audit trail e firme, e riconciliazione delle eccezioni. Un file presente ma non interpretabile dall’applicazione non basta.
6. Mantieni il piano utilizzabile nel tempo
La prova parte da criteri approvati e registra copia scelta, condizioni iniziali, tempi effettivi, attività eseguite, esiti e decisione. Includi campioni rappresentativi della complessità reale e funzioni necessarie alla revisione; evita prove distruttive sul sistema in uso. Distingui recupero tecnico e autorizzazione al ritorno in servizio.
Assegna a IT l’esecuzione tecnica e al laboratorio la verifica del significato dei dati, con responsabilità qualità definite localmente. Sorveglia job mancati, errori, capacità e accessibilità delle copie. Cambi di versione, nuovi percorsi o nuove interfacce devono attivare una valutazione del piano e delle prove da ripetere.
Il backup sostiene il recupero operativo; l’archivio sostiene la conservazione e reperibilità nel periodo richiesto. Una rotazione delle copie che elimina la storia non risolve da sola l’obbligo di conservazione. Le due finalità devono essere coordinate e verificate separatamente.
Fonti e stato — verifica: 2 ottobre 2026. EU GMP Annex 11, revisione gennaio 2011, §§7.2 e 16; EMA GMP/GDP Q&A, Data Integrity, Q10; PIC/S PI 041-1, 1 luglio 2021, §9.9, guida ispettiva GMP/GDP; NIST SP 800-34 Rev. 1, maggio 2010, aggiornamento novembre 2010, §§3.2.1 e 5.1.2: riferimento tecnico per sistemi federali, non requisito GMP universale. Matrice e caso sono esempi editoriali.
Continua l’approfondimento
PL-06-024
Registri ibridi in laboratorio: carta, dati elettronici e responsabilità
La firma sulla stampa non racconta necessariamente tutta l’analisi. Definisci componenti, collegamenti e responsabilità del record ibrido.
Leggi l’articoloPL-06-023
Aggiornamenti del software strumentale: impatto e ritorno all’uso
Una nuova versione può avviarsi correttamente e cambiare il significato dei dati esportati. Collega ogni modifica a rischi, prove e criteri di rilascio.
Leggi l’articoloPL-06-022
Accesso remoto per assistenza agli strumenti: autorizzazioni e controlli
Governare una sessione di assistenza significa controllare identità, attività e conseguenze sui record. Una checklist e un caso di escalation guidano la decisione.
Leggi l’articolo


