Selfhosted

39435 readers

1 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago

MODERATORS

[email protected]

Immich help, please -- Am I boned now? (lemm.ee)

submitted 6 months ago* (last edited 6 months ago) by [email protected] to c/[email protected]

14 comments fedilink hide all child comments

Ohboy. Tonight I:

installed a cool docker monitoring app called dockge
started moving docker compose files from random other folders into one centralized place (/opt/dockers if that matters)
got to immich, brought the container down
moved the docker-compose.yml into my new folder
docker compose up -d
saw errors saying it didn't have a DB name to work with, so it created a new database

panik

docker compose down
copy old .env file from the old directory into the new folder!
hold breath
docker compose up -d

Welcome to Immich! Let's get started...

Awwwwww, crud.

Anything I can do at this point?

No immich DB backup but I do have the images themselves.

EDIT: Thanks to u/atzanteol I figured out that changing the folder name caused this too. I changed the docker folder's name back to the original name and got my DB back! yay

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 4 points 6 months ago* (last edited 6 months ago) (1 children)

Glad you sorted it!

It's very unexpected behavior for docker compose IMHO. When you say the volume is named "foo" it creates a volume named "directory_foo". Same with all the container names.

You do have some control over that by setting a project name. So you could re-use your old volumes with the new directory name.

Or if you want to migrate from an old volume to a new one you can create a container with both volumes mounted and copy your data over by doing something like this:

docker run -it --rm -v old_volume:/old:ro -v new_volume:/new ubuntu:latest 
$ apt update && apt install -y rsync
$ rsync -rav --progress --delete /old/ /new/ # be *very* sure to have the order of these two correct!
$ exit

For the most part applications won't "delete and re-create" a data source if it finds one. The logic is "did I find a DB, if so then use it, else create a fresh one."

[–] [email protected] 1 points 6 months ago (1 children)

This is one of the reasons I never use docker volumes. I bind mount a local folder from the host or mount and NFS share from somewhere else. Has been much more reliable because the exact location of the storage is defined clearly in the compose file.

Borg backup is set to backup the parent folder of all the docker storage folders so when I add a new one the backup solution just picks it up automatically at the next hourly run.

[–] [email protected] 1 points 6 months ago

I have a similar distrust of volumes. I've been warming up to them lately but I still like the simple transparency of bind mounts. It's also very easy to backup a bind mount since it's just sitting there on the FS.