Backups

One command makes a complete backup while Ronne runs: the database (whichever kind), the stored items and plugins, and the settings file, in one archive. It reads one consistent moment of the database, so people keep working meanwhile. Upgrades can't be undone, so a backup is also the way back.

The archive is as sensitive as the server: with the settings file, it holds AUTH_SECRET and the database's password. It's written readable only by its owner; encrypt the copies that leave the machine.

• --keep 14 removes the oldest archives in the folder beyond 14, after a backup that succeeded.
• --encrypt seals it with a passphrase (.tar.enc), asked in a terminal or read from --passphrase-file or RONNE_BACKUP_PASSPHRASE. A lost passphrase can't be recovered.
• --verify ARCHIVE checks an archive without restoring it: every checksum, and every released version's file.
• --no-settings leaves the settings file out; keep a copy of it elsewhere.

On a schedule: Ronne has none of its own; the system's scheduler runs the command. Daily, keeping two weeks, is a good start, for example in root's crontab:

15 3 * * * /usr/bin/rmk-server backup --keep 14 >> /var/log/rmk-server-backup.log 2>&1
15 3 * * * cd /opt/ronne-marketplace && docker compose exec -T web pnpm run backup --keep 14 >> /var/log/ronne-backup.log 2>&1   # Docker

A backup holds personal data: what the database held when it was made, IP addresses and all. Keep backups no longer than the retention root set (Privacy).

Keep copies off the machine: a backup on the same disk doesn't survive the disk. The archive is a plain file: copy it with rsync, rclone or your cloud's tool (from Docker, take it out of the volume first with docker compose cp web:/app/data/backups/. ./ronne-backups/). Now and then, restore one somewhere and start it: that's the only check that it restores.

The backup runbook has the systemd timer, launchd and cron set-ups, encrypted schedules, Caddy's certificates and timings.

Restore goes only into an empty database and storage, with Ronne stopped. It checks the whole archive first and changes nothing when the archive was cut or altered, comes from a newer Ronne, or the target isn't empty. Then it restores the rows and files, runs the database changes the installed version has since, and writes or keeps the settings file. With a Linux service (on macOS, in the data folder rmk-server service status shows):

sudo rmk-server service stop
cd /var/lib/rmk-server
sudo mkdir -m 700 before-restore && sudo mv ronne.db* storage before-restore/
sudo rmk-server restore /var/lib/rmk-server/backups/ronne-backup-20261014-130541.tar
sudo rmk-server service start

• Docker: stop web, move the data aside inside the volume, then docker compose run --rm --no-deps web pnpm run restore ARCHIVE and docker compose up -d. With the bundled PostgreSQL or MySQL, empty that database instead.
• On another machine: install Ronne the same way without running its setup, copy the archive over, and restore with --with-settings: the backup's settings come along, with the new machine's database and storage.
• Into another kind of database: a backup restores into SQLite, PostgreSQL, MySQL or MariaDB, whatever it came from: the way to move an instance that outgrew SQLite. Make an empty database and name it with --database-url.

Sign-ins: with --with-settings on a machine with no settings file yet, or with the same settings file, everyone stays signed in. Restored without the backup's settings, the instance gets a new AUTH_SECRET: everyone signs in again. Access tokens keep working either way, so rmk and the MCP server carry on. Two-factor secrets are encrypted with the backup's AUTH_SECRET: when the restored instance will run with another one, the restore turns two-factor off for everyone who has it, and says how many (for a backup with no settings, it tries one with the secret the instance will use). Identity providers' client secrets are encrypted the same way: restored with another AUTH_SECRET, the provider shows Failing until root enters its client secret again (Lockout and broken providers). Each restore is recorded in the audit log, on top of the restored history. An account erased after the backup was made comes back with it, personal data included: erase it again.