Exactly this, my docker host has a folder for docker data. In there are sub folders for each docker app. Borg back grabs the entire docker data folder and backs it up.
If there are any issues, I can easily see all the files.
I have no idea how people trust things like docker volumes with valuable data without the ability to just see into the filesystem easily.
Who the hell is pulling the docker-compise.yml automatically every release?
I find myself already crazy by pulling the latest release but the compose file is just a disaster waiting to happen.
Then again it seems like people were using a docker volume to save all their precious photos rather than a mount point on the host. Also seems insane to me.
ArcticDagger@feddit.dk
on 21 Apr 07:21
nextcollapse
Could you explain a bit more about why it’s insane to have it as a docked volume instead of a mount point on the host? I’m not too well-versed with docker (or maybe hosting in general)
A normal file system is something anything can access. You can open it in file browser. You can get to it via command line. You can ssh into from another computer and you can easily back it up with numerous tried and tested backup methods.
Why lock yourself into only being able to access your data via docker?
In a disaster scenario when you are trying to recover files, you will greatly appreciate being able to just see all the files super easily without anything fancy. It also means you can use any standard method to back up all those file.
Recovery is also almost as easy, copy the files back to where they were and just run the docker container.
I really wish they get to the point where we can expect long term with no breaking changes. I love it but I have been burnt twice, which is not a lot, but it was very annoying both times
timbuck2themoon@sh.itjust.works
on 20 Apr 22:20
collapse
It’s only made worse that they are now so tied to whatever versioning they’re using instead of semver.
First time im not completely sure how to proceed with update. This part is unclear to me:
Unfortunately there isn’t a “proper” way to export a docker volume.
The recommended method is to mount the volume and the directory (you want to copy your data to) to an arbitrary container, get a shell inside that container and copy the folder manually.
I know how to stop the container and dump db, but need some help here
Pretty simple to switch (if you have a little docker experience). Create a folder (e.g. ./postgres), add the folder as a volume in the postgres portion of the compose file (maybe something like /db), then run just the database with newly mounted folder, shell in, and copy everything from the Postgres folder to this new folder. After that, swap mounts so the new folder is used as Postgres db and you’re good. If something went wrong, the pgdata volume is still there to switch back to.
pe1uca@lemmy.pe1uca.dev
on 20 Apr 18:48
nextcollapse
Just did the upgrade. Only went and copied the docker folder for the volume.
Inside that folder were all the DB files, so I just copied that into the new folder I created for ./postgres
I thought there would be issues with the file permissions, but not, everything went smoothly and I can’t see any data loss.
(This even was a migration from 1.94 to 1.102, so I also did the pgvecto-rs upgrade)
ReallyActuallyFrankenstein@lemmynsfw.com
on 20 Apr 19:04
nextcollapse
What does it mean that it’s “opt-in”? Meaning, my opt-out is just to never update Immich again?
So the way I read it, if you want to opt in, you make the new changes they state in your yml. I didn’t and just hit upgrade to pull the new images and it worked fine. I don’t see any issues, but I’ll be glad if someone says I did it wrong.
I think it’s only breaking if you pull the new yml and don’t move your data.
Who was pulling the dicker compose and just straight up running the GitHub version on their server. That seems crazy. Even pulling :latest tag seems crazy to me but this is another level.
This change is only breaking if you are running someone else’s docker compose on your server without looking at it.
Also who was running their entire photo album in a docker volume rather than a mount point on the host. Another insane decision. To be fair, the default docker compose never should have had that. It should have been a mount point right from the start.
Mainly because of the number of things I have that I rely on every day and definitely don’t want to break until I’m ready to upgrade it and have time to fix it if it does break.
I know many do use :latest but having a service break while I’m away or travelling really sucks
CriticalMiss@lemmy.world
on 21 Apr 12:37
nextcollapse
Only I rely on my services and if they break I’ll fix them myself.
It’s not unusual for an update to have breaking changes that require some manual intervention to fix.
If you are on latest, it can also be hard to know which version you used to be on if you want to roll back.
For important things, I used specific version tags and then check the release notes before upgrading.
MangoPenguin@lemmy.blahaj.zone
on 22 Apr 03:29
collapse
Who is out there running compose down -v when they want to keep their data lol
Not a fan of this change, using volumes is what makes docker truly portable between systems. It’s not the responsibility of Immich if people are running the wrong commands when managing their system.
threaded - newest
I mounted that volume the first time I opened immich’s compose file, glad they changed it =)
Me too!
lol same I like to know exactly where the data is
I’m not using immich in docker. Can you explain what this breaking is there to fix?
The datbase files were saved in an internal docker directory and the breaking change is that the location is now different, outside of docker.
Exactly this, my docker host has a folder for docker data. In there are sub folders for each docker app. Borg back grabs the entire docker data folder and backs it up.
If there are any issues, I can easily see all the files.
I have no idea how people trust things like docker volumes with valuable data without the ability to just see into the filesystem easily.
Who the hell is pulling the docker-compise.yml automatically every release? I find myself already crazy by pulling the latest release but the compose file is just a disaster waiting to happen.
Especially since the original doesn’t care about selinux and it would overwrite everything.
And it doesn’t specify a repository which breaks auto updates of podman
I honestly never once thought to do this. Ever. No likey.
Complete insanity.
Then again it seems like people were using a docker volume to save all their precious photos rather than a mount point on the host. Also seems insane to me.
Could you explain a bit more about why it’s insane to have it as a docked volume instead of a mount point on the host? I’m not too well-versed with docker (or maybe hosting in general)
Edit: typo
A normal file system is something anything can access. You can open it in file browser. You can get to it via command line. You can ssh into from another computer and you can easily back it up with numerous tried and tested backup methods.
Why lock yourself into only being able to access your data via docker?
In a disaster scenario when you are trying to recover files, you will greatly appreciate being able to just see all the files super easily without anything fancy. It also means you can use any standard method to back up all those file.
Recovery is also almost as easy, copy the files back to where they were and just run the docker container.
Thank you, those are some good points!
What’s the difference? The docker volume, on my setup anyway, is in /mnt/md0/docker-data/immich_upload/_data/
It’s still a directory on the host either way? Although I guess if it’s a mount point it won’t get removed when removing volumes in docker.
That last point is the important one. For important data, I want the setup to be as easily accessible and system agnostic as possible.
Didn’t know it, so from readme: Immich, a high performance self-hosted photo and video management solution.
I was surprised to see the default compose file not force the user to specify an external directory for the database.
I really wish they get to the point where we can expect long term with no breaking changes. I love it but I have been burnt twice, which is not a lot, but it was very annoying both times
It’s only made worse that they are now so tied to whatever versioning they’re using instead of semver.
First time im not completely sure how to proceed with update. This part is unclear to me:
I know how to stop the container and dump db, but need some help here
lemmy.ca/comment/8719773
Thx ill give it a try
Just go to /var/lib/docker/volumes and copy the data out of the relevant volume. No need to mount anything.
I went about it this way as well, was much easier this way.
Pretty simple to switch (if you have a little docker experience). Create a folder (e.g.
./postgres), add the folder as a volume in the postgres portion of the compose file (maybe something like/db), then run just the database with newly mounted folder, shell in, and copy everything from the Postgres folder to this new folder. After that, swap mounts so the new folder is used as Postgres db and you’re good. If something went wrong, thepgdatavolume is still there to switch back to.Just did the upgrade. Only went and copied the docker folder for the volume.
Inside that folder were all the DB files, so I just copied that into the new folder I created for
./postgresI thought there would be issues with the file permissions, but not, everything went smoothly and I can’t see any data loss.
(This even was a migration from 1.94 to 1.102, so I also did the pgvecto-rs upgrade)
What does it mean that it’s “opt-in”? Meaning, my opt-out is just to never update Immich again?
So the way I read it, if you want to opt in, you make the new changes they state in your yml. I didn’t and just hit upgrade to pull the new images and it worked fine. I don’t see any issues, but I’ll be glad if someone says I did it wrong.
I think it’s only breaking if you pull the new yml and don’t move your data.
You don’t have to change the database location.
Me, an intellectual, who was already mounting the database data folder to the host filesystem.
.
Who was pulling the dicker compose and just straight up running the GitHub version on their server. That seems crazy. Even pulling :latest tag seems crazy to me but this is another level.
This change is only breaking if you are running someone else’s docker compose on your server without looking at it.
Also who was running their entire photo album in a docker volume rather than a mount point on the host. Another insane decision. To be fair, the default docker compose never should have had that. It should have been a mount point right from the start.
I don’t run Immich specifically but all other software I run is on :latest tags and unattended-upgrades on Debian. It works so, why bother?
Mainly because of the number of things I have that I rely on every day and definitely don’t want to break until I’m ready to upgrade it and have time to fix it if it does break.
I know many do use :latest but having a service break while I’m away or travelling really sucks
Only I rely on my services and if they break I’ll fix them myself.
Ok…so it should be easy to understand why for many people :latest is not a good idea
Why would using latest randomly break your containers?
It’s not unusual for an update to have breaking changes that require some manual intervention to fix.
If you are on latest, it can also be hard to know which version you used to be on if you want to roll back.
For important things, I used specific version tags and then check the release notes before upgrading.
Who is out there running
compose down -vwhen they want to keep their data lolNot a fan of this change, using volumes is what makes docker truly portable between systems. It’s not the responsibility of Immich if people are running the wrong commands when managing their system.