Two servers can go down together. They might use the same storage array, depend on the same switch, or accept the same bad deployment. Counting replicas tells you little about how a service will recover.
Start with a specific failure: the database host stops responding, an administrator deletes a volume, or the building loses power. Work through what happens to the application, who gets called, and where the recovery procedure lives.
Agree on what the business can lose
Recovery time objective (RTO) is the target time to restore service. Recovery point objective (RPO) describes how far back you can afford to go in the data. Set both for each service before choosing the architecture.
For example, suppose an internal reporting tool can be unavailable until the next morning and its inputs can be imported again. Restoring it from backup may be adequate. An order system with a much shorter recovery target needs a different design. Those are example requirements; the people who use the systems need to set the actual limits.
Include dependencies in the timing. A restored application that cannot reach its identity provider is still unavailable to its users.
Check what your redundant components share
Put the hosts, storage, switches, power supplies, DNS, and identity services on one diagram. Mark the components that share a failure domain: anything that could disappear in the same incident.
A second power supply helps only if it has a working power source when the first loses power. A second application instance helps only if the remaining infrastructure can carry the load. Test that reduced capacity under realistic traffic.
Replicas also copy mistakes. If a valid command deletes records, replication can spread the deletion. Keep recovery copies with appropriate retention and access controls, and check that the credentials used to administer production cannot also destroy every backup.
Separate replication from failover
PostgreSQL streaming replication keeps a standby updated; it does not, by itself, detect a failed primary and arrange automatic failover. The PostgreSQL failover documentation describes the additional coordination required, including preventing the old primary from returning as a competing writer.
For your chosen database setup, document who or what promotes a standby, how clients find it, and how the old primary is isolated. Measure the result. An aggressive timeout can turn a short network interruption into an unnecessary failover.
A second site adds another decision. Waiting for a remote write can increase transaction latency. Replicating asynchronously can leave recent writes behind if the primary site is lost. Choose against the agreed recovery targets and measure replication lag during busy periods.
Restore a service and use it
Choose one application for a recovery exercise. Restore it into an isolated environment using the written procedure. Have someone other than its usual operator follow the steps.
Record how long it takes to obtain credentials, retrieve the backup, restore the data, start the application, and complete a normal user task. Check the age of the recovered data. Test login, a read, a write, and any essential integrations.
Then update the procedure with what was missing. That might be a key stored in the failed environment, a DNS change nobody owns, or a restore that takes longer than the target allows. Resolve those gaps before adding more infrastructure. If the fix involves moving the workload, include the same exercise in the migration plan.