Verify and restore a backup

--verify checks a backup without writing anything. --restore decrypts a backup into a normal LMDB environment you can open. Both need the encryption key the backup was made with.

The commands on this page load the key from /etc/lmdb-lws-backup/key.env, as set up in the beginner guide. If you use a key_file instead, drop the sh -c wrapper and run sudo lmdb-lws-backup ... directly.

Find the backup you want

sudo lmdb-lws-backup --config /etc/lmdb-lws-backup/config.toml --list

Backups are listed newest first. ITEMS is the account count (monero-lws) or row count (other databases), from each backup's manifest. bad-manifest means the manifest could not be read; - means there is none.

Verify a backup

sudo sh -c 'set -a; . /etc/lmdb-lws-backup/key.env; exec lmdb-lws-backup --config /etc/lmdb-lws-backup/config.toml --verify /var/backups/monero-lws/lws-backup-20261109.lmdbbak.enc'

Verify decrypts the backup into memory (never to disk), opens it as an LMDB database and reads every table end to end. It then compares the result with the backup's .manifest.json, if one is next to it.

A good backup prints verify ok: followed by:

Line	Meaning
profile:	monero-lws or generic; see Profiles.
accounts: and scan height:	monero-lws only: wallet accounts, and the lowest and highest block height they have been scanned to.
tables: and total rows:	Tables and rows read.
plaintext bytes:	Size of the decrypted database.
sha256:	Checksum of the encrypted file.
manifest:	matches, or (none found) if there is no manifest.

The command exits with 0 when the backup is good and 1 when it is not.

When verify fails

Message	What it means
verify FAILED: decryption failed: wrong key or corrupted/tampered data	The key is not the one this backup was made with, or the file has been damaged or changed.
verify FAILED: invalid stream header (wrong key or corrupt file)	Same causes, detected at the start of the file.
verify FAILED: not an lmdb-lws-backup encrypted file (bad magic)	The file is not a backup made by this tool.
verify FAILED: encrypted file truncated ...	The file is incomplete, for example from an interrupted copy.
MISMATCH: manifest sha256 differs from file ...	The encrypted file was changed after the backup was made.
MISMATCH: manifest account_count ... or total_rows ...	The decrypted contents do not match what the manifest recorded.

Try another backup, and check that you are using the right key. If a [alerting] on_failure_webhook is configured, a failed verify also calls it.

Restore a backup

DANGER

A restore writes the decrypted database to disk. For monero-lws that includes every user's view key in plain form. Restore only to a folder on an encrypted filesystem, or one you control fully, and delete the restored copy as soon as you no longer need it.

1. Choose an empty target folder, for example /root/recovered. It must not already contain a data.mdb.

2. Run the restore:

   sudo sh -c 'set -a; . /etc/lmdb-lws-backup/key.env; exec lmdb-lws-backup --config /etc/lmdb-lws-backup/config.toml --restore /var/backups/monero-lws/lws-backup-20261109.lmdbbak.enc --to /root/recovered'

3. Read the result. A successful restore prints restored ... -> /root/recovered/data.mdb, then the account and row counts (monero-lws) or table and row counts (other databases), and a note reminding you that the folder holds decrypted data.

What the restore does, in order:

• Creates the target folder if needed, and sets its permissions to 700 (owner only). This also applies to a folder that already exists.
• Refuses to continue if the folder already has a data.mdb, so it never overwrites a database.
• Decrypts the backup into data.mdb with mode 600.
• Opens the result as an LMDB environment and reads every table.
• If any step fails, deletes the decrypted data.mdb (and the lock.mdb created by opening it), so no plaintext is left behind.

The profile from your configuration, or --profile, applies here too. With profile = "monero-lws", restoring a backup that has no accounts table fails.

Put a restored database back into service

lmdb-lws-backup deliberately stops at producing the restored folder. Pointing monero-lws, or your own application, at it is up to you. Whatever your procedure:

• Stop the server before you replace its database.
• Keep the current database folder (rename it rather than deleting it) until the restored one is confirmed working.
• Give the restored files the owner and permissions the server expects.

Next steps

• Keys and security
• Troubleshooting and FAQ