Hi @Revali25! I'm Dosu and I’m helping the Trilium team.

Starting with a new database in Trilium does overwrite any existing data in the database file—there’s no automatic backup or archival of the previous data at that moment. If you didn’t manually back up your database file (usually called document.db), the old notes are likely lost from that file, unless you have a backup elsewhere or on another device. Trilium does create daily automatic backups by default, so check your Raspberry Pi’s Trilium data directory for files like backup-daily.db or similar—restoring one of these can recover your notes if available (details, docs).

The 400 error during sync or login is usually caused by a mismatch between the sync protocol versions of your client and server, or by incorrect sync credentials (for example, if the document secret doesn’t match between devices). This can happen if the server and client are running different Trilium versions, or if the local database was reset and no longer matches the server’s sync state (source).

If you have backups, you can restore them by replacing the current document.db with a backup file and restarting Trilium. If you were syncing with a server and the server still has your notes, you can try deleting your local data folder and re-syncing from the server. If not, your best bet is to look for those automatic backups on your Raspberry Pi or any manual backups you may have made.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

I replaced my document.db with a backup db and now it's saying that the database is malformed

A "database is malformed" error means the SQLite database file (document.db) is corrupted or incompatible and can't be read by Trilium. This often happens if you restore a backup while Trilium is running, if there are leftover document.db-wal or document.db-shm files, if the backup itself is corrupted, or if there's a version mismatch between the backup and your Trilium install (details, more).

To properly restore a backup:

1. Stop Trilium completely.
2. In your data directory, delete document.db, document.db-wal, and document.db-shm.
3. Copy your backup file into the data directory and rename it to document.db.
4. Make sure document.db is writable by Trilium.
5. Start Trilium.

If you still get the malformed error, the backup file itself may be corrupted. Try restoring from an older backup if you have one. If none of your backups work, recovery is unlikely, but you can try SQLite repair tools (with low success rate), or—if you have access to any working Trilium instance—export your notes as a zip and import them into a new instance (source).

If you want more targeted help, let me know which backup file you used, whether Trilium was stopped during the restore, and if you have other backups available.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

Trilium doesn't support changing the built-in backup frequency to every 6 hours (or any custom interval) through its UI, config.ini, or environment variables—the built-in automatic backup is daily and not user-configurable beyond that (source).

If you want more frequent backups, you can automate periodic exports using Trilium's ETAPI (HTTP API) and schedule them with cron (Linux) or Task Scheduler (Windows). For example, to export your notes every 6 hours:

1. Get your ETAPI token from Trilium's Options → ETAPI.
2. Find your root note's ID (usually "root").
3. Use a command like:

   curl -H "Authorization: <YOUR_ETAPI_TOKEN>" \
     "http://localhost:8080/etapi/notes/root/export?format=html" \
     -o /path/to/export/trilium-export-$(date +%F-%H%M).zip

4. Schedule this command to run every 6 hours with cron or Task Scheduler (details).

This approach gives you flexible, frequent backups without interfering with Trilium's built-in backup system.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

okay this is really weird. on my desktop computer, I have access to the database, but on my laptop I try accessing the server with the web address, and also with the electron app, and the behavior is the same as before. The electron app says "Sync in progress" but never actually progressing past that, and the server website is asking me to set up the database. Accessing it from my phone asks for the password I set when I accidentally overwrote the database earlier. I haven't been able to SSH into the server because I accidentally lost my ssh key, I'm working on fixing that but is it possible somehow that Docker is running two containers and for whatever reason my desktop is accessing one of them, and the other devices are accessing another? On my desktop I'm able to access the database with both the website and the electron app, so I'm just super confused now.