DumpCat Install
EN

Released October 20, 2026 · latest version

What's new in DumpCat 1.5.0

PostgreSQL: backups with pg_dump and pg_basebackup, continuous WAL archiving and point-in-time recovery, restores under new names or onto another server, roles, and restore drills. MySQL and MariaDB work as before, now as one of several database engines.

Install DumpCat 1.5.0All versions

PostgreSQL

  • Choose PostgreSQL as the database engine of a server (port 5432, or a socket directory). The server check shows the version, WAL level, the backup role's attributes and what it is missing, and each database with its size, tables, encoding and locale.
  • New backup method pg_dump: each database is dumped in directory format with its tables in parallel (--jobs), from one consistent snapshot, then stored as one archive through the usual compression, encryption, checksums, storages, retention and verification. Roles and tablespaces adds pg_dumpall --globals-only (passwords when the backup account is a superuser). Tables can be excluded as database.table or database.schema.table.
  • Restores with pg_restore --jobs, into the same database (the backup's objects are replaced, others stay), under a new name, or onto another PostgreSQL server: the database is created with the source's encoding and locale, roles the target lacks can be created from the backup, and Skip ownership / Skip privileges are suggested for another server.
  • Restore drills for PostgreSQL backups: every table and its row count compared with the backup (count(*), or the server's estimates after ANALYZE for very large tables), SQL assertions in a read-only session.
  • DumpCat finds every installed version of the client tools and uses the server's major version (or the nearest newer one); the Linux installer installs them with --postgres 16 (several: --postgres 15,16).
  • Passwords go through a private password file, never the command line; database names are passed inside a quoted connection string, so a name like a=b cannot become connection options.
  • New backup method pg_basebackup: the whole cluster over a replication connection (nothing to install on the database host), written as one tar stream with the WAL of the backup straight into the storage pipeline; a temporary replication slot keeps that WAL until it is fetched. Full backups; clusters with additional tablespaces are not supported yet.
  • Restoring a pg_basebackup backup prepares a data directory on the DumpCat host and recovers it with a temporary PostgreSQL server of the backup's version (its own configuration: a local port, no archiving); without the server binaries the directory is left ready to recover. Admins on Linux can replace a local cluster's data directory with it: recovered next to it, swapped in while the service is stopped, rolled back on any error. As root the recovery runs as the OS user postgres, and the folders DumpCat creates for the directory let it in. A directory whose configuration lived in /etc/postgresql (Debian/Ubuntu) gets a minimal postgresql.conf, pg_hba.conf and pg_ident.conf, so that it starts on its own.

Point-in-time recovery for PostgreSQL

  • Continuous WAL archiving for pg_basebackup jobs: pg_receivewal streams the WAL through a replication slot of the job, so the server keeps it while DumpCat is down; every completed segment is compressed, encrypted and uploaded to every storage of the job like the binlogs of MySQL jobs. Turning archiving off, disabling or deleting the job drops the slot. A slot that lost WAL (max_slot_wal_keep_size) is reported as a gap and streaming starts again. When the server's timeline left the archived one before its end (the cluster was restored to an earlier point, or a standby was promoted behind DumpCat), the archive keeps the old timeline and continues on the new one.
  • DumpCat reads the WAL itself (no pg_waldump needed): the LSN range of every segment, the times of its commits and the restore points created in it, CRC-checked.
  • Recover to a point in time, a restore point or a WAL position (LSN), or the latest state including the segment still being received: the newest pg_basebackup before the target is picked, every segment is downloaded and checked before anything is changed, and PostgreSQL replays the WAL to the target and promotes. Restore points found in the archive are suggested.
  • Close segment now and close the current segment after N minutes (pg_switch_wal()), lag and slot monitoring on the Binlog / WAL & PITR page, lag alerts and dashboard warnings, retention after the oldest kept backup (timeline history files are kept).

Several database engines

  • Everything that is specific to a database engine (inspection, backup methods, restores, the queries of restore drills) now sits behind one driver interface; jobs, schedules, storages, encryption, retention, verification, notifications, monitoring, agents and WireGuard are shared. Backup methods and restore options shown in the UI come from the driver. See docs/design-multidb.md.
  • Servers have an engine (existing ones are MySQL), manifest.json records it, and a job's method must belong to its server's engine. Restoring a backup onto a server of another engine is refused.
  • Log archiving and point-in-time recovery sit behind one interface too: the archiver of each job, the upload to its storages, the catalog of archived files, retention, lag monitoring and the recovery plan are shared by MySQL binlogs and PostgreSQL WAL. The page is now Binlog / WAL & PITR; the API reports the server's position as server_position (instead of server_file / server_pos) and the start of a plan as base.start.
  • A restarted binlog stream no longer counts the previous session's last check as caught up, so a recovery planned right after a restart does not miss the binlog still being received.

AI assistants (MCP)

  • DumpCat is an MCP server for Claude Desktop, Claude Code and other MCP clients: POST /api/mcp (streamable HTTP) and dumpcat mcp, a stdio bridge that reads its address and token from DUMPCAT_MCP_* variables or an env file and checks certificates like the agent. Tools give the overview, monitoring and alerts, servers (with a live connection check), jobs, backups, restores, restore drills, the end of any task's log and a point-in-time recovery preview; with a full-access token of an operator they also run a backup, verify a backup or start a drill. Each tool runs the matching API request with the caller's token, so roles, audit log and secret-free answers are the API's; restores, deletions, credentials and settings are not exposed.
  • API tokens are read-only or full. New tokens are read-only unless Full is chosen; a read-only token can look but not change anything, download a backup or create a token, whatever its user's role. Existing tokens keep full access. Token names refuse control characters.

Other fixes

  • Physical restores that only prepare a directory (MySQL and PostgreSQL) refuse one in /tmp or /var/tmp when DumpCat runs as its systemd service: these are the service's private folders (PrivateTmp), invisible to other users and deleted when DumpCat stops.