PostgreSQL failsafe start after disk crash

Question

We use PostgreSQL to store logs.

A disk crashed and some files in the file system were corrupt.

I read this: https://wiki.postgresql.org/wiki/Corruption

But this page does not solve my needs.

I don't care if some transactions got lost.

I care for availability.

Above page suggests "Consider contacting a professional support service provider".

That's not an option.

I see two ways to solve this:

Solution 1: If PostgreSQL does not start, then rename the data directory. Init postgres, create required DB and tables.

Solution 2: Use a tool which can start a corrupted DB. It does not matter if some transactions got lost.

Is there such a tool which can start a corrupted DB?

Given my current context (DB exists to be store logs), what other solutions could be used to ensure the DB is up again soon after a corruption?

• user1822: "what other solutions could be used to ensure the DB is up again soon after a corruption" - backups? Or a standby?

Answer 1

Among the options you give, the first is the only feasible one. But neither one of them is very good.

The only good solutions is to prevent it from happening. If your disks randomly eat your data, maybe next time it will be the postgres binaries that get eaten, or the kernel itself, or the init script you wrote to re-init the database when it gets corrupted, or the dump files which contains the schema you want to use to reload.

If your disks are honest and true but your database got corrupted anyway because you were running with fsync=off, then don't do that. Run with synchronous_commit=off instead, if you must. That risks losing some transactions, but doesn't corrupt your database.

• guettli: It happened for the first time after using PostgreSQL for nearly ten years. But using it for storing logs is new.

Answer 2

Your best solution would be to replace the bad disks and then restore your database from your last, good Backup. OK, you'll probably lose some data (depending on how your backups are organised) but you'll get back a working database.

Trying to piece things together at the disk level is generally a Bad Idea.