Backups

Um comando faz um backup completo enquanto o Ronne roda: o banco de dados (seja qual for), os itens e plugins armazenados e o arquivo de configurações, num só arquivo. Ele lê um momento consistente do banco, então as pessoas continuam trabalhando. Uma atualização não pode ser desfeita, então o backup também é o caminho de volta.

O arquivo é tão sensível quanto o servidor: com o arquivo de configurações, ele guarda o AUTH_SECRET e a senha do banco de dados. Ele é gravado legível só pelo dono; criptografe as cópias que saem da máquina.

• --keep 14 apaga os arquivos mais antigos da pasta além de 14, depois de um backup que deu certo.
• --encrypt o protege com uma frase-senha (.tar.enc), pedida no terminal ou lida de --passphrase-file ou RONNE_BACKUP_PASSPHRASE. Uma frase-senha perdida não tem como ser recuperada.
• --verify ARCHIVE confere um arquivo de backup sem restaurá-lo: cada checksum e o arquivo de cada versão lançada.
• --no-settings deixa o arquivo de configurações de fora; guarde uma cópia dele em outro lugar.

Num agendamento: o Ronne não tem um próprio; o agendador do sistema roda o comando. Diário, guardando duas semanas, é um bom começo, por exemplo no crontab do root:

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

Um backup guarda dados pessoais: o que o banco de dados tinha quando foi feito, endereços IP e tudo. Não guarde backups por mais tempo que a retenção que o root definiu (Privacidade).

Guarde cópias fora da máquina: um backup no mesmo disco não sobrevive ao disco. O backup é um arquivo comum: copie com rsync, rclone ou a ferramenta da sua nuvem (no Docker, tire-o do volume antes com docker compose cp web:/app/data/backups/. ./ronne-backups/). De vez em quando, restaure um em algum lugar e inicie: é a única forma de saber que ele restaura.

O runbook de backup tem o timer do systemd, o launchd e o cron, agendamentos criptografados, os certificados do Caddy e tempos medidos.

A restauração só vai para um banco de dados e um armazenamento vazios, com o Ronne parado. Ela confere o arquivo inteiro antes e não muda nada quando o arquivo foi truncado ou alterado, vem de um Ronne mais novo, ou o destino não está vazio. Depois restaura as linhas e os arquivos, roda as mudanças de banco que a versão instalada tem desde então, e grava ou mantém o arquivo de configurações. Com um serviço no Linux (no macOS, na pasta de dados que rmk-server service status mostra):

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: pare o web, tire os dados do caminho dentro do volume, depois docker compose run --rm --no-deps web pnpm run restore ARCHIVE e docker compose up -d. Com o PostgreSQL ou MySQL incluídos, esvazie esse banco em vez disso.
• Em outra máquina: instale o Ronne do mesmo jeito sem rodar o setup dele, copie o arquivo e restaure com --with-settings: as configurações do backup vêm junto, com o banco e o armazenamento da máquina nova.
• Para outro tipo de banco: um backup restaura em SQLite, PostgreSQL, MySQL ou MariaDB, venha de onde vier: o jeito de mudar uma instância que ficou grande demais para o SQLite. Crie um banco vazio e informe-o com --database-url.

Logins: com --with-settings numa máquina ainda sem arquivo de configurações, ou com o mesmo arquivo de configurações, todos continuam conectados. Restaurado sem as configurações do backup, a instância ganha um AUTH_SECRET novo: todos entram de novo. Os tokens de acesso continuam valendo nos dois casos, então o rmk e o servidor MCP seguem funcionando. Os segredos do login em duas etapas são criptografados com o AUTH_SECRET do backup: quando a instância restaurada for rodar com outro, a restauração desativa o login em duas etapas de todos que o têm e diz quantos (para um backup sem configurações, ela tenta um com o segredo que a instância vai usar). Os client secrets dos provedores de identidade são criptografados do mesmo jeito: restaurado com outro AUTH_SECRET, o provedor mostra Failing até o root digitar o client secret dele de novo (Bloqueio e provedores com falha). Cada restauração fica registrada no log de auditoria, por cima do histórico restaurado. Uma conta apagada depois de o backup ser feito volta com ele, dados pessoais incluídos: apague-a de novo.