Datensicherung im Labor: Wiederherstellung und Vollständigkeit

„Datensicherung abgeschlossen“ beschreibt eine technische Tätigkeit. Die Meldung allein belegt nicht, dass das Labor eine Sequenz wiederherstellen, native Daten öffnen und die Genehmigung eines Ergebnisses nachvollziehen kann. Dieser Unterschied wird oft erst bei einem Ausfall sichtbar, wenn fehlende Bestandteile schwerer zu beschaffen sind.

Ein brauchbarer Plan verbindet den Schutzbedarf mit dem Nachweis der Wiederherstellbarkeit. Er umfasst Daten und Abhängigkeiten, den Zeitpunkt der Kopie, Verantwortlichkeiten und Kriterien für die erneute Nutzbarkeit. Die hier beschriebenen Prüfungen sind Beispiele für getrennte, autorisierte Umgebungen.

1. Den vollständigen wiederherzustellenden Datenbestand bestimmen

Von einer repräsentativen Labortätigkeit ausgehen und ihre Objekte verfolgen: Probe, Sequenz, Instrumentendateien, Methoden und Versionen, Verarbeitungen, Audit Trails, Signaturen und übermitteltes Ergebnis. Speicherort jeder Komponente und die Beziehung zu ihrer Wiederauffindbarkeit bestimmen. Der Abschlussbericht allein enthält möglicherweise nicht alles für die Prüfung.

Konfigurationen, Anwendungsversionen, kompatible Komponenten, Berechtigungen und zum Lesen erforderliche Abhängigkeiten ergänzen. Lizenzen und die Verfügbarkeit von Entschlüsselungsschlüsseln über geeignete Verwahrungsverfahren berücksichtigen: Geheimnisse gehören nicht in einen normalen Prüfbericht.

Die SDMS-Verwaltung von Daten und Metadaten hilft bei der Abgrenzung. Zentralisierung belegt jedoch nicht automatisch, dass alle Quellen in der Sicherung enthalten sind.

2. Einen konsistenten Wiederherstellungspunkt erhalten

Datenbank und verknüpfte Dateien können zu unterschiedlichen Zeitpunkten kopiert werden. Enthält die Datenbank eine neue Erfassung, während die Dateikopie früher endet, kann nach Wiederherstellung ein Datensatz ohne Signal erscheinen. Die Architektur muss eine Strategie unterstützen, die Konsistenz zwischen Komponenten sicherstellt.

Kopiergrenzen, Behandlung laufender Tätigkeiten, Abhängigkeiten zwischen Voll- und inkrementellen Sicherungen sowie Abgleich dokumentieren. Nominell gleichzeitige Jobs belegen keine Anwendungskonsistenz. Erwartetes Verhalten anhand der Dokumentation der verwendeten Version und einer repräsentativen Prüfung bestätigen.

Bei Schnittstellen ausstehende Nachrichten, Empfangsbestätigungen und Importstatus berücksichtigen. Nach Wiederherstellung müssen bereits übertragene und noch zu bearbeitende Datensätze unterscheidbar bleiben, ohne unbemerkte Verluste oder Duplikate. Die Kontrolle der Instrument–LIMS-Übertragung bleibt Teil der Prozesswiederherstellung.

3. Den Umfang in prüfbare Kriterien übersetzen

Die folgende eigene Matrix ist ein anzupassendes Beispiel. Für jede Zeile außerdem Verantwortlichen, verwendete Kopie und Testsystemversion angeben. „Nicht anwendbar“ benötigt eine Begründung statt eines leeren Feldes.

4. Häufigkeit, Schutz und Ziele begründen

Das Recovery Point Objective, RPO, bezeichnet den Zeitpunkt, auf den Daten wiederherstellbar sein müssen; es steht mit tolerierbarem Datenverlust in Beziehung. Das Recovery Time Objective, RTO, betrifft die zulässige Nichtverfügbarkeit einer Ressource vor unakzeptablen Auswirkungen. Diese Ziele werden aus dem Prozess begründet und sind keine universellen pharmazeutischen Vorgabewerte.

