What Are the Warning Signs That a Database Container Was Corrupted by Power Loss?

Suspect corruption when the database cannot complete normal crash recovery or reports checksum, page, log-sequence, table, or index inconsistencies afterward.

An unclean shutdown does not automatically mean the database is corrupted; PostgreSQL, MySQL, MariaDB, and similar engines use journals or write-ahead logs specifically to recover committed state. The warning boundary appears when recovery repeats, the engine exits, the same query hits invalid pages, checksums fail, tables disappear, indexes contradict table data, or backups and integrity checks cannot read the cluster consistently.

Distinguish Normal Crash Recovery From a Recovery Loop

Preserve the first startup log after power returns. Record whether the engine replays logs once and becomes ready, or repeatedly restarts, enters forced recovery, or stops at the same record or page.

InnoDB can report restoration of possible half-written pages after an interrupted write; the message indicates the engine is attempting safe crash recovery, but repeated failures can point to post-outage InnoDB errors.

A single successful recovery followed by normal checks is not proof of corruption. A loop, fatal assertion, repeated signal, or inability to reach ready state is a stop signal for copying raw files and testing backups before more writes occur.

Look for Checksum and Invalid-Page Errors

Search logs for checksum mismatch, page verification failed, invalid page in block, corrupt page, short read, bad magic number, or unexpected end-of-file. Record the relation, table, block, or tablespace named.

pganalyze shows PostgreSQL corruption surfacing as page checksum failures followed by an invalid-page error when the damaged block is read.

Do not silence the error or zero damaged pages before preserving evidence and confirming backup coverage. The same block failing across restarts is stronger evidence than a one-time application timeout.

Watch for Queries That Fail Only on Specific Rows or Tables

Run read-only checks against tables and queries the application normally uses. Corruption may remain hidden until a scan, vacuum, backup, or request touches one damaged page.

A PostgreSQL analysis explains that a checksum mismatch points toward a problem below the database, while an invalid page without a checksum warning can still reflect storage, memory, filesystem, or accidental file damage. The practical symptom is a repeatable invalid-page read during ordinary queries.

Record exactly which query and object fail. Do not let the application continue broad writes while only part of the database remains readable, because new state can complicate recovery and backups.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Check for Index, Transaction, and Metadata Inconsistencies

Warning signs include duplicate keys that violate a unique index, missing rows reachable through one access path but not another, invalid transaction IDs, broken TOAST or large-value chunks, and indexes that fail validation.

Credativ’s corruption review notes that clusters without data checksums may expose damage through low-level errors such as invalid pages, transaction-ID problems, TOAST inconsistencies, or backend crashes. Some file-copy backups can preserve corrupted pages without detecting them.

Run supported integrity and index checks on a copy or controlled maintenance window. Reindexing can repair a damaged derived index, but it does not repair corrupted table data or underlying storage.

Correlate Database Errors With Filesystem and Storage Warnings

Inspect the host kernel, filesystem, pool, drive, controller, UPS, and container-runtime logs around the outage. Look for I/O errors, resets, checksum errors, read-only remounts, degraded pools, and lost or truncated files.

A database recovery guide notes that power failures and bad memory can produce corrupted page writes, especially when storage behavior does not match the database’s durability assumptions. Those host-level events help separate InnoDB page corruption from a normal application restart.

Fix the storage path before restoring a clean database onto it. A successful logical restore to failing media can recreate the incident or silently damage the replacement.

Stop Writes and Prove Recovery From a Clean Backup

When corruption signs are repeatable, stop dependent applications, snapshot or clone the affected volume if safe, and preserve logs and configuration. Test the most recent backup on separate storage before modifying the original cluster.

The ZimaSpace checklist for backing up Docker application state defines what must exist before a destructive database recovery attempt.

The system is trustworthy only when the restored database starts cleanly, integrity checks pass, representative queries and writes succeed, backups complete, and host storage reports no new errors. Forced-recovery modes should be used for salvage under a documented recovery plan, not as normal operation.