Бэкап и восстановление Trilium Notes

MAATRIX

Trilium Notes — удобная штука ровно до момента, когда вы понимаете, что вся ваша база знаний, годы заметок с вложенными деревьями, кодом и вложениями, лежит в одном-единственном файле на диске одного сервера. В отличие от заметок в облачном сервисе, здесь не с кого спросить в случае сбоя диска — резервное копирование целиком на вас. Хорошая новость: устройство Trilium простое (одна SQLite-база), и бэкап делается за несколько строк в cron, если понимать, что именно и как копировать.

Что и где хранит Trilium

Вся содержательная часть — дерево заметок, текст, код-блоки, метаданные, ревизии, теги, связи между заметками и (в современных версиях) сами вложения — лежит в одном файле document.db, это обычная SQLite-база. Рядом с ней в той же директории данных находятся ещё несколько файлов, о которых легко забыть при бэкапе:

Директория данных по умолчанию — ~/.local/share/trilium-data при обычной установке на Linux, или /home/node/trilium-data внутри контейнера при Docker-развёртывании. Путь можно переопределить переменной окружения TRILIUM_DATA_DIR.

Важный нюанс: Trilium работает в WAL-режиме SQLite (Write-Ahead Logging) — это значит, что часть свежих изменений может физически находиться не в document.db, а в файле document.db-wal, и попадает в основной файл только при контрольной точке (checkpoint). Если скопировать один document.db без -wal, можно потерять последние операции или получить структурно неконсистентную копию. Отсюда правило: либо копируем все три файла разом и синхронно, либо используем безопасный механизм копирования на уровне SQLite, а не банальный cp.

Встроенный бэкап Trilium — первый и обязательный слой

У Trilium есть штатный механизм бэкапа, доступный в Options → Backup. Там можно включить три независимых переключателя:

• бэкап при каждом запуске приложения (backup at app startup);
• ежедневный автоматический бэкап;
• еженедельный автоматический бэкап.

Каждый из них создаёт снимок в поддиректории backup/ внутри директории данных: backup-daily.db, backup-weekly.db и так далее. Плюс есть кнопка «Backup Now» для ручного снимка в любой момент.

Ключевая деталь, которая делает этот механизм действительно полезным: внутри Trilium использует безопасный API SQLite для горячего копирования базы (аналог команды .backup в sqlite3), а не простое копирование файла. Это значит, что снимок консистентен, даже если в этот момент кто-то редактирует заметку через открытый клиент.

Проблема этого слоя одна, но принципиальная: файлы бэкапа лежат на том же диске, того же сервера, что и рабочая база. При отказе диска, случайном rm -rf, взломе сервера или полном факапе VPS вы теряете и оригинал, и бэкап одновременно. Встроенный механизм Trilium — это защита от «случайно удалил заметку и хочу откатить», а не от отказа сервера. Дальше он используется как первая ступень, поверх которой строится вынос копий наружу.

Ручной горячий бэкап SQLite для внешнего хранения

Если нужно снять копию для выноса на другой сервер прямо сейчас, а не через встроенное расписание Trilium, то напрямую копировать document.db командой cp во время работы приложения — плохая идея: файл может оказаться в промежуточном состоянии из-за WAL. Правильный инструмент — сама SQLite, у которой команда .backup создаёт консистентную копию независимо от того, кто ещё пишет в базу в этот момент.

Если Trilium установлен нативно (не в Docker) и sqlite3 есть на сервере:

sqlite3 /home/user/.local/share/trilium-data/document.db \
  ".backup '/backups/trilium/document_$(date +%F_%H%M).db'"

Если Trilium в Docker, а данные — на именованном volume, найдите реальный путь к файлу на хосте:

docker volume inspect trilium_trilium_data --format '{{ .Mountpoint }}'

и снимите бэкап той же командой .backup, указав путь из вывода. Для этого потребуется sqlite3 на хосте (apt install sqlite3 / dnf install sqlite) — сам контейнер трогать не нужно, .backup работает на уровне файловой системы поверх запущенного процесса.

Альтернативный вариант, не требующий sqlite3 на хосте вообще — выполнить бэкап через сам контейнер, если в образе есть Node с better-sqlite3 (используется внутри Trilium), но это громоздко для разового скрипта. Проще и надёжнее в большинстве случаев — использовать штатную функцию Backup Now из интерфейса Trilium (раздел выше), а затем копировать уже готовый, гарантированно консистентный файл из backup/ наружу — без ручной возни с SQLite вообще:

cp /home/user/.local/share/trilium-data/backup/backup-daily.db \
   /backups/trilium/document_$(date +%F).db

Такой подход перекладывает ответственность за консистентность на сам Trilium (он это уже умеет), а внешний скрипт занимается только переносом готового файла.

Бэкап Docker-инсталляции целиком

Для развёртывания в Docker Compose типичный конфиг выглядит так:

