Diagnose MariaDB Table Corruption Without More Damage

MariaDB table corruption is an incident category, not a single diagnosis. An application may report a corrupt table when the real cause is a failed disk, unreadable page, missing tablespace, incompatible system-table definition after an upgrade, filesystem damage, memory error, bad encryption key, or a crashed non-transactional table. The recovery procedure depends on both the failure layer and the storage engine.

The most damaging response is to run every repair command found online. REPAIR TABLE, aria_chk, myisamchk, innodb_force_recovery, file deletion, and tablespace import solve different problems and have different preconditions. Some do not support InnoDB at all. Some can discard rows to rebuild a usable structure. Some require the MariaDB server to be stopped. A command that makes the error disappear can quietly reduce recoverable data.

This guide builds an evidence-first production runbook. It preserves the original state, separates infrastructure failure from logical damage, identifies the engine and exact objects affected, chooses restore or supported repair, and verifies row-level and application-level correctness afterward. Commands are examples for Linux and MariaDB Server; adapt them to the installed version, topology, backup system, encryption, and change-control policy.

What “corrupt table” can mean

Corruption symptoms appear at several layers:

Do not accept the application summary as the root cause. Capture the MariaDB error code, SQLSTATE, engine message, error-log lines, affected schema/table, query type, and incident time.

Search intent and recovery goals

People searching for “MariaDB corrupt table” usually want to know:

1. Whether their data is actually corrupt.
2. Whether REPAIR TABLE is safe.
3. How to recover InnoDB when MariaDB will not start.
4. Whether they should repair, dump, fail over, or restore.
5. How to prove that recovery did not lose data.

The production goal is not merely to reopen the table. It is to recover the most authoritative consistent data while preserving replication, point-in-time recovery, audit evidence, and the ability to retreat from a failed repair.

Immediate containment

Stop mutation, not observation

Pause schema changes, bulk jobs, table optimization, automated repair tasks, and application writes to the affected object. If only one table is involved, avoid turning a scoped problem into a full-site outage; route or disable the feature that writes that table when the application supports it.

On replicated systems, record topology before failover. A replica may contain the same corrupted page if the cause was logical or existed in the backup used to seed it. Conversely, a healthy replica may be the fastest recovery source. Do not promote it until position, consistency, capacity, and fencing are verified.

Capture current service and log state:

date -Is
hostnamectl
systemctl status mariadb --no-pager -l
journalctl -u mariadb --since '-60 min' --no-pager

When SQL is available, record identity and topology:

SELECT VERSION(), @@hostname, @@server_id, @@read_only;
SHOW MASTER STATUS;
SHOW REPLICA STATUSG

Commands unsupported by a node’s role or release may return an error; record that rather than changing configuration during evidence collection.

Preserve a recoverable copy

Before repair, preserve the original bytes whenever the storage layer is stable enough to read them. Options include:

• A storage snapshot with documented database consistency semantics.
• A physical backup made by a compatible mariadb-backup version.
• A filesystem/block image taken while the server is stopped.
• A copy of the affected non-transactional table files while MariaDB is fully stopped.
• A logical dump of readable data from a healthy server or forced-recovery instance.

An ordinary recursive copy of a live datadir is not a consistent MariaDB backup. Files change independently, and copied redo/tablespaces may not represent one recoverable point.

Store evidence and recovery copies outside the suspect device. Record hashes for files used in forensic or high-assurance recovery:

sha256sum /recovery-copy/path/file > /recovery-copy/path/file.sha256

Do not hash an entire busy datadir in place during an outage without considering additional I/O and changing files.

Step 1: rule out infrastructure failure

Database repair cannot fix unreliable storage. Check the kernel and filesystem first:

journalctl -k --since '-2 hours' --no-pager
dmesg -T | tail -n 200
findmnt -T /var/lib/mysql
df -hT /var/lib/mysql
df -i /var/lib/mysql

Look for I/O errors, controller resets, filesystem warnings, a read-only remount, device-mapper errors, RAID degradation, NVMe/SCSI media errors, or OOM termination. Inspect the actual block stack with the platform’s approved tooling. For example, SMART data can be useful for local devices:

