Healthcare organisations generate and accumulate data at a scale that makes backup management a genuine operational challenge. A busy acute-care hospital may add terabytes of PACS imaging data monthly, process millions of clinical transactions annually, and maintain records spanning decades. When a ransomware attack, hardware failure, or software corruption event occurs, the ability to recover that data completely and quickly can be the difference between a manageable incident and a catastrophic one.
Backup strategy in healthcare is not a set-and-forget infrastructure task — it is an ongoing programme that requires careful design, disciplined execution, and regular testing.
The 3-2-1 Rule Applied to Healthcare
The 3-2-1 backup rule is the foundational principle: maintain at least three copies of your data, on at least two different media types, with at least one copy stored offsite. In healthcare, this maps to:
- Primary copy — the production data in clinical systems (EHR databases, PACS storage arrays, laboratory systems).
- Local backup copy — a backup copy on different storage media at the same site (tape, separate storage array, NAS).
- Offsite copy — a copy in a geographically separate location, either a secondary data centre, co-location facility, or cloud storage.
For ransomware resilience, a fourth principle is increasingly standard: ensure at least one copy is immutable — protected from modification or deletion, even by the backup system's own credentials. Ransomware attacks routinely target backup systems to eliminate the recovery option. Immutable backup storage (object storage with object lock, air-gapped tape, write-once media) provides a copy that attackers cannot destroy.
What to Back Up
EHR Databases
The EHR is the most critical clinical data source and the primary backup priority. EHR data typically lives in relational databases (Oracle, Microsoft SQL Server, IBM Db2 are common in enterprise EHR platforms). Backup strategy must address both the database itself and associated application configuration, customisations, and integration configurations.
Many EHR platforms include vendor-specific backup and restore tools that must be used for supported recovery. IT teams should understand whether standard database backup methods are fully supported by the EHR vendor or whether vendor-specific tooling is required.
PACS and Medical Imaging
PACS stores diagnostic imaging data — CT, MRI, X-ray, ultrasound, nuclear medicine — and is typically the largest data volume in a healthcare organisation. A moderate-sized hospital may accumulate several hundred terabytes of imaging data over its lifetime.
PACS backup requires a strategy that balances storage cost against recovery requirements. Active and recent studies (the past two to five years) should be on fast-access primary storage with backup. Older archived studies may be on tiered storage — slower, cheaper media — with appropriate backup. Backup windows for PACS can be long given the data volumes, requiring careful scheduling and network capacity planning.
Configuration Files and System Builds
Clinical application configurations, integration engine mappings, interface definitions, and system build documentation are often overlooked in backup planning. Rebuilding a clinical integration engine from scratch after a system failure can take weeks. Backing up configuration data ensures that system configurations can be restored efficiently.
Databases for Laboratory, Pharmacy, and Other Clinical Systems
Laboratory information systems, pharmacy systems, radiology information systems, and other departmental clinical applications each have their own databases and configurations. Backup coverage must extend to all clinical systems, not just the primary EHR.
Backup Technologies
Incremental and Differential Backups
Most production backup strategies use a combination of scheduled full backups (weekly or monthly) with more frequent incremental or differential backups throughout the week.
Incremental backups capture only data changed since the last backup run. They are fast and storage-efficient but require restoration of the full backup plus all subsequent incrementals, which can be time-consuming.
Differential backups capture all changes since the last full backup. Restoration requires only the last full backup and the most recent differential — simpler than incremental restoration but with larger backup sizes as the differential grows through the week.
For clinical databases where RPO requirements are measured in minutes rather than hours, continuous data protection (CDP) tools provide near-real-time replication to a backup system, capturing every write and enabling point-in-time recovery.
Retention Requirements
HIPAA Retention
HIPAA requires covered entities to retain documentation of their Security Rule policies and procedures for six years from the date of creation or the date last in effect, whichever is later. While HIPAA does not mandate a specific retention period for patient records themselves (that is governed by state law), the policies and documentation of backup and security controls must be retained for six years.
State and National Regulations
Patient record retention requirements vary by jurisdiction. In the United States, most states require adult patient records to be retained for a minimum of seven to ten years, with longer requirements for paediatric records (often until the patient reaches 25 or 28). Imaging records may have separate retention requirements.
International healthcare organisations must assess the retention requirements of each country in which they operate, as these vary significantly.
Backup Retention vs Records Retention
Backup retention and records retention are distinct. Backups are point-in-time copies used for recovery; they are not typically the mechanism for meeting long-term records retention obligations. Clinical records archives for long-term retention are a separate function, often managed in a dedicated archive platform with appropriate access controls and audit logging.
Backup Encryption
All backup copies of ePHI must be encrypted, including local backups, offsite backups, and cloud backups. Backup encryption protects against theft of media — a surprisingly common cause of HIPAA breach reports involving physical media.
Encryption keys must be managed carefully. Keys should be stored separately from the encrypted backup data — storing encryption keys alongside the data they protect defeats the purpose of encryption. Key management procedures must be documented, and key recovery procedures must be tested.
Offsite and Cloud Backup
Cloud storage has become a common and cost-effective destination for offsite backup. AWS S3, Azure Blob Storage, and equivalent services provide highly durable object storage with configurable retention policies, lifecycle tiers for cost management, and object lock capabilities for immutable storage.
Healthcare organisations using cloud backup must have a BAA covering the backup storage service and must configure appropriate encryption and access controls. Ingress to cloud storage is typically free; egress (downloading data during a restore) incurs charges that should be understood and accounted for in DR planning.
Network bandwidth is a practical consideration for large backup sets. Initial backup seeding — getting the first full backup of large PACS archives to cloud — may require physical media transfer (AWS Snowball, Azure Data Box) rather than network transfer.
Testing Restores
The most common backup failure is discovering, during an actual recovery, that the backup data is corrupt, incomplete, or not restorable within the required timeframe. The only way to prevent this failure is to test restores regularly.
Restore tests should be scheduled and documented. For critical clinical systems, a test restore to an isolated environment should be conducted at least quarterly. The test should validate that the restored system functions correctly — not just that data was recovered, but that the application operates and data is consistent.
Common Mistakes
Not testing restores — the most consequential oversight. A backup that cannot be restored is not a backup.
No immutable copy — leaving all backups accessible to credentials that could be compromised in a ransomware attack.
Insufficient offsite bandwidth — backup jobs failing because network capacity to the offsite destination cannot accommodate the daily change rate within the backup window.
Overlooking application-layer consistency — backing up database files at the OS level while the database is running, resulting in inconsistent backups that cannot be restored cleanly. Database-aware backup agents or pre/post-backup scripts that quiesce the database are required.
Not including clinical application configuration — recovering a database without the application configuration that makes it usable.
FZ Consulting LLP supports healthcare organisations in designing, implementing, and auditing backup strategies that meet clinical, operational, and regulatory requirements. Contact our team to assess your backup posture.