Recovering the old server

Running an ordinary update on a major change is not a mistake you pay for, but it does take the old server away before you have dumped it. This page brings it back, long enough for the dump, and then hands you to PostgreSQL major upgrade to finish.

What you are looking at

docker compose up -d --build builds the image, recreates the database container on the new major, waits for a health it never gets, and exits 1 on dependency failed to start: container badlen-db-1 is unhealthy. docker compose logs db says why, repeated once per restart:

Error: in 18+, these Docker images are configured to store database data in a format
       which is compatible with "pg_ctlcluster" ...
       Counter to that, there appears to be PostgreSQL data in:
         /var/lib/postgresql

That is the refusal doing its job: the server stopped before touching anything, so the volume still holds your database exactly as the old major left it. What you no longer have is a server able to read it.

Bringing one back

Beside the stack, on the same volume and in the layout it was written in. The volume says which major wrote it:

export PGPASSWORD=$(grep -m1 '^POSTGRES_PASSWORD=' .env | cut -d= -f2-)
docker compose stop app db
docker run --rm -v badlen_pgdata:/vol alpine cat /vol/PG_VERSION   # the major to bring back, e.g. 16
docker run --rm -d --name badlen-db-old --network badlen_default \
  -e POSTGRES_PASSWORD="$PGPASSWORD" -v badlen_pgdata:/var/lib/postgresql/data postgres:16-alpine
until docker exec badlen-db-old pg_isready -U badlen -q; do sleep 1; done
docker run --rm --network badlen_default -e PGPASSWORD postgres:18-alpine \
  pg_dump -h badlen-db-old -U badlen -d badlen > badlen-dump.sql
grep -c 'PostgreSQL database dump complete' badlen-dump.sql   # must print 1
docker stop badlen-db-old

Then carry on with PostgreSQL major upgrade from its docker compose down, the dump already taken.

Privacy