Laboratory data backup: restoration and completeness

“Backup completed” describes a technical activity. Alone, it does not demonstrate that the laboratory can recover a sequence, reopen native data and reconstruct how a result was approved. This distinction often emerges only during a failure, when finding missing components is harder.

A useful plan connects what needs protection to evidence of its recovery. Scope includes data and dependencies, the copy’s point in time, responsibilities and criteria for declaring the system usable again. The tests described here are examples for separate authorised environments.

1. Define the complete dataset to recover

Start with a representative laboratory activity and follow its objects: sample, sequence, instrument files, methods and versions, processing, audit trails, signatures and transferred result. Identify each component’s location and the relationship that allows it to be found. The final report alone may not contain everything needed for review.

Add configurations, application versions, compatible components, permissions and dependencies needed for reading. Consider licences and decryption-key availability through appropriate custody procedures: do not place secrets in an ordinary test report.

SDMS management of data and metadata helps identify scope, but centralisation does not automatically demonstrate that every source is backed up.

2. Preserve a consistent recovery point

Databases and linked files may be copied at different times. If the database includes a new acquisition but the file copy stops earlier, recovery may show a record without its signal. The architecture must support a strategy that maintains consistency between components.

Document copy boundaries, handling of work in progress, dependencies between full and incremental copies, and reconciliation. Jobs nominally running together do not prove application consistency. Verify expected behaviour in documentation for the version used and through representative testing.

For interfaces, consider pending messages, acknowledgements and import status. After recovery, already-transferred records and records still requiring attention must be distinguishable, avoiding silent loss or duplication. Instrument–LIMS transfer controls remain part of recovering the process.

3. Translate scope into verifiable criteria

The following original matrix is an example to adapt. For each row, also identify the owner, copy used and test-system version. “Not applicable” requires a reason, not an empty field.

4. Justify frequency, protection and objectives

The recovery point objective, RPO, identifies the point in time to which data must be recoverable; it relates to tolerable data loss. The recovery time objective, RTO, concerns how long the resource can remain unavailable before unacceptable impact. These objectives are justified by the process, not universal values prescribed for pharmaceutical companies.

An RPO does not authorise loss of required GMP records. If the architecture leaves an uncovered interval, assess how to protect it and the consequences of loss. Actual frequency must consider failed copies, delays and media availability; a theoretical schedule does not demonstrate achievement.

Protect copies from unauthorised access, alteration and deletion. Assess shared risks between original and copy: the same room, shared credentials or the same compromised infrastructure. Separate risks on a justified basis, control access and verify that copies and dependencies remain available when the source is not.

5. Simulated case: the database works, signals are missing

In an isolated test, the CDS is restored and permits login. Sequence S24 appears with its results, but three injections cannot open their native signals: the file path was excluded from the job. Record counts and application startup were correct, but recovery fails the completeness criterion.

The team records the deviation, preserves evidence and checks whether a consistent copy of the missing files exists. It does not recreate signals from reports or change links to conceal their absence. It corrects backup scope, assesses the affected period and repeats relevant tests on a new representative copy.

Closure requires opening signals, matching identifiers and versions, accessing audit trails and signatures, and reconciling exceptions. A file that exists but cannot be interpreted by the application is insufficient.

6. Keep the plan usable over time

Testing starts from approved criteria and records the selected copy, initial conditions, actual timings, activities, results and decision. Include samples representing real complexity and functions needed for review; avoid destructive tests on the system in use. Distinguish technical recovery from authorisation to return to service.

Assign technical execution to IT and verification of data meaning to the laboratory, with locally defined quality responsibilities. Monitor missed jobs, errors, capacity and copy accessibility. Version changes, new paths or new interfaces must prompt assessment of the plan and testing to repeat.

Backup supports operational recovery; archiving supports retention and retrieval throughout the required period. Rotating copies that discard history do not alone meet retention needs. Coordinate both purposes and verify them separately.

Sources and status — checked 2 October 2026. EU GMP Annex 11, January 2011 revision, §§7.2 and 16; EMA GMP/GDP Q&A, Data Integrity, Q10; PIC/S PI 041-1, 1 July 2021, §9.9, GMP/GDP inspector guidance; NIST SP 800-34 Rev. 1, May 2010, November 2010 update, §§3.2.1 and 5.1.2: technical reference for federal systems, not a universal GMP requirement. Matrix and case are editorial examples.