You've diagnosed this exactly right. That memory is Linux page cache from pgBackRest reading your data directory during the backup, not a Postgres leak. To be equally straight on the numbers: billed memory is the container's cgroup memory.current plus swap, sampled every 30 seconds, with nothing subtracted, so that cache does count until something evicts it.

One reassurance: it can't hurt the service. It's clean, reclaimable memory, and the kernel evicts it before anything else if your workload ever needs the RAM, so there's no OOM or performance risk from it sitting there.

The supported way to keep it from accumulating is a service memory limit. Your real usage is around 1 GB, so a limit of 4 GB gives plenty of headroom while creating just enough pressure for the kernel to reclaim the backup cache on its own instead of letting it sit at 6 GB until the next restart. Reclaim happens well before any OOM risk at that sizing. That keeps PITR exactly as it is, with no restarts and nothing to run after each backup.

Separately, I'm raising with the team that owns the Postgres image whether it should release that cache automatically at the end of each backup, since you're not the first to hit this. I'll follow up if that lands.

Railway Team