Backing Up Your CRM Database Properly

Oct 5, 2026

Run mysqldump once, put the file somewhere, feel safe. That is where most backup strategies stop, and it is roughly half of one.

A backup has three properties: it exists, it is somewhere else, and you have restored from it. Skip any one and you do not have a backup, you have a file.

What Needs Backing Up

For a self hosted Clientverse installation there are two things:

The database. This is the CRM - contacts, companies, deals, notes, users, settings. Everything people typed. If you only back up one thing, back up this.

The uploads and configuration. Any files attached to records, plus the configuration file holding your database credentials and application settings. These change rarely, but restoring without them means reconfiguring from memory.

The application code itself does not need backing up in the same sense. You can reinstall it from the release you were running. What you cannot reinstall is your data.

How Often

Match the frequency to how much work you are willing to redo. Nightly is the sensible default for a CRM: if the server dies at 4pm, you have lost one day of note taking, which is annoying but survivable.

If your team logs a lot of deal activity and losing a day would genuinely hurt, move to twice daily. Going further than that usually means you want replication rather than more dumps.

The Off Machine Rule

A backup on the same disk as the database protects you from exactly one failure mode: someone deleting a row. It does nothing for disk failure, a compromised server, or a provider account problem.

Send the dump somewhere else. Object storage, a different provider, an encrypted copy on a machine in your office - the destination matters less than the fact that it is not the server that made it.

Encrypt it before it leaves. A CRM dump is a plain text file containing every customer email address and phone number you hold. Treat it with the seriousness that implies, especially under GDPR where a leaked backup is a reportable breach like any other.

Retention That Is Not Just Yesterday

Keeping only the most recent backup means a problem you notice a week late is unrecoverable. Data corruption and accidental bulk deletions are often discovered long after they happen.

A reasonable pattern for a small CRM: seven daily backups, four weekly, twelve monthly. That is a couple of gigabytes for most installations, costs very little in object storage, and covers both “the server died” and “somebody imported a bad CSV last Tuesday”.

Prove It Works

This is the step everyone skips.

Once a quarter, take the most recent backup, restore it into a scratch database on a test machine or a local Docker container, and open the application against it. Count the contacts. Open a deal. Log in.

Ten minutes of work, and it is the only thing that distinguishes a backup strategy from a filing habit. Restores fail for boring reasons - a truncated dump, a missing table, a character set mismatch that mangles every accented name - and you want to find those on a Wednesday afternoon, not during an outage.

The Export You Should Also Keep

Separately from the database dump, a periodic CSV export of contacts, companies, and deals is worth having. It is readable without a database server, it is the format every other tool imports, and it means even a catastrophic infrastructure failure leaves you with your customer list intact.

Two different formats, two different places, one tested restore. That is the whole of it.