A complete Mirth Connect backup covers more than the message database: channel configurations, the database itself, server configuration files and certificates, and any shared code templates. Set a backup frequency matched to your acceptable data loss window, store backups somewhere genuinely redundant, automate the process, and keep channel exports under version control. None of it matters without testing — run actual restore drills, document a step-by-step recovery runbook, define a realistic recovery time objective, and improve the plan after every drill or real incident.
Quick answer
Mirth Connect backup and disaster recovery only matters the moment something goes badly wrong, which is exactly why an untested backup strategy is riskier than it looks — a backup never restored is just an assumption, not a real safety net. Building a real recovery plan means knowing precisely what needs backing up, how often, and confirming the restore process actually works before you're forced to rely on it during a real crisis.
Below is what needs backing up beyond the obvious database, how to build a strategy, and how to test recovery so it holds up. Our free Mirth Health Check can review your setup — part of the Mirth Connect support work we do for US healthcare teams.
What Actually Needs to Be Backed Up
A complete Mirth backup covers more than just the message database, and missing any one of these pieces can turn a routine restore into a much longer, more painful recovery process than it needed to be.
Channel Configurations Across Your Entire Deployment
Every channel's configuration, including connectors, transformers, and filters, needs to be backed up in a restorable format, since losing this means rebuilding every interface manually from scratch during an already stressful recovery situation.
The Message Database Itself
Your database, whether the embedded default or an external platform, holds message history and metadata that channel configuration backups alone don't capture, so it needs its own dedicated backup process running on a defined schedule. See our database sizing and retention guide for what to actually keep.
Server Configuration Files and Settings
Configuration files covering server settings, security certificates, and JVM parameters are easy to overlook but genuinely necessary for rebuilding a functionally identical server rather than one that's subtly different in ways you'll discover later.
Code Templates and Shared Libraries
Any code templates or shared libraries used across multiple channels need their own backup, since losing them breaks every channel that depends on that shared logic, not just one isolated interface.
Building a Backup Strategy That Actually Holds Up
A backup strategy is only as good as its weakest link, so each component below deserves deliberate attention rather than assuming a single backup job covers everything by default.
Set a Backup Frequency That Matches Your Risk Tolerance
Back up frequently enough that your acceptable data loss window, however you define it, is genuinely covered by your backup schedule, rather than choosing a frequency based on convenience alone without considering real recovery needs.
Store Backups in a Genuinely Redundant Location
Keep backups somewhere physically or logically separate from your production environment, since a backup stored on the same server or network segment as production offers little real protection against a broader infrastructure failure.
Automate the Backup Process Wherever Possible
Automated backups remove the risk of a manual process being forgotten during a busy week, which is exactly when a backup often turns out to matter most, right when nobody had time to run it manually.
Keep Channel Exports Under Version Control
Exporting channels as XML and committing them to version control gives you both a backup and a change history simultaneously, which is more useful during recovery than a backup with no record of what changed when.
Testing Your Disaster Recovery Plan Before You Need It
A backup strategy without tested recovery is really just a hope, and the only way to know your disaster recovery plan actually works is to genuinely exercise it before a real crisis forces you to find out the hard way.
Run Actual Restore Drills on a Schedule
Periodically restore your backups to a test environment and confirm the result is fully functional, since a backup file that exists doesn't guarantee it will actually restore cleanly when you genuinely need it to work.
Document a Clear, Step-by-Step Recovery Runbook
Write a runbook detailing the exact steps to recover from a range of failure scenarios, so recovery doesn't depend entirely on one specific person's memory being available and functioning well during an active crisis.
Define a Realistic Recovery Time Objective
Set a clear target for how quickly you need to be back up and running after a failure, and test whether your actual recovery process can genuinely meet that target under realistic, honest conditions.
Review and Improve After Every Drill or Real Incident
Treat every restore drill, and any real recovery event, as a chance to identify gaps in your process and fix them before the next time you need to rely on that same plan again.
When to call for help
Not confident your backups would actually work under pressure? That's the single most common gap our engineers find. Our free Mirth Connect health check reviews your backup setup as part of the standard diagnostic.
Something specific prompt this? Send us the log, or check pricing for ongoing support plans.
Not confident your backups would actually work? Free Mirth health check — a written 12-point audit report in 48 hours, no cost.