Как да хоствате самостоятелно Trilium Notes през 2026 г.: директория за данни, WebSockets и резервни копия

Контейнерът на Trilium Notes може да е в зелено състояние, докато основната задача за потребителите е повредена. При Trilium Notes този скрит проблем обикновено означава, че директорията за данни е монтирана на грешен път или не позволява запис. Това ръководство приема за acceptance test следната последователност: „създаване на свързани бележки, добавяне на прикачен файл и релация, търсене на същите елементи и проверка на историята на ревизиите след рестарт“, след което изгражда deployment-а в обратен ред спрямо този резултат.

Trilium Notes има конкретна роля в stack-а: personal knowledge base с дървовидна структура. Затова production въпросът не е дали порт 8080 ще отговори веднъж, а дали state-ът, зависимостите и публичният адрес ще продължат да бъдат съгласувани след рестарт, update и restore.

Опишете Trilium Notes, преди да докосвате Docker

HTTP процесът на Trilium Notes слуша на 8080; оставете този порт в application network-а и публикувайте само platform route-а. Локалното изискване по време на runtime е durable data directory и достатъчно memory за indexing. Валидирайте го при acceptance workload; idle health check не може да докаже, че ресурсът е достатъчен.

Запишете границата като кратък contract: кой отговаря за изискването, кой credential се използва, какъв timeout е приемлив и как изглежда failure-ът. След това изпълнете тази transaction: създайте свързани бележки, добавете прикачен файл и релация, потърсете ги и проверете историята на ревизиите след рестарт. Наблюдавайте indexing-а на бележките, размера на прикачените файлове, scripting-а и нарастването на document.db по време на изпълнението, защото този workload дава по-полезен начален размер от idle контейнер.

Тествайте Trilium Notes извън сървъра

Изложете един HTTPS hostname за Trilium Notes; оставете raw порт 8080 private. Публикувайте web UI през HTTPS със запазени WebSockets. Така браузърите и API клиентите няма да научат за два конкуриращи се адреса.

От clean client изпълнете known-good transaction и проверете първата failing request. Използвайте ръководството за custom domain, когато DNS или TLS са конфигурирани неправилно. Разглеждайте „директорията за данни е монтирана на грешен път или не позволява запис“ като отделна application диагноза, след като route-ът е доказано работещ.

Стартирайте Trilium Notes с наблюдаеми настройки по подразбиране

Production-shaped launch умишлено е скучен: named state, изрично зададен порт и без secret вътре в image-а.

docker run -d \
  --name trilium-notes \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v trilium-notes-data:/home/node/trilium-data \
  -e TRILIUM_DATA_DIR=/home/node/trilium-data \
  triliumnext/notes:latest

Примерът е baseline, а не напълно завършен supporting stack. Потвърдете локалното изискване преди exposure: durable data directory и достатъчно memory за indexing. Проверете effective mounts и listener-а, след което опитайте да създадете свързани бележки, да добавите прикачен файл и релация, да ги потърсите и да проверите историята на ревизиите след рестарт. Pin-нете работещия image преди следващия рестарт.

Наблюдавайте workload-а, а не само контейнера

Наблюдавайте работата, която Trilium Notes извършва: indexing на бележки, размер на прикачените файлове, scripting и нарастването на document.db. Задайте limits с headroom за тази работа и избягвайте liveness probe, която се конкурира с нея. Operator check-ът все пак трябва периодично да се опитва да създаде свързани бележки, да добави прикачен файл и релация, да ги потърси и да провери историята на ревизиите след рестарт.

При updates не забравяйте, че миграциите на TriliumNext, scripts и theme extensions трябва да се тестват върху duplicate data directory. Deploy-нете candidate-а към recovered copy и повторете известния тест. Ако директорията за данни е монтирана на грешен път или не позволява запис, използвайте runtime logs и реалната network request, за да установите кое предположение се е променило.

Какво трябва да премине, преди да постъпят реални данни в Trilium Notes

Release record-ът за Trilium Notes трябва да съдържа факти, а не „изглежда добре“. Съхранявайте избрания image digest, configuration checksum, публичния hostname и timestamp-нат резултат за: създаване на свързани бележки, добавяне на прикачен файл и релация, търсене на същите елементи и проверка на историята на ревизиите след рестарт. Използвайте non-production sample data, за да може проверката да се изпълнява след всеки deployment.

