I dug into your Postgres service (the drill's source). The reason volumeInstancePITRRestore returns "couldn't reach the source service's pgBackRest catalog" is that the source isn't actually running pgBackRest / WAL archiving, there's no stanza or catalog for a restore to read from. Its logs over the last day show only normal checkpoints, with no archive-push / WAL-archiving activity at all.

PITR has to be enabled on the service first: that's what provisions pgBackRest, creates the stanza, takes a base backup, and begins continuously archiving WAL. Until that's running and a base backup has completed, a PITR restore has no catalog to restore from, which is exactly the error you're hitting. So the next step is to confirm PITR / continuous backups is enabled on this Postgres service (Settings → Backups). If it's off, enable it and let the first base backup complete, then the drill will work. If you believe it's already enabled, reply and I'll escalate to find why the stanza/archiving isn't running on your service. Your live production service and data are untouched by any of this. — Angelo

Thanks, that makes sense.

So my current setup has scheduled volume backups, but not PITR / continuous WAL archiving yet.

Before I enable PITR in Settings → Backups, can you confirm:

1. Will enabling PITR touch or modify the existing production data?
2. Will it restart or redeploy the Postgres service?
3. Is there expected downtime?
4. Is there additional cost beyond storage/backup usage?
5. After enabling it, how do I confirm that the first base backup and pgBackRest stanza are complete and ready for a restore drill?

Once PITR is enabled and the first base backup has completed, I will retry the non-destructive restore drill into a separate new Postgres service only.

Good questions, going through them. Existing data is not touched: enabling PITR provisions pgBackRest, creates the stanza, and starts archiving WAL alongside your data; it reads from the database and does not rewrite or restore over your volume. It does redeploy the Postgres service once to apply the new archive config, which is the only disruptive moment, just the normal short restart window rather than an extended outage (do it during low traffic if you want to minimize it). There is no separate PITR charge beyond the extra backup storage and usage the WAL archive and base backups consume. To confirm readiness, the first base backup runs automatically after you enable it; you are ready once Settings, Backups shows a completed base backup and a recovery window with an earliest restorable timestamp. Once that window is populated, retry volumeInstancePITRRestore with a target timestamp inside it, into a new separate service. If it still returns the catalog error after the base backup shows complete, reply here and I will escalate. Your plan to restore into a brand new service, leaving DATABASE_URL and the live volume alone, is the right approach. — Angelo