Immich•7mo ago

"Getting Started" screen after restoring from a backup

I just moved from one machine running immich to another. Both are running under Docker. The old install was from before the DB was stored outside of docker. So, I planned to do a restore from the last DB dump.

I followed the instructions here: https://immich.app/docs/administration/backup-and-restore/ but once they were done, I'm getting the "Getting Started" screen.

I've rerun them a couple times, using different DB dumps, but still get the same result. I put a bunch of time into setting the old instance up that I'd rather not repeat, but I don't see what else I can do to troubleshoot. I'm hoping someone here has an idea.

Immich•5/25/25, 9:41 PM

:wave: Hey @Thomas,

Thanks for reaching out to us. Please carefully read this message and follow the recommended actions. This will help us be more effective in our support effort and leave more time for building Immich :immich:.

References

Container Logs:
```
docker compose logs
```
```
docker compose logs
```
docs
Container Status:
```
docker ps -a
```
```
docker ps -a
```
docs
Reverse Proxy: https://immich.app/docs/administration/reverse-proxy
Code Formatting https://support.discord.com/hc/en-us/articles/210298617-Markdown-Text-101-Chat-Formatting-Bold-Italic-Underline#h_01GY0DAKGXDEHE263BCAYEGFJA

Immich•5/25/25, 9:41 PM

Checklist

I have...

:ballot_box_with_check: verified I'm on the latest release(note that mobile app releases may take some time).
:ballot_box_with_check: read applicable release notes.
:ballot_box_with_check: reviewed the FAQs for known issues.
:ballot_box_with_check: reviewed Github for known issues.
:ballot_box_with_check: tried accessing Immich via local ip (without a custom reverse proxy).
:ballot_box_with_check: uploaded the relevant information (see below).
:ballot_box_with_check: tried an incognito window, disabled extensions, cleared mobile app cache, logged out and back in, different browsers, etc. as applicable

(an item can be marked as "complete" by reacting with the appropriate number)

Information

In order to be able to effectively help you, we need you to provide clear information to show what the problem is. The exact details needed vary per case, but here is a list of things to consider:

Your docker-compose.yml and .env files.
Logs from all the containers and their status (see above).
All the troubleshooting steps you've tried so far.
Any recent changes you've made to Immich or your system.
Details about your system (both software/OS and hardware).
Details about your storage (filesystems, type of disks, output of commands like
```
fdisk -l
```
```
fdisk -l
```
and
```
df -h
```
```
df -h
```
).
The version of the Immich server, mobile app, and other relevant pieces.
Any other information that you think might be relevant.

Please paste files and logs with proper code formatting, and especially avoid blurry screenshots.
Without the right information we can't work out what the problem is. Help us help you ;)

If this ticket can be closed you can use the

/close

/close

command, and re-open it later if needed.

IImmich ## Checklist I have... 1. :ballot_box_with_check: verified I'm on the latest rel...

ImmichAPP•5/25/25, 9:45 PM

Successfully submitted, a tag has been added to inform contributors. :white_check_mark:

ThomasOP•5/25/25, 9:45 PM

the attached files are from the new install

docker-compose.yml2.66KB

env1.08KB

bo0tzz•5/26/25, 9:49 AM

If you're getting that screen it means the backup didn't restore properly

ThomasOP•5/26/25, 4:15 PM

Yup, I figured. Any tips on how to debug that?

Mraedis•5/26/25, 4:16 PM

What is the size of your DB dump for starters

ThomasOP•5/26/25, 4:16 PM

Also, does that mean the DB restore specifically didn't work or could problems with the file system portion cause it?

Mraedis•5/26/25, 4:16 PM

if it's very tiny it's probably just broken and contains a line that amounts to "didn't work"

ThomasOP•5/26/25, 4:17 PM

I don't think that's it. I've tried two different daily dumps, both of which are ~500 MB:
total 4.4G
-rw-r--r-- 1 root root 552M May 16 17:03 immich-20250517.sql.gz
-rw-r--r-- 2 root root 552M May 17 17:01 immich-20250518.sql.gz
-rw-r--r-- 1 root root 552M May 18 17:05 immich-20250519.sql.gz
-rw-r--r-- 1 root root 553M May 19 17:02 immich-20250520.sql.gz
-rw-r--r-- 1 root root 553M May 20 17:07 immich-20250521.sql.gz
-rw-r--r-- 1 root root 553M May 22 17:02 immich-20250523.sql.gz
-rw-r--r-- 2 root root 553M May 23 17:03 immich-20250524.sql.gz
-rw-r--r-- 4 root root 553M May 24 17:03 immich-20250525.sql.gz
lrwxrwxrwx 1 root root 22 May 24 17:03 immich-latest.sql.gz -> immich-20250525.sql.gz

ThomasOP•5/26/25, 4:17 PM

Also, thanks for helping.

Mraedis•5/26/25, 4:18 PM

alrighty so next up, how are you restoring

