Practice continuity
Patient-record backup and restore for medical software
Create a consistent local copy, verify its SHA-256 checksum and test restoration before a failure occurs.
Verified 8 September 2026
Real software capture
A backup is useful only when it is recent, readable and restorable. Clinosys creates timestamped SQLite copies with SHA-256 checksums, verifies them and makes a safety copy before restoration.
The Clinosys backup cycle
Consistent copy
A SQLite operation creates a compact, consistent copy of the local database.
SHA-256 checksum
A separate fingerprint detects modification or corruption.
Verification
The interface checks integrity before a restore is selected.
Safety net
A fresh backup is made before the current database is replaced.
The 3–2–1 rule remains the practice’s responsibility
Keep at least three copies on two media types, with one away from the host computer. The built-in backup folder cannot protect against loss, theft or whole-disk ransomware by itself.
Move a verified copy to an approved protected medium and record each test. Use fictional data for exercises on any non-clinical computer.
- Daily or risk-based copy
- Storage separate from the host
- Restricted backup access
- Documented restore test
A restore test is better than a green icon
Select a backup, verify its fingerprint, restore it in an authorised test environment and inspect fictional records, appointments and consultations. Clinosys requires a restart after restore so the replacement database opens cleanly.
Measure the time and record who holds the passphrase. The clinic should know how much data it can lose and how long recovery will take.
Clinosys backup questions
Does Clinosys verify backup integrity?
Yes. A SHA-256 checksum is created alongside the file and can be checked from the backup workflow.
Is a backup on the same computer sufficient?
No. It helps with some errors but not loss, theft or total device failure. Keep a protected copy on separate media.
What happens before restore?
Clinosys verifies the selected copy and creates a safety backup of the current state before staging replacement. The app then needs a restart.
Time a real restore test
Run the workflow on the synthetic demo profile and leave with a procedure adapted to your practice.