ZFS. Snapshot the entire filesystem, ship it off somewhere. Done. At worst, Postgres is slow to startup from the snapshot because it thinks it’s recovering from a crash.
Postgres is recovering from a crash if it's reading from a ZFS snapshot. It probably did have several of it's database writes succeed that it wasn't certain of, and others fail that it also wasn't certain of, and those might not have been "in order". That's why WAL files exist, and it needs to fully replay them.
Classic HN reply that’s very disconnected from reality. Most people don’t run ZFS, most people using these tools are using this to self host their apps as it’s cheaper than managed cloud server. Usually on a dedicated or VPS server where by default you run stock Ubuntu and no niche file system.
TrueNas needs to embody best practice for application backup and restore even though it runs ZFS.
As a side note, it's pretty interesting TrueNas is heavily designed around the ZFS paradigm. Most people think of applications and time stamps to restore not data pools and the snapshot paradigm accompanying ZFS.
With the right layer of abstraction on top of snapshots one could have the cake you need it to as it is difficult for beginners to grasp ZFS.
You are missing the point, nobody doubts it's possible but defaults matter and people just commission a new "Ubuntu" server on OVH, Hetzner, DO etc. and don't configure ZFS or snapshotting or even want to know what that is.
I didn’t say most people run it, I offered it as a solution. If you’re willing to run a server, you should be willing to try ZFS. As long as you follow some best practices, you’ll be fine.
