Your Unraid server, sealed in a vault. Drop a backup. Detonate a restore.

Containers, VMs, appdata, ZFS datasets, the flash drive and any folder you point it at. BombVault also backs up itself, because a backup tool that cannot save its own skin is a hobby project. A restore puts it all back: containers reappear in the Docker tab, VMs in the VM tab, already configured. No reinstall, no rebuild, no evening lost.

Built on restic, so every snapshot is deduplicated, incremental and encrypted before it leaves the box. Off-site copies can be append-only, which is a polite way of saying ransomware is welcome to knock.

Important

Android testers wanted. Google Play only lists an app from a new developer account after at least 12 testers have kept it installed for 14 days. If you have an Android phone:

1. Open the tester group, sign in with the Google account your phone uses and click Join group.
2. Open the test page and tap Become a tester.
3. Install BombVault from Google Play and keep it for 14 days. Using it for real helps most, and anything that goes wrong is welcome as an issue.

     

   

A one-knight job: I build it, keep it running, work through the issues and add what people ask for, until nothing is missing. It is free, with no accounts, no telemetry, no ads and no paid tier. No asterisk anywhere. Nothing readable ever leaves your own walls. Forged on evenings and weekends, with heart and stubbornness.

If it has earned a place on your server or computer, toss a coin to your knight: it helps cover the costs and keeps the project alive. It also makes this knight's heart beat a little faster. Three ways below, whichever suits you.

   

Table of Contents

1. Screenshots
2. What it does
3. How it compares
4. Getting started
5. Documentation
6. How AI is used here
7. Support this project

1. Screenshots

Overview: a ring shows how much is protected, then what needs you, the protection of each section, how full each storage location is and the history with every run and the log. More cards wait under Customize.

Restore: one page for everything. Pick a section, search for an entry and choose a backup. One window restores every kind, next to the original by default. The Emergency wizard brings back a lost server from its recovery kit, through your group or with its typed key.

Backups: everything that is backed up stands in one list, each row with its last fourteen runs and one status. Tiles pick a kind, Filters, Sort and Search sit above the list, and every entry has a page with its backups, its settings and its checks.

Settings as fourteen tiles (General · Look · Schedule · Storage locations · Restore · Notifications · Verify · Security · Instances · Pairing · Integrations · Apps · System · Info), with a search over all of them on / or Ctrl+K. Nothing here has a Save button; every change is written as you make it.

Instances: paired servers take on roles for each other: receiver, fetcher, ZFS server and key keeper. A receiver keeps the other's off-site copy in an append-only server, lists what arrived from each source and when, and runs its own integrity check on this hardware instead of trusting the sender.

The Android app: every server of your group on one list, their activity in one log, paired by twelve words.

2. What it does

• Backs up the whole server. Containers with their appdata and definition, VMs with their disks, XML and NVRAM, the Unraid flash, any folder, ZFS datasets with their children, and BombVault's own settings. PostgreSQL, MySQL and MariaDB containers are dumped first. Features
• Restores to a running state. A container comes back in the Docker tab with its image, settings and data, a VM in the VM tab with its disks and NVRAM. By default the copy lands next to the original and the original stays as it is: a second, stopped container named <name>-restored, a VM's disks in a folder of their own, a folder beside the old one. When a restore replaces the original, BombVault first backs up what is there now unless you switch that off, and if that backup fails, the restore does not start. Every restore shows what it will change before it starts. Features
• Copies off site, entry by entry. Encrypted, to one or more storage locations that can be append-only. A storage location is set up once, from tiles that know S3 storage services, your own servers and every cloud drive rclone supports. A picture shows 3-2-1 for every section, and each entry says how many sites hold it and whether 3-2-1 is met. A ZFS dataset can also keep a replica as real datasets on a second ZFS host or a paired BombVault, sent incrementally with zfs send. Off-site & recovery, ZFS replica
• Proves that restores work. A restore check after each entry's first backup, scheduled drills, and a start test that runs a restored container in an isolated network. Features
• Notices when a backup looks wrong. Much more new data than usual, a source that shrank, a run that took far longer. When a source shrinks sharply, its old backups are kept until you acknowledge the finding. Features
• Survives losing the server. A new install reads the old backups without the old APP_KEY in its template. The Emergency wizard takes the old key from the recovery kit, from a key keeper in your group or as typed text, tries it on every storage location, and restores settings, containers, VMs and folders. A key keeper is another server of your group that holds a sealed copy of the recovery kit. It cannot open the copy itself, only your recovery code does, and it hands the copy out only after someone there presses Allow. Emergency wizard, Key keeper
• Lets you back in without the password. Forgot password? on the login page writes a code to the container log, and that code sets a new password. The reset also switches two-factor authentication off, removes every passkey, revokes API tokens, MCP keys and OAuth sign-ins and signs out every other session and paired phone. Anyone who can read the container log can do this, so give log access only to people you would trust with the password. Login
• Keeps everything in one list. The sidebar has five entries: Overview, Anomalies, Backups, Restore and Settings. Backups shows every container, VM, folder set, the flash drive, every ZFS dataset and the self-backup in one list, and each entry has a page with its backups, its settings and its checks. Restore is one page for all of them, and Settings are fourteen tiles with a search. Finding your way
• Fits into the rest of your setup. Servers pair by twelve words and take on roles for each other: receiver, fetcher, ZFS server and key keeper. Receiver, fetcher and ZFS server start only after someone at the other server presses Allow. The Android app shows every server of the group and opens each one from any network, at home at its own address and elsewhere through the relay. AI assistants, scripts and Home Assistant read the status over MCP, an HTTP API and MQTT. Instances and roles, Android app, MCP server, API and integrations

