Database Deleted or Corrupted — How Do You Recover It?

A deleted or corrupted database is the most abrupt data loss a site owner can face: your files are still there, the site almost loads, but there is no content. Orders, members, posts — they were all in the database. This article walks through exactly what to do, in order.

1. Stop writing immediately

This is the most critical step in the whole process, and the one most often skipped. If the database has been deleted or corrupted, then for as long as the system keeps running new data is written over it and your chances of recovery shrink by the minute.

• Put the site into maintenance mode; stop new orders, sign-ups and comments from being recorded.
• Stop any automatic import or synchronisation jobs.
• Before trying to "repair" anything in a panic, take a copy of the current state.

2. Diagnose what actually happened

What you should do depends entirely on the type of problem. There are three distinct situations and they must not be confused:

• The database or table has been deleted: the data really is gone. The only solution is to restore from a backup.
• The table is corrupted: the data is there but unreadable. Repair tools can recover it.
• The connection is broken: both the data and the tables are intact; the problem is the username, password or host address in the configuration file. This is the best case and there is no data loss.

If the site shows an "error establishing a database connection", always rule out the third possibility first — it is common after a server move or a password change, and no data has been lost at all.

3. If it's corruption, try repair first

Table corruption usually stems from an abrupt server shutdown, a full disk or a hardware fault. Most database management tools include a check-and-repair function, which you can run from the database manager in your hosting panel. Before repairing, don't forget to copy the existing files — the repair process can corrupt the data further.

4. Restore from a backup

If the data really has been deleted, this is the only real solution. Things to watch when restoring:

• Pick the right date. The newest backup isn't always the best; if the problem has been going on for a while you may need an older copy.
• Test first. If you can, load the backup into a separate database, check its contents and only then put it live.
• Update the connection details. If you are restoring to a different server or database name, your site's configuration file must be updated too.
• Try to recover the data in between. You can partly reconstruct orders placed after the backup date from your payment provider's records, and sign-ups from email notifications.

5. Find the cause

A database doesn't delete itself. Common causes: a command run against the wrong database, the wrong account deleted from the hosting panel, a compromised site, a misbehaving plugin, or a full disk quota. If you don't find the cause, it is likely to happen again.

Minimising data loss: backup frequency

The real question to ask after a recovery is this: "What is the most data I can afford to lose?" The answer determines your backup frequency directly.

• A brochure site: content rarely changes; a weekly or daily backup is enough.
• A blog or news site: a daily backup is reasonable; at most you lose a day of content.
• E-commerce: a daily backup gets expensive. An hourly backup shrinks the loss window to one hour.
• A busy store: may need backups more often than hourly.

Files usually change rarely, while the database changes constantly. Being able to give the two separate frequencies therefore both improves protection and lowers cost: files daily, database hourly, for example.

In summary

When a database is lost, the order is clear: stop → diagnose → repair (if corrupted) → restore from backup → find the cause. The fourth link in that chain snaps if you have no backup. So the real work is setting up your backup routine before the loss happens.

Frequently Asked Questions