Physical base backup vs logical dump for 4‑hour RTO on 500 GB Rails/PostgreSQL

Goal

Select a restoration strategy that meets a 4‑hour RTO for a 500 GB PostgreSQL database plus 200 GB of ActiveStorage attachments in a Rails 7.x application.

Constraints & uncertainty

• Physical base backup (pg_basebackup + PITR) restores the data directory in ~45 minutes but demands identical PostgreSQL major version, OS architecture, and pg_control compatibility, ruling out heterogeneous disaster‑recovery targets.
• Logical dump (pg_dump/pg_restore) allows selective table restore and in‑place version upgrades, yet parallel restore plateaus at ~8 cores due to catalog lock contention, yielding 6‑8 hours for the full dataset.
• ActiveStorage blobs stored on S3/GCS survive both methods unchanged; local‑disk attachments need a separate rsync/snapshot step that neither backup captures.
• Post‑restore verification: physical restore inherits page checksums (if data_checksums=on), while logical restore requires application‑level checks (constraint validation, row‑count audits). Rails lacks a built‑in way to verify ActiveStorage blob checksums after a physical restore without iterating every blob (O(n) API calls).

Which approach minimizes total RTO while guaranteeing blob integrity? Can a sidecar manifest be integrated without custom tooling? What verification steps are mandatory for each method?