It runs as one Docker container on Unraid, TrueNAS Scale or a plain Docker host and stores everything with restic. The interface comes in 42 languages and the documentation in 26. The idea of one-click backup with automatic reinstall comes from VolumeVault by @Darkdragon14; BombVault is a separate implementation (see Credits).

3. How it compares

On Unraid, backups usually run through Appdata.Backup, a CA plugin that archives appdata folders, or through a general engine such as Duplicati, Kopia or BorgBackup. They save files well, but a restore gives you files back, not a running container or VM.

The closest counterpart is Vault by @ruaan-deysel, a native Unraid plugin built on the same idea: it recreates containers and re-defines VMs on restore, and it has a good deal of what BombVault has, down to changed-block VM backups and Home Assistant. BombVault is ahead on getting data back: restic reads its backups without BombVault, the off-site copy can be append-only, and restores are tested for real, up to starting a restored container in isolation. Worth a look.

	BombVault	Vault (plugin)	Appdata.Backup (CA)	Duplicati	Kopia	BorgBackup
Restore brings a container back whole (image, env, ports, labels)	✅	✅	⚠️ files and XML	❌	❌	❌
Restore re-defines a VM, not only its disks	✅	✅	⚠️ XML only	❌	❌	❌
VM backups read only changed blocks	✅ qcow2	✅ qcow2	❌	❌	❌	❌
Database dumps for recognised database containers	✅	✅	❌	❌	❌	⚠️ via Borgmatic
Installed Unraid plugins	✅ one by one from the flash backup	✅	⚠️ in flash backup	❌	❌	❌
ZFS datasets as a source	✅	✅	❌	❌	⚠️ via action scripts	⚠️ via Borgmatic
Deduplication	✅	✅ opt-in	❌	✅ fixed blocks	✅	✅
Client-side encryption	✅ on by default	✅ opt-in	❌	✅	✅	✅
Backups readable with a standard open-source CLI	✅ restic	⚠️ not with dedup, own recover tool	✅ tar	⚠️ Python script	✅ kopia	✅ borg
Append-only or immutable off-site copy	✅	❌	❌	✅	✅	✅
Scheduled backup waits until the app is idle	✅	✅	❌	❌	❌	❌
Scheduled test restores, not only a checksum read	✅	❌	❌	❌	❌	⚠️ via Borgmatic
Start test: a restored container is started in isolation and checked	✅	❌	❌	❌	❌	❌
Off-site upload slows down while a media server streams	✅	✅ any outside traffic	❌	❌	❌	❌
Several off-site targets, each with its own credentials	✅	⚠️ one per job	❌	✅	⚠️ CLI sync	⚠️ via Borgmatic
Each item chooses which off-site targets get a copy	✅	⚠️ a second job per target	❌	⚠️ a job per destination	❌	⚠️ via Borgmatic
Each item chooses local only, local and off-site, or off-site only	✅	⚠️ by the jobs it is in	❌	⚠️ a job per destination	❌	⚠️ via Borgmatic
Shows how many sites hold each item and whether 3-2-1 is met	✅	⚠️ for the whole server, not per item	❌	❌	❌	❌
Pre/post-backup hooks	✅	✅	✅	✅	✅	⚠️ via Borgmatic
Live progress and cancel, backup and restore	✅	⚠️ no restore cancel	⚠️ log, no percentage	✅	⚠️ no restore percentage	⚠️ CLI or Vorta
Notifications	✅ SMTP, Matrix, Apprise, more	✅ Discord, Unraid	✅ Unraid's agents	✅ email, Telegram, HTTP	✅ email, Pushover, webhook	⚠️ via Borgmatic
Anomaly detection (size, duration, shrink)	✅	✅	❌	⚠️ paid Console	❌	❌
AI assistant access (MCP)	✅	✅	❌	⚠️ third party	❌	❌
Documented HTTP API for scripts, with its own tokens	✅	✅	❌	⚠️ undocumented	⚠️ undocumented	❌
Home Assistant integration	✅ over MQTT	✅	❌	⚠️ third party	⚠️ third party	⚠️ third party
Announces itself on the network (mDNS)	✅	✅	❌	❌	❌	❌
Backs up desktops and laptops	❌	❌	❌	✅	✅	⚠️ Windows experimental
Runs outside Unraid	✅	⚠️ replica only	❌	✅	✅	✅
In Unraid Community Applications	✅	✅	✅	✅ community template	✅ community template	✅ community template
Android app	✅ APK, F-Droid, Google Play in closed test	❌	❌	❌	❌	❌
Track record	⚠️ since 2026, one maintainer	⚠️ since 2026, one maintainer	⚠️ since 2023, feature-frozen	✅ since 2008	✅ since 2019	✅ since 2015

