Backup is not restore: validating GxP backup and disaster recovery

What the rules ask for

EU GMP Annex 11 is short on this point and clear. Data should be secured by both physical and electronic means against damage, regular backups should be done, and the integrity and accuracy of backup data and the ability to restore it should be checked during validation and monitored periodically. It also asks for business continuity arrangements for systems that support critical processes.

21 CFR Part 11 comes at it from a different angle, through the requirement that records can be accurately and completely reproduced and protected throughout the retention period. Both end in the same place: it is not enough to copy the data, you have to show you can get it back.

A backup is not a restore

Backup jobs report success when the copy completes. They do not tell you whether the copy is usable. The common failures only show up when you try to restore: a database backed up while it was being written, so the copy is inconsistent; attachments stored in a different location that was never included; encryption keys that were not backed up with the data; or a restore procedure that depends on one person who has since left.

That is why validation needs a real restore, to a separate environment, followed by checks that the data is all there and the application can read it. Restoring a single file to prove the tool works is a start, not the test.

What a meaningful restore test checks

• Record counts match between the source and the restored copy, for the tables or record types that matter.
• A sample of records opens correctly in the application, including attachments and signatures.
• Audit trail entries are present and linked to the right records.
• Metadata survived: who created a record, when, and its status.
• The restore completed within the time the business needs, which you should have written down beforehand.

The last point is the one most often skipped. If production needs to be back within a day and the restore took four, the backup works and the business continuity plan does not.

Cloud and SaaS systems

With a SaaS system the vendor runs the backups, so it is tempting to tick the box and move on. You still own the data and the obligation. Ask the vendor how often they back up, how long they keep copies, where they keep them, and when they last tested a restore. Ask for the evidence, not the policy.

Then think about the scenario the vendor cannot help with: the vendor itself becomes unavailable, or the contract ends. Make sure you can export your data, with audit trails and metadata, in a format you can read without their software. Test that export at least once. Our cloud & SaaS validation page covers the wider shared-responsibility question.

Recovery objectives in plain terms

Two numbers make disaster recovery concrete. How much data can you afford to lose, measured in time since the last good copy? And how long can the system be down before it hurts product, patients or compliance? A system holding batch release data and a system holding training records should not have the same answers.

Agree these with the process owner, not just IT. Then size backup frequency and recovery arrangements to meet them, and test against them.

Keeping it true over time

Systems change. New modules add new data locations, storage moves, encryption gets switched on, and the backup scope quietly stops matching the system. Repeat the restore test on a fixed schedule, and again after any change that touches storage or infrastructure. Record the result in the same place every time, so periodic review can see the history at a glance. Our pieces on periodic review and data integrity cover how this fits into the wider picture.