sudo smartctl -x /dev/nvme0n1

Replace the device after mapping the mount correctly. SMART may be unavailable or misleading behind RAID, SAN, virtualization, or cloud volumes; use the storage control plane too.

If the filesystem is damaged, stop MariaDB and follow the filesystem/vendor recovery process on a clone or with a verified backup. Do not run fsck against a mounted production filesystem, and do not treat filesystem repair as proof of database consistency.

Step 2: collect the first engine error

MariaDB’s error log is more useful than the final client message. Discover its destination through the running server or configuration:

SHOW VARIABLES LIKE 'log_error';

mariadbd --print-defaults
journalctl -u mariadb --since '-2 hours' --no-pager

Capture the first checksum, page, file, or table error and the lines around it. Later messages may be consequences. Record whether the server crashed, marked a table as crashed, disabled an index, failed to open a tablespace, or detected corruption only during a scan.

Check whether the incident followed:

• Power loss or forced shutdown.
• Disk-full or inode exhaustion.
• Package or major-version upgrade.
• Restore, snapshot rollback, or datadir copy.
• Storage migration or volume expansion.
• Encryption key rotation or KMS outage.
• Online DDL, bulk load, or table rebuild.
• Hardware replacement or kernel/filesystem event.

This timeline changes the likely recovery path.

Step 3: identify the storage engine

When MariaDB accepts SQL, query authoritative metadata:

SELECT table_schema, table_name, engine, table_type
FROM information_schema.tables
WHERE table_schema = 'appdb'
  AND table_name = 'orders';

For all base tables in a schema:

SELECT engine, COUNT(*) AS table_count
FROM information_schema.tables
WHERE table_schema = 'appdb'
  AND table_type = 'BASE TABLE'
GROUP BY engine;

Do not infer the engine solely from filename extensions. Partitioning, encryption, general tablespaces, older versions, and missing files can make that inference incomplete.

The engine determines available actions:

Views are not base-table storage corruption. Invalid views often reflect renamed objects, missing definers, privileges, or upgrade incompatibility.

Step 4: use CHECK TABLE carefully

Start with a specific table, not every schema on a production primary:

CHECK TABLE appdb.orders;

More intensive options can take longer and increase I/O:

CHECK TABLE appdb.orders EXTENDED;

The exact work and support vary by engine. Run intensive checks during a controlled window, monitor latency and storage, and keep enough free space. A successful check proves only what that engine/version checked at that time; it does not validate business invariants or the underlying hardware.

Avoid this incident-time anti-pattern:

# Do not launch an unbounded all-database repair on production.
mariadb-check --all-databases --auto-repair

--auto-repair can mutate supported tables, and an all-database scan adds load and obscures which action changed which object. Inventory first, then approve table-specific work.

InnoDB corruption recovery

InnoDB is transactional and crash-recoverable. A crash-recovery message is not automatically corruption, and a corrupt secondary index is different from damage to clustered data pages or the system tablespace.

Do not use REPAIR TABLE for InnoDB

REPAIR TABLE is not a general InnoDB repair facility. For an InnoDB table, recovery normally means one of these:

• Fail over to a verified healthy copy.
• Restore a known-good physical backup and replay binary logs.
• Dump readable rows and rebuild the table.
• Rebuild a damaged secondary index through supported DDL.
• Recover/import an individual tablespace only when all prerequisites match.
• Use innodb_force_recovery temporarily to extract data from a server that otherwise cannot start.

Choose based on which pages and metadata are damaged, not on command convenience.

Prefer restore when integrity is uncertain

A validated backup plus binary logs often provides the cleanest chain of custody. Establish:

1. The last known-good backup before corruption.
2. Whether that backup has been restore-tested.
3. The matching encryption keys and MariaDB version requirements.
4. The binlog range required for point-in-time recovery.
5. A stop point before the event that introduced logical damage, if applicable.

Restore into an isolated environment first when time permits. Validate the recovered table, related foreign-key/business data, and target transaction point before production cutover.

Rebuild a secondary index only with evidence

If diagnostics prove corruption is confined to a rebuildable secondary index and clustered rows are readable, supported DDL may recreate it. Capture the exact definition first:

