• Home
  • Guides
  • Your MySQL backup takes 12 hours. Here is how to fix it.

Your MySQL Backup Takes 12 Hours. Here Is How to Fix It.

A 2-minute self-check and a four-step fix for slow, untested MySQL backups at terabyte scale: incremental backups, chain-aware retention, point-in-time recovery and automated restore tests.

  • MySQL
  • Backups
  • Database Reliability

Full backups of a 2 TB MySQL database that take more than 12 hours, fail regularly and have never been restored are a common finding. The backup exists, but nobody knows if it works. This guide gives you a two-minute check and the four steps we use to fix it. It is based on a real engagement.

Two-minute self-check

Answer these honestly:

  1. When did you last restore a backup into a test system, end to end?
  2. How long does a full restore take? Do you know, or is it a guess?
  3. If a backup fails at night, who finds out, and when?
  4. Can you restore to a specific point in time, for example five minutes before a bad deploy?
  5. What does backup storage cost you per month?

If you cannot answer two or more of these, you have a recovery risk, not a backup.

Why it breaks at scale

  • Full backups grow with the data. At terabyte scale they take half a day and fail more often.
  • Incremental backups depend on a chain. Delete one link and everything after it is useless.
  • Restoring a terabyte takes so long that teams avoid testing it. Untested backups fail when you need them.
  • Generic backup tools do not understand InnoDB. Managed options charge per GB.

The fix, in four steps

  1. Use a database-native backup tool. XtraBackup understands InnoDB page changes. Take a full backup weekly and incrementals every six hours, encrypted and compressed, written to fast local disk first and synced to object storage.
  2. Make retention chain-aware. Only delete a backup when every backup in its chain is past the retention period. This prevents orphaned incrementals that cannot be restored.
  3. Script point-in-time recovery. One command restores to a chosen timestamp: full backup, then incrementals in order. Add a dry-run mode so the plan can be checked before it runs.
  4. Automate the restore test. Restore into a scratch system on a schedule and alert on failure. If testing is manual, it will not happen.

What it looked like in practice

On a 2 TB production database, backup time went from 12 hours to 30 minutes for a full backup and 5 minutes for an incremental. The backup success rate went from 60% to 99.8%, restores are tested monthly, and storage costs about $3 a month instead of $150+ for a managed tool. Details: the case study.

Next step

Run the self-check today. If it shows gaps, book a call and we will look at your setup together.

Ready to simplify your platform?

We work with a small number of clients at a time. If you’re dealing with reliability problems, complexity, or a platform that’s hard to operate, let’s talk.

Get in touch →