The best answer I know of to this question is Litestream - https://litestream.io/ - you can use it to inexpensively replicate a backup of your database up to an S3 bucket (or various other storage providers) to give you a very solid robust recovery option should you lose the disk that your SQLite database lives on.

The big question here would be whether the filesystem that the data file resides on is mounted on a single-disk volume or a RAID-volume (or even a clustered SDS volume such as Ceph). On a single-disk volume, if the disk dies your DB is gone (at least until you can replace the disk and restore the backup). On a sensibly designed RAID-volume, if one of the disks dies the application's admin probably would never even know. The sysadmin would see it in their logging/alerting infrastructure and replace the dead disk. There would not be any loss of data or availability of the data (just a temporary degradation in the overall resiliency). Same is true for a clustered SDS volume such as Ceph.

Postgresql stores data to disk, so it has the same risk of loss. Both setups need a backup solution to mitigate the problem of disk failure.

My understanding of the situation is sqlite's solution is a bit more low level than postgresql but should be workable.

Not a dumb question, but some people don’t care for their use case (either the data is cheap, or they don’t think it will happen)

These days, you could replicate it to something like S3 via something like Lifestream.