Ein RPO erlaubt keinen Verlust erforderlicher GMP-Aufzeichnungen. Bleibt architektonisch ein ungeschütztes Intervall, sind dessen Absicherung und mögliche Verlustfolgen zu bewerten. Die tatsächliche Häufigkeit muss fehlgeschlagene Kopien, Verzögerungen und Medienverfügbarkeit berücksichtigen; ein theoretischer Zeitplan belegt keine Zielerreichung.

Kopien vor unautorisiertem Zugriff, Änderung und Löschung schützen. Gemeinsame Risiken von Original und Kopie bewerten: gleicher Raum, gemeinsame Zugangsdaten oder dieselbe kompromittierte Infrastruktur. Risiken begründet trennen, Zugriffe kontrollieren und die Verfügbarkeit von Kopien und Abhängigkeiten bei nicht verfügbarer Quelle prüfen.

5. Simulierter Fall: Datenbank vorhanden, Signale fehlen

In einem isolierten Test wird das CDS wiederhergestellt und erlaubt die Anmeldung. Sequenz S24 erscheint mit Ergebnissen, doch drei Injektionen öffnen keine nativen Signale: Der Dateipfad war vom Job ausgeschlossen. Datensatzanzahl und Anwendungsstart waren korrekt, das Vollständigkeitskriterium ist dennoch nicht erfüllt.

Das Team dokumentiert die Abweichung, sichert Nachweise und prüft, ob eine konsistente Kopie der fehlenden Dateien existiert. Es rekonstruiert keine Signale aus Berichten und verändert keine Verknüpfungen, um das Fehlen zu verdecken. Es korrigiert den Sicherungsumfang, bewertet den betroffenen Zeitraum und wiederholt relevante Prüfungen mit einer neuen repräsentativen Kopie.

Zum Abschluss gehören das Öffnen der Signale, passende Kennungen und Versionen, Zugriff auf Audit Trails und Signaturen sowie geklärte Ausnahmen. Eine vorhandene, aber von der Anwendung nicht interpretierbare Datei reicht nicht.

6. Den Plan dauerhaft nutzbar halten

Prüfungen beginnen mit genehmigten Kriterien und dokumentieren ausgewählte Kopie, Ausgangsbedingungen, tatsächliche Zeiten, Tätigkeiten, Ergebnisse und Entscheidung. Repräsentative Beispiele realer Komplexität und benötigte Prüffunktionen einbeziehen; destruktive Tests am genutzten System vermeiden. Technische Wiederherstellung von der Freigabe zur Wiederinbetriebnahme trennen.

Technische Ausführung der IT und Prüfung der Datenbedeutung dem Labor zuweisen, mit lokal festgelegter Qualitätsverantwortung. Ausgebliebene Jobs, Fehler, Kapazität und Zugänglichkeit der Kopien überwachen. Versionsänderungen, neue Pfade oder Schnittstellen müssen eine Bewertung des Plans und erforderlicher Wiederholungsprüfungen auslösen.

Backups dienen der betrieblichen Wiederherstellung; Archive der Aufbewahrung und Auffindbarkeit im erforderlichen Zeitraum. Eine Kopienrotation, die Historie verwirft, erfüllt den Aufbewahrungsbedarf nicht allein. Beide Zwecke koordinieren und getrennt prüfen.

Quellen und Status — geprüft am 2. Oktober 2026. EU-GMP-Annex 11, Revision Januar 2011, §§7.2 und 16; EMA GMP/GDP Q&A, Datenintegrität, Frage 10; PIC/S PI 041-1, 1. Juli 2021, §9.9, GMP/GDP-Inspektionsleitfaden; NIST SP 800-34 Rev. 1, Mai 2010, Aktualisierung November 2010, §§3.2.1 und 5.1.2: technische Referenz für US-Bundessysteme, keine universelle GMP-Anforderung. Matrix und Fall sind redaktionelle Beispiele.