SHOW CREATE TABLE appdb.ordersG
SHOW INDEX FROM appdb.orders;

Do not drop the only usable access path or a constraint-backed index casually. Rebuild operations require time, temporary space, redo/binlog capacity, and can block or heavily load production. Test the exact ALTER TABLE algorithm and lock behavior on the installed MariaDB version.

Treat innodb_force_recovery as emergency read access

innodb_force_recovery does not repair corruption. It changes InnoDB behavior so the server may start long enough to dump data. Higher levels disable more background/recovery work and can expose inconsistent results. Begin at 1 and increase one level at a time only when the previous level cannot start, under a recovery plan.

Create a dedicated temporary configuration include:

[mariadb]
innodb_force_recovery = 1

Start the isolated recovery instance and observe the error log. Do not return application traffic. Avoid writes; at more severe modes, writes are restricted or unsafe. Export the most valuable/readable data first:

mariadb-dump --single-transaction --quick 
  --databases appdb > /safe-recovery-volume/appdb.sql

--single-transaction may not provide its normal guarantees under severe recovery or corruption, and a dump can stop at a bad page. Dump tables or primary-key ranges separately if necessary, documenting gaps and errors. Store output on a healthy filesystem.

After extraction, remove the forced-recovery setting and rebuild a clean instance from trusted data. Never leave innodb_force_recovery enabled as normal operation.

Do not delete InnoDB files

Never delete ibdata1, redo, undo, .ibd, dictionary, or temporary-looking InnoDB files to make startup succeed. Their relationships depend on version and configuration. File deletion can destroy the transaction history or metadata required to recover otherwise readable rows.

Aria corruption recovery

Aria tables can be marked crashed after an interrupted write or suffer index/data damage. Start with server-managed checks:

CHECK TABLE appdb.queue;

If the engine and diagnosis support it, perform an approved SQL repair on a preserved copy or after a backup:

REPAIR TABLE appdb.queue;

REPAIR TABLE may rebuild indexes and can lose rows that cannot be recovered from damaged structures. Review returned messages and compare data afterward; “status OK” is not a business-level completeness guarantee.

For offline work, stop MariaDB fully before aria_chk. Confirm no server process uses the datadir:

sudo systemctl stop mariadb
pgrep -a mariadbd || true

First check without repair:

sudo aria_chk /var/lib/mysql/appdb/queue.MAI

Only after preserving a copy and reading the exact version’s utility documentation should you choose a repair mode. Run the aria_chk shipped with the same MariaDB installation. Never operate on Aria files while mariadbd has them open.

System tables may also use Aria. Repairing them incorrectly can prevent startup or authentication, so treat them as server-critical objects and prefer a tested recovery procedure.

MyISAM corruption recovery

MyISAM has no transactional crash recovery. A crash during a write can leave a table marked as crashed. Diagnose through SQL first:

CHECK TABLE appdb.legacy_events;

An approved online repair can be attempted after backup:

REPAIR TABLE appdb.legacy_events;

For offline repair, stop MariaDB and verify no process is using the files:

sudo systemctl stop mariadb
pgrep -a mariadbd || true
sudo myisamchk /var/lib/mysql/appdb/legacy_events.MYI

Do not run myisamchk concurrently with the server. The utility works directly on files and does not coordinate normal server locks. Repair modes range from normal to slower and more invasive; begin with a check, preserve .MYD and .MYI copies, and select the least invasive documented method that matches the damage.

After repair, start MariaDB and validate through SQL. Consider migrating business-critical MyISAM tables to InnoDB during a planned project, after checking full-text/spatial/features, locking semantics, storage, and workload behavior.

Metadata problems that resemble corruption

Upgrade mismatch

Errors about wrong column counts or definitions in mysql.* system tables can follow a binary upgrade without the required upgrade procedure. They are not fixed by deleting system tables.

Confirm package and server versions:

mariadb --version
mariadbd --version
dpkg-query -W 'mariadb-*' 2>/dev/null || rpm -qa 'MariaDB*' 'mariadb*'

Back up first, start the intended new server successfully, then run the version-appropriate mariadb-upgrade procedure. The tool connects to a running server; it is not a fix for a server that cannot start.

