this post was submitted on 14 Jun 2026
44 points (97.8% liked)

Selfhosted

60177 readers
579 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:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

Resources:

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

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

Hello,

As the title suggests, how do you manage your DBs for docker services.

Do you spin a new DB for every new docker cluster or do you have a centralized DB that is accessible to the docker clusters.

What are the pros and cons of both method?

For the moment, I spin a new DB for every services as I feel it is easier to backup the service in case of a problem.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] Mertn33@lemmy.world 1 points 1 week ago (1 children)

The last thing I want is database corruption. That is why I "docker compose down" before I make a backup then "docker compose up" when the backup is complete. Is that not good enough? Do I have to do something else?

[โ€“] Zikeji@programming.dev 1 points 1 week ago* (last edited 1 week ago)

Yes that's good enough! Sorry I missed your statement about shutting down first. To clarify I leave mine running since a dump can recover if it gets corrupt.

Basically my backup contains the database and the SQL dump (or equivalent) - that way I don't need to shutdown the service.