A HIPAA-compliant backup that nobody has ever restored is a filing cabinet with a lost key. Ransomware crews know it. In its 2024 healthcare survey, Sophos found that only 22% of victims fully recovered within a week, while 37% needed more than a month, and 67% of the healthcare organizations it polled had been hit that year, up from 60% in 2023.Why Ransomware Recovery Decides Your HIPAA Backup PlanWhat the HIPAA Security Rule Requires of Clinic Backups in 2026Prerequisites and Versions You NeedWhich Cloud Backup Route Fits a Small ClinicPhase 1: Plan Recovery Tiers and Targets (Steps 1 and 2)Phase 2: Build the Immutable Cloud Repository (Steps 3 to 5)Phase 3: Run Encrypted Backups on a Schedule (Steps 6 and 7)Phase 4: Build the Clean Room (Steps 8 and 9)Phase 5: Simulate the Attack, Restore, and Record Evidence (Steps 10 to 13)The Complete Working Project: One-Command Recovery DrillThe drill scriptSample outputCommon Pitfalls That Break Clinic RecoveryTroubleshooting: 10 Problems and FixesAdvanced Tips for Tighter RecoveryWhen to move up to a commercial platformAustralian Readers: Using This Drill Across Two RulebooksFAQ: HIPAA Ransomware Recovery and Cloud Backup
This tutorial walks a small clinic through HIPAA ransomware recovery from the cloud backup side. You will build an immutable repository, lock down who can restore from it, stand up an isolated clean room, and run a timed drill that produces evidence for your auditor. The pattern follows the ransomware-proof backup approach with Arq and Google Cloud we covered earlier, but here the focus is the restore, not the backup job.
The build takes about 90 minutes on a spare Linux box and a small test dataset. It costs a few dollars of object storage while you test. By the end you will have a working script, a drill log, and a one-page recovery record you can hand to a compliance officer.
Google · Preferred Sources
Don’t miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Add Now
Why Ransomware Recovery Decides Your HIPAA Backup Plan
Most “best HIPAA cloud backup” lists compare storage prices and encryption badges. Those matter, yet they skip the question a regulator asks after an incident: how fast did you get patient data back, and can you prove it? A backup you have not restored under pressure is an assumption, not a control.
The same Sophos research shows why. Attackers tried to compromise backups in 95% of healthcare attacks, and 73% of victims still restored encrypted data from backups. Those two numbers sit side by side for a reason. Your backup is the target, so the design has to survive an attacker who holds a domain admin password. The mean cost of recovery, excluding any ransom, reached US$2.57 million in the 2024 survey.
You may like
The U.S. Department of Health and Human Services keeps pressing the point in enforcement. On July 29, 2026, HHS’s Office for Civil Rights announced a settlement with OSF Healthcare System over a ransomware incident involving the Nephilim variant, which affected the protected health information of 53,907 people. The resolution stressed that stolen data led to an impermissible disclosure. That tells clinics backups cover only one part of the response. Prevention, detection, access control and breach notification still apply.
Money is part of the picture too. HHS reportedly kept 2026 civil monetary penalties at 2025 levels by skipping the inflation adjustment, as HIPAA Journal reported on October 22. That is a pause in indexing, not a softer stance. A clinic that cannot show a tested restore carries the same exposure it did last year.
So the goal of this guide is narrow and practical. We design for the day your file server, your EHR export share and your domain controller are all encrypted at once. Everything below serves that day.
What the HIPAA Security Rule Requires of Clinic Backups in 2026
The HIPAA Security Rule remains in force as of October 26, 2026. It requires covered entities and business associates to keep retrievable exact copies of electronic protected health information (ePHI), maintain a disaster recovery plan, and run an accurate and thorough risk analysis. Periodic testing of those plans sits in the rule as an addressable specification, which means you either do it or document why an equivalent measure works.
Three points trip clinics up. First, HHS does not prescribe a backup product, a retention period or a recovery time objective. You choose them through your risk analysis and defend the choice. Second, HIPAA is a regulatory framework, so no vendor is “HIPAA certified” by HHS. Third, a Business Associate Agreement (BAA) with your storage provider is a separate paper trail from the technical setup. We cover the contract side in our guide to signing a HIPAA BAA for cloud backup.
A 2025 proposal to tighten the Security Rule had not been finalised as of October 24, 2026, with the proposed final action reportedly pencilled in for July 2027. Treat it as a preview, not law. Building immutable, tested recovery now costs little and positions you for either outcome.
CISA, the U.S. cyber agency, has pushed the same design. Its Gunra ransomware advisory, published August 10, 2026, reportedly recommends multiple copies of sensitive data in physically separate, segmented locations including cloud storage, plus offline or immutable backups. The agency is under budget and staffing pressure (a proposed fiscal 2027 cut of roughly US$700 million has been reported, though it remains a proposal), so do not count on it for hands-on help during an incident.
Prerequisites and Versions You Need
Gather these before you start. The lab uses open-source tooling so you can test without a licence, then swap in a commercial product later if you prefer. Where a vendor publishes a version, we give it. Where we do not have a confirmed number, we say “latest stable release” instead of guessing.
Backup host: a small Ubuntu Server LTS machine with modest CPU, memory and disk. A VM or spare mini PC works.Clean-room host: a second, fresh Ubuntu Server machine with no domain membership and no saved credentials.Backup engine: Kopia, latest stable release (it supports S3 Object Lock retention natively).Object storage: an S3-compatible bucket with Object Lock. This guide uses Wasabi Hot Cloud Storage in the Sydney region (ap-southeast-2). Backblaze B2 also offers Object Lock.CLI tools: AWS CLI v2 (latest stable release) for bucket setup, ClamAV (from the Ubuntu repositories), jq and nftables.Test data: about 500 MB of synthetic records. Never use real patient data in a drill until your BAA and access controls are signed off.Accounts: a cloud storage account with MFA enabled on the root login, plus a password manager for keys.
One cost note. Wasabi lists Hot Cloud Storage at US$7.99 per TB per month, with no egress, API request or Object Lock charges, subject to its fair-use policy. The product guide reportedly applies a 1 TB monthly minimum and a 90-day minimum storage duration, so a tiny test bucket still bills for 1 TB. Budget a few dollars and delete the lab bucket only after the retention window lapses.
Which Cloud Backup Route Fits a Small Clinic
Before the build, pick your route. A clinic with one IT contractor and 10 to 50 workloads has three realistic paths: assemble it yourself, buy a self-managed commercial platform, or hand it to a managed service. The table uses only details confirmed on vendor pages or in current vendor announcements as of October 26, 2026.
RouteCurrent state (Oct 26, 2026)Clean-room fitPrice signalKopia plus Wasabi Hot Cloud Storage (this tutorial)Wasabi still sells Hot Cloud Storage under that name, with Object Lock includedYou build and script the clean room yourselfUS$7.99 per TB per monthVeeam Data PlatformBackup & Replication 12.3.2.4934 (Patch 4, released Oct 6, 2026), Recovery Orchestrator v13.1 (Oct 8, 2026) in the Premium EditionOrchestrator automates repeatable recovery plansNo official public price confirmedVeeam Data Platform EssentialsSelf-managed option for smaller environments, up to 50 workloadsSame engine, fewer orchestration extrasNo official public price confirmedN-able Cove Data ProtectionCove 26.10 released Oct 22, 2026, DRaaS announced Apr 14, 2026Isolated clean-room recovery described Oct 15, 2026, provisioned before an attackNo public per-seat price confirmedBackblaze B2 with a backup clientB2 Cloud Storage active, Object Lock available at no extra chargeStorage target only, you add the restore workflowCheck Backblaze’s current price page
Two caveats apply. Veeam has announced Data Platform v13.2 for later in Q4 2026, but it is not generally available today, so plan around v13.1 and the 12.3.2 patch line. And for N-able Cove, we could not confirm a HIPAA-specific plan or a BAA from current sources, so ask the vendor in writing before you load ePHI onto any managed service. N-able also reported that Omdia named Cove a managed BDR champion for the third consecutive year. That is a vendor-reported recognition, not an independent test of clinic recovery speed.
The rest of this tutorial uses the Kopia and Wasabi route because every step is visible and scriptable. The same drill logic carries over to Veeam or Cove. You would swap the commands and keep the structure: immutable copy, restore-only identity, isolated target, scan, verify, record.
Phase 1: Plan Recovery Tiers and Targets (Steps 1 and 2)
Step 1: Inventory what holds ePHI. Open a spreadsheet and list every system that stores, processes or transmits patient data. Include the obvious ones such as the practice management database and the EHR export share. Add the forgotten ones too: the scanner that emails PDFs, the shared drive full of referral letters, the VoIP voicemail server and the laptop the practice manager uses at home. Your HIPAA risk analysis should already hold this list. If it does not, this is the moment to start it.
For each system, record the owner, the data size, where it runs and how a restore would work. Keep the sheet short. Twenty rows beat two hundred, because you will test every row.
Step 2: Assign tiers and write down your targets. Clinic recovery guidance restores in tiers, and so should you. Tier 1 covers anything tied to patient safety, such as medication records and the core clinical system. Tier 2 covers scheduling, billing and the patient portal. Tier 3 covers admin shares and archives. Pick a recovery time objective (RTO) and a recovery point objective (RPO) per tier, then check whether your backup frequency can meet them.
Tier 1: RTO 4 hours, RPO 1 hour. Example: clinical records database export.Tier 2: RTO 24 hours, RPO 24 hours. Example: billing and scheduling data.Tier 3: RTO 72 hours, RPO 24 hours. Example: general documents and old scans.
These numbers are examples, not requirements. HHS does not set recovery targets, so your risk analysis does. Pick numbers you can actually hit in the drill, then tighten them later. A target you meet beats an ambitious target you only wrote down.
The industry shorthand for the copy count has grown over the past few years. One October 2026 explainer from Harmony MSP describes how ransomware pushed the classic 3-2-1 rule to 3-2-1-1-0: three copies, two media types, one off-site, one immutable or offline, and zero errors after restore verification. Our drill tests the last two of those digits directly.
Phase 2: Build the Immutable Cloud Repository (Steps 3 to 5)
Step 3: Create an Object Lock bucket. Object Lock must be switched on when the bucket is created. You cannot add it later on most S3-compatible stores, so do not skip the flag. Install the AWS CLI v2, then add a named profile for your storage account. Use an administrator key held by a human, never by the backup host.
aws configure --profile wasabi-admin
# AWS Access Key ID: (admin key, stored in your password manager)
# AWS Secret Access Key: (admin secret)
# Default region name: ap-southeast-2
export EP=https://s3.ap-southeast-2.wasabisys.com
export BUCKET=clinic-hipaa-backup-lab
aws s3api create-bucket --bucket "$BUCKET" \
--object-lock-enabled-for-bucket \
--create-bucket-configuration LocationConstraint=ap-southeast-2 \
--endpoint-url "$EP" --profile wasabi-admin
aws s3api put-object-lock-configuration --bucket "$BUCKET" \
--object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}' \
--endpoint-url "$EP" --profile wasabi-admin
aws s3api get-object-lock-configuration --bucket "$BUCKET" \
--endpoint-url "$EP" --profile wasabi-admin
Expect the last command to echo back your retention rule. Compliance mode means nobody, including the account owner, can shorten or remove the lock before the 30 days pass. That is the point. It is also why you test with a throwaway bucket first. For retention periods that fit your own record rules, see our walkthrough on HIPAA backup retention with immutable cloud storage.
Step 4: Create two identities, one that writes and one that only restores. This split is the heart of the design. The backup host gets a writer key. The clean room gets a restore-only key that lives in a password manager and never touches a production machine. If ransomware steals the writer key, it cannot read old data. If someone steals the restore key, they cannot change a byte.
Create two users in your storage console, then attach these policies. Save each as a JSON file and upload it through the console or the provider’s IAM commands.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "WriterObjects",
"Effect": "Allow",
"Action": ["s3:PutObject","s3:GetObject","s3:DeleteObject",
"s3:PutObjectRetention","s3:GetObjectRetention"],
"Resource": "arn:aws:s3:::clinic-hipaa-backup-lab/*"
},
{
"Sid": "WriterBucket",
"Effect": "Allow",
"Action": ["s3:ListBucket","s3:GetBucketObjectLockConfiguration",
"s3:GetBucketLocation"],
"Resource": "arn:aws:s3:::clinic-hipaa-backup-lab"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestoreObjects",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:GetObjectVersion","s3:GetObjectRetention"],
"Resource": "arn:aws:s3:::clinic-hipaa-backup-lab/*"
},
{
"Sid": "RestoreBucket",
"Effect": "Allow",
"Action": ["s3:ListBucket","s3:ListBucketVersions",
"s3:GetBucketObjectLockConfiguration","s3:GetBucketLocation"],
"Resource": "arn:aws:s3:::clinic-hipaa-backup-lab"
}
]
}
Validate each file with jq . policy.json before you upload it, because a stray bracket makes the console reject the policy with a vague error. Turn on MFA for the console login of both users, and store both secrets in your password manager under separate entries. If you hold the keys under a customer-managed scheme, the pattern in our piece on HIPAA cloud backup encryption keys applies here too.
Step 5: Initialise the Kopia repository with retention. Install Kopia from its official apt repository on the backup host. Then create the repository with Object Lock retention so Kopia extends locks during its own maintenance runs. Use the writer key here. Choose a long, random repository password and write it on paper in a sealed envelope held by the practice owner, because that password encrypts everything.
export AWS_ACCESS_KEY_ID='WRITER_KEY_ID'
export AWS_SECRET_ACCESS_KEY='WRITER_SECRET'
export KOPIA_PASSWORD='long-random-repository-password'
kopia repository create s3 \
--bucket=clinic-hipaa-backup-lab \
--endpoint=s3.ap-southeast-2.wasabisys.com \
--region=ap-southeast-2 \
--access-key="$AWS_ACCESS_KEY_ID" \
--secret-access-key="$AWS_SECRET_ACCESS_KEY" \
--retention-mode=COMPLIANCE \
--retention-period=720h
kopia repository status
The status output should show an S3 repository on your bucket, the encryption algorithm and the retention settings. If you see an error about Object Lock not being enabled, the bucket was created without the flag in Step 3. Delete the empty bucket and start again. Kopia encrypts data on the client before upload, so the storage provider only ever holds ciphertext.
Phase 3: Run Encrypted Backups on a Schedule (Steps 6 and 7)
Step 6: Create test data, a hash manifest, and the first snapshot. The manifest is what lets you prove a restore is complete rather than merely “looks fine”. It lists the SHA-256 hash of every file, and it travels inside the snapshot so you can verify against it after recovery. Run these commands on the backup host.
sudo mkdir -p /srv/ehr-export
sudo chown "$USER" /srv/ehr-export
cd /srv/ehr-export
for i in $(seq 1 150); do
head -c 2M /dev/urandom | base64 > "record-$i.txt"
done
find . -type f ! -name MANIFEST.sha256 -exec sha256sum {} + > MANIFEST.sha256
wc -l MANIFEST.sha256
du -sh /srv/ehr-export
kopia policy set --global \
--keep-latest 10 --keep-daily 30 --keep-weekly 8 --keep-monthly 12 \
--compression=zstd
kopia snapshot create /srv/ehr-export
You should see one line in the manifest for every test file, a folder size that matches what you generated, and a snapshot summary that reports the files uploaded and the elapsed time. Note the snapshot ID and the duration. That duration is your first rough measure of backup speed on your own link. Because the test files are random, they will not compress, so a real clinic dataset will usually upload less than this.
You may like
Step 7: Schedule backups and maintenance with systemd. Cron works, but a systemd timer gives you logs through the journal and catches runs missed while the machine was off. Create a service and a timer. The Tier 1 RPO of one hour in our plan means this timer runs hourly. Tier 2 and 3 data can sit on a daily timer.
# /etc/systemd/system/kopia-ehr.service
[Unit]
Description=Kopia snapshot of /srv/ehr-export
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
User=backup
Environment=KOPIA_PASSWORD_FILE=/etc/kopia/repo.pass
ExecStart=/usr/bin/kopia snapshot create /srv/ehr-export
ExecStartPost=/usr/bin/kopia maintenance run
# /etc/systemd/system/kopia-ehr.timer
[Unit]
Description=Hourly Kopia snapshot
[Timer]
OnCalendar=hourly
Persistent=true
RandomizedDelaySec=120
[Install]
WantedBy=timers.target
Enable it with sudo systemctl enable --now kopia-ehr.timer, then confirm with systemctl list-timers kopia-ehr.timer. Store the repository password file with mode 600, owned by the backup user. A readable password file on the backup host is a weak point, so treat that host as high value and keep it off the domain. For a commercial equivalent with immutability built into the product, our Veeam immutable cloud backup guide shows the same idea on the Veeam stack.
The maintenance step matters more than it looks. Kopia extends Object Lock on blobs it still needs during maintenance, so skipping it lets locks on live data expire. Check the journal after the first scheduled run with journalctl -u kopia-ehr.service -n 40 and look for a clean exit.
Phase 4: Build the Clean Room (Steps 8 and 9)
A clean room, sometimes called an isolated recovery environment, is a separate network segment or cloud account where you restore, scan and rebuild systems before reconnecting them to production. ProvenData’s October 2026 incident-response write-up describes the same idea and adds restore-only access through a separate account to immutable, offline or logically air-gapped backups. That matches the two-identity design from Step 4.
Step 8: Lock down the clean-room network. Use a fresh Ubuntu Server machine. It must not join your domain, trust your DNS, or hold any production credential. Apply an nftables ruleset that allows only what the drill needs: outbound DNS and HTTPS (for the storage endpoint and virus signature updates), and inbound SSH from one admin address. Block your internal address ranges so a compromised restore cannot reach production.
# /etc/nftables.conf on the clean-room host
flush ruleset
table inet cleanroom {
chain input {
type filter hook input priority 0; policy drop;
iif "lo" accept
ct state established,related accept
ip saddr 203.0.113.10 tcp dport 22 accept
}
chain output {
type filter hook output priority 0; policy drop;
oif "lo" accept
ct state established,related accept
ip daddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 } drop
udp dport 53 accept
tcp dport 53 accept
tcp dport 443 accept
}
}
Replace the placeholder admin address in the ruleset with your own. Load the rules with sudo nft -f /etc/nftables.conf and enable the service so they survive a reboot. Then test the wall. From the clean room, curl -I https://example.com should work, while a ping or a connection to any 192.168.x.x host should fail. Point the machine at a public DNS resolver, because your internal resolver now sits behind the block.
In a cloud-account version of this step, you would create a separate account or project, give it no peering to production, and pre-provision the networking before an incident. N-able’s Cove material makes the same timing point: build the isolated environment ahead of the attack, not during it.
Step 9: Install tools and connect with the restore-only key. On the clean room, install Kopia and ClamAV, refresh the virus signatures, and connect to the repository in read-only mode using the restore key from Step 4. Never copy the writer key here. Type the restore secret by hand from the password manager and clear your shell history afterwards.
sudo apt-get update
sudo apt-get install -y clamav jq
sudo systemctl stop clamav-freshclam
sudo freshclam
# install kopia from its official apt repository, then:
export KOPIA_PASSWORD='long-random-repository-password'
kopia repository connect s3 \
--readonly \
--bucket=clinic-hipaa-backup-lab \
--endpoint=s3.ap-southeast-2.wasabisys.com \
--region=ap-southeast-2 \
--access-key='RESTORE_KEY_ID' \
--secret-access-key='RESTORE_SECRET'
kopia snapshot list --all
A healthy connection lists your snapshots with timestamps and sizes. Now prove the restore key cannot write. Run kopia snapshot create /etc/hostname from the clean room and confirm it fails with a read-only or access denied error. If that command succeeds, your key is too powerful, so stop and fix the policy before you go further.
Phase 5: Simulate the Attack, Restore, and Record Evidence (Steps 10 to 13)
Step 10: Simulate ransomware against the test data. Work only on the synthetic folder from Step 6. Encrypt every file the way a crypto-locker would, delete the originals, then try to destroy the stored backup using the most powerful key you own. The point is to see the lock hold under your own attack.
# On the backup host: encrypt the test folder (SYNTHETIC DATA ONLY)
cd /srv/ehr-export
for f in record-*.txt; do
openssl enc -aes-256-cbc -pbkdf2 -salt -pass pass:attacker \
-in "$f" -out "$f.locked" && rm "$f"
done
echo "ATTACK-TIME: $(date -u +%Y-%m-%dT%H:%M:%SZ)" | tee /tmp/attack-time.txt
# Try to wipe a stored object version with the ADMIN key
KEY=$(aws s3api list-object-versions --bucket "$BUCKET" --max-items 1 \
--endpoint-url "$EP" --profile wasabi-admin \
--query 'Versions[0].[Key,VersionId]' --output text)
set -- $KEY
aws s3api delete-object --bucket "$BUCKET" --key "$1" --version-id "$2" \
--endpoint-url "$EP" --profile wasabi-admin
The delete should fail with an AccessDenied error that mentions object lock or retention. If it succeeds, your bucket is not in compliance mode, or Object Lock was never enabled, and you have found a serious gap in a safe place. Write the attack timestamp down. It anchors the next step, because you want the last snapshot taken before it. The hourly timer may already have captured encrypted files, so do not simply restore the newest snapshot.
Step 11: Pick the last trusted snapshot and restore it, timed. Start a stopwatch the moment you sit down at the clean room. Choosing the recovery point is a human decision in a real incident, so practise it. Filter snapshots by start time, then restore the newest one that predates the attack.
# On the clean-room host
ATTACK=$(cut -d' ' -f2 /tmp/attack-time.txt) # copy the value across by hand
SNAP=$(kopia snapshot list --all --json | jq -r --arg t "$ATTACK" \
'[.[] | select(.startTime < $t)] | sort_by(.startTime) | last | .id')
echo "Restoring snapshot: $SNAP"
sudo mkdir -p /restore && sudo chown "$USER" /restore
START=$(date +%s)
kopia restore "$SNAP" /restore
END=$(date +%s)
echo "Restore seconds: $((END-START))"
A typical run prints the snapshot ID, a progress line for files and bytes, and finally the elapsed seconds. On a small test set over a decent connection the restore should finish quickly, although your numbers will differ with link speed and region. Compare the figure against your Tier 1 RTO. A fast restore of a small test set tells you nothing about restoring 2 TB, so scale it: divide your real dataset size by the throughput you just measured and see whether the answer fits the target.
For deeper drill structure, including monthly sample restores and quarterly full-application tests, see our guide to running cloud backup restore drills. This tutorial is the clinic-and-ransomware version of that routine.
Step 12: Verify integrity and scan before anything goes back. Two checks run before the restored data leaves the clean room. First, compare every file against the manifest to confirm the restore is complete and untouched. Second, scan the files for malware, because an attacker may have sat in your network for weeks before encrypting, which means old snapshots can hold implants too.
cd /restore
sha256sum -c MANIFEST.sha256 --quiet
echo "Manifest check exit code: $?"
clamscan -r --infected --log=/var/log/drill-clamscan.log /restore
tail -n 8 /var/log/drill-clamscan.log
kopia snapshot verify --verify-files-percent=10
Expect a silent manifest check with exit code 0, a ClamAV summary showing zero infected files, and a verify run that reports no errors. Any non-zero exit means stop. ClamAV is a lab-grade scanner, so on a real incident run your endpoint detection tool inside the clean room too, and rebuild servers from known-good images rather than trusting restored system files. Restore Tier 1 first, validate it with the clinical lead, then move to Tier 2 and Tier 3.
Read nextStacklet’s AI FinOps Benchmark Spans 3 Clouds [2026]Cloud Computing · 20 h ago
Step 13: Write the drill record. The drill is only half the value. The other half is a dated record that shows you tested recovery, what you found and what you fixed. Keep it in a place the attacker cannot reach, such as a separate document system with its own login. Our HIPAA cloud backup disaster recovery plan guide shows where this record sits in the wider plan.
Evidence itemWhat to captureWhy an auditor caresScope and dateSystems tested, tier, drill date, who ran itShows testing of the contingency plan on a scheduleObject Lock proofOutput of the lock configuration command and the failed deleteShows backups cannot be altered during the retention windowRecovery point choiceAttack timestamp, snapshot ID chosen, reasonShows a deliberate decision on the last trusted copyTimingsStart, end, elapsed seconds, throughputCompares real recovery against the stated RTOIntegrity resultManifest check exit code, verify outputShows data came back complete and unalteredMalware scanClamAV or EDR summary, signature dateShows data was checked before reconnecting to productionFindings and fixesWhat failed, who owns the fix, due dateShows the risk-management loop actually closes
Keep the record for at least as long as your policy requires for compliance documentation, and apply the same schedule to every drill. Check your own policy and any state rules with counsel, since this article is not legal advice.
The Complete Working Project: One-Command Recovery Drill
Steps 10 to 13 are fine for a first run, but a drill you repeat every month has to be a script. This one runs on the clean-room host after you have connected to the repository in read-only mode. It picks the last trusted snapshot, restores it, checks the manifest, scans for malware, compares elapsed time against your RTO, and writes a JSON record you can file as evidence.
The drill script
#!/usr/bin/env bash
# clean-room-drill.sh : timed restore, verify and scan, with a JSON record
set -euo pipefail
: "${KOPIA_PASSWORD:?set KOPIA_PASSWORD}"
: "${ATTACK_TIME:?set ATTACK_TIME, UTC, e.g. 2026-10-26T01:30:00Z}"
RESTORE_DIR="${RESTORE_DIR:-/restore}"
LOG_DIR="${LOG_DIR:-$HOME/drills}"
RTO_SECONDS="${RTO_SECONDS:-14400}"
RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$LOG_DIR" "$RESTORE_DIR"
START="$(date +%s)"
SNAP="$(kopia snapshot list --all --json | jq -r --arg t "$ATTACK_TIME" \
'[.[] | select(.startTime < $t)] | sort_by(.startTime) | last | .id')"
if [ -z "$SNAP" ] || [ "$SNAP" = "null" ]; then
echo "No snapshot older than $ATTACK_TIME" >&2
exit 2
fi
echo "Using snapshot $SNAP"
find "$RESTORE_DIR" -mindepth 1 -delete
kopia restore "$SNAP" "$RESTORE_DIR"
RESTORED="$(date +%s)"
MANIFEST_OK=true
( cd "$RESTORE_DIR" && sha256sum -c MANIFEST.sha256 --quiet ) || MANIFEST_OK=false
SCAN_RC=0
clamscan -r --infected --log="$LOG_DIR/$RUN_ID-clamscan.log" \
"$RESTORE_DIR" >/dev/null || SCAN_RC=$?
END="$(date +%s)"
ELAPSED=$((END - START))
RESTORE_SECS=$((RESTORED - START))
WITHIN_RTO=false
[ "$ELAPSED" -le "$RTO_SECONDS" ] && WITHIN_RTO=true
PASS=false
if [ "$MANIFEST_OK" = true ] && [ "$SCAN_RC" -eq 0 ] && [ "$WITHIN_RTO" = true ]; then
PASS=true
fi
jq -n --arg run "$RUN_ID" --arg snap "$SNAP" --arg attack "$ATTACK_TIME" \
--argjson restore "$RESTORE_SECS" --argjson total "$ELAPSED" \
--argjson rto "$RTO_SECONDS" --argjson manifest "$MANIFEST_OK" \
--argjson scanrc "$SCAN_RC" --argjson pass "$PASS" \
'{run:$run,snapshot:$snap,attack_time:$attack,restore_seconds:$restore,
total_seconds:$total,rto_seconds:$rto,manifest_ok:$manifest,
clamscan_exit:$scanrc,pass:$pass}' | tee "$LOG_DIR/$RUN_ID.json"
[ "$PASS" = true ]
Run it with ATTACK_TIME=2026-10-26T01:30:00Z KOPIA_PASSWORD='...' ./clean-room-drill.sh. The script exits 0 on a pass, 1 on a failed check and 2 if no snapshot predates the attack time. Because it exits non-zero on failure, you can wrap it in a monthly systemd timer on the clean-room host and send the exit status to your monitoring.
Sample output
Here is what a passing run looks like on a lab machine. The numbers are illustrative from a small test set, so yours will differ.
Using snapshot k5f1c0e8a2b7d4c9e1a3b6d8f0e2c4a6
Restoring to /restore
Restored 150 files (540.3 MB) in 71s
{
"run": "20261026T031500Z",
"snapshot": "k5f1c0e8a2b7d4c9e1a3b6d8f0e2c4a6",
"attack_time": "2026-10-26T01:30:00Z",
"restore_seconds": 71,
"total_seconds": 118,
"rto_seconds": 14400,
"manifest_ok": true,
"clamscan_exit": 0,
"pass": true
}
File the JSON alongside the Step 10 lock proof and your written findings. After three clean monthly runs you have a documented testing history. If a run fails, that failure is the most valuable artefact in the folder, because it shows a gap found and fixed before a real attacker found it.
Common Pitfalls That Break Clinic Recovery
Clinics repeat the same mistakes, and most are cheap to avoid once you know them. Check your setup against this list before you call the project done.
Creating the bucket without Object Lock. The flag cannot be added afterwards on most S3-compatible stores. A bucket without it feels protected but lets a stolen admin key delete everything. Run the lock configuration query and keep the output.Using one key for backup and restore. If the backup host holds a key that can read and delete, ransomware on that host inherits both powers. Keep the restore key off every production machine.Restoring the newest snapshot by reflex. Hourly jobs happily back up encrypted files. Anchor on the attack timestamp, then step back until the data is clean, and keep several recovery points so you can.Setting retention shorter than attacker dwell time. If intruders sit in a network for five weeks and your lock lasts 30 days, every clean copy may expire before you notice. Pick a retention period that survives your realistic detection time.Skipping the malware scan. A clean manifest only proves the files match what was backed up. It does not prove the backed-up files were clean. Scan in the clean room before reconnecting.Keeping the repository password only on the backup host. If that machine is encrypted, so is your only copy of the password. Store it in a sealed envelope and a password manager, in two separate places.Testing once and filing it forever. Systems change, keys rotate and staff leave. A single drill from last spring does not describe today’s recovery.Loading real ePHI before the contract is signed. A technical setup with no BAA in place is still a compliance gap. Use synthetic data until the paperwork is finished.
The last pitfall deserves a second look. Cloud vendors market “HIPAA ready” storage, but the sources we checked for this article did not confirm that any specific Backblaze B2 configuration, or Cove plan, satisfies a clinic’s HIPAA duties by itself. The obligations sit with you and your signed agreement, so verify them with the vendor in writing.
Troubleshooting: 10 Problems and Fixes
Most failures in this build come from permissions, regions or the firewall. Work down the table from the symptom you see.
SymptomLikely causeFixcreate-bucket fails or ignores the lock flagWrong endpoint or region, or flag omittedUse the regional endpoint that matches the region and pass the object-lock flag at creationKopia says Object Lock is not enabledBucket was made without the flagDelete the empty bucket and recreate it with Object Lock onAccessDenied when listing snapshots on the clean roomRestore policy lacks list permissionsAdd ListBucket and ListBucketVersions to the restore policy and revalidate the JSONInvalid repository password on connectTypo, trailing space, or a different password than at creationRetype from the password manager and check the exported variable with a safe echo of its lengthMaintenance logs retention errorsWriter policy lacks PutObjectRetentionAdd the retention actions to the writer policy and rerun maintenanceClean room cannot resolve the storage hostnameInternal DNS blocked by the RFC1918 rulePoint the host at a public resolver and retestfreshclam fails to update signaturesOutbound HTTPS is blocked or the freshclam service holds the lockStop the clamav-freshclam service, run freshclam by hand, and confirm outbound HTTPS is openManifest check reports mismatchesSnapshot taken after the files changed, or the wrong snapshot restoredConfirm the snapshot ID and start time, then restore an earlier oneRestore runs far past the RTOLink throughput or small default parallelismTest from a faster link, review kopia restore options for parallelism, and revisit the tier targetsHourly timer never firesTimer not enabled, or service has a syntax errorRun systemctl status on both units, check journalctl, and enable the timer
If a fix does not match any row, work backwards from the failing command. Check the identity first (which key is loaded), then the network (can the host reach the storage endpoint over HTTPS), then the repository (does kopia repository status answer). That order finds the cause in most cases within a few minutes.
Advanced Tips for Tighter Recovery
Once the basic drill passes three times in a row, tighten the design in these directions. Each tip adds real resilience without turning the clinic into an enterprise data centre.
Add a second immutable copy at another provider. One provider outage or one compromised account should not end your recovery. Our walkthrough of immutable backup with Backblaze B2 Object Lock shows how to build the second copy.Check lock dates on a schedule. Before any real recovery, confirm the object-lock dates on the snapshots you plan to use. Script a weekly check that alerts when the oldest protected copy gets close to expiry.Alert on stale snapshots. If the newest snapshot is older than your Tier 1 RPO, something is broken. A short script that compares the latest snapshot time to the clock catches silent failures within hours.Pre-provision the cloud clean room. Define the separate account, network and base images as code, then keep them dormant. Provisioning during an incident wastes the hours you do not have.Rehearse with humans, not only scripts. Run a tabletop exercise where the clinical lead, practice manager and IT contractor walk through paper downtime procedures and decide who approves the clean restore.Rotate the restore key every quarter. Test that the new key lists and restores, then revoke the old one. A key nobody has used in a year is a key nobody can find.
When to move up to a commercial platform
Scripts scale to a handful of servers. Past roughly a few dozen workloads, or once you need virtual machine failover and application-aware restores, a commercial platform earns its cost. Veeam’s Recovery Orchestrator v13.1, available in the Premium Edition since October 8, 2026, builds repeatable recovery plans for exactly this stage, while N-able’s Cove DRaaS targets managed-service shops. Evaluate against the same drill: restore-only access, isolated recovery, a timed run and a written record. The vendor that passes your drill wins, whatever the brochure says.
Australian Readers: Using This Drill Across Two Rulebooks
HIPAA applies to U.S. covered entities and their business associates. If you run a clinic in Australia with no U.S. patients, it does not govern you directly, but Australian privacy law and health-records rules do, and the sources used here do not spell out those obligations. An Australian managed service provider that backs up a U.S. clinic is a different case. That provider may qualify as a business associate and will need the BAA, the access controls and the drill record described above.
The drill itself works under both regimes because the engineering problem is the same: keep a copy the attacker cannot touch, restore it somewhere clean, and prove it. Australian organisations already measured against the Essential Eight will recognise the pattern, and our piece on why regular backups is the Essential Eight control ransomware actually tests covers that side. Check data-residency terms in the BAA or contract before you pick the Sydney region for a U.S. client’s records, and ask counsel about breach-notification duties in both countries. Our cloud computing coverage tracks vendor and regional changes as they land.
FAQ: HIPAA Ransomware Recovery and Cloud Backup
Does HIPAA require immutable backups?
No. The Security Rule does not name a technology, a retention period or a recovery time. It requires retrievable exact copies, a disaster recovery plan and an accurate risk analysis. Immutable storage is one strong way to meet those duties against ransomware, and your risk analysis should explain why you chose it.
Is a HIPAA ransomware recovery drill mandatory?
Periodic testing of contingency plans is an addressable specification, so you either test or document an equivalent alternative. In practice, a dated drill record is the easiest way to show you did the work.
How often should a clinic run the drill?
There is no mandated interval. A sensible cadence for a small clinic is this script monthly, a fuller application-level recovery quarterly, and a human tabletop at least once a year. Rerun it after any major change to servers, keys or vendors.
Which provider is best for HIPAA cloud backup?
No provider is HIPAA certified by HHS, so “best” depends on your BAA, your recovery needs and your budget. Wasabi lists US$7.99 per TB per month with Object Lock included, Veeam and N-able sell fuller recovery tooling without public prices, and Backblaze B2 offers Object Lock too. Test each against the same drill and read the BAA before you trust any of them.
What is a clean room in ransomware recovery?
It is an isolated recovery environment, either a separate network segment or a separate cloud account, where you restore, scan and rebuild systems before reconnecting them to production. It keeps a hidden implant in your backup from reinfecting a live network.
Can I use this setup for real patient data?
Only after you have a signed BAA with the storage provider, MFA on every console, a documented risk analysis and legal review of your retention and encryption choices. Run the tutorial on synthetic data first, then move production datasets in tiers.
What happens if my immutable retention period is too short?
Locks expire, and clean copies become deletable. If an attacker lingers longer than your retention window, every good recovery point may age out before you discover the breach. Set retention against realistic detection time and keep monthly points for longer.More on this topicCloud ComputingCybersecuritySoftwareAI & Machine LearningTrending nowTelstra’s Brady Loses $607K Pay at AGM Fury [2026]Telstra Outage Costs Economy $552M, Says Report [2026]Health’s $32.8M Google Cloud Bet Defies DTA Snub [2026]Firmus After the Float: US$2B Backers, 7.2% Nvidia [2026]Canva Built Craft in 6 Months With 160 Staff [2026]
Nadia DuboisAI & Innovation EditorNadia Dubois is the AI & Innovation Editor at Tech Insider, where she tracks the rapid evolution of artificial intelligence, from foundation models to real-world enterprise deployment. She previously covered AI and startups for La Tribune and contributed to MIT Technology Review’s European coverage. Nadia specializes in generative AI, AI regulation, and the intersection of technology and European industrial policy. She holds a dual degree in Computational Linguistics and Journalism from Sciences Po Paris.View all articles
——————————————————–
Click Here For The Original Source.
