Как у меня устроен Obsidian - от заметки до статьи на сайте

Изначально приложением для заметок у меня был Trilium. Об этом замечательном приложении можно почитать здесь. Но потом я перешел на Obsidian, в определенной степени вынужденно, так как у Trilium нет удобных инструментов для автоматизации публикаций в блоге. Подробнее об этом - в сравнении Obsidian и TriliumNext. С учетом своих профессиональных интересов, работы и моих хобби, Obsidian у меня давно перестал быть просто приложением для заметок. В нем лежат рабочие материалы, справочники по винилу, справочники по homelab, сценарии роликов и все статьи этого сайта. Отсюда же статьи и публикуются - я печатаю или правлю текст прямо в Obsidian, а через несколько минут статья уже сама оказывается на prohomelab.com.

Про плагины я уже писал отдельно - Плагины Obsidian, которыми я пользуюсь. В этой статье я постараюсь рассказать про устройство моего рабочего процесса целиком. Как разложены папки, как vault синхронизируется с другими устройствами, где лежат бэкапы, как черновик превращается в страницу сайта и что будет, если домашний кластер упадет.

Общая схема

#

flowchart LR
    PC["Obsidian на ПК"] -- Remotely Save --> NC["Nextcloud"]
    NC -- Remotely Save --> DEV["Другие устройства"]
    PC -- "git вручную" --> VR["Forgejo, репозиторий vault"]
    PC -- "Obsidian Git, каждые 10 минут" --> CR["Forgejo, prohomelab-content"]
    CR -- "notify.yml" --> SR["Forgejo, prohomelab-site"]
    SR -- "deploy.yml, Hugo + Blowfish" --> GH["GitHub Pages"]
    GH --> WEB["prohomelab.com"]

Три независимых потока. Синхронизация между устройствами идет через Nextcloud, бэкап всего vault - в Forgejo, а статьи сайта живут в отдельном репозитории и уходят на публикацию на GitHub Pages самостоятельно. Разделение не случайное, ниже объясню почему.

Структура vault - PARA с номерами

#

Папки разложены по методу PARA (Projects, Areas, Resources, Archive), хотя принцип немного другой, а номера в начале держат порядок в проводнике.

• 00-Inbox - быстрые заметки, черновики, вырезки из Web Clipper и ежедневные заметки, которые не столько ежедневные, а скорее что-то, что я пока не решил куда перенести, но надо чтобы мысль не убежала.
• 01-Projects - активные проекты. Главный из них Prohomelab, это статьи сайта. Рядом сценарии для видео. Там же проект моей стойки, который длится уже полгода, и непонятно, когда он закончится. Причем заметок там уже на целый блог.
• 02-Areas - постоянные области ответственности. У меня это Homelab (вплоть до css разных сервисов, которые я раскрашиваю в цвета своего брендбука), основная работа и личная база знаний.
• 03-Resources - справочники и библиотека (книги, авторы, копия разных статей других авторов, профессиональные статьи и так далее)
• 04-Archive - все, что закончено. Оказалось, ничего. Что только подтверждает мое утверждение, что система PARA у меня не совсем PARA.
• 05-Templates - шаблоны для Templater и QuickAdd
• 06-Attachments - вложения.
• 99-Meta - служебное, здесь же все базы-дашборды и разная аналитика по vault или в отношении моего сайта.

Папки с номерами я не переименовываю, на них завязаны шаблоны, базы и пути. Для навигации внутри папки работает простая связка - база (core-плагин Bases) прямо по папке и folder note как оглавление этой папки.

На чем все держится

#

Полный список плагинов есть в отдельной статье, здесь только основные, на которых все держится.

• Bases - таблицы и дашборды. Dataview у меня выключен, Bases его полностью заменили
• Notebook Navigator - основной проводник с двумя панелями, иконками папок и folder notes. Собственно этот плагин может заменить огромное количество плагинов, вплоть до Templater.
• Templater и QuickAdd - новые заметки только по шаблонам, включая черновик статьи для сайта
• Obsidian Git - работает только с папкой статей, не со всем vault
• Remotely Save - синхронизация между устройствами через Nextcloud
• Local Images Plus - скачивает картинки из вставленных ссылок и кладет их рядом с заметкой. С этим плагином надо быть очень осторожным. Он имеет тенденцию качать все картинки из всех статей, даже моих собственных с сайта. Мне же нужны физические картинки только из статей, которые я копирую с помощью плагина Web Clipper.
• Omnisearch с Text Extractor - полнотекстовый поиск, в том числе по тексту внутри PDF и картинок

Синхронизация и бэкап - это разные задачи

#