services:
  trilium:
    image: triliumnext/notes:latest
    container_name: trilium
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - trilium_data:/home/node/trilium-data
    environment:
      - TRILIUM_DATA_DIR=/home/node/trilium-data

volumes:
  trilium_data:

Для бэкапа такой связки нужны три вещи: сам document.db (безопасным способом из раздела выше), config.ini рядом с ним и сам docker-compose.yml с версией образа, чтобы поднять точно такое же окружение при восстановлении.

Полный скрипт, объединяющий сбор всего этого в одну датированную папку:

#!/bin/bash
set -euo pipefail

DEST="/backups/trilium/$(date +%F_%H%M)"
DATA_DIR=$(docker volume inspect trilium_trilium_data --format '{{ .Mountpoint }}')
mkdir -p "$DEST"

# 1. Консистентный снимок базы через sqlite3 .backup
sqlite3 "$DATA_DIR/document.db" ".backup '$DEST/document.db'"

# 2. Конфигурация сервера
cp "$DATA_DIR/config.ini" "$DEST/config.ini"

# 3. docker-compose.yml — чтобы знать, из какого образа поднимать
cp /opt/trilium/docker-compose.yml "$DEST/docker-compose.yml"

# 4. Ротация — храним 14 последних снимков
find /backups/trilium -maxdepth 1 -mtime +14 -type d -exec rm -rf {} \;

echo "Backup done: $DEST"

Если Trilium развёрнут вместе с другими сервисами на одном сервере, полезно свериться с разбором про бэкап Docker-volume и типичные ошибки — там разобраны грабли с правами доступа и монтированием, которые не специфичны для Trilium, но регулярно всплывают именно на этом шаге.

Автоматизация и вынос копий за пределы сервера

Локальная папка /backups/trilium на том же VPS — это гигиенический минимум, а не полноценный бэкап: она не переживёт отказ диска или компрометацию сервера целиком. Ставим скрипт выше в cron:

0 4 * * * /opt/scripts/trilium-backup.sh >> /var/log/trilium-backup.log 2>&1

и синхронизируем результат на отдельное хранилище — другой сервер, объектное хранилище или репозиторий с шифрованием и дедупликацией. Для базы знаний, где важна история изменений (а не только последний снимок), удобно смотреть в сторону restic — он снимает только дельту между запусками, даже если каждый раз копируется «весь» файл document.db заново, и хранит шифрованную историю версий:

restic -r /mnt/backup-storage/trilium-repo backup /backups/trilium/$(date +%F)*

Если restic ещё не настроен, есть пошаговый разбор установки restic на VPS и готовый docker-compose с restic, если хочется держать его в контейнере рядом. А если для бэкапов и архива под такие сценарии ещё нет отдельного сервера — стоит посмотреть как выбрать и настроить VPS под бэкапы и архив: держать копии базы знаний физически отдельно от рабочего сервера — не паранойя, а стандартная практика 3-2-1.

Отдельно стоит сказать про экспорт заметок как дополнительную, не основную страховку: в интерфейсе Trilium можно экспортировать любое поддерево заметок в .zip (HTML + метаданные) через контекстное меню. Это не замена полному бэкапу базы — теряются часть связей и системные метаданные — но как читаемый снимок «на всякий случай» раз в месяц, который можно открыть даже без самого Trilium, вещь не лишняя.

Восстановление Trilium из бэкапа

На новом сервере порядок такой:

1. Поднимите тот же образ Trilium, желательно той же версии, что была на момент бэкапа — так же, как и с любой другой self-hosted системой, у Trilium есть внутренние миграции схемы базы при первом запуске новой версии, и лучше сначала восстановиться «как было», а обновление делать отдельным осознанным шагом.

2. Остановите контейнер (если он уже успел создать пустую базу при первом старте) и подложите файлы бэкапа:

docker compose stop trilium

docker run --rm \
  -v trilium_trilium_data:/data \
  -v /backups/trilium/2026-08-30_0400:/backup \
  alpine sh -c "cp /backup/document.db /data/document.db && cp /backup/config.ini /data/config.ini"

3. Запустите Trilium и проверьте логи:

docker compose up -d trilium
docker compose logs -f trilium

4. Зайдите в веб-интерфейс и сверьте контрольные точки — раскройте дерево заметок на пару уровней, откройте заметку с вложением или кодом, проверьте, что последние по времени изменения на месте (это подтвердит, что бэкап снимался консистентно, а не в момент незавершённой записи).

Если по какой-то причине восстановленная база не открывается или Trilium жалуется на повреждённую структуру — почти всегда это означает, что копировался только document.db без учёта -wal/-shm файлов при живом процессе, то есть был нарушен принцип из раздела про горячий бэкап. В этом случае помогает восстановление из более раннего снимка backup/, снятого штатным механизмом Trilium — он от этой проблемы не страдает по построению.

Частые вопросы