in-place: when the current database cluster is re-bootstrapped from the backup;
on a side cluster: when the backup of the source cluster (cluster1) is used to bootstrap a new cluster (cluster2) that is created on the same virtual infrastructure but is independent of the source cluster.
on an "external" cluster: when the backup of the source cluster (cluster1) is used to bootstrap a new cluster (cluster2) that is created in a different virtual environment. I can be made a stand-by cluster, replicating from the WALs generated by cluster1 and stored on a cloud bucket, or yet completely independent of it.
I would say a very important 4th scenario is that of deploying a single PostgreSQL server with a backup from the cluster. A use case for this would be for PITR to retrieve some data that has been modified. Creating an entire side cluster just for this would be overkill.
The section Restore the cluster from a previously saved backup of the Providing Backups manual page of the PostgreSQL operator can be improved to consider different scenario options:
in-place: when the current database cluster is re-bootstrapped from the backup;
on a side cluster: when the backup of the source cluster (cluster1) is used to bootstrap a new cluster (cluster2) that is created on the same virtual infrastructure but is independent of the source cluster.
on an "external" cluster: when the backup of the source cluster (cluster1) is used to bootstrap a new cluster (cluster2) that is created in a different virtual environment. I can be made a stand-by cluster, replicating from the WALs generated by cluster1 and stored on a cloud bucket, or yet completely independent of it.
I would say a very important 4th scenario is that of deploying a single PostgreSQL server with a backup from the cluster. A use case for this would be for PITR to retrieve some data that has been modified. Creating an entire side cluster just for this would be overkill.