How to restore my old Trillium backup to a new server

[AumCoin]

I installed Trillium on my old Debian 11 device in 11/2025 and have been using it since. I installed a new Debian 13 server on another machine, "initialized it" by visiting it in a browser and setting up a password etc., and then copied document.db from my old system to the new one, replacing the newly-installed document.db. The system just kept restarting over and over. So I started over, and this time copied a weekly backup file. This had the same result. How can I restore my old data?

[dosubot[bot]]

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

To restore your Trilium backup to a new server, make sure you follow these steps exactly:

1. Stop or kill the Trilium server process.
2. In your Trilium data directory (by default ~/trilium-data, but check if you use the TRILIUM_DATA_DIR environment variable), delete these files: document.db, document.db-wal, and document.db-shm. The -wal and -shm files are automatically recreated and must be removed to avoid restart loops or corruption.
3. Copy your backup file (for example, backup-weekly.db) into the data directory and rename it to document.db.
4. Ensure the new document.db file is writable by the Trilium server process (e.g., run chmod 600 document.db).
5. Start the Trilium server.

If you skip deleting the -wal and -shm files, Trilium may get stuck in a restart loop because those files reference the old database state and can cause consistency errors in WAL (Write-Ahead Logging) mode. This is a common cause of the issue you described (source, official docs).

Also, make sure both your old and new servers are running the same Trilium version to avoid database incompatibility issues (source). If the problem persists, check file permissions and review the server logs for any error messages.

Let me know if you need help finding your data directory or interpreting any error logs.

To reply, just mention @dosu.

---

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

   

[AumCoin]

The above did not resolve my issue. document.db-wal and document.db-shm were not present.

[dosubot[bot]]

The absence of document.db-wal and document.db-shm files does not rule out database corruption or version incompatibility—these files may not exist if the database was cleanly shut down, but Trilium can still enter a restart loop if the main document.db is corrupted or incompatible with the server version. This is a common symptom when restoring from a backup that is itself corrupted, or when there is a version mismatch between the old and new servers, especially if intermediate upgrades were skipped or the backup was not created using Trilium's built-in backup feature (source, source).

To diagnose further, please provide:

• The latest log files from your trilium-data/log directory after a failed restore attempt.
• The exact Trilium version numbers on both your old and new servers.
• How the backup was created (Trilium's built-in backup/export or manual file copy).
• Confirmation that there are no extra files in the data directory (like session_secret.txt or lock files).
• The data directory path in use (and whether TRILIUM_DATA_DIR is set).

These details will help pinpoint whether the issue is database corruption, version incompatibility, or something else.

To reply, just mention @dosu.

---

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

   

[AumCoin]

I also tried a sync but I get a sync version error mismatch.

[dosubot[bot]]

A "sync version error mismatch" means your Trilium instances are running different versions, so their sync protocols don't match and syncing is blocked. To fix this, make sure both your server and client are running the exact same Trilium version—update whichever side is older so both match. This is the only way to resolve the sync protocol mismatch and allow syncing again details & example.

If you still see sync errors after aligning versions, it could be a document ID mismatch (which can happen after restoring backups or re-initializing). In that case, pick the most up-to-date database, back it up, and re-initialize the other side with that backup before setting up sync again see explanation.

If you need help with the exact steps for your setup, let me know which side has your latest notes and the Trilium versions in use.

To reply, just mention @dosu.

---

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

   

[AumCoin]

@dosu

The absence of document.db-wal and document.db-shm files does not rule out database corruption or version incompatibility—these files may not exist if the database was cleanly shut down, but Trilium can still enter a restart loop if the main document.db is corrupted or incompatible with the server version. This is a common symptom when restoring from a backup that is itself corrupted, or when there is a version mismatch between the old and new servers, especially if intermediate upgrades were skipped or the backup was not created using Trilium's built-in backup feature (source, source).

To diagnose further, please provide:

* The latest log files from your `trilium-data/log` directory after a failed restore attempt.

* The exact Trilium version numbers on both your old and new servers.

* How the backup was created (Trilium's built-in backup/export or manual file copy).

* Confirmation that there are no extra files in the data directory (like `session_secret.txt` or lock files).

* The data directory path in use (and whether `TRILIUM_DATA_DIR` is set).

These details will help pinpoint whether the issue is database corruption, version incompatibility, or something else.

To reply, just mention @dosu.

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

trilium-2025-12-22.log

OLD SERVER
App version: 0.59.4
DB version: 213

NEW SERVER
App version: 0.100.0
DB version: 233

The backup was created with Trillium's internal scheduled backup feature.

There is a file session_secret.txt in the data folder on both the new and old servers.
There are also files document.db-shm and document.db-wal. Both files are deleted when the server is stopped. I stop the container on the new machine before replacing document.db. Am I supposed to replace document.db while the container is running?

The old data directory was /root/docker/storage/trilium-data. The new data directory is /root/trilium-data.

[dosubot[bot]]

Your log shows repeated SqliteError: database disk image is malformed, which means your database file is corrupted. This is the cause of the restart loop—not a version incompatibility. The only reliable fix is to restore from a valid backup.

Here’s the safest restore procedure:

1. Stop the Trilium server/container.
2. Delete document.db, document.db-wal, document.db-shm, and (optionally) session_secret.txt from your data directory.
3. Copy your backup (e.g., backup-weekly.db) to the data directory and rename it to document.db.
4. Make sure document.db is writable by the server (e.g., chmod 600 document.db).
5. Start Trilium.

If your backup is also corrupted, try older backups. If none work, you can attempt SQLite repair tools, but recovery is unlikely and data loss is probable.

Once you have a valid backup, you can upgrade directly from 0.59.4/213 to 0.100.0/233—Trilium will handle migrations automatically on startup. Make sure all clients are updated to the same version before syncing to avoid protocol mismatches. Never replace document.db while the server is running—always stop it first (source, official docs).

If you see new errors after following these steps, share the latest log and I can help interpret them.

To reply, just mention @dosu.

---

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

   

[cwlind]

I found that the 'easiest' way to transfer your db, is to export your top-level note (and all sub-notes) to a zip file. Then, in the new instance, click the top level (usually root), and right-click and select 'Import into note', and select your zip file. For me, this was the easiest and cleanest to at least get the data into a new instance without pulling out more hair trying to find a solution to version incompatibility.
Hope that helps! (if you just need the notes/formatting)