Lost data after DB/BabyBuddy container update

[andremsousa]

Hello guys,
Hope everything is fine!

I'm encountering some issues with BabyBuddy, that everytime there is an update on the DB container or on BabyBuddy all of my data gets errased.
No users, no babies, nothing tracked.
Like a fresh install.

If i go to the folders where i have the config files and DB all is there..
Do you know what is causing this issue?

(I'm using Postgres in order to use the grafana dashboard)
Had 0 issues with MySQL when i was testing.

Here is my docker-compose.yml:

babybuddy:
    image: lscr.io/linuxserver/babybuddy
    container_name: babybuddy
    environment:
      - DJANGO_SETTINGS_MODULE=babybuddy.settings.docker
      - SECRET_KEY="redacted"
      - TZ=Europe/Lisbon
      - CSRF_TRUSTED_ORIGINS=https://babybuddy.mydomain
      - SECURE_PROXY_SSL_HEADER=True
      - PGID=101
      - PUID=1026
      - ALLOWED_HOSTS=*
      - DB_ENGINE=django.db.backends.postgresql
      - DB_HOST=db
      - DB_NAME=babybuddy
      - DB_PASSWORD=redacted
      - DB_PORT=5432
      - DB_USER=babybuddy
    volumes:
      - ./babybuddy/config:/config
    ports:
      - 8300:8000
    restart: unless-stopped  
    depends_on:
      - db
    networks:
      - baby_network
    links:
      - db:db

  db:
    image: docker.io/library/postgres:13
    restart: unless-stopped
    container_name: db
    volumes:
      - ./babybuddy/db:/db-data:rw
    networks:
      - baby_network
    environment:
      POSTGRES_DB: babybuddy
      POSTGRES_USER: babybuddy
      POSTGRES_PASSWORD: redacted
      PG_DATA: /db-data

Thanks!

[cdubz]

Nothing jumps out at me as a potential cause here but also I'm not a big Docker user myself so not super familiar 😬

The only thing I notice is the PGID and PUID differ from the LSIO example. Is that intentional? I'm unclear on how that stuff works.

Also do you see anything in logs that points to missing or unreadable files?

[MrApplejuice]

I think, to this date the, general policy regarding databases in containers (like docker) is: do not do it for production!

The container isolation stuff can mess with database engines in some unexpected ways and the shutdown routines tend to not trigger as well as when they are installed directly on the OS. It is also a bit questionable to containerize a full production database engine which generally is quite heavy-weight and really benefits from filesystem-caching... could name a few more reasons.

Sqlite is not a very bad choice unless you have low-latency requirements. I do not know your exact requirements but if you insist on running on an full database engine I would run or install the database in a VM or baremetal and work with that instance. Or use a managed database solution if possible? That probably is even more hands-off!