# The database found damaged data on disk

A MySQL or PostgreSQL server read a page of its data files that is broken or incomplete, and stopped or refused the query rather than serve wrong data.

- Code: `database_corrupted`
- Severity: fatal
- Category: Databases
- Server types: MySQL, PostgreSQL
- Page: https://failures.perland.online/failures/database_corrupted/

## Example log

```text
2026-11-05T11:08:37.661204Z 0 [ERROR] [MY-011906] [InnoDB] Database page corruption on disk or a failed file read of page [page id: space=7, page number=212]. You may have to recover from a backup.
2026-11-05T11:08:41.903377Z 14 [ERROR] [MY-011899] [InnoDB] [FATAL] Unable to read page [page id: space=7, page number=212] into the buffer pool after 100 attempts. The most probable cause of this error may be that the table has been corrupted.
```

## Parameters

| Parameter | Meaning |
| --- | --- |
| `database` | Which database printed it, `mysql` or `postgres`. |

## Log lines this page covers

- `Database page corruption on disk or a failed file read of page`
- `Unable to read page [page id: …] into the buffer pool`
- `invalid page in block … of relation …`
- `could not read block … in file …: read only … of … bytes`

## What it means

A database stores its tables in files made of fixed-size pages (16 KiB for MySQL's InnoDB, 8 KiB for PostgreSQL). Each page carries a checksum or a header the database checks when it reads it. Here a page failed that check, or the file was shorter than it should be: part of the data on disk is not what the database wrote.

The database refuses to go on with a damaged page rather than return wrong data. MySQL usually stops the whole server; PostgreSQL fails the queries that touch the damaged table. The plugins or mods that use those tables stop working.

## Why it happens

- **The database was stopped abruptly** while writing, by a power loss, a crash of the machine, or its container being killed, on storage that does not guarantee what it acknowledged was written.
- **The disk is failing**, or the file system under it has errors.
- **The disk filled up** during a write, leaving files cut short.
- **The data files were copied or restored while the database ran**, which gives a copy of files caught halfway through changes.
- Rarely, a bug in the database or the storage driver.

## How to fix

1. **Stop the database and back up its whole data folder as it is now**, before any repair. Every recovery step can make things worse, and you want to be able to start over.
2. The safest fix is to restore a backup or a dump taken before the damage. If you have one, restore it on a fresh, empty data folder.
3. Without a backup, try to save what is readable:
   - **MySQL:** start it with `innodb_force_recovery = 1` in its configuration (raise it one step at a time up to 3 only if it still does not start; values of 4 and above can damage the files for good, so use them only on a copy), dump everything with `mysqldump`, then load the dump into a new, empty database. Do not keep running on forced recovery.
   - **PostgreSQL:** dump each database with `pg_dump`; a table that cannot be read fails the dump, so dump the other tables one by one with `pg_dump -t`. Load the result into a new cluster.
4. Check the disk afterwards (the machine's `dmesg` or SMART data, the file system check). If it happens again, the disk may be failing: tell whoever runs the machine.

## In Perland

A server's database sidecar is a MySQL or PostgreSQL container next to the server, with its data in a Docker volume on the host. This issue appears in the sidecar's diagnosis (the stack's diagnosis with `service` `mysql` or `postgres`). With backups on, each backup holds a dump of the database that you can download and load into a fresh database by hand; Perland never loads it over a running database for you.

## References

- [MySQL 8.4: forcing InnoDB recovery](https://dev.mysql.com/doc/refman/8.4/en/forcing-innodb-recovery.html)
- [PostgreSQL wiki: corruption](https://wiki.postgresql.org/wiki/Corruption)