Restore backups
There are two ways to get data back: From the web console (licensed): pick a backup and a target client. The agent on that client downloads, decrypts and restores it. Offline with bmrecover (always free): decrypt and extract a backup file on any machine, with no BackupMunk server at all. You can also download a single archive from the console at any time, licensed or not. Restore from the console [!NOTE] Restoring from the web console requires a license. Without one, use bmrecover. Find the backup. Either: open Backups and choose Restore to a client on the archive, or open Destinations, choose Browse on a destination, and choose Restore… on the archive. Choose the target client. It can be any enrolled client, not only the host the backup came from, so you can recover onto a new or replacement host. The client must be online and have enough free disk space. If you pick the host the backup came from, the console warns that the restore overwrites data in place. Choose where the files go: Original locations (the default): files are written back to their original absolute paths, overwriting what's there. An alternate path: tick Restore under an alternate path (or fill in Restore under alternate root when restoring from Browse) and enter a target root, then choose how paths map under it: Mode Result for /srv/app/app.ini, from a backup of /srv/app, restored under /restore Sandbox — mirror the original tree /restore/srv/app/app.ini. Good for checking a backup without touching the real locations. Relocate — drop the original root /restore/app.ini. The backup's original parent folder is removed, which is good for moving data to a new home. For a Docker Compose backup, tick Start containers after restore to run docker compose up -d once the files and volumes are back. Start the restore. It appears on the Runs page like a backup, with its log. What a restore does Files are written with their original permissions (including setuid, setgid and sticky bits) and their original owners. Named volumes are restored into new Docker volumes with the same names, so the compose file needs no changes. Images saved in the backup are loaded into Docker. Starting a restored stack. If you asked to start containers, the agent first checks the host for clashes with existing containers: ports already in use, container names, network names, subnets and static IP addresses. It then adjusts a private copy of the compose file to avoid each clash, and starts the stack under its own project. Every change is listed in the run log. On a clean host, the stack starts unchanged. Relocated stacks. On a relocated restore, bind-mounted folders that would land beside the compose folder are moved under it, and the compose file is rewritten to use relative paths. The restored stack is then one self-contained folder. Interrupted downloads resume. The agent picks up from where it stopped after a network error, and downloads large archives in parallel. Other copies are used if needed. If the backup is stored in several destinations and the chosen copy can't be read, the agent uses another copy (see Store copies in several destinations). Damaged data is rejected. Encryption is authenticated, so a damaged, altered or truncated archive, or the wrong key, makes the restore fail rather than produce corrupt files. Download an archive On Backups (Download archive) or in a destination's Browse list (Download), you can download any archive through your browser. The server decrypts it on the way out, so the file you get is not encrypted. Store it accordingly. To unpack it, use bmrecover without a passphrase: Restore offline with bmrecover bmrecover decrypts and restores a backup using only the backup file and the destination's recovery passphrase. It needs no server, database, master key, network connection or license. Use it when the server is gone, when the installation is unlicensed, or to recover on an isolated machine. [!WARNING] Offline recovery only works for backups written…
BackupMunk Enterprise documentation