Синхронизация между устройствами идет через Remotely Save и мой Nextcloud. Плагин устаревший, последний релиз вышел осенью 2024 года, но со своей задачей справляется. Obsidian Sync я не использую, подписки нет - дорого. Vault при этом физически лежит в папке OneDrive, но синхронизация OneDrive для него выключена, чтобы два синхронизатора не трогали одни и те же файлы. Да и я осознанно отказался от оплаты OneDrive.

Бэкап всего vault - это git-репозиторий в моем Forgejo. Корень vault автоматически не коммитится, коммит и пуш я делаю руками, когда закончил осмысленную часть работы. Так история изменений получается читаемой, а не сотней коммитов «vault backup». И тут есть еще один нюанс - Obsidian Git в одном vault работает с одним репозиторием, а он у меня уже занят папкой со статьями для сайта. Да, конечно, можно завести несколько vault, но я не хочу плодить сущности.

Несколько деталей настройки:

• в .gitignore исключена папка статей (у нее свой репозиторий, о нем дальше) и кэш Text Extractor
• включен core.longpaths - в папках с картинками от Local Images Plus бывают очень длинные пути, а без этой настройки git на Windows не работает с путями длиннее 260 символов
• файлы, где лежат API-ключи плагинов и экспорты с секретами, в git не добавлены вообще

Авторизация в Forgejo идет через Git Credential Manager по OAuth, а запасной вариант - персональный токен. Тот же вход подхватывают и Obsidian Git, и остальные репозитории на этом компьютере.

Как статья попадает на сайт

#

Где лежит статья

#

Каждая статья - это отдельная папка (page bundle в терминах Hugo) внутри своей категории.

01-Projects/Prohomelab/
  <Категория>/
    _index.md          - страница категории
    <папка статьи>/
      index.md         - статья на русском (имя файла строго index.md)
      index.en.md      - английская версия
      featured.png     - обложка
      0.png, 1.png     - картинки, ссылки только относительно папки статьи

Новая статья создается из шаблона черновика и сразу переименовывается в index.md. Любой другой .md в этой папке Hugo отдельной страницей не опубликует.

Путь от правки до сайта

#

1. Пишу и правлю статью в Obsidian.
2. Obsidian Git каждые 10 минут сам коммитит и пушит папку статей в репозиторий prohomelab-content в Forgejo. Отдельной кнопки «опубликовать» нет, можно сказать, что публикациями я управляю через поле draft во фронтматтере.
3. Пуш запускает в этом репозитории workflow notify.yml, который дергает сборку в репозитории сайта.
4. В prohomelab-site срабатывает deploy.yml - чистый checkout с темой Blowfish, скрипт забирает свежий контент и заодно переводит obsidian-вставки картинок ![](file.png) в обычный markdown, затем срабатывает команда hugo --minify.
5. Готовая папка public уходит в ветку gh-pages репозитория GitHub Pages, и сайт обновлен.

Как я к этой схеме пришел и сколько раз ее перестраивал, описано в цикле про автоматизацию - первая версия на Forgejo Actions, переезд с хостинга провайдера на GitHub Pages, попытка свести все в один репозиторий с self-hosted GitHub Actions и возврат к двум репозиториям. Как поднять сам Hugo с Blowfish, есть в отдельной инструкции.

Источник правды для сайта - репозитории в Forgejo, а не рабочая копия на сервере сборки. Настройки самого сайта (hugo.toml, меню, шаблоны) живут в репозитории prohomelab-site, вне vault.

Правила, которые проще соблюдать, чем потом чинить непонятно что

#

Сборка сайта полностью автоматическая, поэтому любая ошибка в статье сразу становится либо упавшей сборкой, либо поломкой на сайте.

• Пока статья пишется - у статьи значение draft: true. Автопуш раз в 10 минут унесет на сайт все, что не помечено как черновик, включая статью на середине фразы.
• Битый YAML валит сборку целиком. Если в title, description или summary есть двоеточие с пробелом, значение нужно брать в кавычки, иначе YAML-парсер Hugo видит начало вложенной структуры и падает. Превью Obsidian этого не покажет, ошибка видна только в логах сборки в Forgejo.
• published - это дата публикации, а не true/false. Hugo использует это поле как дату публикации. Если вы используете ИИ для повторения написанного в этой статье, учтите этот момент. ИИ пока еще туповат и может решить, что это логический флаг.
• categories - одно значение в единственном числе.
• Сменил slug или перенес статью - надо указать старый адрес в aliases. Иначе Google Search Console быстро обрастает ошибками 404 в аналитике. Ох, сколько нервов я потратил, чтобы понять в чем проблема.
• Внутренние ссылки - только полным адресом вида https://prohomelab.com/posts/..., а в английской версии - на английскую версию статьи.
• Картинки - только путь от папки статьи. Путь от корня vault Obsidian показывает, а Hugo нет, и картинка молча пропадает на сайте.
• Диаграммы Mermaid - только шорткодом темы, а не markdown-блоком. Blowfish подключает Mermaid только при наличии шорткода, а обычный блок выводит как код. В превью Obsidian шорткод виден как текст, с этим я смирился.

