WordPress Database Corruption: Signs, Prevention, and Recovery

Database corruption strikes without warning. One moment your WordPress site runs perfectly; the next, you see “Error establishing a database connection” or find posts displaying garbled characters. Database corruption can stem from server crashes, power failures, plugin conflicts, or storage issues—and when it happens, every second counts.

This comprehensive guide teaches you how to identify database corruption early, understand what causes it, use WordPress’s built-in repair tools, and—most critically—restore from backups when repair isn’t enough. You’ll learn which error messages indicate corruption, how to run diagnostic checks, and when to repair versus restore.

By the end of this tutorial, you’ll have a complete database corruption recovery playbook, from first symptoms through full restoration, ensuring minimal downtime and data loss.

Understanding Database Corruption

What Causes Database Corruption

Server-Level Causes:

Server Crash:

• MySQL server terminates unexpectedly during write operation
• In-progress transactions left incomplete
• Table indexes become inconsistent
• Most common cause of InnoDB corruption

Storage Failure:

• Hard drive bad sectors affect database files
• SSD controller errors corrupt data
• File system errors (ext4, NTFS issues)
• Hosting provider storage infrastructure problems

Power Failure:

• Unexpected server shutdown during database writes
• Write cache not flushed to disk
• Particularly affects MyISAM tables

Software-Level Causes:

Plugin Conflicts:

• Poorly coded plugins directly modify database
• Multiple plugins updating same tables simultaneously
• Database optimization plugins too aggressive
• Security plugins interfering with legitimate operations

Failed WordPress/Plugin Updates:

• Database migration scripts fail midway
• New plugin version incompatible with old schema
• Update interrupted by timeout or crash
• Partial schema changes applied

Manual Database Modifications:

• SQL queries with syntax errors
• Direct phpMyAdmin edits without transaction safety
• Incorrect table repairs
• Forced database shutdowns during operations

Resource Exhaustion:

• Disk space full during database write
• Memory limits exceeded during large operations
• Connection timeouts during long transactions
• Too many concurrent database connections

MySQL Table Types and Corruption

InnoDB (Default since WordPress 5.5):

• Transaction-safe with automatic crash recovery
• Less prone to corruption than MyISAM
• Self-repairs minor issues on restart
• Corruption usually indicates serious hardware problem

MyISAM (Older WordPress versions):

• No transaction support
• More susceptible to corruption
• Corrupts easily from crashes
• Requires manual repair more often

Check Your Table Type:

SHOW TABLE STATUS FROM your_database_name;

Look at “Engine” column. Modern WordPress uses InnoDB for all tables.

Warning Signs of Database Corruption

Common Error Messages

“Error establishing a database connection”

• Most common corruption symptom
• Also occurs from wrong credentials or MySQL down
• Corruption likely if credentials unchanged recently

“Table is marked as crashed and should be repaired”

• Definitive corruption indicator
• Usually affects MyISAM tables
• Appears in WordPress error logs

“Can’t open file: ‘wp_posts.MYI’ (errno: 145)”

• MyISAM index file corrupted
• File exists but unreadable
• Repair usually successful

“Got error 28 from storage engine”

• Disk space full
• Not corruption per se, but causes corruption if ignored
• Free disk space immediately

“Incorrect key file for table”

• Table index corrupted
• SELECT queries may return wrong results
• Repair required

Visual Symptoms

Garbled Characters:

• Posts show �������� or strange symbols
• Indicates character encoding corruption
• Often from improper export/import or collation changes

Missing Content:

• Posts exist but content blank
• Specific sections of posts disappeared
• Random data loss throughout site

Duplicate Content:

• Same post appears multiple times
• Order numbers or IDs duplicated
• Indicates table relationship corruption

Random Fatal Errors:

• PHP errors mentioning database
• “Call to member function on null” from missing DB data
• WordPress functions failing unpredictably

Admin Panel Symptoms

Cannot Save Changes:

• Clicking “Update” does nothing
• Changes revert after save
• “Could not update database” errors

Dashboard Shows Incorrect Counts:

• Post count shows 100, but only 90 visible
• Comment count mismatch
• Plugin list incomplete

Login Issues:

• Can’t log in with correct credentials
• User accounts disappeared
• Password resets don’t work

Diagnosing Database Corruption

Built-In WordPress Database Check

Enable WordPress Repair Mode:

