I can highly recommend running MongoDB on XFS on ZFS (best of both worlds; there are some downsides to running MongoDB directly on ZFS…), using ZFS zvol snapshots for backups. It's super effective. For details, see: https://serverfault.com/questions/583688/mongodb-and-zfs-bad-performance-disk-always-busy-with-reads-while-doing-only-wr and https://www.percona.com/blog/2019/04/29/zfs-for-mongodb-backups/

Interesting point, touching on Postgres. I have, historically, successfully deployed Postgres DB clusters without any permanent primary storage: the entire thing would run on an ephemeral AWS VM (reboot = reset to stock) w/ automatic RAID of the two local bulk partitions (dom0 local storage). The WAL was archived to S3 every minute (once a week snapshots) and the VM, on startup, would identify if it was alone. If so, restore from that snapshot and apply the per-minute logs until caught up, if not, recover from another node then join. If alone, after recovery, spin up sibling nodes. RPO (recovery point objective) of one minute. Recovery time objective/RTO of ~10 minutes to spin up an entirely new cluster. On the MongoDB side, I can highly recommend running a local replica as a backup mechanism, and additionally replicating a delayed replica from that local live copy. This combines disaster recovery (latest live data) and the ability to recover from user error (e.g. user deletes everything), and, you could always actually utilize the in-office database to service the application from the office (vs. hosting provider) during recovery.