3 ms·

What’s the issue with running Postgres inside a docker container + regular backups? Never had problem and relatively easy to manage.

matt-p 1y ago
no PITB, but mostly just 'it's hassle' for the application server I literally don't need backups, just automated provisioning/docker container etc. Adding postgres then means I need full backups including PITB because I don't even want to lose an hours data.
- ozozozd 1y ago
  Or use SQLite and your backups are literally a copy of a file. You can abuse git for it if you really want to cut corners.
  - vanviegen 1y ago
    Only if you can freeze your application for that long, in which case your statement is true for all non-broken databases.
    - wild_egg 1y ago
      It only freezes your application if you've misconfigured it.
      - vanviegen 1y ago
        If you want to backup your database using just a file copy, you'd better freeze your database if you value your data. Or use a fancy snapshotting filesystem.
    - markusw 1y ago
      You can easily do consistent backup on live databases. There’s a backup command and API.
      - vanviegen 1y ago
        Sure. But then it's not "just a file" copy, like GP said.
Biganon 1y ago
Why use a docker container? I run Postgres as is, what would I gain with running it in a container?
- Nextgrid 1y ago
  It makes the whole thing is configured in a docker-compose file (or your raw Docker CLI invocation) + the data volume. So as long as you have those two things you can replicate it and move it to other hosts regardless of their distro. Compare that with using your distro's packaged version where you can have version variations, variations in default config or file path locations, etc.
- aflukasz 1y ago
  You can decouple Postgres and surrounding userspace upgrade cycles from your host os, if this is something that you want. Or run multiple different PG versions (have independent upgrades schedule) without being tied to the host os specific mechanisms for that.

matt-p 1y ago

no PITB, but mostly just 'it's hassle' for the application server I literally don't need backups, just automated provisioning/docker container etc. Adding postgres then means I need full backups including PITB because I don't even want to lose an hours data.

ozozozd 1y ago
Or use SQLite and your backups are literally a copy of a file. You can abuse git for it if you really want to cut corners.
- vanviegen 1y ago
  Only if you can freeze your application for that long, in which case your statement is true for all non-broken databases.
  - wild_egg 1y ago
    It only freezes your application if you've misconfigured it.
    - vanviegen 1y ago
      If you want to backup your database using just a file copy, you'd better freeze your database if you value your data. Or use a fancy snapshotting filesystem.
  - markusw 1y ago
    You can easily do consistent backup on live databases. There’s a backup command and API.
    - vanviegen 1y ago
      Sure. But then it's not "just a file" copy, like GP said.

Biganon 1y ago

Why use a docker container? I run Postgres as is, what would I gain with running it in a container?

Nextgrid 1y ago
It makes the whole thing is configured in a docker-compose file (or your raw Docker CLI invocation) + the data volume. So as long as you have those two things you can replicate it and move it to other hosts regardless of their distro. Compare that with using your distro's packaged version where you can have version variations, variations in default config or file path locations, etc.
aflukasz 1y ago
You can decouple Postgres and surrounding userspace upgrade cycles from your host os, if this is something that you want. Or run multiple different PG versions (have independent upgrades schedule) without being tied to the host os specific mechanisms for that.