Оформление

#

Тема Minimal плюс собственный CSS-сниппет в цветах брендбука ProHomeLab - графитовый фон, спокойный mint для ссылок и чекбоксов, короткая градиентная черта под названием заметки и шрифты Unbounded, Onest и JetBrains Mono. Шрифты грузятся из Google Fonts, без интернета откатываются на системные. Руки не доходят скачать все для локального хранения, да и дискового пространства не напасешься на все. Вы цены-то на диски в 2026 году видели?

Яркий акцент у меня всего один - выбранная папка в Notebook Navigator. Остальное намеренно нейтральное, в длинном тексте цветные заголовки и теги быстро начинают утомлять, а потом раздражать.

Если домашний кластер упал

#

Почти вся эта схема держится на собственных сервисах, поэтому аварийный план продуман заранее.

Что переживет падение

#

• Сайт продолжает работать - он раздается с GitHub Pages, кластер для этого не нужен. Не получится только публиковать новое. Выбор осознанный, почему так - в цикле статей на сайте. Ну и вы про ситуацию с Beget читали? Вот мне такого не надо.
• Vault цел на ПК и на других устройствах - это обычные файлы, Obsidian работает без всякого сервера.
• Ломается на время синхронизация (нет Nextcloud), автопуш статей и ручной пуш корня (нет Forgejo), сборка сайта (нет Forgejo и раннера). Ошибки Obsidian Git в это время ожидаемы - коммиты копятся локально и уйдут после восстановления.

Таким образом работа не будет сильно страдать при падении какой-то одной части рабочего процесса.

Порядок восстановления

#

1. Forgejo первым - от него зависят и бэкап vault, и сайт. После подъема просто надо проверить, что на месте все репозитории - vault, статьи, сайт и брендбук. При этом в качестве базы данных я использую внешнюю базу PostgreSQL, это тоже добавляет отказоустойчивости.
2. Если Forgejo поднят с нуля без бэкапа - не страшно, репозитории восстанавливаются обычным пушем с ПК, локальные копии полные.
3. Секреты Actions. Из бэкапа они восстанавливаются, а при чистой установке токены приходится выпускать заново - Forgejo значения секретов не показывает, перенести их нельзя. Нужны три - токен, которым репозиторий статей запускает сборку сайта, токен, которым сборка забирает статьи, и токен GitHub для записи в ветку Pages. Перевыпустить их - дело двух минут.
4. Раннер - проверить сервис forgejo-runner в LXC сборки и его регистрацию. При запуске нового Forgejo - зарегистрировать заново. Это вообще десять секунд.
5. Проверка сайта - запустить deploy.yml вручную. Однажды первый прогон после переезда у меня уже падал без внятной причины, я занервничал, но тогда помог обычный повторный запуск.
6. Git Credential Manager - при запуске нового Forgejo старая OAuth-запись становится недействительной. Ее просто нужно удалить и один раз запушить вручную, дальше вход подхватят все репозитории.
7. Nextcloud и Remotely Save - после подъема нужно будет просто проверить, что синхронизация проходит. Перед первым синком после долгого простоя я делаю копию vault, чтобы конфликт между устройствами не съел свежие правки. Такое у меня уже тоже было, когда все статьи сайта были затерты. Я уже подумывал о скоропостижном окончании карьеры ютубера, но ведь не просто же так у меня git.

Сбросить старую запись GCM для Forgejo можно так (адрес - условный пример, подставьте свой):

printf "protocol=https\nhost=forgejo.stilicho.ru\n\n" | git credential reject

Если переустановлен сам ПК

#

• Vault восстанавливается либо через Remotely Save из Nextcloud, либо клоном репозитория из Forgejo. Плагины и их настройки лежат в .obsidian, кроме кэша Text Extractor (пересоберется сам) и файлов с API-ключами (тут надо будет ввести все заново).
• Папка статей в корневом репозитории исключена, ее клонирую отдельно из prohomelab-content в то же место.
• Для длинных путей - git config core.longpaths true в корневом репозитории.

Итог

#

Если коротко, схема держится на трех решениях. Синхронизация и бэкап - в моем случае это разные инструменты. Статьи живут в отдельном репозитории и публикуются сами (ну не сами конечно, но автоматизировано), а единственный выключатель публикации - поле draft. И все неочевидные правила записаны в одном месте, где их могу прочитать только я.

Слабые места тоже есть конечно. Remotely Save - плагин устаревший, а почти все, кроме самого сайта, зависит от домашнего Forgejo. Поэтому план восстановления лежит прямо в vault и доступен офлайн.