Mario Fetka
5897512fd9
Complete the current IMAP, POP3, SMTP and proxy protocol work; add the validated setup and administration UI, packaging examples, tests, and maintained roadmap/documentation for the 0.7 development line.
72 lines
3.3 KiB
Markdown
72 lines
3.3 KiB
Markdown
# Storage and backup
|
|
|
|
Bongo does not put every message in one global SQLite database. The Store
|
|
uses a per-user layout so a large account does not lock or enlarge the
|
|
metadata database of every other account.
|
|
|
|
## Store layout
|
|
|
|
Each account below `/var/lib/bongo/users` has its own `store.db` SQLite
|
|
metadata database and Maildir-like collection directories containing the
|
|
document payloads. Mail, calendar objects, and contacts use the Store's common
|
|
object and collection model. The SQLite database tracks collections, UIDs,
|
|
flags, properties, and indexes; message bodies remain separate files.
|
|
|
|
The system Store below `/var/lib/bongo/system` contains server configuration
|
|
documents and other system-owned objects. The Queue spool below
|
|
`/var/lib/bongo/spool` contains messages which have been accepted but not yet
|
|
fully delivered.
|
|
|
|
Other SQLite databases serve separate purposes:
|
|
|
|
- `/var/lib/bongo/dbf/userdb.sqlite` stores local authentication records,
|
|
Argon2id password hashes, encrypted TOTP secrets, recovery codes, app
|
|
passwords, login aliases, and LDAP cache metadata.
|
|
- `/var/lib/bongo/dbf/sieve.sqlite` stores ManageSieve scripts and vacation
|
|
state.
|
|
- `/var/lib/bongo/dbf/external-accounts.sqlite` stores external account
|
|
schedules, identities, encrypted credentials, and import state.
|
|
- `/var/lib/bongo/web/sessions.db`, `tasks.db`, and `identities.db` store the
|
|
corresponding Web data.
|
|
|
|
SQLite write-ahead-log and sidecar files are part of a live database state;
|
|
copying only the main `.db` file while Bongo is writing is not a reliable
|
|
backup.
|
|
|
|
## Backup scope
|
|
|
|
A complete backup includes at least:
|
|
|
|
- `/etc/bongo`;
|
|
- all of `/var/lib/bongo`, including Store payloads, metadata, Queue spool,
|
|
account and Web databases;
|
|
- TLS, DKIM, SRS, external-account encryption, TOTP encryption, and ACME hook
|
|
keys wherever the configuration points to them;
|
|
- distribution service overrides and reverse-proxy configuration needed to
|
|
reproduce the deployment.
|
|
|
|
For a simple consistent filesystem backup, stop Bongo, confirm that its
|
|
agents have exited, snapshot or copy the entire state and configuration tree,
|
|
then restart it. A storage snapshot is acceptable only when the filesystem
|
|
and SQLite state are captured atomically. Online backup tooling must use the
|
|
SQLite backup API or checkpoint/locking rules and coordinate Store payload
|
|
creation; a file-by-file copy is insufficient.
|
|
|
|
`bongo-storetool` can import and export mailbox data in mbox or Maildir form.
|
|
That is useful for migration and recovery of mail content, but it is not a
|
|
replacement for a complete server backup because it does not preserve every
|
|
account, key, configuration, calendar, contact, task, and protocol state.
|
|
|
|
## Restore testing
|
|
|
|
Restore into an isolated host with the same or a newer compatible Bongo build.
|
|
Check database integrity, ownership and permissions, then validate the
|
|
configuration before starting the agents. Test login, message counts, flags,
|
|
folder hierarchy, calendar/contact access, queued delivery, app passwords,
|
|
and a signed outbound message.
|
|
|
|
Large-store and migration benchmarks are part of the 1.0 release work. The
|
|
per-user metadata design avoids a single database bottleneck, but it does not
|
|
remove the need to test filesystem inode usage, indexes, backup duration,
|
|
search performance, and recovery with realistically large mailboxes.
|