Mraedis•5/26/25, 4:18 PM

like exactly the command

Mraedis•5/26/25, 4:18 PM

I know you linked the docs but I want the one YOU are entering

ThomasOP•5/26/25, 4:20 PM

Sure thing.

Here's the commands I ran:

docker compose down
Delete the old postgres out of the way
docker compose pull
docker compose create
docker start immich_postgres
sleep 10
gunzip --stdout "db_dumps/daily/immich-20250525.sql.gz" \| sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g" \| docker exec -i immich_postgres psql --dbname=postgres --username=postgres
docker compose up -d # Start remainder of Immich apps

Mraedis•5/26/25, 4:21 PM

ok so when you gunzip, what are the logs there?

Mraedis•5/26/25, 4:22 PM

docker compose logs

docker compose logs

should work

Mraedis•5/26/25, 4:22 PM

so without starting the rest

ThomasOP•5/26/25, 4:22 PM

sure. one sec. I'll rerun it now

ThomasOP•5/26/25, 4:24 PM

do you want to see the output from the gunzip command as well?

Mraedis•5/26/25, 4:24 PM

sure

ThomasOP•5/26/25, 4:25 PM

`There's the output

message.txt5.35KB

ThomasOP•5/26/25, 4:26 PM

Here's the docker logs
`

message.txt4.86KB

Mraedis•5/26/25, 4:29 PM

Did you have a newer postgres version before?

ThomasOP•5/26/25, 4:30 PM

both were running through docker, although I believe the old one was from before when postgres wrote to a volume outside of docker

ThomasOP•5/26/25, 4:30 PM

So, I don't believe they had different postgres versions, given they were both virtualized with the same docker-compose file

Mraedis•5/26/25, 4:32 PM

I ask because your dump seems to be using a parameter transaction_timeouttransaction_timeout which is new since postgres v17

Mraedis•5/26/25, 4:32 PM

@Zeus any ideas?

Zeus•5/26/25, 4:35 PM

How was the dump made?

Zeus•5/26/25, 4:35 PM

Hm. Builtin?

ThomasOP•5/26/25, 4:36 PM

the new one is attached at the top of this

message.txt2.67KB

ThomasOP•5/26/25, 4:36 PM

But yes, the dump was using the built in immich_db_dumper

TThomas But yes, the dump was using the built in immich_db_dumper

Zeus•5/26/25, 4:37 PM

Thats not builtin

Zeus•5/26/25, 4:37 PM

Just change your postgres image to 17 instead of 14. Its fine to do

Zeus•5/26/25, 4:38 PM

Or maybe it is builtin either way the dump was def made with 17

ThomasOP•5/26/25, 4:38 PM

The original docker compose was from waaaaay back, and I know a bunch changed since then.

Regardless, I'll change the current pg image and retry. Thanks much.

ThomasOP•5/26/25, 4:43 PM

What's the easiest way to switch the image to 17? Just use this image intead: ghcr.io/immich-app/postgres:17-vectorchord0.3.0-pgvectors0.3.0 I assume?

Mraedis•5/26/25, 4:44 PM

Yup

Mraedis•5/26/25, 4:44 PM

(wow we make a lot of images

)

ThomasOP•5/26/25, 4:44 PM

yes. yes, you do.

ThomasOP•5/26/25, 6:58 PM

Ultimately, that didn't fix the issue, but I've gotten my system back up by recreating the old instance. Which gives me something stable to work with, while I sort out how to migrate away from it.

Regardless, thank you both for your help. You helped me get back on a better path.

Mraedis•5/26/25, 7:00 PM

Alright, let us know how it goes

ThomasOP•5/26/25, 7:26 PM

OK, solved. I'm sharing here in case it's useful for the future.

For context, I've been running Immich since late 2022, and the docker-compose file I've been using is largely unchanged since then.

There were two separate issues:

the postgres password was something other than the current default
I was pulling the backups from those generated via immich_db_dumper (https://github.com/prodrigestivill/docker-postgres-backup-local) which I just today realized is no longer the norm

1 meant that manual backups using pg_dumpall didn't work out of the box. 2 is what (I believe) introduced the version problem.

I had to address both to get a working version.

Anyway, I'm now up and running with the recommended docker-compose file on the new machine.

Thanks again for the help. Your suggestions helped me clear some of the complexity away, so I could untangle the rest.

MMraedis (wow we make a lot of images 😛 )

Mio•6/29/25, 11:12 AM

With the latest immich version, should I use postgres:17-vectorchord0.4.3-pgvectors0.3.0?

Mraedis•6/29/25, 11:15 AM

Please don't bump other people's topics

Mraedis•6/29/25, 11:15 AM

You should use whatever postgres version you had before

Mraedis•6/29/25, 11:15 AM

with -vectorchord0.4.3-pgvectors0.3.0

"Getting Started" screen after restoring from a backup

References

Checklist

Information

Similar Threads

Similar Threads

References

Checklist

Information

Similar Threads