1. Edit wp-config.php (via FTP/SFTP)
2. Add before /* That's all, stop editing! */:

define('WP_ALLOW_REPAIR', true);

3. Visit: https://yoursite.com/wp-admin/maint/repair.php
4. No login required – security risk, enable only temporarily

Repair Options:

• Repair Database: Attempts to fix corrupted tables
• Repair and Optimize Database: Fixes and optimizes tables

After Repair: Remove WP_ALLOW_REPAIR from wp-config.php immediately to close security hole.

MySQL CHECK TABLE Command

Access phpMyAdmin or MySQL command line:

-- Check specific table
CHECK TABLE wp_posts;

-- Check all WordPress tables
CHECK TABLE wp_posts, wp_postmeta, wp_options, wp_comments,
wp_commentmeta, wp_users, wp_usermeta, wp_terms, wp_term_taxonomy,
wp_term_relationships;

Results:

• status: OK – Table healthy
• status: warning – Minor issues (usually safe)
• status: error – Corruption detected
• status: corrupt – Severe corruption

Example Output:

Table         | Op    | Msg_type | Msg_text
wp_posts      | check | status   | OK
wp_postmeta   | check | status   | OK
wp_options    | check | error    | Table is marked as crashed

Advanced Diagnostics

Check Table Overhead:

SELECT table_name, data_free
FROM information_schema.tables
WHERE table_schema = 'your_database_name'
  AND data_free > 0;

Large data_free values indicate fragmentation (optimization needed, not corruption).

Check InnoDB Status:

SHOW ENGINE INNODB STATUS;

Look for errors in output. Healthy InnoDB shows no corruption messages.

Repair Methods

Method 1: WordPress Built-In Repair

When to Use:

• First attempt for any corruption
• Quick and safe
• Works for MyISAM and InnoDB

Limitations:

• Doesn’t work for severe corruption
• Can’t recover deleted data
• May fail on hardware-level issues

Success Rate: ~60% for MyISAM, ~40% for InnoDB

Method 2: MySQL REPAIR TABLE

For MyISAM Tables Only:

REPAIR TABLE wp_posts;

Options:

-- Quick repair (faster, less thorough)
REPAIR TABLE wp_posts QUICK;

-- Extended repair (slower, more thorough)
REPAIR TABLE wp_posts EXTENDED;

-- Use frm file to recreate index
REPAIR TABLE wp_posts USE_FRM;

For InnoDB Tables: InnoDB doesn’t support REPAIR TABLE. Instead:

1. Dump table with mysqldump
2. Drop table
3. Recreate table from dump

Method 3: mysqlcheck Command Line

Repair all tables in database:

mysqlcheck -u username -p --auto-repair --optimize database_name

Check and repair specific table:

mysqlcheck -u username -p --repair database_name wp_posts

Repair all databases:

mysqlcheck -u username -p --auto-repair --all-databases

When Repair Fails

Symptoms of Failed Repair:

• REPAIR TABLE returns errors
• Corruption persists after repair
• New errors appear after repair
• Data still missing or garbled

Next Steps:

1. Do NOT run repair repeatedly (can worsen corruption)
2. Create backup of current corrupted state (for investigation)
3. Restore from clean backup (see below)

Restoring from Database Backups

Choosing the Right Backup

Identify When Corruption Occurred:

Check WordPress error logs:

/wp-content/debug.log

Or server error logs (varies by host):

/var/log/mysql/error.log

Find first corruption error timestamp.

Select Backup:

• Choose backup from BEFORE corruption timestamp
• Ideally: Most recent backup before corruption
• Verify backup is from when site was healthy

Step-by-Step Database Restoration

1. Backup Current Corrupted Database:

mysqldump -u username -p database_name > corrupted_backup.sql

Safety net in case restoration fails.

2. Download Healthy Backup:

• From Backup Copilot Pro: Manage Backups > Download database
• From cloud storage: Download .sql file
• From server: Copy from .bkps/ directory

3. Drop Corrupted Database (Optional but Recommended):

DROP DATABASE your_database_name;
CREATE DATABASE your_database_name;

4. Import Healthy Backup:

Via phpMyAdmin:

1. Select database
2. Click “Import” tab
3. Choose .sql file
4. Click “Go”
5. Wait for import (may take several minutes)

Via Command Line:

mysql -u username -p database_name < healthy_backup.sql