✅ yes · ⚠️ partly · ❌ no. The other tools were checked against their code and docs on 25 September 2026, the start-test row and Vault's cells for idle waiting, mDNS, Home Assistant and changed-block VM backups again on 28 September 2026, the rows for placement, 3-2-1 and the Android app on 4 October 2026, and every Vault cell on 20 October 2026.

4. Getting started

On Unraid, install BombVault from Community Applications. The one setting it needs is APP_KEY, a secret you make with openssl rand -hex 32. Keep a copy somewhere other than the server, because without it nobody can read the encrypted backups. Then open https://<server-ip>:3443. A new install opens on a welcome page with what BombVault found, and Let's go leads to three first steps: choose sections, add a storage location, run the first backup. After that it runs every night by itself. Then set a login password and download the recovery kit under Settings, Restore, or let another server of your group keep it as key keeper. If the install replaces a lost server, Restore from a backup on the welcome page opens the Restore page with the Emergency wizard.

On any other Docker host or on TrueNAS Scale, take deploy/docker-compose.generic.yml, set APP_KEY and the Host Data volume, and run docker compose up -d. VM and ZFS backups reach the host over SSH, so BombVault's public key has to be added there once. Getting started and Configuration cover the template, the mounts, every variable and the SSH setup.

• Synology: in Container Manager, create a project from the compose file (DSM 7.2 or newer).
• Proxmox: run it in a VM or an LXC container that has Docker.
• MOS: install BombVault from the MOS Hub. It runs there as PLATFORM=generic with Host Data on /mnt/cache.
• ZimaOS and CasaOS: add the community store and install BombVault from it. It runs there as PLATFORM=generic with Host Data on /DATA.

Android app

   

Every release has the app as bombvault-android.apk. On any server, open Settings, Pairing, choose Show phrase and scan the QR code with the app. It joins through the group's relay, adds every server of your group and shows what runs on all of them. Each server opens already signed in, at home at its own address and from any other network through the relay, where the server signs every answer. A paired phone reaches what the app shows; keys, settings and deleting backups still need the password at the server itself. It is on F-Droid, and Google Play has it in a closed test for now. The Android app page has the details, and the privacy policy lists what the app stores and sends.

5. Documentation

The documentation, in 26 languages, has what this page leaves out:

• Getting started: requirements, the Unraid template, other Docker hosts and TrueNAS Scale, the welcome page and the first backup, the sidebar and the settings tiles, and building from source
• Android app: pairing by QR code, opening a server from any network through the relay, what a paired phone may do, servers outside a group, settings and downloads
• Features: everything BombVault backs up, restores, checks and reports
• Configuration: environment variables, mounts, the security model with the login and the password reset, phones and group members, the APP_KEY and a taken-over backup key, VM backup over SSH and the off-site setup
• Off-site & recovery: storage locations and moving or removing them, placement per entry, append-only copies, tamper tests, pairing and the four roles, the Emergency wizard, the key keeper and the recovery kit
• ZFS datasets: entries and child datasets, restores, the safety snapshot and the replica on a second ZFS host or a paired BombVault
• MCP server: connecting AI assistants, keys and limits
• API and integrations: the HTTP API, Home Assistant and mDNS
• Troubleshooting: failed backups, locks, a lost APP_KEY or password, a phone on the login page, VM connections and a container that restarts
• VM backup over SSH: the full SSH and networking guide, including TrueNAS Scale

6. How AI is used here

One knight builds this, and AI is one of the tools I work with, the same way I work with an editor or a compiler. It helps me write code and documentation and it checks my work, and that saves me a good many evenings. It does not make the decisions, though. I read and understand everything before it ships, and if something here breaks, that is on me and not on the tool.

You do not have to take my word for it. The code is open and every release note is written by hand. The issue tracker shows how problems actually get handled, including the ones I got wrong the first time. If you find something that is not right, open an issue and I will look at it.

7. Support this project

Questions? Ask in Discussions or check the support thread. Bugs, ideas or feature requests? Please open a GitHub issue.

A one-knight job: I build it, keep it running, work through the issues and add what people ask for, until nothing is missing. It is free, with no accounts, no telemetry, no ads and no paid tier. No asterisk anywhere. Nothing readable ever leaves your own walls. Forged on evenings and weekends, with heart and stubbornness.

If it has earned a place on your server or computer, toss a coin to your knight: it helps cover the costs and keeps the project alive. It also makes this knight's heart beat a little faster. Three ways below, whichever suits you.