Missing or mismatched tablespace

An orphan .ibd file, missing definition, wrong innodb_file_per_table history, snapshot assembled from different times, or absent encryption key can produce “cannot open table” messages. Do not create placeholder files or copy a similarly named tablespace from another server.

Tablespace import requires a compatible table definition and a supported discard/import workflow, normally with exported metadata where the version requires it. Test on a clone and use official instructions for the exact release.

Invalid view or definer

Check the object type:

SELECT table_type
FROM information_schema.tables
WHERE table_schema='appdb' AND table_name='report_view';

For a view, inspect:

SHOW CREATE VIEW appdb.report_viewG

Missing referenced objects, invalid definers, or privileges need metadata/security correction, not storage repair.

Replication and Galera considerations

Corruption on a replica may be local physical damage, but executing repair SQL can enter the binary log or create divergence depending on topology and settings. Record positions and stop the affected channel before invasive action:

SHOW REPLICA STATUSG

Often the safest replica recovery is reprovisioning from a known-good primary/backup rather than repairing an uncertain copy. Do not skip a replication event just to turn status green unless the transaction’s effect and consistency consequences are proven.

For Galera, record cluster state:

SHOW GLOBAL STATUS WHERE Variable_name IN (
  'wsrep_cluster_size', 'wsrep_cluster_status',
  'wsrep_connected', 'wsrep_ready', 'wsrep_local_state_comment'
);

An individual node with physical corruption should normally be isolated and rebuilt through the cluster’s supported state transfer/reprovision process. Do not bootstrap a component or copy datadir files between live nodes as a table-repair shortcut.

Validate recovered data

Repair completion is the start of verification. Use multiple layers.

Structural checks

CHECK TABLE appdb.orders;
SHOW CREATE TABLE appdb.ordersG
SHOW INDEX FROM appdb.orders;

Compare schema, engine, columns, indexes, constraints, partitions, character sets, and table options with source control or a trusted environment.

Data checks

Validate known business invariants, not only row count:

• Primary keys are unique and present.
• Child rows have valid parents where the application requires it.
• Financial/control totals reconcile to an external ledger or event stream.
• Minimum and maximum timestamps match the expected retention window.
• Critical status distributions and counts match pre-incident metrics.
• Sampled rows and attachments/blobs can be read end to end.

Queries must be designed for the schema. A full-table COUNT(*) or checksum can be expensive and may revisit the damaged page; schedule it with capacity controls.

Operational checks

Verify:

SHOW ENGINE INNODB STATUSG
SHOW REPLICA STATUSG

Review fresh logs, backup success, restore tests, application error rates, write/read latency, and storage hardware alerts. Run a controlled write transaction in a dedicated health schema rather than altering business data.

Common mistakes

Running REPAIR TABLE on every table

It is engine-specific and mutating. It is not an InnoDB repair command and can add load or discard unrecoverable rows on supported engines.

Starting at innodb_force_recovery=6

Higher levels disable more safety mechanisms. Start at 1, increase only when necessary, export data, and rebuild cleanly.

Using offline utilities while MariaDB is running

aria_chk and myisamchk access files directly. Concurrent server writes can worsen damage and invalidate results.

Repairing before preserving a copy

A failed repair may overwrite the structures needed by a different recovery method. Snapshot or copy through a valid consistency procedure first.

Assuming a healthy replica is identical

It may lag, filter tables, contain the same logical damage, or use a different schema. Verify position and content before promotion or copying data.

Ignoring the underlying device

Repeated corruption after a successful rebuild strongly suggests an unresolved hardware, filesystem, memory, power, or operational problem. Database commands cannot stabilize failing infrastructure.

Treating CHECK TABLE OK as complete proof

It does not prove all business rows exist, relationships are correct, backups are usable, or corruption will not recur.

Prevention and best practices

Use recoverable storage and tested backups

Maintain physical backups appropriate to the dataset, binary logs for PITR, off-host copies, encryption keys, and documented restore procedures. Test restores on the same major-version family and measure recovery time.

Monitor the failure chain

Alert on:

