Restoring a 2017 Redmine backup into Redmine 5.0.2 (Docker)

by

Update 2026: this setup has since been upgraded to Redmine 6.1 on PostgreSQL 15, and the permission workaround below is no longer needed. See Upgrading a neglected Redmine: PostgreSQL 9.6 → 15 and Redmine 5.0 → 6.1 in Docker.

I had an old Redmine backup from 2017 lying around and wanted it running again on a current system. This is a quick record of how I restored it with the sameersbn Docker images, and the permission problem that kept getting in the way.

Old and new setup

  • Old: Redmine 3.3.0, PostgreSQL 9.6-2, on a Ubuntu version I no longer remember. The backup dates from 2017.
  • New: Ubuntu 22.04 with sameersbn/redmine:5.0.2 and sameersbn/postgresql:9.6-4.

The problem: permission errors

The PostgreSQL container kept failing and aborting with permission errors on its data directory. The fix I ended up with isn’t pretty: a chmod 777 on the PostgreSQL data directory before each container start. After that, everything ran without problems.

Relevant paths:

  • PostgreSQL data directory: /data/redmine/postgresql/
  • Backup file: /data/redmine/backup/. The restore command finds it there automatically.

The steps

docker network create redmine
docker-compose create

# start the database and watch it come up
docker start sqlcontainer && docker logs sqlcontainer -f
chmod 777 -R /data/redmine/postgresql/

# start Redmine once so it initializes
docker start redminecontainer && docker logs redminecontainer -f
chmod 777 -R /data/redmine/postgresql/

# stop and remove the Redmine container, then restore the backup
docker-compose stop redmine
docker-compose rm redmine
docker-compose run redmine app:backup:restore
chmod 777 -R /data/redmine/postgresql/

# recreate the Redmine container
docker-compose create redmine

A word on chmod 777

Making a database directory world-writable works, but it’s a workaround, not a fix. The cleaner approach is to give the directory to the user ID the database process runs as inside the container. In the end the problem went away for good by moving to the official postgres image, which manages its data directory permissions itself; see the update linked at the top.

Leave a comment