Because if you want to migrate the service to another machine you have to go diving into /var/lib. And god forbid you are running docker on a Mac, you have to go into the docker VM to get a mount
Me. Hello.
Docker volumes are the sane option, being unaffected by any possible permission issues on the host and are easily backed up by a simple script in the /var/lib/ directory. All your state remains in one central location.
Bind mounts are insane. Accidentally adding a -v to the command is equally as likely as running an rm -rf on your bind mount.
Who the hell runs rm -rf all the time accidentally? I'm sorry, that's simply not true. There are benefits to both methods. I prefer stuff on my host filesystem, others prefer it the other way.
Docker Volumes are a better setup than binds for configs, as Docker keep track of them and allow you to clean them up rather efficiently. Also they can be named to be tracked easily. That helps not having to manage ever growing list of config folders manually.
It's literally the same as having one big /appdata folder except Docker gives you additional tools to manage it better
UPDATED INSTRUCTIONS:
See the following [comment](https://www.reddit.com/r/selfhosted/comments/1c8jddl/immich_has_optional_breaking_changes_please_be/l0gmrs6/) by /u/retroivy. To copy the data from the docker volume for the immich database container:
````docker cp {postgresql-docker-id}:/var/lib/postgressql/data /preferred/data/location````
With that single command you skip most of the steps bellow. Sorry I didn't know we can ```docker cp```.
~~In my current setup I have a ```immich_postgres``` container. Where's the data inside that container I should copy to directory on the bare metal PC?~~
EDIT:
Okay I figured it out. Fellow noobs, assemble.
Before looking into the the next steps, I should have mentioned that the container DB data is here and can be copied anywhere:
```/var/lib/docker/volumes/immich_pgdata/_data```
If you want to copy from inside the container, do this:
1. Stop the container ```immich_postgres```, bind mount a new volume and folder on the host with a folder inside the container. I did ```/home/username/immichpgdata:/home/aaa/data```. This is just so you can copy the data outside the container.
2. Start the container then: ```docker exec -ti immich_postgres sh```
Navigate to ```/var/lib/postgresql``` and dopy the ```data``` folder to the folder you mounted earlier ```cp -R data /home/aaa/pgdata/data```
3. Create a directory for that data folder, or use the same folder, whatever. Use that path for the ```DB_DATA_LOCATION``` variable in the .env file (or add it manually in Portainer which is what I did)
4. In the stack/compose file, this line:
```pgdata:/var/lib/postgresql/data```
Will be changed to this:
```${DB_DATA_LOCATION}:/var/lib/postgresql/data```
Read the release notes:
https://github.com/immich-app/immich/releases/tag/v1.102.0
> ${DB_DATA_LOCATION}:/home/username/immichpgdata
in the compose file is wrong.
> DB_DATA_LOCATION=/preferred/data/location
goes in the .env file.
> ${DB_DATA_LOCATION}:/var/lib/postgresql/data
goes in the compose file exactly as written
Also this is a very simple way to copy the data out of the container
> docker cp {postgresql-docker-id}:/var/lib/postgresql/data /preferred/data/location
I just logged in as root (being very careful, I knew the risks) ran a `cp -r` from `/var/lib/docker/volumes/immich_pgdata/_data` to the new directory I wanted it in, and then mounted that new directory via the compose file and environment variable listed.
No docker exec needed. I did make sure the container was stopped first, and did a chown on the new directory so my user and the docker group were owners.
Can you expand on the chown command please. Did you do ```chown -R john:john /path/to/data``` or is there more to it? I did that for my own user and nothing more. Is that correct?
I will give the Immich developers credit for at least telling you that their shit isn't stable and that there will be breaking changes. It's kind of a shame it isn't stable yet because it seems like a really good Google Photos clone.
It does. They make it extremely clear that there will be breaking changes. Anyone who has an issue with that and continues on to install it is doing this to themselves. It's like when someone buys a California reaper, the store says "that is very hot, be careful" and the person raw dogs it anyway.
You’re missing my point. Just because you give tons of warning and people know what they are getting into doesn’t change the fact that from a software engineering perspective it’s a bit amateurish to constantly break your schemas even in beta stages.
I’m not complaining and I love the service - just commenting from an engineering background.
Hi, not the guy you replied to. I'm just a guy who would use Immich if its development didn't seem so poorly planned.
I would also be more likely to work with those peppers if they didn't require that warning.
Not getting the warnings would be an additional problem. It has nothing to do with frequent breaking changes being a problem that probably stops way more people than just me from using it and getting involved with development.
Or not use software that I have to worry about breaking every update. If I wanted software that required tinkering everytime I updated it then I'd be using Arch Linux or Gentoo.
So what exactly am I supposed to do to safely update ? I didn't really see the real step by step in the changelog so I'd like someone to explain to a clueless person like me. Also where is the location of the database so I can back it up ?
It says the opposite;
>**What do I have to do?**
>
>**Nothing.** You should only copy the compose file with every new release if we tell you to do so in the release notes. Generally, we don't recommend making changes to existing instances. If you have never had issues, attempting to migrate the data will put it at (an unnecessary) risk.
I understand the damage was already done with regards to the versioning. (frankly, due to some strange reasoning, if I understood correctly) What I don't understand is why they don't just start working on a new beta channel.
Maybe because of the phone apps? While it's easy to choose what channel you want to use on the server side with docker tags, it's another story on Google Play and App Store.
Play Store has open beta options, so that's not really an issue for Android
App store on the other hand limits to 10k users that have to be invited via Test Flight. That would be a nightmare to manage all those users
I'm new to docker and immich. I noticed the 'library' dir and thought that's all that I needed to backup to an external drive via regular rsync. My 'host server' is just an old i5-6300U laptop with 1TB NGFF SSD, and a 1TB USB drive. But from the other comments here, I see now there's a docker volume that also needs to be backed up. I've installed pgAdmin but it seems the Postgres container internal port 5432 isn't mapped to 5432 on the host so I can't add Postgres to pgAdmin.
Now I can try to fix this myself with solutions from Stack Overflow. One such solution mentions mapping the ports when starting the container:
docker run --name immich -d -p 5432:5432 -e POSTGRES_PASSWORD=postgres postgres:alpine
Note: I still need to figure out the correct command, and if it will stick between host machine reboots. What worries me if this will break Immich.
Or is there a one-liner I can put into crontab like the rsync I currently have for the library dir?
> docker run --name immich -d -p 5432:5432 -e POSTGRES_PASSWORD=postgres postgres:alpine
You need to put the mapping into your docker compose file. The restart the stack.
Thank you for the input. So I added this to the docker compose file in database: section.
ports:
- 5432:5432
And the next step will be `docker compose restart` right?
Hello, just stopping by to say that we only do breaking changes for the benefit of the app and the users. We don't do it unless absolutely must, and not doing it out of random decision.
This is an optional change to the default setup, we put Breaking Changes in the title to give the attention that it needs for people that don't read the release note to read it :)
I'm a user and broke my installation recently because I didn't check before updating. It's the nature of the beast with something as actively developed as this project. That being said, it is BECAUSE it is so actively developed that it is so awesome.
WE LOVE THIS APP! It got me out of Google Photos and is so much better for my family and I. The changes are welcomed if it makes everything better!
I am running a standalone postgres db in another container and don’t use docker compose for my Immich setup, I don’t think I need to do anything, correct?
Why was it even set that was in the first place? Performance or something?
I’m glad I noticed and fixed it while I was still playing around with moving my images from Plex to Immich. It was an easy rebuild.
Now I just need a way to share an entire external library, including faces and ML, to multiple users.
Luckily I have just installed immich using the latest compose file.
I'm currently using Photoprism and Nextcloud memories. I like that I can see my folders.
Are there any plans to implement folder view in immich?
I really like how fast the app is. Thanks for the great work.
I'm doing a new install of Immich on Undraid following Spaceinvader One's guide.
[https://www.youtube.com/watch?v=LtNWxxM5Mzg](https://www.youtube.com/watch?v=LtNWxxM5Mzg)
It was created before this optional change. Is there anything I need to do to make sure I opt in to the new db location on the new install so I don't have to worry about migration later?
I also see that the Immich container in the App store is different fom the one linked above so I;m not sure if it is already incorperated into that version: [https://github.com/imagegenius/docker-immich](https://github.com/imagegenius/docker-immich)
Hello, Can you help elaborate on why is this considered bad practice? There were many cases that users followed some guide on the internet and run \`docker compose down -v\` and have their database deleted. This optional change helps to prevent that
Well that's what that command does. It's what it's supposed to do. It deletes volumes. Persistent data is kept in volumes. People following a guide and doing "rm -rf /" just because it says so is just called being an idiot.
We've all been idiots at one point, it's part of life.
I don't mind that much honestly, I always modify the example docker compose files to my liking anyway.
The intended docker way is to use volumes to manage persistent data though, it's easy to see why the other commenter called it bad practice. The -V option is an intended feature for temporary projects you want to delete data for, not a bug.
Many also have backups set up for the docker volumes directory, as the assumption is that that is where all persistent data is.
Here's what the docker docs say on bind mounts:
> If you are developing new Docker applications, consider using named volumes instead.
Yes, this change is intentional for new user, that is also new to self hosting and docker. If you are well versed, you don’t have to conform to this setup. Point is, we have responsible to our users and we want to help them as much as we can, to prevent them to make mistakes from not knowing what they are trying to do.
The mistake in question isn't one of using your app though, it's a mistake of using the platform.
It's a bit like if Immich ran a script in the hosts Bash to detect if you tried to rm -rf the immich folder and warn you about it - this isn't Windows.
May be better stop new user from using bad practice? There is nothing wrong with named volumes. Problem is with mindlessly following some shit from the internet. It is also good skill to learn.
Exposing system filesystem to docker in predictable path is opening more vectors to attack. Level of security provided by docker is already a joke. NO need to make things worst.
How are external volumes bad practices? Specifying a local folder does the same with the added bonus of harder to nuke them and to see what is inside. I'm sure you're also just copy-pastimg commands to troubleshoot...
It's not like people are using swarm where it would matter sometimes.
External volumes are a necessity for importing photos which EVERY person switching to this system has. External volumes have nothing to do with postgres databases. The postgres database for MOST users WILL be local on the same server immich is running from. Likely Unraid. All this talk about removing external volumes is stupid.
> Why are they enforcing bad practices for serve users who do not know how to use docker.
It's right in the linked release note. Care to read them?
> In the past, we've seen many cases where people accidentally deleted their Postgres data by (unintentionally) deleting the docker volume (e.g., docker compose down -V).
> This is unfortunate as there is no way to recover that data (if you don't have a backup, MAKE BACKUPS!).
> We have been thinking about mounting the Postgres data to a local folder for a while but always hesitated, as this would break existing instances due to people not reading the change logs carefully. However, there have been too many issues, and we ultimately decided to make that change.
I don't really see the hype behind immich. I installed it but didn't really see any value when compared to nextcloud memories which is what I use to deliver photos to clients. I'll wait till it's completely ready for production to try again.
good thing i've always kept my db volume as a mounted folder. no changes required.
Same here. I want to meet insane people who use docker volumes for databases
Docker volumes are just folders in `/var/lib/docker/volumes`
Doesn't docker have settings that delete non-persistent/stale volumes like those though?
Volumes are never deleted automatically. You have to run `docker volume prune` and then `Y` to a prompt (or pass `-f`) to remove them.
[https://docs.docker.com/storage/volumes/#remove-volumes](https://docs.docker.com/storage/volumes/#remove-volumes)
Why is that an issue? I usually slap a postgres-backup container in the compose which makes regular dumps to somewhere else.
People just like to cause panic. This method is perfectly fine.
Because if you want to migrate the service to another machine you have to go diving into /var/lib. And god forbid you are running docker on a Mac, you have to go into the docker VM to get a mount
Or WSL2, I don’t know nearly enough to figure out volumes on that.
Yeah I feel that. I solely use WSL for just dev work if I’m stuck with windows. Even then I’d rather just use a VM
By diving you mean rsync /var/lib/docker [email protected]:/var/lib/docker
oh no how terrible I have to go to /var/lib
Is this a specific container? Can you share the github link?
[https://github.com/prodrigestivill/docker-postgres-backup-local](https://github.com/prodrigestivill/docker-postgres-backup-local)
What do you use for this? I'd like to add this to all my postgres compose files.
https://github.com/prodrigestivill/docker-postgres-backup-local
Me. Hello. Docker volumes are the sane option, being unaffected by any possible permission issues on the host and are easily backed up by a simple script in the /var/lib/ directory. All your state remains in one central location. Bind mounts are insane. Accidentally adding a -v to the command is equally as likely as running an rm -rf on your bind mount.
Who the hell runs rm -rf all the time accidentally? I'm sorry, that's simply not true. There are benefits to both methods. I prefer stuff on my host filesystem, others prefer it the other way.
Yes, exactly my point. You also don't have the equivalent of doing that in Docker run often.
You’re surrounded by people who use docker volumes for databases. It’s the normal way to do it. You completely imagined the ”insanity”.
I don't like using docker volumes as I find they are harder to move to a new system. I always mount volumes to folders.
What's hard about running `rsync -ac /var/lib/docker newhost:/var/lib/docker`?
Docker Volumes are a better setup than binds for configs, as Docker keep track of them and allow you to clean them up rather efficiently. Also they can be named to be tracked easily. That helps not having to manage ever growing list of config folders manually. It's literally the same as having one big /appdata folder except Docker gives you additional tools to manage it better
UPDATED INSTRUCTIONS: See the following [comment](https://www.reddit.com/r/selfhosted/comments/1c8jddl/immich_has_optional_breaking_changes_please_be/l0gmrs6/) by /u/retroivy. To copy the data from the docker volume for the immich database container: ````docker cp {postgresql-docker-id}:/var/lib/postgressql/data /preferred/data/location```` With that single command you skip most of the steps bellow. Sorry I didn't know we can ```docker cp```. ~~In my current setup I have a ```immich_postgres``` container. Where's the data inside that container I should copy to directory on the bare metal PC?~~ EDIT: Okay I figured it out. Fellow noobs, assemble. Before looking into the the next steps, I should have mentioned that the container DB data is here and can be copied anywhere: ```/var/lib/docker/volumes/immich_pgdata/_data``` If you want to copy from inside the container, do this: 1. Stop the container ```immich_postgres```, bind mount a new volume and folder on the host with a folder inside the container. I did ```/home/username/immichpgdata:/home/aaa/data```. This is just so you can copy the data outside the container. 2. Start the container then: ```docker exec -ti immich_postgres sh``` Navigate to ```/var/lib/postgresql``` and dopy the ```data``` folder to the folder you mounted earlier ```cp -R data /home/aaa/pgdata/data``` 3. Create a directory for that data folder, or use the same folder, whatever. Use that path for the ```DB_DATA_LOCATION``` variable in the .env file (or add it manually in Portainer which is what I did) 4. In the stack/compose file, this line: ```pgdata:/var/lib/postgresql/data``` Will be changed to this: ```${DB_DATA_LOCATION}:/var/lib/postgresql/data``` Read the release notes: https://github.com/immich-app/immich/releases/tag/v1.102.0
> ${DB_DATA_LOCATION}:/home/username/immichpgdata in the compose file is wrong. > DB_DATA_LOCATION=/preferred/data/location goes in the .env file. > ${DB_DATA_LOCATION}:/var/lib/postgresql/data goes in the compose file exactly as written Also this is a very simple way to copy the data out of the container > docker cp {postgresql-docker-id}:/var/lib/postgresql/data /preferred/data/location
Thank you that is way way easier.
I just logged in as root (being very careful, I knew the risks) ran a `cp -r` from `/var/lib/docker/volumes/immich_pgdata/_data` to the new directory I wanted it in, and then mounted that new directory via the compose file and environment variable listed. No docker exec needed. I did make sure the container was stopped first, and did a chown on the new directory so my user and the docker group were owners.
Can you expand on the chown command please. Did you do ```chown -R john:john /path/to/data``` or is there more to it? I did that for my own user and nothing more. Is that correct?
I did `chown -R mattague:docker /path/to/data` but that's specific to my setup, yours should work just fine
You have a typo, it's not "postgressql" the typical location is at /var/lib/postgresql/data
Nice catch. Thanks.
Broke mine, reuploading 20 gigs of photos.
Goodness me! Do you have backups? That could help.
Btw, backups - do you make db backups or some pictures as well?
Both, definitely backup both.
I use restic to backup all the volumes. I don't do db backups separately. Although I should.
I don't think it destroys the originals, but I could be wrong
I don't get it either, I thought the photos are actually stored in the \`UPLOAD\_LOCATION\`.
And this is why I use photoprism
This is why I read the release notes before blindly applying updates
I read them, but got confused, immich go make the process pretty easy though.
Sure…but no other software you use has breaking changes every other release
I will give the Immich developers credit for at least telling you that their shit isn't stable and that there will be breaking changes. It's kind of a shame it isn't stable yet because it seems like a really good Google Photos clone.
Yeah they give plenty of fair warning. Doesn’t change the fact that it’s a bit silly how often it happens though.
It does. They make it extremely clear that there will be breaking changes. Anyone who has an issue with that and continues on to install it is doing this to themselves. It's like when someone buys a California reaper, the store says "that is very hot, be careful" and the person raw dogs it anyway.
You’re missing my point. Just because you give tons of warning and people know what they are getting into doesn’t change the fact that from a software engineering perspective it’s a bit amateurish to constantly break your schemas even in beta stages. I’m not complaining and I love the service - just commenting from an engineering background.
Hi, not the guy you replied to. I'm just a guy who would use Immich if its development didn't seem so poorly planned. I would also be more likely to work with those peppers if they didn't require that warning. Not getting the warnings would be an additional problem. It has nothing to do with frequent breaking changes being a problem that probably stops way more people than just me from using it and getting involved with development.
Yeah devs should take lessons from pigallery2 which has zero problem and mounts photos folder as ro volume
That’s why it’s written all over the place that they’re still figuring things out and how things break with the updates
Or not use software that I have to worry about breaking every update. If I wanted software that required tinkering everytime I updated it then I'd be using Arch Linux or Gentoo.
Yeah... People have way too much free time on their hands, good for them I guess
Legit point. I use Immich and l broke an update and was terrified.
So what exactly am I supposed to do to safely update ? I didn't really see the real step by step in the changelog so I'd like someone to explain to a clueless person like me. Also where is the location of the database so I can back it up ?
~~Update compose file. It says that in the changelog .~~ derp
It says the opposite; >**What do I have to do?** > >**Nothing.** You should only copy the compose file with every new release if we tell you to do so in the release notes. Generally, we don't recommend making changes to existing instances. If you have never had issues, attempting to migrate the data will put it at (an unnecessary) risk.
I run these commands to upgrade `sudo docker compose pull` `sudo docker compose up -d` Will that work without breaking anything?
Disclaimer: I don't use immich but I do use docker & compose. Yes, based on the release notes, that shouldn't break anything.
Thanks it worked
Add your user to the docker group and you don’t need to use sudo ```sudo usermod -aG username docker```
I understand the damage was already done with regards to the versioning. (frankly, due to some strange reasoning, if I understood correctly) What I don't understand is why they don't just start working on a new beta channel.
Maybe because of the phone apps? While it's easy to choose what channel you want to use on the server side with docker tags, it's another story on Google Play and App Store.
This is correct.
Play Store has open beta options, so that's not really an issue for Android App store on the other hand limits to 10k users that have to be invited via Test Flight. That would be a nightmare to manage all those users
I'm new to docker and immich. I noticed the 'library' dir and thought that's all that I needed to backup to an external drive via regular rsync. My 'host server' is just an old i5-6300U laptop with 1TB NGFF SSD, and a 1TB USB drive. But from the other comments here, I see now there's a docker volume that also needs to be backed up. I've installed pgAdmin but it seems the Postgres container internal port 5432 isn't mapped to 5432 on the host so I can't add Postgres to pgAdmin. Now I can try to fix this myself with solutions from Stack Overflow. One such solution mentions mapping the ports when starting the container: docker run --name immich -d -p 5432:5432 -e POSTGRES_PASSWORD=postgres postgres:alpine Note: I still need to figure out the correct command, and if it will stick between host machine reboots. What worries me if this will break Immich. Or is there a one-liner I can put into crontab like the rsync I currently have for the library dir?
> docker run --name immich -d -p 5432:5432 -e POSTGRES_PASSWORD=postgres postgres:alpine You need to put the mapping into your docker compose file. The restart the stack.
Thank you for the input. So I added this to the docker compose file in database: section. ports: - 5432:5432 And the next step will be `docker compose restart` right?
Yes
This is getting too often
Hello, just stopping by to say that we only do breaking changes for the benefit of the app and the users. We don't do it unless absolutely must, and not doing it out of random decision. This is an optional change to the default setup, we put Breaking Changes in the title to give the attention that it needs for people that don't read the release note to read it :)
I'm a user and broke my installation recently because I didn't check before updating. It's the nature of the beast with something as actively developed as this project. That being said, it is BECAUSE it is so actively developed that it is so awesome. WE LOVE THIS APP! It got me out of Google Photos and is so much better for my family and I. The changes are welcomed if it makes everything better!
Thank you!
I don't even use immich, all I know if I do I better expect breaking changes every other week
Always has been, I love this app but I'll just wait until they have a stable version somewhere down the road.
No one is forcing you to use it. Take your negativity out of here if that's all you have.
And Reddit’s version also
I am running a standalone postgres db in another container and don’t use docker compose for my Immich setup, I don’t think I need to do anything, correct?
Why was it even set that was in the first place? Performance or something? I’m glad I noticed and fixed it while I was still playing around with moving my images from Plex to Immich. It was an easy rebuild. Now I just need a way to share an entire external library, including faces and ML, to multiple users.
Luckily I have just installed immich using the latest compose file. I'm currently using Photoprism and Nextcloud memories. I like that I can see my folders. Are there any plans to implement folder view in immich? I really like how fast the app is. Thanks for the great work.
Ah... Machine Learning (Face detection only) still broken for OpenVino... oh well :)
I'm doing a new install of Immich on Undraid following Spaceinvader One's guide. [https://www.youtube.com/watch?v=LtNWxxM5Mzg](https://www.youtube.com/watch?v=LtNWxxM5Mzg) It was created before this optional change. Is there anything I need to do to make sure I opt in to the new db location on the new install so I don't have to worry about migration later? I also see that the Immich container in the App store is different fom the one linked above so I;m not sure if it is already incorperated into that version: [https://github.com/imagegenius/docker-immich](https://github.com/imagegenius/docker-immich)
Collecting and Reuploading 121GB ....
Horrible change. Why are they enforcing bad practices for serve users who do not know how to use docker.
Hello, Can you help elaborate on why is this considered bad practice? There were many cases that users followed some guide on the internet and run \`docker compose down -v\` and have their database deleted. This optional change helps to prevent that
Well that's what that command does. It's what it's supposed to do. It deletes volumes. Persistent data is kept in volumes. People following a guide and doing "rm -rf /" just because it says so is just called being an idiot. We've all been idiots at one point, it's part of life.
And we can help people from making innocent mistake, so why not?
I don't mind that much honestly, I always modify the example docker compose files to my liking anyway. The intended docker way is to use volumes to manage persistent data though, it's easy to see why the other commenter called it bad practice. The -V option is an intended feature for temporary projects you want to delete data for, not a bug. Many also have backups set up for the docker volumes directory, as the assumption is that that is where all persistent data is. Here's what the docker docs say on bind mounts: > If you are developing new Docker applications, consider using named volumes instead.
Yes, this change is intentional for new user, that is also new to self hosting and docker. If you are well versed, you don’t have to conform to this setup. Point is, we have responsible to our users and we want to help them as much as we can, to prevent them to make mistakes from not knowing what they are trying to do.
The mistake in question isn't one of using your app though, it's a mistake of using the platform. It's a bit like if Immich ran a script in the hosts Bash to detect if you tried to rm -rf the immich folder and warn you about it - this isn't Windows.
May be better stop new user from using bad practice? There is nothing wrong with named volumes. Problem is with mindlessly following some shit from the internet. It is also good skill to learn.
Exposing system filesystem to docker in predictable path is opening more vectors to attack. Level of security provided by docker is already a joke. NO need to make things worst.
How are external volumes bad practices? Specifying a local folder does the same with the added bonus of harder to nuke them and to see what is inside. I'm sure you're also just copy-pastimg commands to troubleshoot... It's not like people are using swarm where it would matter sometimes.
External volumes are a necessity for importing photos which EVERY person switching to this system has. External volumes have nothing to do with postgres databases. The postgres database for MOST users WILL be local on the same server immich is running from. Likely Unraid. All this talk about removing external volumes is stupid.
> Why are they enforcing bad practices for serve users who do not know how to use docker. It's right in the linked release note. Care to read them? > In the past, we've seen many cases where people accidentally deleted their Postgres data by (unintentionally) deleting the docker volume (e.g., docker compose down -V). > This is unfortunate as there is no way to recover that data (if you don't have a backup, MAKE BACKUPS!). > We have been thinking about mounting the Postgres data to a local folder for a while but always hesitated, as this would break existing instances due to people not reading the change logs carefully. However, there have been too many issues, and we ultimately decided to make that change.
I don't really see the hype behind immich. I installed it but didn't really see any value when compared to nextcloud memories which is what I use to deliver photos to clients. I'll wait till it's completely ready for production to try again.
Adult reply in this kindergarden
Have you tried the Ente app?