Field Note · Diagnosis
The PostgreSQL database that was never lost.
A Linux reboot left PostgreSQL running on port 5432—but every database the customer expected to see had disappeared. Eight hours later, the decisive question was not “How do we restore it?” but “Which PostgreSQL instance are we connected to?”
The situation
The server came back. The business data did not.
An owner-operated small business asked for urgent help after rebooting its Linux server. PostgreSQL started and accepted connections, yet the production databases and all expected data appeared to be gone.
The owner had limited PostgreSQL and Linux experience. He stayed with me on Zoom, shared what he knew, and watched the investigation unfold. From his perspective, the database had existed before the reboot and had vanished afterward.
The trap
A plausible description can still point to the wrong problem.
The phrase “the data is gone” naturally directs attention toward deletion, corruption, storage failure, or restore options. I inspected logs, configuration, filesystem state, startup behavior, and recovery possibilities. I used controlled restarts and kept comparing what PostgreSQL reported with what the owner expected.
The backup was not immediately useful because we had not yet established what had actually failed—or whether anything had failed at all.
The turn
Challenge the premise, then inventory the instance.
I stepped back from recovery and asked a more basic question: could the running PostgreSQL server be different from the one that owned the production data?
It was. The host contained two PostgreSQL installations of different versions, two postgresql.conffiles, and two separate data directories. Both expected to use port 5432. After the reboot, the wrong instance had won the startup race. It was healthy, reachable, and empty of the customer's data.
Why it took time
The final command was simple. Finding the right problem was not.
With the complete picture, the repair looked obvious. During the incident, however, every visible signal reinforced the customer's original frame: PostgreSQL was up, and the data was gone. You do not look for a second instance until the evidence gives you a reason to doubt the first one.
The customer recovered the entire business state and later left a strongly positive review. The durable value was not a clever recovery command. It was the discipline to keep investigating until the explanation accounted for every observation.
DBRE lesson
Before restoring a database, prove which database you are observing.
Confirm the server identity, version, configuration file, data directory, port ownership, and startup mechanism. Recovery work performed against the wrong instance can turn a harmless configuration error into a real outage.