5. Verify Restoration:

• Visit site homepage
• Log into WordPress admin
• Check posts, pages, comments display correctly
• Verify plugins active
• Test functionality

6. Data Loss Assessment: Restoration from backup = data loss from backup time to corruption time.

Example:

• Backup: Feb 20, 3:00 AM
• Corruption: Feb 22, 10:00 AM
• Lost: All changes Feb 20-22 (2 days)

Minimize loss with frequent backups (hourly for critical sites).

Prevention Strategies

Reliable Hosting Environment

Choose Quality Hosting:

• Avoid ultra-cheap shared hosting ($2/month plans)
• Look for SSD storage (more reliable than HDD)
• Ensure MySQL server runs on separate from web server
• Verify daily hosting-level backups

Recommended Hosts:

• SiteGround, Kinsta, WP Engine (managed WordPress)
• DigitalOcean, Linode, Vultr (VPS)
• Avoid: EIG-owned budget hosts

Regular Database Optimization

Monthly Optimization:

OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_comments;

Or use WP-Optimize plugin:

1. Install WP-Optimize
2. Run weekly optimization
3. Clean post revisions, spam, transients

Benefits:

• Reduces fragmentation
• Improves query performance
• Reduces corruption risk

Plugin Hygiene

Avoid Risky Plugins:

• Database “accelerator” plugins (often unsafe)
• Untested optimization plugins
• Plugins with direct SQL queries in reviews/support

Update Safely:

• Backup before every plugin update
• Test updates on staging site first
• Read update changelogs for database changes
• Update one plugin at a time

Monitoring and Alerts

Database Health Monitoring:

• Use UptimeRobot to monitor site availability
• Enable WordPress debug logging
• Check error logs weekly
• Monitor hosting provider status emails

Automated Database Checks:

Create cron job to check tables daily:

#!/bin/bash
mysqlcheck -u username -p password --check database_name > /tmp/db_check.log 2>&1
if grep -q "error" /tmp/db_check.log; then
    mail -s "Database Error Detected" admin@yoursite.com < /tmp/db_check.log
fi

Backup Strategy for Corruption Protection

Frequency:

• Personal sites: Daily database backups
• Business sites: Every 6-12 hours
• E-commerce: Every 2-4 hours
• High-traffic: Hourly

Retention:

• Keep 30 days of daily backups
• Keep 12 weeks of weekly backups
• Enables restoration from before corruption started

Verification:

• Test restore monthly
• Verify backup files aren’t corrupted
• Ensure backups complete successfully

Recovery Workflow Decision Tree

Corruption Detected
    │
    ├── Run WordPress Repair
    │   ├── SUCCESS → Verify site works → Done
    │   └── FAIL → Continue below
    │
    ├── Run CHECK TABLE on all tables
    │   ├── All OK → Issue not corruption → Debug further
    │   └── Errors found → Continue below
    │
    ├── Run REPAIR TABLE on corrupted tables
    │   ├── SUCCESS → Verify data integrity → Done
    │   └── FAIL → Continue below
    │
    └── Restore from Backup
        ├── Have recent backup → Import backup → Done
        └── No backup → Contact professional recovery service

Post-Recovery Actions

1. Identify Root Cause:

• Check server logs for crashes
• Review recent plugin updates
• Contact hosting provider about hardware issues
• Investigate what led to corruption

2. Implement Prevention:

• Increase backup frequency
• Move to better hosting if needed
• Remove problematic plugins
• Set up database monitoring

3. Document Incident:

Corruption Incident - Feb 22, 2025
Symptom: "Table wp_posts is marked as crashed"
Cause: Server crashed during backup
Resolution: Restored from Feb 21 backup
Data Loss: 1 day (18 hours)
Prevention: Increased to 6-hour backups, added server monitoring

4. Test Thoroughly:

• Verify all functionality
• Check for data inconsistencies
• Test forms, checkout, user registration
• Monitor for recurring issues

Related Resources

1. WordPress Database Repair – Official Guide
2. MySQL CHECK TABLE Documentation
3. MySQL REPAIR TABLE Documentation
4. Understanding InnoDB vs MyISAM
5. Database Optimization Guide

---

Protect against database disasters! Backup Copilot Pro creates frequent database backups with one-click restoration. Recover from corruption in minutes, not hours. Try it risk-free today!