DHIVA LABS · LEARN

Appearance

Back up other LMDB databases ​

Nothing in the backup itself is specific to monero-lws: every backup is a compacted, page-level copy of the whole environment. What changes between databases is how much the check after the backup understands, and what the manifest records. That is set by the profile.

Profiles ​

Set the profile with profile in [source], or for one run with --profile.

ProfileWhat verify doesWhat the manifest records
auto (default)Reads every table. If the monero-lws accounts table is present, behaves as monero-lws; otherwise as generic.Whatever the detected profile records.
monero-lwsEverything generic does, plus a strict check of the accounts table (every row must be exactly 144 bytes). Fails if that table is missing.Account count, lowest and highest scan height, table count, total rows.
genericReads every table without interpreting any row.Table count and total rows.
  • Detection runs on the backup snapshot, not on the live database.
  • The manifest always records the detected profile (monero-lws or generic), never auto.
  • --verify and --restore use the profile in the same way, so a pinned monero-lws also applies when you check or restore an old backup by hand.

For monero-lws, auto works without changes. Set profile = "monero-lws" if you want a missing accounts table (for example, db_path pointing at the wrong database) to fail the backup instead of quietly being treated as generic.

A minimal configuration ​

toml
[source]
db_path = "/var/lib/myapp/db"
profile = "generic"

[backup]
destination_dir = "/var/backups/myapp"
filename_prefix = "myapp"

[encryption]
key_env_var = "LWS_BACKUP_KEY"

This writes myapp-YYYYMMDD.lmdbbak.enc and myapp-YYYYMMDD.manifest.json to /var/backups/myapp. Every other setting keeps its default, including 30 days of retention.

Run and list it like any other:

bash
lmdb-lws-backup --config myapp.toml --once
lmdb-lws-backup --config myapp.toml --list

with the key in LWS_BACKUP_KEY, as described in Keys and security.

The user running the backup needs write access to the environment's lock.mdb, not only read access to data.mdb.

File name prefix ​

filename_prefix (default lws-backup) names the files <prefix>-YYYYMMDD.lmdbbak.enc and <prefix>-YYYYMMDD.manifest.json. The tool adds the dash, so do not end the prefix with one. It must be 1 to 100 characters from A-Z, a-z, 0-9, ., _ and -, and must not start with . or -.

Retention, --list and the clean-up of stray manifests only touch files with the configured prefix. If you change the prefix on an existing destination, the old files are left alone and no longer pruned; delete them yourself when you no longer need them.

Several databases ​

Give each database its own configuration file, its own filename_prefix and, ideally, its own destination_dir.

WARNING

If two databases share one destination folder, never let their backups run at the same time. Every run starts by deleting all .partial files in the destination folder, whatever their prefix, which would destroy the other run's backup in progress.

Many tables ​

LMDB needs the number of named tables (sub-databases) declared when an environment is opened. max_named_dbs in [source] sets it: default 128, allowed 1 to 4096. monero-lws uses 13. If a database has more tables than the limit, verify stops with an error telling you to raise it.

Pointing db_path at the right thing ​

db_path is normally the environment folder that holds data.mdb and lock.mdb. The tool also handles these cases:

db_path isWhat happens
A folderOpened as the environment.
A file named data.mdb with a lock.mdb next to itTreated as its folder. Opening the file directly would use a different lock file from the running application, and the copy could be inconsistent.
Any other fileOpened as a single-file environment, with the lock file <file>-lock.
A path that does not existPassed to LMDB, which reports the usual "not found" error.

If both lock.mdb and data.mdb-lock exist, the tool cannot tell which one the application uses and refuses to open the database (ambiguous LMDB layout). Delete the stale lock file, the one no running process has open, and run again.

Next steps ​