Can You Actually Restore Your Servers?

Most organizations have backups. Far fewer have tested what happens when they need them. The backup job has been green for months, then a server dies or ransomware hits, and the restore turns up a copy that’s missing its configuration, sits next to the data it was meant to protect, or can’t be opened because the keys went down with the backup server.

This article looks at why backups fail at the moment they matter, what a recoverable backup looks like, and how BackupMunk Enterprise, our self-hosted backup platform for servers and Docker Compose applications, is built around getting your data back.

Why backups fail when you need them

• Every copy is in one place. If your only backup lives on the same network, in the same building or with the same cloud account as the original, whatever takes out one can take out both.
• The backup server is a single point of failure. Many tools keep the schedules, the catalog and the encryption keys on one machine. Lose that machine and your archives may be unreadable, even though they’re sitting safely in storage.
• Applications come back without what they need to run. Copying a database folder isn’t the same as restoring an application. Without its configuration, environment files and container images, a restored service often won’t start.
• Backups are readable by anyone who reaches the storage. Unencrypted archives in a bucket are a data breach waiting for a misconfigured permission.
• Nobody notices the failures. A job that quietly fails for weeks leaves you with a backup that’s much older than you think.
• The backup system needs a way into every host. Tools that connect in over SSH or WinRM need open ports and stored credentials for every server, which attackers can use too.

What a recoverable backup looks like

• Encrypted on the host, before it leaves, so storage providers and the network only ever see ciphertext.
• Stored in more than one place, in line with the long-standing 3-2-1 rule: several copies, with at least one kept off-site.
• Recoverable even if the backup server itself is gone.
• Complete enough to restore whole applications, not just their files.
• Visible: you can see what ran, what failed and when, and get alerted.
• No inbound access to your servers.

Meet BackupMunk Enterprise

BackupMunk Enterprise is centrally managed backup for the servers you run yourself: Docker Compose applications and Linux, Windows and macOS file systems. A self-hosted server holds the schedules, credentials, encryption keys and restore console, and a small agent on each host does the work, streaming encrypted archives to the S3-compatible storage you already use.

1. Run the server. It’s a single Docker Compose stack in your own environment.
2. Install the agent. One command per host, or a reusable registration key for fleets and golden images. Agents connect out over HTTPS, so hosts need no inbound ports, SSH or WinRM.
3. Set up a backup. A guided flow: pick the host, browse its real file system or pick a Compose stack, choose a schedule in plain language, pick where to store it and review.
4. Store it anywhere S3-compatible. AWS S3, MinIO and other S3-compatible services, and Backblaze B2.

Built so you can always get your data back

• Encryption you can’t switch off. Every archive is encrypted on the protected host with ChaCha20-Poly1305 before it leaves, using per-destination keys.
• Offline recovery. Set a recovery passphrase on a destination and any archive can be decrypted and restored with the free bmrecover command-line tool, with no server, no database and no license required. Each archive also carries a small manifest, so the catalog can be rebuilt from the bucket alone.
• Copies in more than one place. Write each backup to several destinations at once. A slow or failed destination doesn’t hold the others up, missing copies are re-created automatically, and restores fall back to another copy.
• A hot standby for the server itself. Pair a second server in another site. It keeps a read-only copy of the primary, and if the primary’s site is lost you promote the standby and the agents follow it on their own.

How your data stays safe

Backups hold copies of your most sensitive data, so encryption in BackupMunk is always on and can’t be turned off.

• Authenticated encryption on the host. Archives are encrypted with ChaCha20-Poly1305 (or AES-256-GCM in FIPS 140-3 mode) before they leave the protected host and are only decrypted on the host they’re restored to. A damaged, altered or truncated archive makes a restore fail instead of producing corrupt files.
• A separate 256-bit key for every destination. Your own server generates the keys. When a backup is stored in several places, each copy is encrypted independently.
• Keys never stored in the clear. Destination keys and storage credentials are sealed under a master key that you generate and keep, so a copy of the server’s database reveals nothing on its own. Each agent receives keys sealed to its own key pair and holds them only in memory.
• A recovery passphrase that’s never saved. A key derived from it with Argon2id (or PBKDF2-HMAC-SHA256 in FIPS 140-3 mode) lets bmrecover restore a backup offline, and the passphrase itself is never stored anywhere.
• Verified uploads and least-privilege storage keys. Every upload is checked and its SHA-256 hash recorded. With write-only storage keys, a compromised host can add backups but can’t read or delete the ones already stored.
• FIPS 140-3 mode for regulated organizations. If you must use FIPS-validated cryptography, one setting switches all new backups, key exchange and password hashing to FIPS-approved algorithms (AES-256-GCM, P-256 and PBKDF2-HMAC-SHA256), with the server and agents running on the Go Cryptographic Module v1.0.0, validated under FIPS 140-3 (CMVP certificate #5247). It needs no license, and backups made in either mode restore in the other.

BackupMunk runs entirely in your environment: your backups and your keys never pass through Sage ISG.

Applications, not just folders

A Docker Compose backup captures the whole stack as one recoverable unit: the compose file, its .env and env_file entries, the named volumes and, optionally, the container images. A restored stack actually starts, even on an air-gapped host. Containers are stopped briefly for a consistent copy, or backed up live when the data allows it. On Linux hosts with Docker checkpoint (CRIU), BackupMunk can freeze running containers with their memory and resume them afterwards, with no cold start.

You can restore in place, into another folder or onto a different machine, and BackupMunk brings Compose stacks back up automatically.

Free to start, licensed when you need more

Without a license, BackupMunk still gives you:

• scheduled, encrypted backups through the server to one destination
• retention, so old backups are cleaned up automatically
• the dashboard and audit log
• offline recovery with bmrecover, which always works

A license adds direct uploads from each host to storage, several destinations per backup, incremental backups, restores from the web console and audit shipping to your SIEM. The Base plan starts at CA$10 a month for 5 hosts. Licenses are verified offline, and BackupMunk keeps working through a grace period if it can’t reach our store.

You can try every licensed feature free for 30 days on up to 5 hosts, with no card needed. When the trial ends, the free features keep working.

Getting started

The server runs on any Linux host with Docker Compose, and agents run on Linux (amd64 and arm64), macOS (Intel and Apple silicon) and Windows. You need S3-compatible storage or Backblaze B2 for the archives.

• Learn more about BackupMunk Enterprise, including how your data is protected.
• See pricing and start the free trial

Want help planning a backup and recovery strategy, or deploying BackupMunk across your servers? Talk to our team.