• Kernel I/O and filesystem errors.
• RAID, SMART, SAN, cloud-volume, or Ceph health.
• Read-only remounts and device latency.
• MariaDB checksum, page, crashed-table, and recovery messages.
• Disk bytes and inodes.
• OOM kills and unclean shutdowns.
• Backup validation and replication health.

Keep versions and tools aligned

Use supported MariaDB releases and the mariadb-backup, aria_chk, and myisamchk binaries built for the installed family. Apply upgrade procedures and validate configuration before restart.

Practice engine-specific recovery

In a disposable environment, restore a backup, diagnose a deliberately damaged test copy, dump under low forced-recovery modes, repair an Aria/MyISAM test table, and validate results. Never corrupt a production or shared volume for a drill.

Incident checklist

1. Capture the original error, time, table, query, server identity, and topology.
2. Pause writes, DDL, bulk jobs, and automated repair.
3. Check kernel, filesystem, device, bytes, inodes, and recent changes.
4. Preserve a consistent recovery copy outside the suspect storage.
5. Identify whether the object is a base table or view and determine its engine.
6. Run the least invasive supported check on a specific object.
7. Prefer a verified restore when integrity is uncertain.
8. For InnoDB, use forced recovery only for extraction and start at level 1.
9. For Aria/MyISAM, stop the server before offline utilities.
10. Record every repair action, output, and potential row loss.
11. Validate structure, business data, replication/cluster, logs, and backups.
12. Fix the underlying storage, operational, upgrade, or retention cause.

FAQ

Can REPAIR TABLE fix an InnoDB table?

No. InnoDB recovery normally uses restore, dump and rebuild, secondary-index rebuild, supported tablespace recovery, or temporary forced-recovery extraction.

Is CHECK TABLE safe on a busy production server?

It is diagnostic but can consume substantial I/O and time, especially with intensive options or large tables. Test and run table-specific checks under monitoring.

What does innodb_force_recovery repair?

Nothing. It may let InnoDB start with recovery work disabled so readable data can be exported. Rebuild a clean instance afterward.

Can I run aria_chk while MariaDB is online?

Do not run it on files open by MariaDB. Stop the server and verify no mariadbd process remains before offline checks or repair.

Should I restore or repair a corrupt table?

Prefer restore when a validated, sufficiently current recovery chain exists or integrity is uncertain. Repair may fit scoped Aria/MyISAM damage after preserving a copy.

Does table corruption replicate?

Physical page damage is often node-local; logical bad changes can replicate. Repair actions may also create divergence. Verify every node independently.

Can I copy an .ibd file from another server?

Not as an ordinary file replacement. InnoDB tablespace import has strict definition, metadata, version, encryption, and workflow requirements.

How do I know recovery preserved every row?

Combine structural checks with trusted row totals, business reconciliations, external records, temporal boundaries, sampling, and application tests. A repair status alone cannot prove completeness.

Conclusion

Safe MariaDB table corruption recovery begins by refusing to treat every symptom as the same failure. Preserve evidence and a recoverable copy, rule out unstable hardware and filesystems, identify the exact object and storage engine, and use the least invasive engine-supported path. REPAIR TABLE is not an InnoDB repair tool, offline utilities must not race the server, and innodb_force_recovery is an extraction mode rather than a fix.

When a verified restore can provide a clean, auditable recovery point, it is often safer than modifying damaged structures. Whatever path is chosen, prove the result through schema checks, business invariants, replication or cluster state, application behavior, and a new validated backup. Recovery is complete only after the root cause is corrected and the data can withstand more than a superficial table check.

Suggested Internal Links

• Safely Recover MariaDB When the Service Will Not Start
• Troubleshoot MariaDB Disk Full and Inode Exhaustion
• Back Up MariaDB with mariadb-backup
• Restore MariaDB and Perform Point-in-Time Recovery
• Upgrade MariaDB Safely Between Major Versions
• Build MariaDB Replication and Recovery Procedures

Suggested External Sources

• MariaDB CHECK TABLE
• MariaDB REPAIR TABLE
• MariaDB InnoDB Recovery Modes
• MariaDB InnoDB Troubleshooting Overview
• MariaDB aria_chk
• MariaDB myisamchk