Hospital PACS storage, backup and disaster recovery: what to design and specify

What does a PACS store, and why is it hard to protect?

A PACS stores every image study a hospital's scanners produce, with the patient and study details carried inside each DICOM object, and serves those studies to radiologists, clinicians and reporting systems. DICOM defines the formats for medical images so they can be exchanged with the data and quality needed for clinical use. It is maintained with NEMA as its secretariat and recognised by ISO as ISO 12052.

Three things make PACS harder to protect than most hospital systems. The data is large and grows every day the scanners run. It is clinically live: a surgeon or emergency physician may need a study within minutes, including an old one for comparison. And it is long-lived: images may be needed years later, so the archive keeps growing and must stay readable through several generations of storage hardware.

That is why storage, backup and disaster recovery must be designed as three separate layers. Storage keeps studies available day to day. Backup keeps a recoverable copy if data is lost, corrupted or encrypted by an attacker. Disaster recovery keeps imaging running, or brings it back quickly, if the whole data centre is lost.

How should PACS storage be arranged?

PACS storage is usually arranged in tiers, with fast storage for recent studies and larger, cheaper storage for the long-term archive. Recent studies are read most often and need the fastest retrieval. Older studies are read less often but must still come back in reasonable time when a clinician asks for a prior.

Many hospitals also separate the archive from the PACS application, using an archive that stores studies in standard DICOM form and can serve more than one viewer or department. Some call this a vendor neutral archive. The point is that the images remain the hospital's, in a standard format, if the PACS software changes.

DICOM gives the buyer a way to check what each system promises. The DICOM Storage Commitment Service Class lets a sending system ask an archive to take responsibility for safekeeping specific images. Under DICOM, the archive must document in its conformance statement the nature of that commitment, including duration of storage, retrieve capabilities and capacity. A tender should ask for those conformance statements and read them.

How long must a hospital keep medical images?

The hospital's legal and medical records teams must set the retention period, and the storage design must be built to meet it. This guide does not state a statutory retention period for medical images in India, because it has not verified one against a primary source for every type of hospital and record.

What is verified is the guidance in the Electronic Health Record Standards for India, first notified by the Ministry of Health and Family Welfare in September 2013 and later revised. They name DICOM as the standard for images. They say all electronic medical records should be preserved and not destroyed during the lifetime of the person, that records of a deceased patient may be made inactive, preferably three years after death, and that hospitals are strongly encouraged never to destroy them. They also say data capacity should be planned to meet the storage requirement set by the mandated rules and laws.

For a storage design, that points one way: plan for a long-lived archive that grows every year, migrates across hardware generations without losing data, and can still be searched and retrieved.

How should RPO and RTO be set for a PACS?

RPO and RTO should be set per service, from what clinicians need, and then used to choose the protection. NIST Special Publication 800-34 Rev. 1 defines the recovery time objective as the maximum time a system can be unavailable before there is an unacceptable impact, and the recovery point objective as the point in time to which data can be recovered after an outage, which reflects how much data loss can be tolerated.

For a PACS the targets often split in two. Studies acquired today and in recent days need a short RTO, because emergency and inpatient care depend on them, and a very short RPO, because a lost scan may mean recalling a patient. The historical archive can often accept a longer RTO, as long as priors for current patients come back first. Setting one target for everything either overspends on the archive or underprotects current work.

No single protection layer covers every failure. The table shows what each layer is for.

Why do PACS backups need an offline or immutable copy?

Because attackers go after backups first. CISA's #StopRansomware Guide, updated in September 2023, advises organisations to maintain offline, encrypted backups of critical data and to regularly test their availability and integrity in a disaster recovery scenario. It notes that many ransomware variants try to find and delete or encrypt backups they can reach.

An immutable backup is one that cannot be changed or deleted for a set period, even by an administrator. It closes the gap that replication leaves open. CISA's guide also sounds a caution: immutable storage does not meet compliance criteria for certain regulations, and misconfiguration can impose significant cost. The immutability period, who can change it, and the cost of keeping large imaging data locked should all be settled before purchase.

The backup system should sit apart from the hospital's everyday systems: separate administrator accounts, multi-factor authentication, and no shared credentials with the PACS or the domain. A backup that can be deleted with a stolen hospital password is not a last line of defence.

Security of the PACS itself also matters. DICOM Part 15 defines security profiles, including secure transport over TLS and audit trail messages. In India, the Digital Personal Data Protection (DPDP) Rules, 2025, notified on 14 November 2025 with an eighteen-month phased compliance period, sit under an Act that penalises a failure to maintain reasonable security safeguards for personal data.

What does disaster recovery for PACS involve?

Disaster recovery for PACS means a second site that can store new studies and serve recent ones if the primary data centre is lost, plus a tested plan for switching over and back. The second site should not share the primary site's main risks, such as the same building, flood zone or power supply.

The plan must cover the scanners as well as the servers. The hospital should decide in advance where each modality sends studies when the primary archive is unreachable, how reporting continues, and how studies acquired during the outage are reconciled afterwards. Radiology and IT staff should rehearse the downtime procedure together.

Recovery should be tested on a schedule, with the results recorded. A test should restore real studies from backup, not only confirm that backup jobs completed, and should measure the actual time against the RTO. A disaster recovery plan that has never been run is an assumption.

What should a PACS storage and DR tender specify?

A tender should specify recovery targets, capacity growth and proof of recovery, not only terabytes and hardware brands.

• RPO and RTO for current studies and for the historical archive, stated separately
• Current annual imaging volume, expected growth, and the retention period the hospital has confirmed
• Storage in standard DICOM form, with DICOM conformance statements for every archive and PACS component
• At least one offline or immutable backup copy, with its retention period and who may change it
• A second site at a safe distance, with its capacity and what it must serve during a disaster
• Separate credentials and multi-factor authentication for backup administration
• Encryption in transit and at rest, and audit logging of access to studies
• Scheduled recovery tests with real restores, measured against the targets, reported to the hospital
• A data migration plan for moving the archive to new hardware without loss

How Ahuva approaches PACS storage and recovery

Ahuva's cloud and virtualisation scope covers private, public and hybrid cloud; backup, disaster recovery and business continuity; and PACS medical imaging. Its data centre scope covers server, storage, virtualisation and HCI, and high-availability architectures. Its OEM authorisations include HPE for server, storage and compute platforms.