All of this comes from @famewolf in #2, after a week in which he lost his configuration more than once and had to rebuild three hosts by hand.
/backup in Telegram, as a file
Can we get a /backup option in telegram that sends the backup as a file VIA telegram?
The same bundle the Web UI exports — settings, groups, pins, auto-update flags, notes, links, update windows — uploaded straight into the chat. Restoring used to mean reaching a browser on the machine you are trying to repair, which is exactly the machine you cannot reach when it matters.
The chat is already the trusted channel: CHAT_ID plus the allow-list gate every command, and the file goes back to that chat and nowhere else. It still contains webhook URLs and the Web UI password hash, so the command says so instead of shipping it quietly.
A copy that lives next to the data
I would REALLY REALLY like it if backups stored a local copy so restores are not dependent on another machine to get going again […] In every case I've lost a config having a copy in the docksentry container directory would have solved the issue.
/data/backups/ now gets one on startup and after anything that changes state, debounced so a burst of saves makes one file rather than ten. Five are kept.
The obvious objection is that a backup inside the volume it backs up protects against nothing. It protects against what actually keeps happening: a settings.json lost while the rest of the directory survives, or a restore needed from a browser that is not to hand. It is not a substitute for the copy you keep somewhere else and does not pretend to be.
And a way back from one. If settings.json is missing on startup and this directory has held one before, the newest copy is restored automatically and the log names the file. Settings only — groups, pins and links live in their own files and survive on their own, so pulling those from an older backup would overwrite live state to fix a problem they never had. A boot that lost settings and could not repair them writes no new copy, because archiving the damage would evict the good ones.
Restore on the wizard's first page
Why force the user to go through the setup wizard if they plan to import a backup? It should be on the first page as an option to skip the click-through's.
Quite right. By the time you are restoring, you are usually having a bad day already. The file carries the "setup done" flag, so a successful restore ends the wizard as well as filling it in.
A beta tag
Please consider a seperate developmental chain (beta) that is opt in for future large changes. We could have ran them in parallel with seperate containers/directories.
beta moves with pre-releases the way latest moves with stable ones, so trying one alongside your real instance is a single compose change rather than a new pin every time. latest is never moved by a pre-release, exactly as before.
Also
Backup filenames no longer fall back to a container id. Without a BOT_LABEL, HOSTNAME inside a container is usually the container id, and docksentry-backup-9cef9348bc8f-… is worse than no name — it looks like it means something. Set BOT_LABEL and your backups carry it.
Nothing to do on upgrade.