iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The safest Trilium Notes recovery plan has two layers: use Trilium’s built-in backup points, then keep a copy outside the application’s data directory. The file that matters most is document.db, a SQLite database containing your notes, tree structure, metadata, and most configuration. Trilium stores its automatic copies in a backup folder beneath that data directory.
Restoring is a file replacement, not an in-app undo: stop Trilium, preserve the current database, remove the active database and SQLite sidecar files, copy a selected backup into place as document.db, make it writable, and restart. If synchronization is configured, restore every member of the sync cluster before allowing them to reconnect; otherwise a newer member can overwrite the older restored state.
What a Trilium backup contains
Trilium’s primary knowledge-base database is document.db, a SQLite file in the application’s data directory. The project’s database documentation says this file stores notes, the note tree, metadata, and most configuration. A copy of this file is therefore the central recovery artifact, not merely an export of note text. Read the Trilium database documentation for the project’s description of the schema and its warning that advanced users should back up before modifying the database directly.
Recommended Free Tools
SQLite can also create document.db-wal and document.db-shm beside the main file. They are generated working files, not separate knowledge bases. The documented restore process removes them with the active database before putting the selected backup in place, so a stale write-ahead log cannot be applied to the restored file.
#1 Best Overall
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Find the real data directory
Do not assume that a desktop installation, a self-hosted server, and a container use the same path. Open Trilium’s About Trilium Notes menu and use the displayed data-directory location. The backup guide uses ~/trilium-data as an example only; it is not a universal location. Record the exact path, the account or service that runs Trilium, and whether a service manager or container controls the process.
Trilium is cross-platform, and the current project repository directs users to current documentation and in-app help. The older documentation repository was archived on March 9, 2025, so confirm labels and operational details against the help included with your installed release and deployment. Useful starting points are the current Trilium project repository and its documentation index.
Trilium’s built-in backup points
The documented built-in scheme creates database copies at four events:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Backup event | Typical file or location | What the documentation establishes |
|---|---|---|
| Daily | backup directory under the data directory |
A daily point is part of the documented schedule. |
| Weekly | For example, backup/backup-weekly.db |
The guide uses this filename when explaining a weekly restore. |
| Monthly | backup directory under the data directory |
A monthly point is part of the documented schedule. |
| Before a database migration | backup directory under the data directory |
A pre-migration point is created according to the guide. |
The guide describes at most four backups from different points in time. That is a description of the documented built-in scheme, not a guarantee that every current release or deployment has identical retention behavior. Treat these files as a small rolling safety net rather than a complete historical archive.
Inspect the backup directory before relying on a particular point. Check the filename, modification date, and file size, and make sure the copy belongs to the data directory used by the instance you intend to recover. The official procedure is documented on the Trilium backup page.
Rank #2
- Easily store and access 5TB of content on the go with the Seagate portable drive, a USB external hard Drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Why a second copy is necessary
The project documentation calls the built-in arrangement “This is only very basic backup solution, and you’re encouraged to add some better backup solution – e.g. backing up the document to cloud / different computer etc.” That advice addresses a different failure mode: if the disk, server, account, or data directory is damaged, copies stored beside the live database can be lost at the same time.
| Approach | Strength | Limitation | Best use |
|---|---|---|---|
| Built-in daily, weekly, monthly, and pre-migration points | Automatic and close to the application; no separate scheduling system is required. | Only a small rolling set is documented, and it remains under the same data-directory failure boundary. | Quick rollback from a recent mistake or failed migration. |
| Separate cloud copy | Places a copy outside the local machine or server. | You must arrange scheduling, access control, retention, and restore testing yourself; no provider is specified by the project documentation. | Protection against local disk or host loss. |
| Copy on a different computer | Provides physical or administrative separation from the live instance. | Requires a reliable copy process and enough storage on the other computer. | Self-hosted deployments that need an independent recovery location. |
| Portable external drive | A practical physical way to hold a second copy when disconnected storage is appropriate. | It is optional, can be lost or damaged, and is not a Trilium requirement or a model-specific recommendation. | An additional offline or rotated copy of the database. |
Keep the second copy separate from the live backup folder. Copying the folder to another location on the same failing disk improves convenience but does not provide the same protection as a different computer, cloud destination, or removable drive.
Prepare before making a copy
- Identify the instance. If more than one Trilium installation exists, record which data directory belongs to the knowledge base you need to protect.
- Understand process control. A desktop app may be stopped from its window; a server may require stopping a service, supervisor, or container. Know the correct shutdown method before touching database files.
- Plan storage. Verify that the destination can hold the database and the retained copies. Keep the original filename and record the copy date in the destination’s folder or filename.
- Protect access. A knowledge base can contain confidential notes. Use access controls appropriate to the destination and avoid placing an unprotected copy in a broadly shared folder.
- Decide what must be recoverable. Preserve the active database and, when practical, the built-in
backupdirectory. A single recent copy cannot recover an older state that has already been overwritten.
The backup guide gives a restore procedure that starts with stopping Trilium. It does not provide a guaranteed-consistent recipe for copying a live SQLite database. Do not assume that an ordinary file copy made while Trilium is writing is a valid snapshot. For a planned manual copy, schedule a short maintenance window and stop the instance first. If your deployment requires continuous availability, follow the backup mechanism and shutdown instructions for that specific release rather than improvising a live file copy.
Make a manual, recoverable copy
The following workflow supplements the built-in points with a separately retained copy. It deliberately avoids assuming a universal path.
- Open About Trilium Notes and record the data directory. Use the path shown by your installation, not the example
~/trilium-data. - Stop Trilium cleanly. Close the desktop application, stop the server service, or stop the container that owns the data directory. Confirm that no second Trilium process is still using the same files.
- Inspect the source. Confirm that
document.dbis present and that thebackupdirectory contains the expected built-in points. Do not substitute a database from another profile or installation. - Copy the database to a separate destination. On a Unix-like system, after setting
TRILIUM_DATA_DIRto the actual path, a basic stopped-instance copy can be expressed ascp "$TRILIUM_DATA_DIR/document.db" /separate-backup-location/. Use your platform’s normal file-copy tool on Windows or another operating system. The destination should be outside the source data directory. - Retain useful recovery points. If storage allows, copy the
backupdirectory as well. Keep the source filename and add a date to the destination folder or file record so you can distinguish copies made before and after a change. - Record the release and deployment. Note the Trilium version, operating system, whether the instance is desktop or self-hosted, and any sync configuration. This makes a later recovery decision less ambiguous.
- Restart only after the copy completes. Check that the destination file exists and has a plausible size before bringing the instance back online.
For a routine protection schedule, combine the built-in points with a separately maintained copy rather than deleting the built-in files after exporting them. The two layers serve different purposes: one gives convenient recent rollback points, while the other survives a failure of the original host or data directory.
Rank #3
- Easily store and access 1TB to content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop. Reformatting may be required for Mac
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Critical warning when sync is configured
If this knowledge base participates in a sync cluster, restore the chosen database on every cluster member before allowing the members to synchronize again. The backup documentation warns that restoring only one member can cause its older database to be detected and synchronized toward the newer state on another member. In that situation, a technically correct file replacement can appear to “fail” because synchronization brings newer content back.
List every member, identify how each one is stopped, and keep all of them disconnected from synchronization while the replacement is performed. Do not restart one restored member into a live cluster while another member still has the newer database. The documentation does not specify a newer conflict-resolution workflow, so use the installed release’s in-app help for any version-specific sync recovery instructions.
Manual restore procedure
Use this procedure for a desktop or self-hosted instance when you have selected a database backup. The guide’s weekly example is backup/backup-weekly.db; choose the point that matches your recovery objective.
- Choose the recovery point. Locate the intended file under the correct data directory. Confirm its date and filename before changing anything.
- Preserve the current state. Make a separate copy of the current
document.dbbefore replacement if there is any chance you will need notes or changes created after the backup. For example, a dated name such asdocument.db.before-restore-2026-10-16distinguishes it from the replacement. Keep this copy outside the active data directory or in a clearly separate folder. - Stop Trilium completely. Close the app or stop the service, supervisor, or container. A database that is still open can be locked or can receive writes during the replacement.
- Coordinate sync members. If sync is configured, stop or isolate every member and do not reconnect any member until all have been restored to the coordinated point.
- Open the data directory identified in About Trilium Notes. Do not run removal commands in an arbitrary working directory. On a Unix-like shell, set
TRILIUM_DATA_DIRto the displayed path and change into it. - Remove the active database and SQLite sidecars. Delete
document.db,document.db-wal, anddocument.db-shmfrom that data directory. The sidecar files may not exist; the important point is that no old sidecar is left beside the restored database. - Copy the selected backup into place as
document.db. With the guide’s weekly example, the operation is conceptuallycp backup/backup-weekly.db document.dbafter you have verified the path. On another operating system, use its file-copy operation and rename the destination exactly todocument.db. - Make the file writable by Trilium. The backup page gives
chmod 600 document.dbas an example. Apply the equivalent permission and ownership for your platform and the account that runs Trilium; the process must be able to read and write the restored database. - Start Trilium and inspect the result. Confirm that expected notes, hierarchy, and recent configuration are present. Look for startup errors before making new edits.
- Restore the remaining sync members. Repeat the same coordinated replacement on every member, then reconnect synchronization only after all members contain the intended recovery point.
Do not skip the preservation step merely because the selected backup looks correct. The pre-restore copy is your route back if you chose the wrong date, discovered missing notes, or need to extract a newer change later.
Choosing the right recovery point
| Situation | Point to consider | Decision question |
|---|---|---|
| A mistaken edit or deletion discovered quickly | Most recent daily point, if it predates the mistake | How much legitimate work since that point can you recreate? |
| A problem noticed after several days | Weekly point, such as backup/backup-weekly.db |
Does the weekly copy precede the first known bad state? |
| A long-running issue or corruption | Monthly point or a separately retained copy | Which dated copy is known to be from before the problem? |
| A failed database migration | Pre-migration point | Was the point created immediately before the migration in question? |
| Unknown or mixed damage | Preserve the current database, then inspect available points | Can you compare dates and files without destroying evidence? |
The built-in schedule does not preserve every historical day indefinitely. If the only available point is too recent, do not invent a recovery history that the files cannot provide. Use the separately retained copies you have, document the resulting loss window, and improve retention for the next cycle.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsRank #4
- High capacity in a small enclosure – The small, lightweight design offers up to 6TB* capacity, making WD Elements portable hard drives the ideal companion for consumers on the go.
- Plug-and-play expandability
- Vast capacities up to 6TB[1] to store your photos, videos, music, important documents and more
- SuperSpeed USB 3.2 Gen 1 (5Gbps)
Verify after the restart
- Open several notes from different parts of the tree, not only the home note.
- Check tags, attributes, and other metadata that matter to your workflow.
- Confirm that the application can create and edit a test note, then remove that test note if appropriate.
- Check the data directory for a newly writable
document.dband confirm that Trilium is not reporting a permission or database error. - If synchronization is enabled, verify that every member was restored before reconnecting and watch for unexpected changes after reconnection.
- Keep the pre-restore database until you have completed this inspection and decided that the restored state is acceptable.
A restore is successful only when the application opens the intended state and can continue writing to it. A file that exists but is read-only, belongs to another instance, or is immediately replaced by synchronization is not a usable recovery.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshooting common failures
The expected backup file is not present
Check that you opened the data directory for the correct installation and that you are looking inside its backup directory. The documented scheme keeps at most four points, so an older date may already have rolled out. Also check separately retained copies; do not assume the built-in folder is an archive of every day.
Trilium says the database is locked or the restore appears incomplete
Stop every process that can access the data directory, including a service or container that may restart automatically. Remove the old document.db-wal and document.db-shm as specified by the restore procedure, then repeat the copy with the application stopped.
The application cannot write after restoration
Check that the replacement is named exactly document.db, is in the data directory shown by About Trilium Notes, and is writable by the account running Trilium. On Unix-like systems, the documentation’s example is chmod 600 document.db; adjust ownership or equivalent permissions when the service runs under a different account.
Newer notes return after the restore
This is the high-risk sync scenario. Stop synchronization, preserve the current files, and check every cluster member. The documented warning is that an older restored database can be synchronized toward a newer member. Coordinate the restore across all members before reconnecting them.
Best Value
- Plug-and-play expandability
- SuperSpeed USB 3.2 Gen 1 (5Gbps)
The restored database opens, but expected content is missing
Stop editing that instance and preserve it as another dated copy. You may have selected a point from after the loss, used the wrong data directory, or restored only one member of a sync cluster. Compare the dates and locations of the available copies before attempting another replacement.
Version and deployment considerations
The procedure above follows the TriliumNext backup guide, but the guide repository is archived and deployments differ. Desktop builds, self-hosted services, and containers can use different startup, shutdown, permission, and volume-management commands. A container may store the data directory in a mounted volume; a server may require a service stop rather than a window close.
Before a real incident, open the installed application’s help and confirm the current data-directory label, backup behavior, and service instructions for your release. Use the current project repository and its documentation links as the version-aware starting point, while treating the archived documentation repository as the source of the backup procedure described here.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →A practical maintenance checklist
- Locate and record the data directory through About Trilium Notes.
- Confirm that the built-in
backupdirectory is being populated. - Maintain a second copy on a different computer, in cloud storage, or on optional removable storage.
- Use a dated naming convention and retain enough history for the mistakes you realistically need to undo.
- Schedule manual copies only when the instance is stopped unless your release documents a consistent live-backup method.
- Before replacing files, preserve the current
document.db. - During a sync recovery, restore every cluster member before reconnecting synchronization.
- Periodically open a copy in a controlled environment or otherwise verify that your recovery files are readable and writable.
- Recheck the instructions after upgrading Trilium or changing from desktop to self-hosted or container deployment.
With those controls, Trilium’s automatic points become one layer of recovery instead of the entire plan: document.db remains identifiable, an independent copy protects against local failure, and the restore sequence avoids both SQLite sidecar problems and sync-cluster rollback.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
