/var/backup/postgresql is not on persistent data #259

New Issue

JakeHillion · 2024-05-11T10:46:25+01:00

JakeHillion commented

2024-05-11 10:46:25 +01:00

This is the intermediate store before getting backed up with restic. I don't think having this on tmpfs creates any correctness issues because the real data is on the remote, but it does use ~7GiB of valuable tmpfs space that will only grow over time.

Perhaps it makes sense to put some explicit directories in a non-tmpfs root that gets set back to zero? We could add a subvolume like /data/current-boot that gets reset to an empty snapshot each boot but otherwise stores data on the SSD, as an extension to the tmpfs. This would feel nicer than replacing the tmpfs with an empty snapshot while bringing the benefits of larger space for specific files/directories. It would be a particular improvement if these sql dumps were on a compressed filesystem, though tmpfs+zram swap does poorly emulate this.

This is the intermediate store before getting backed up with `restic`. I don't think having this on `tmpfs` creates any correctness issues because the real data is on the remote, but it does use ~7GiB of valuable `tmpfs` space that will only grow over time. Perhaps it makes sense to put some explicit directories in a non-tmpfs root that gets set back to zero? We could add a subvolume like `/data/current-boot` that gets reset to an empty snapshot each boot but otherwise stores data on the SSD, as an extension to the `tmpfs`. This would feel nicer than replacing the `tmpfs` with an empty snapshot while bringing the benefits of larger space for specific files/directories. It would be a particular improvement if these sql dumps were on a compressed filesystem, though tmpfs+zram swap does poorly emulate this.

JakeHillion added the

bug

label 2024-05-11 10:46:25 +01:00

JakeHillion referenced a pull request that will close this issue

2024-08-09 23:47:45 +01:00

boron: move postgresqlBackup to disk to reduce ram pressure #305

JakeHillion closed this issue

2024-08-09 23:48:57 +01:00

Sign in to join this conversation.