Why dump size lies
A 5 GB custom-format dump can be 40 GB of data (compression) and might carry hours of index rebuilds — CREATE INDEX runs at restore time, from scratch, for every index. Rule of thumb: data load scales with heap size; index rebuild often exceeds it on read-heavy schemas.
Speeding it up
pg_restore --jobs=8 --no-owner -d target db.dump
Parallel jobs help until you saturate I/O. On the target, temporarily raise maintenance_work_mem (index builds) and max_wal_size; consider --section=pre-data/data/post-data staging for surgical control. Restoring into an instance with more cores than production is legitimate — it's temporary.
Measure, don't estimate
The only trustworthy RTO number comes from restoring your actual current backup on hardware like your recovery target and timing it. Do it quarterly — data grows, RTO grows with it. Firedrill reports measured restore duration on every verification, so the number in your runbook updates itself and you see the trend as your database grows.