Closed prometheanfire closed 4 months ago
For the compose setup, using a container like that is a reasonable approach to backups. In my opinion, on a kubernetes cluster, the much better option is to use a real postgres operator that handles everything including backups for you.
This chart seems to assume that it deploys it's own DB. If using an operator is expected then I think disabling the self deployed DB by default would make sense. An operator would need support the pgvecto-rs stuff as well.
That isn't assumed. From the readme:
You need to make sure that Immich has access to a redis, and postgresql instance. You can do this either by enabling them directly in the values.yaml, or by manually setting the entries under the env key to point to existing instances.
The included postgres is in fact disabled by default.
If you want an operator example, here's my personal postgres deployment using cloudnative-pg: https://github.com/bo0tzz/kube/blob/main/database/app-db.yaml
Technically you can use the backup
in the Bitnami chart that can be enabled:
postgresql:
enabled: true
backup:
enabled: true
cronjob:
storage:
storageClass: "<something-external>"
However, it does not work straight away because Immich uses the postgresql user "immich" and the backup cronjob uses the user "postgres" which does not have password access. There must be someway of either
There is a "customUser" variable in the cronJob template of Bitnami's chart, but I just created a cronJob manually that used the correct credentials and went to put up some shelves instead.
I wasn't aware the bitnami chart includes that, neat. With that I'll close this request.
The official docs reference using a container for DB backups. It'd be nice if that were supported as an optional additional container to deploy for this app.
https://immich.app/docs/administration/backup-and-restore/
Filesystem wise I imagine would depend on the backing store/driver in use for the cluster.