Докажете двата lifecycle event-а поотделно. Подмяната на контейнер трябва да запази нормалната работа; clean recovery трябва да покаже, че бележките, релациите, прикачените файлове, атрибутите и ревизиите са възстановени и че познатото търсене намира същата бележка. Докато проверките се изпълняват, измервайте indexing-а на бележките, размера на прикачените файлове, scripting-а и нарастването на document.db и запазете резултата като очакван envelope за тази версия.

Тествайте и denied или invalid condition: подайте безвреден input близо до resource или format limit-а, свързан с тази граница: директорията за данни е монтирана на грешен път или не позволява запис. Trilium Notes трябва да се провали по диагностируем начин и да не презаписва здравия state. Върнете валидното условие, стартирайте отново sample-а и приложете съответните redacted logs. Тези artifacts дават на бъдещото решение за rollback конкретни доказателства.

Направете резервно копие на state-а, който Trilium Notes не може да пресъздаде

Определете recovery point и recovery time за Trilium Notes чрез document.db, прикачените файлове, ревизиите и конфигурацията. Монтирайте /home/node/trilium-data преди bootstrap, запишете безвредни sample данни и заменете контейнера, за да докажете, че този път наистина е persistent. Named volume решава persistence при redeploy; не решава компрометиране или загуба на сървъра.

Изградете clean restore environment, използвайте същата pinned application version и докажете, че бележките, релациите, прикачените файлове, атрибутите и ревизиите са възстановени и че познатото търсене намира същата бележка. Запишете командите, корекциите на ownership-а и изминалото време. Ръководството за резервни копия е полезен стандарт: на едно backup се има доверие след restoration, а не след upload.

Изберете trust boundary-а на Trilium Notes

Затворете bootstrap window-а веднага щом съществува първият trusted administrator. Конкретният капан при Trilium Notes е излагането на personal knowledge base без strong login; по-сигурната граница е да третирате notebook-а като private data, да изисквате strong login и да не излагате по-широка filesystem област от неговата data directory.

TRILIUM_DATA_DIR контролира behavior-а, а не confidentiality; валидирайте неговия type и value и съхранявайте реалните credentials за Trilium Notes отделно. Private networking трябва да пренася credentials за dependencies, а ролите в Trilium Notes трябва да предоставят минималното полезно действие. Не допускайте sensitive request bodies и provider responses в обичайните logs.

Какво Dockup трябва да автоматизира за Trilium Notes

За Trilium Notes Dockup може да създаде route и TLS certificate, да запази mounts, да достави secrets и да осигури durable data directory и достатъчно memory за indexing в private networking при deployment както към Dockup, така и към attached servers.

Release gate-ът все още е конкретната transaction на Trilium Notes: създаване на свързани бележки, добавяне на прикачен файл и релация, търсене на същите елементи и проверка на историята на ревизиите след рестарт. Проверете и restore condition-а — бележките, релациите, прикачените файлове, атрибутите и ревизиите са възстановени и познатото търсене намира същата бележка. Тези две проверки показват дали deployment-ът работи и дали може да бъде възстановен.

Често задавани въпроси

Какво е необходимо на Trilium Notes за production deployment?

Маршрутизирайте контейнера на Trilium Notes през порт 8080 към един HTTPS origin. Локалното изискване по време на runtime е durable data directory и достатъчно memory за indexing. Не обявявайте Trilium Notes за ready, докато не можете да създадете свързани бележки, да добавите прикачен файл и релация, да ги потърсите и да проверите историята на ревизиите след рестарт.

Кои данни на Trilium Notes трябва да бъдат включени в backup?

Запазете /home/node/trilium-data и включете document.db, прикачените файлове, ревизиите и конфигурацията в един и същ recovery manifest. Clean restore на Trilium Notes е успешен само когато бележките, релациите, прикачените файлове, атрибутите и ревизиите са възстановени и познатото търсене намира същата бележка.

Изисква ли Trilium Notes HTTPS зад reverse proxy?

Използвайте HTTPS за публичния Trilium Notes origin и оставете порт 8080 във вътрешния route. Приложете настройката на Trilium Notes правилно: публикувайте web UI през HTTPS със запазени WebSockets. При Trilium Notes HTTPS защитава credentials или user content по време на преноса и запазва съгласувано client behavior-а, зависим от origin.

Как трябва да се тества upgrade на Trilium Notes?

Възстановете текущия state на Trilium Notes в изолиран deployment, приложете candidate version и повторете acceptance transaction-а му. Обърнете особено внимание, защото миграциите на TriliumNext, scripts и theme extensions трябва да се тестват върху duplicate data directory. Запазете предишния Trilium Notes image, докато границата на data migration-а и rollback-а не бъде изяснена.