On this page
Self-hosted software lives or dies on how good its backup story is — there’s no vendor ops team quietly snapshotting a managed database for you. NodaBroker handles this with a single export format that does three jobs at once: routine backup, server migration, and (if you ever need it) a clean exit.
What’s in a snapshot
A full snapshot export is a single zip containing:
- Every database table
- Every setting, including integration configuration
- API keys
- Every document file that’s been uploaded, not just references to them
Nothing is left behind for “ask us to export the rest.” If it’s in your instance, it’s in the zip.
Re-encryption happens on import, automatically
Field-level encryption uses a key that’s specific to each instance. That creates an obvious problem for migration: a snapshot taken from Instance A is encrypted with Instance A’s key, so it can’t just be dropped onto Instance B as-is.
NodaBroker handles this at import time — when a snapshot lands on a new instance, every encrypted field is decrypted with the source key and re-encrypted with the target instance’s own key, as part of the import itself. You don’t manage key material by hand, and the two instances never need to share a key.
Three uses, one mechanism
- Point-in-time backup. Take a snapshot, store it wherever you store backups. Nothing special about it sitting on disk or in cold storage.
- Server migration. Moving from a home server to a VPS, or from one VPS to a bigger one? Export, copy the zip across, import. The re-encryption step means there’s no manual key handling in between.
- The exit plan. If you ever stop using NodaBroker, the snapshot is also just… your data, in a documented structure, with every file present. That’s the actual test of “self-hosted, your data” — not what happens while you’re a happy customer, but what you’re left holding if you’re not.
A concrete number
Snapshot size scales with your book, obviously, but as a reference point: a snapshot covering 38 tables and 214 files lands at roughly 23 MB compressed on a mid-sized instance. Most of that is the document files; the table data itself is small. Plan your backup storage around document volume, not row counts.