DumpCat Install
EN

Released October 19, 2026

What's new in DumpCat 1.4.0

Physical backups through the agent, restore drills that prove a backup restores, alerts when backups go stale, Prometheus metrics, a weekly email digest, and a one-command install.

Install DumpCat 1.4.1All versions

Physical backups through the agent

  • An agent started with --allow-physical (install.sh --agent --allow-physical, install.ps1 -AllowPhysical, DUMPCAT_AGENT_ALLOW_PHYSICAL=1) runs MariaBackup / XtraBackup on the database host when a job asks and streams the backup back over its connection. DumpCat compresses, encrypts, uploads, verifies and applies retention exactly as for a local physical backup; incrementals work, the tool's log lines appear in the run log, and cancelling the run stops the tool on the database host.
  • The credentials travel with each backup and only live in a private option file while the tool runs. The agent only backs up databases on its allow list, builds the command line itself and passes a job's extra arguments only when they name no file, directory, program or server.
  • On Linux, --allow-physical runs the agent as the owner of the datadir (a systemd drop-in) instead of a throwaway user.
  • Agents report what they can do when they connect: the Agents page has a Physical backups column (tool and version, OS user, datadir readable), and the server page and the job editor say why physical backups are not available (agent without --allow-physical, tool missing, datadir not readable, tool not matching the server, agent too old). Older agents keep working and report no physical capability.
  • Physical restores still run where DumpCat runs: backups taken through an agent are prepared there, and the restore log shows how to copy the prepared directory to the database host.

Restore drills

  • On a schedule (cron, like jobs) or on demand, DumpCat restores the newest backup of a job (or one you pick) into a sandbox server under temporary names (<database>__drill_<id>), checks the copy and drops it. The checks: the restore succeeds, every table of the backup exists in the copy, each table holds exactly the rows the backup recorded, optional SQL assertions (one read-only SELECT each, passing when its first column is true) and an optional maximum restore time. Every run records the restore time (RTO), its checks and a log.
  • New Restore drills page and editor, a result page with live progress, a Restore drills card on the backup page (Drill this backup) and in the job editor, Restore-tested / Drill failed badges on backups and jobs, and dashboard warnings. Failed drills (and copies that could not be dropped) notify the channels as event kind drill.
  • Safety: a drill refuses to run when a temporary name already exists on the sandbox and only ever drops databases it created; their names are recorded first, so the copies of a drill interrupted by a restart are dropped at the next start. Drills never restore users and grants or change global settings; on the backup's own source server they stay out of its binary log. Supported: mysqldump with one file per database, and mydumper.
  • Logical backups count the rows of every table while the dump is written (mysqldump, mydumper) and keep them in the catalog and in manifest.json; the backup page shows the rows per database.

Monitoring and alerts

  • Freshness alerts: every minute DumpCat checks each job against its own schedule. When the newest successful backup is older than 1.5 × the time between two scheduled runs plus a grace period (60 minutes, Settings → Monitoring), or than the job's new Max age of the newest backup, an alert goes once to the channels that send failures, and a second message follows when a backup succeeds again. A max age also watches jobs without a schedule (backups started through the API). Open alerts survive a restart.
  • Binlog lag alerts: when binlog archiving has been behind the server for more than 30 minutes (configurable, 0 = off), because the stream is down or closed binlogs wait for upload, once per incident, with a message when it catches up. The archiver status has a new archive_lag_seconds.
  • The dashboard's fixed "no successful backup in more than 8 days" warning uses the same per-job rule, and overdue jobs get an overdue badge.
  • Prometheus metrics at GET /metrics, off by default: last success, status, duration and size per job, integrity checks, freshness, binlog lag, storage use, agents and WireGuard peers online, version. Access with a bearer token (shown once, stored hashed) or only from the DumpCat host (not through a reverse proxy).
  • Weekly digest by email, opt-in per email channel: backups per job, sizes and growth, integrity checks, overdue jobs, restore drill results and storage use over the last 7 days, in the design of the other emails with a plain-text version. Day and hour in Settings, with Preview; Send digest now on the channel.
  • Webhooks: new kind values stale and binlog_lag, new status recovered.
  • API: POST /api/settings/metrics-token, POST /api/notifications/digest, GET /api/digest/preview; settings freshness_alerts, stale_grace_minutes, binlog_lag_minutes, metrics_access, digest_weekday, digest_hour; job option max_age_hours. PUT /api/settings keeps the fields a request leaves out.

One-command install

  • Install with one command: curl -fsSL https://dumpcat.cc/install.sh | sudo sh on Linux and, in PowerShell as Administrator, irm https://dumpcat.cc/install.ps1 | iex on Windows. Both download the latest release, check its SHA-256 against SHA256SUMS and run the package's installer (options after sh -s --, e.g. --agent ...).
  • The Windows package has Install DumpCat to double-click: it asks for administrator rights, installs the service and opens the web UI. Every package has a START-HERE.txt (English and Vietnamese) with the steps, and dumpcat.cc has a step-by-step guide for beginners at dumpcat.cc/install.

Fixes

  • A restore under a new database name no longer creates triggers, routines or events in the original database when their definitions name it (CREATE TRIGGER shop.t ... ON shop.items); such names now point at the new database.
  • Physical backups now record the binlog file, position and GTID they are consistent with (read from the backup tool's info file), so point-in-time recovery can start from a physical backup.

This is an older version: install the latest one from the install guide. DumpCat 1.4.0 itself stays available at https://downloads.dumpcat.cc/1.4.0/.