How ImpulseDB Postgres backups work

Backups are layered. The base layer ships on by default; everything more durable is operator opt-in per server or per plan. This article covers what's on out of the box, what you can add, what customers see, and what to look at when something goes wrong.

Layer 1: nightly logical dumps (default)

Every Postgres server runs a nightly pg_dump per database. Files land on the host under:

/var/backups/postgres/{db_name}_{YYYYMMDD}.sql.gz

The 02:00 daily cron — impulsepostgres_usage.php — triggers the dumps in addition to its usage rollup. Retention is per-plan with a 7-day default; a daily prune enforces it.

Backup status, last-run timestamps, and sizes appear per server under Servers → (server) → Backups.

This layer is local-only. If the VPS dies and you've enabled nothing else, the dumps die with it. Treat it as a convenience for quick restores, not a disaster recovery plan.

Layer 2: WAL-G to S3 (operator opt-in)

For point-in-time recovery and offsite durability, enable WAL-G per server. WAL-G performs continuous WAL streaming plus nightly base backups to any S3-compatible target — AWS S3, Backblaze B2, Wasabi, Cloudflare R2, ImpulseMinio, or a standalone MinIO.

To configure:

1. Open Settings → Backups.

2. Tick Enable WAL-G.

3. Pick the target type (s3, minio, b2) and fill endpoint, bucket, access key, and secret.

4. Save.

Newly-provisioned servers install WAL-G automatically during cloud-init. Existing servers get a Reconfigure backups button on the server detail page that re-runs the WAL-G install over SSH. Each server detail page also gets a Backup Now button to trigger an immediate base backup.

Restore is a console operation today, not a UI button — destructive enough that the module wants it explicit:

# SSH into the server, then: wal-g backup-list # list base backups wal-g backup-fetch /var/lib/postgresql/16/main LATEST # or by name: wal-g backup-fetch /var/lib/postgresql/16/main base_000000010000000000000007

Then start Postgres and let it replay WAL to the target restore point.

Layer 3: ImpulseMinio offsite mirroring (one-click)

If you also run the ImpulseMinio module on the same WHMCS instance, you can mirror nightly dumps to an ImpulseMinio region without configuring WAL-G credentials by hand:

1. Open Settings → Backups.

2. Tick Enable ImpulseMinio offsite backups.

3. Pick a backup region. For DR, pick a region different from your Postgres servers'.

4. Set the bucket name (or accept the default) and click Create Bucket if it doesn't exist.

5. Optionally untick Keep local copy to delete local dumps after a successful upload.

This integration reads region credentials from mod_impulseminio_regions and routes through the ImpulseMinio admin proxy. It cannot be pointed at raw AWS S3, Backblaze B2, Wasabi, or a standalone MinIO — for those, use the WAL-G path above.

What the customer sees

The Customer Backups card on the client-area service page shows: most recent backup timestamp, size, target (local / wal-g / impulseminio), and a Download Latest Dump button when local copies are kept. Customers can also trigger an on-demand backup from the same card, capped at one per hour by default to prevent overuse on shared infrastructure.

What the operator sees in the audit log

Every backup-related event lands in ImpulseCore's audit log under the impulsepostgres source. Useful filters when investigating:

• backup.local.success / backup.local.failed — nightly dumps.

• backup.walg.install / backup.walg.config_changed — WAL-G install or credential changes.

• backup.walg.success / backup.walg.failed — base backup runs.

• backup.impulseminio.success / backup.impulseminio.failed — offsite mirror runs.

Common failure modes

• Provider credentials revoked. A token rotation at the provider that doesn't propagate into the addon kills both backup uploads and snapshot+restore on patches. Rotate, paste, and click Test Connection.

• Bucket out of quota. WAL-G or ImpulseMinio uploads fail with a quota error from the target. Increase the bucket quota or shorten retention.

• Network outage between Postgres host and S3 target. WAL streaming pauses and resumes when the network returns. If the outage exceeds your wal_keep_size budget, you lose continuous recovery for that gap; the next base backup re-establishes the new baseline.

• Disk fills on the Postgres host. Local dumps fail with ENOSPC. The retention prune is the usual fix; tighten the per-plan retention or untick "Keep local copy" if WAL-G or ImpulseMinio is uploading the same data.

Not every plan enables backups by default

Backups beyond the local nightly dump are operator opt-in per server. WAL-G and ImpulseMinio offsite mirroring don't auto-enable on every plan — decide which tier of plans warrants which layer and opt in deliberately.

Related

• Security & Maintenance for ImpulseDB Postgres

• Backups deep dive