How ImpulseDB Postgres backups work

Backups ship on by default for every database. Dedicated-plan customers can add offsite copies to a bucket they own. This article covers what runs out of the box, what customers can add, what they see, and what to look at when something goes wrong.

What runs by default

Every active database is backed up each time the hourly usage task runs on ImpulseCore's cron runner. Each backup is a gzipped pg_dump (custom format), taken through the server's Admin Proxy and stored on the database server:

/var/backups/impulsepostgres/<service_id>/<db_name>_<YYYY-MM-DD_HHMMSS>.sql.gz

Retention is per plan (Backup Retention, in days). The same task deletes expired backups: the backup record, the file, and any offsite copy. Backups run hourly whatever the Backup Schedule setting says.

These are logical dumps. There is no continuous WAL archiving, so point-in-time recovery isn't available: a restore returns the database to the moment a backup was taken.

Local backups live on the database server. If the server is lost and the customer hasn't connected an offsite destination, the backups go with it. Treat them as quick-restore copies, not a disaster recovery plan on their own.

Offsite copies (dedicated plans)

On dedicated plans, customers can connect an Offsite Backup Destination from the Backups & Migration tab of their service. After every backup, WHMCS downloads the dump through the Admin Proxy and uploads it to the customer's bucket.

1. In the client area, open the database service → Backups & Migration → Offsite Backup Destination.
2. Choose Use Custom S3-Compatible Storage and pick a provider preset: S3-compatible, Amazon S3, Backblaze B2, Wasabi, or Cloudflare R2.
3. Fill in the endpoint, bucket, optional prefix, access key and secret, and choose whether to Keep local copies on the database server.
4. Click Test & Connect. A test upload runs before the destination is saved.

If you also run ImpulseObjects on the same WHMCS, a customer who has an object-storage service can pick one of their own ImpulseObjects buckets instead, with no keys to copy by hand.

Offsite destinations are set per service by the customer and point at their own bucket. There is no install-wide backup target.

What the customer sees

The Backups & Migration tab shows the backup retention, a Backup Now button for an on-demand backup, the offsite destination (dedicated plans), the list of available backups with Download and Restore, a restore history, and Export & Import tools.

Restore kills active connections and replaces the database with the chosen backup, after the customer types the database name to confirm. Only backups that still have a local copy can be restored or downloaded there; an Offsite only backup has to be fetched from the bucket. There is no admin-side restore button.

What the operator sees

Problems are emailed to you, controlled under Settings → Quotas & Limits → Admin Notifications: Usage cron errors when a run of the hourly task (backups included) finished with errors, and Backup failure when an offsite upload failed. Offsite failures are also written to the WHMCS Activity Log. The Dashboard's Backups tile counts the backups currently held.

Common failure modes

• Disk fills on the database server. Backups fail when there's no room for the dump. Shorten the plan's retention, or have dedicated customers turn off Keep local copies once an offsite destination is working.
• Offsite credentials revoked or bucket full. The upload fails and you get a Backup failure email. The customer updates the destination and runs Test & Connect again.
• Admin Proxy unreachable. No backup is taken for that server until the proxy is reachable again; the hourly task reports the error.

Related

• Security & Maintenance for ImpulseDB Postgres
• Backups deep dive