When you request a Direct Backup, Central does a few things:
- Run
pg_dump. - Encrypt the result with an optional passphrase.
- Respond with (stream) the encrypted backup.
The error you describe arises from a Central limitation. When you request a Direct Backup, Central will wait a certain length of time for pg_dump to complete. After that, the request will time out. That length of time turns out to be about 23 minutes.
We could probably increase that length of time. However, if pg_dump isn't completing within 23 minutes, that probably means that the backup is fairly large. It may be better to seek an alternative rather than to attempt to transfer a backup of that size over the API.
In general, we recommend making a full system backup. Direct Backups back up the database, but a database backup by itself does not include sufficient information to re-establish the same Web Form links. See the documentation for more information.
With that caveat, another option is to run pg_dump on your own, not using the API server. Since the API server won't encrypt the result, you won't use Central to restore the backup. Instead, you would use Postgres tools to restore the backup (likely pg_restore). Central calls pg_dump with option -F d to output a directory-format archive, but you may find another format more convenient. Most Central installations won't have pg_dump available outside the Postgres container, but you could run pg_dump within the container. You could also install Postgres tools outside the container.
It's critical to have an ongoing backup strategy in place so that you're completing backups on a regular basis, not just once. In particular, you'll want to have a backup in place before upgrading to v2023.2. That version of Central (the latest) upgrades Postgres to version 14.