How BackupMunk works
BackupMunk Enterprise is centrally managed backup for Docker Compose applications and for files and folders on Linux, macOS and Windows hosts. One server holds the schedules, storage credentials, encryption keys, audit trail and restore console. A small agent on each protected host does the work: it captures the data, encrypts it on the host and streams it to your own S3-compatible object storage. What happens during a backup Schedule. You define a backup in the web console and assign it to one or more clients (hosts running the agent). The server pushes the configuration to the agents over a live connection. Each agent runs the schedule itself, so backups keep running while the server is down. Only reporting pauses. Capture. For a Docker Compose stack, the agent captures the compose file, its environment files, the stack's named volumes, optionally the container images, and any extra folders you pick (such as bind mounts). For files and folders, it walks each selected path, including everything inside. By default a stack's containers are stopped for a consistent copy and started again afterwards. Encrypt. The archive is encrypted on the host before it leaves, with a key that belongs to the destination. Encryption can't be turned off, so the storage provider only ever holds encrypted data. Upload. The agent streams the archive through the BackupMunk server to the destination (relayed), or, with a license, straight to the storage (direct). By default nothing is staged on the host's disk, so a host doesn't need free space equal to its own data. Verify and record. After the upload, the stored object's size is checked against the bytes sent. A SHA-256 and SHA-1 of the stored object are written to a plaintext manifest next to the archive. The run and its log appear on the Runs page, and the archive on the Backups page. Retention. Each destination can keep the newest N backups and delete older ones. Keys and encryption One key per destination. The server generates a 32-byte key for each destination and stores it only in encrypted form, under the server's master key (BMENT_ENC_KEY). A copy of the database on its own doesn't reveal any key or credential. Keys are sealed to each agent. Every agent creates its own key pair when it enrolls. The server seals the destination key to that agent's public key, and the agent holds it in memory only, never on its disk. Offline recovery passphrase. A destination can also have a recovery passphrase. Backups written after you set it can be decrypted with the free bmrecover tool using only the backup file and the passphrase: no server, no database and no master key. See Storage destinations. [!WARNING] The server can decrypt every backup, because it holds the keys. Treat the server and its BMENT_ENC_KEY as sensitive. If you lose BMENT_ENC_KEY, the server can no longer decrypt the destination keys, and only the recovery passphrase can open your backups. See Deploy the server. Components Component Role BackupMunk server The web console, API, scheduler and upload relay, plus the agent and bmrecover downloads. One container. SurrealDB Stores everything the server knows: clients, backups, destinations and their sealed credentials, runs, settings and the audit log. Valkey Sign-in sessions. Safe to lose: users sign in again. Agent (bment-agent) Runs on each protected host. Built for Linux (amd64, arm64), macOS (Intel and Apple silicon) and Windows (amd64). bmrecover Standalone recovery tool for the same platforms. Free, and needs no server. Your object storage AWS S3, Backblaze B2, MinIO or another S3-compatible service. Not part of the BackupMunk stack. Ports and connections Port Service Who needs to reach it 7500 TCP Web console, API and agent connections (plain HTTP) Administrators and agents, through your TLS reverse proxy 8000 TCP SurrealDB Only the server, inside the Compose network 6379 TCP Valkey Only the server, inside the Compose network Agents connect out. Agents open HTTPS connections to the…
BackupMunk Enterprise documentation