←back to thread

Self-Hosting like it's 2025

(kiranet.org)
221 points finnlab | 3 comments | 01 Apr 25 10:11 UTC | HN request time: 0.71s | source
Show context
hankchinaski ◴[01 Apr 25 11:18 UTC] No.43545422[source]▶
The only thing that holds me back for self hosting is Postgres. Has anyone managed to get a rock solid Postgres setup self managed? Backups + tuning?
replies(8): >>43545468 #>>43545490 #>>43545510 #>>43545550 #>>43545777 #>>43545820 #>>43546275 #>>43547434 #
1. swizzler ◴[01 Apr 25 12:59 UTC] No.43546275[source]▶
I was using straight filesystem backups for a while, but I knew they could be inconsistent. Since then, I've setup https://github.com/prodrigestivill/docker-postgres-backup-lo..., which regularly dumps a snapshot to the filesystem, which regular filesystem backups can consume. The README has restore examples, too

I haven't needed to tune selfhosted databases. They do fine for low load on cheap hardware from 10 years ago.

replies(1): >>43547472 #
2. nijave ◴[01 Apr 25 14:50 UTC] No.43547472[source]▶
Inconsistent how? Postgres can recover from a crash or loss of power which is more-or-less the same as a filesystem snapshot
replies(1): >>43551781 #
3. pedantsamaritan ◴[01 Apr 25 22:00 UTC] No.43551781[source]▶
Getting my backup infrastructure to behave they way I'd want with filesystem snapshot (e.g. zfs or btrfs snapshot) was not trivial. (I think the hurdle was my particularity about the path prefix that was getting backed up.) write once pg_dumps could still have race conditions, but considerably fewer.

So, if you're using filesystem snapshots as source of backups for database, then I agree, you _should_ be good. the regular pgdumps is a workaround for other cases for me.