The Clinic That Backed Up to a Desk Drawer
Seaview Community Clinic keeps all patient records on a single reception desktop: a 2016 machine with a 500 GB hard drive holding about 18 GB of records, growing by roughly 4 GB a year. The only backup is a 2 TB USB hard drive that the receptionist swaps every Friday evening and stores in her desk drawer. Last month the drive was knocked off the desk and failed, and eight weeks of visits had to be rebuilt from paper files. The clinic has six staff, three consultation rooms, a five-year-old UPS that holds for about four minutes, and mains power that drops several times a week. The fibre link is 20 Mbps down but only 512 kbps up, and the IT budget is EC$250 a month. The administrator has read that RAID 1 'mirrors everything' and wants to fit a second drive inside the desktop instead of spending money on anything else.
1. Evaluate the clinic's current backup arrangements against the risks it actually faces, and recommend a revised strategy with justification.
Read the worked answer
What the current scheme really protects against
- Recovery point: up to seven days of records can be lost, which for patient data means reconstructing clinical decisions from memory and paper.
- Placement: both copies sit in the same building, so fire, flood, theft or a spilled drink destroys both. The incident that already happened - a removable drive being knocked to the floor - shows the handling risk.
- No versioning: if a corrupted file or ransomware infection is copied to the USB drive on Friday, the good copy is overwritten and the loss becomes permanent.
- Never tested: nobody has proved a restore works until the day it is needed.
- Power: a four-minute UPS allows a clean shutdown but not ride-through, and repeated ungraceful shutdowns damage file systems and drives.
Recommendation
Apply the 3-2-1 principle: three copies, on two different media, one offsite. Keep a local daily image on a network drive or a second USB disk that stays connected only during the backup window, and send an encrypted daily incremental copy of the records to a cloud service. Because upload speed is the constraint (see next task), seed the first full copy by shipping an encrypted drive. Add a quarterly restore test with a written log, replace the UPS battery, and restrict who can delete or format the backup target. Cost it against EC$250 a month: cloud storage for 20 GB plus daily deltas is small, and the real cost is the discipline of checking.
2. The administrator argues that RAID 1 makes the USB drive unnecessary. Explain, with reference to the clinic's own incident, why this reasoning fails.
Read the worked answer
RAID 1 writes identical data to two disks inside the same chassis. That protects against exactly one failure mode: a single disk dying while the machine is running and the failure is noticed. It does not protect against the things that actually threaten this clinic.
- Shared environment. Both mirrors share one power supply, one controller, one operating system and one room. A PSU surge during one of the weekly power drops, a fire, a theft or water damage takes both copies at once.
- User and software error are duplicated instantly. If reception deletes the wrong patient folder or ransomware encrypts the volume, the mirror writes the same deletion or ciphertext to the second disk within milliseconds. There is no history to go back to.
- The incident would not have been prevented. The lost records were on a removable drive that was physically damaged. A RAID pair inside the desktop would simply have been the same single point of physical failure.
- Silent degradation. If one disk fails and nobody monitors the array, the machine runs on one disk while everyone believes it is protected.
RAID is an availability measure - it keeps the clinic working while a disk is replaced. Backup is a recoverability measure - it lets the clinic go back to a known good state after loss, corruption or disaster. The clinic needs both, and RAID is not a substitute for the offsite, versioned copy.
3. Given the 512 kbps upload speed, assess whether the clinic could simply upload its full 18 GB record set nightly to a cloud service. Show your working and state what this implies for the design.
Read the worked answer
Working
18 GB = 18 × 8 = 144 Gbit = 144,000 Mbit.
At 512 kbps = 0.512 Mbps of theoretical upload: 144,000 ÷ 0.512 ≈ 281,250 seconds ≈ 78 hours, or over three days of continuous transfer. In practice, TCP overhead, other traffic and the frequent power and link interruptions on this line make the real figure worse, and any interruption restarts or resumes a partial transfer.
Implication
A full nightly upload is not feasible; the link is roughly 40 times too slow for the data volume. The design must therefore:
- Seed the cloud copy physically. Encrypt a copy of the full 18 GB and send it on a drive to the provider, then upload only changes.
- Send daily deltas. Text records change by a few megabytes a day; even 200 MB of changes is 1,600 Mbit ÷ 0.512 ≈ 3,125 seconds, about 52 minutes - comfortably inside an overnight window, provided the backup runs after hours and is set to resume.
- Prioritise. If bandwidth is still tight, back up the patient index and this week's records first, and archive older imaging or scanned documents less often.
- Use compression and deduplication before transmission, and schedule uploads outside clinic hours so reception's own use of the line is not degraded.
The general lesson: backup design is bounded by recovery point objective and by the bandwidth available to meet it, not by storage capacity alone.