Base backup & schedule

A base backup is a byte-for-byte copy of the entire Postgres data directory via pg_basebackup. Unlike pg_dump (logical), it works at the file level: less CPU at creation time, needed for point-in-time recovery (PITR).

When you need it

PITR — restoring the DB to any moment between backups (needs base backup + WAL archive)
Streaming replication setup — bootstrapping a new replica
Big databases — where pg_dump is too slow

On managed Postgres (Supabase, Neon, RDS, Yandex), the provider handles base backups on schedule. Available via their UI / API. ide99 isn't needed there.

Mostly relevant for self-hosted Postgres.

Open

+ New tab → Backup Center → Base Backup.

Requirements

The pg_basebackup utility on the ide99 machine (same one as pg_dump)
Postgres set up for replication: in postgresql.conf wal_level = replica, in pg_hba.conf replication access for the user

An account with the REPLICATION privilege:

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'secret';

ide99 verifies these on first launch and tells you what's missing.

Form

Source connection — connection to back up
Replication user — usually a separate user with REPLICATION (you can use the same as the connection user if that user has the rights)
Output directory — where to put files
Format:
- Plain — directory as is, can be launched as a new DB straight away
- Tar — packaged into a .tar per tablespace
Compress:
- None / gzip / lz4 / zstd
WAL handling:
- Stream ✓ (default) — WAL streams in parallel with the backup; backup is self-contained
- Fetch — WAL is fetched at the end; faster, but if WAL turnover is high — may lose data
- None — don't include WAL (need a separate archive)
Slot: replication slot name if you want to use one (recommended for guaranteed WAL availability)

ide99 shows the command:

pg_basebackup \
  -h db.example.com -p 5432 -U replicator \
  -D /backups/2026-05-22 \
  -F plain -X stream -P -v \
  --slot=basebackup_slot \
  -Z zstd

The Start backup button runs it. Progress is also visible in Live Ops (pg_stat_progress_basebackup).

Restore

Restoring a base backup means replacing the entire Postgres data directory:

Stop Postgres
Back up the current data dir (just in case) or remove it
Unpack the base backup into the data dir
Create a recovery.signal file (for PITR — recovery_target_time in postgresql.conf)
Start Postgres — it applies WAL and stops at the target

In v1.0, ide99 doesn't perform steps 1–5 for you (those are server-side ops, not client). Restore is via ssh + manual commands.

On managed Postgres, PITR restore is done in the provider's UI. Go there, pick a date — the provider handles it.

Schedule for self-hosted

ide99 isn't a system scheduler. Serious scheduling for self-hosted Postgres:

# /etc/cron.d/postgres-backup
0 2 * * * postgres /usr/local/bin/backup.sh

Where backup.sh is a script with pg_basebackup + WAL archiving + S3 upload.

ide99 is convenient for:

One-off backups before a risky migration
Quick replica setup (when you need a one-time full snapshot)
Audit: comparing backup size over time

What it doesn't do

Continuous archiving / WAL shipping
Point-in-time recovery (no UI for picking a moment; that's server-side)
Master-replica coordination — that's standard Postgres tooling

Logical backup — pg_dump for one-off snapshots and moving between servers.
Live Ops — monitoring backup progress in real time.