Pelo que entendi você está rodando o Postgres dentro dessa mesma máquina, mas sempre vi isso como um risco, pois a hospedagem pode querer mover sua VM para outro server, e para isso ela vai subir uma cópia da sua VM em outra instância e depois derrubar a instância atual.
Se algo estiver sendo gravado nesse período você pode perder dados. Por conta disso, vale considerar um serviço de banco de dados gerenciado como o Supabase, e S3 ou similar para object storage.
Bom ponto! Num live migration o provedor copia memória e disco e só troca no final, e o Postgres só confirma a transação depois de gravar no WAL. Então esse cenário específico não costuma perder dado confirmado.
O risco que eu considero maior é o disco ou a VPS em si: falha de hardware, corrupção, um rm errado. E aí você me pegou: hoje meu backup ainda fica na mesma máquina, e mandar para fora (S3 ou similar) é o próximo item da lista. Valeu por levantar isso.
Concordo que, para dado crítico de cliente pagando, um banco gerenciado (Supabase, Neon, RDS) ou ao menos backup com point-in-time recovery é o caminho. Para projetos pequenos, o custo de um banco gerenciado por projeto é justamente o que eu quis evitar. É um trade-off consciente.