⌂ все дашборды/Флот и узлы← Sync-Repair-20260817 · System-Architecture-Map-ZBOOKG8-2023PAL →
Deep Research · инфраструктура · 07 июля 2026

Syncthing: боль, костыли
и куда бежать

Мы поймали много геморроя с «синк-синком». Здесь — все наши грабли и все костыли, которые мы наворотили вокруг него, и честный разбор альтернатив под нашу реальную задачу.

Собрано с живой машины MacBook-Anton (Mac16) · факты по альтернативам сверены на 2026

TL;DR — короткий ответ

Проблема не в Syncthing. Проблема в том, что мы навесили на него три разные работы сразу, а он умеет только одну.

Syncthing — это «репликатор файлов, где все равны и нет главного». А мы гоняем через него: (1) склад — 180 тыс. файлов волта; (2) конфиг — скиллы/память/CLAUDE.md; (3) рацию — межмашинную связь, консенсус, одобрения. Третье он в принципе не умеет — отсюда весь зоопарк костылей.

Лечение — не «сменить Syncthing на X», а разделить три работы по трём разным инструментам и назначить хаб единственным хозяином. Тогда 80% боли и почти все костыли исчезают. Детали — в конце.

Как мы это используем сейчас

180 202файла / 6.1 ГБ в волте (одна папка!)
959конфликт-копий *.sync-conflict накоплено
6+1синк-папок (+1 битая пустая запись)
14костыль-скриптов вокруг синка

Реальная раскладка папок (с живого конфига Mac16):

ПапкаРежимЧто этоБоль
anton-knowledgesendreceiveВесь волт, 180k файловНа грани возможностей Syncthing по числу файлов
claude-home / skills / memory / importsreceiveonlyКонфиг Claude, только приёмЛокальная правка молча откатывается
machine-bussendreceive«Рация» между машинамиФайл-папка в роли месседж-шины — отстаёт
id="" path=""битаяПустая запись-призрак в config.xmlМусор в конфиге, тихий источник ошибок

Связь только по LAN (192.168.1.44:22000), 1 активное соединение с хабом. Прямо сейчас статус зелёный: idle, 0 ошибок, 0 needFiles — но это «сейчас», а история шрамов ниже.

🩹 Грабли — на что мы наступали

1
Конфликты — хронические, не разовые. критично
По всему home накопилось 959 конфликт-копий *.sync-conflict. Бьют по координационным/индексным файлам: _DR-Registry (8×), каталоги сессий, Task-Backlog, _heartbeat-*, MOC-и, дашборды. 4 июля отдельно раскололо always-loaded MEMORY.md, declined-decisions, cofounder-growth-log.
Улика: find ~ -name "*.sync-conflict-*" → 959; папка _conflict-fix-bak-20260704/. Два узла правят один файл → тихий clobber. Это не «однажды не повезло», это фон.
2
Ловушка receive-only. частая
Конфиг Claude на followers — только приём. Пишешь скилл/память локально — Syncthing молча откатывает. Отсюда правило «пишущая память только в GDrive-проекте».
Улика: claude-home/skills/memory/imports = receiveonly в config.xml. Выглядит как «мои правки пропали».
3
Масштаб: 180k файлов — у края обрыва. растёт
Комьюнити Syncthing: папки >200k файлов начинают тормозить на сканировании, >500k — подвисают/ломаются. Наш волт уже 180k и растёт (+ _imports, + медиа).
Сканирование замирает, индекс-БД пухнет, старт синка медленный. Лечится тюнингом (SSD-индекс, GOMEMLIMIT, .stignore), но это потолок архитектуры.
4
Пир отвалился → «рация» замолчала. критично
Одна машина офлайн/за VPN — и _machine-bus застревает. Межмашинная связь встаёт, пока не поднимешь пира. P2P глушится NAT/VPN (у нас по факту работает только по локалке).
Отсюда 3 слоя self-heal и переезд консенсуса в Telegram. Улика вживую: watchdog сегодня в 12:52 сам перезапускал Syncthing (лог _syncthing_watchdog_log.txt) — костыль работает прямо сейчас.
5
Задержка + «файл не доехал» ≠ «файла нет». частая
fsWatcher копит 10с, при флапе леджер отстаёт до ~часа. Файл в пути / машина выключена / не тот диск (C: vs E:) → выглядит как потеря данных, и есть соблазн пересоздать поверх.
Правило «сначала проверь другой диск/бэкап/машину, не пересоздавай» — прямое следствие этой грабли.
6
Миграция вычистила живой конфиг. было больно
Однажды синк/чистка молча опустошила ~/.claude/skills — спасла ручная копия. Отсюда обязательный git-бэкап конфига на каждой машине + снимок со счётчиками до→после.
Класс «тихое удаление при репликации»: пусто без ошибки = красный флаг.
7
Файл-папка в роли месседж-шины. архитектурное
Консенсус/одобрения/heartbeat пытались жить в синкаемой папке. Но синхронизация папок — это eventual consistency, а не очередь сообщений. «Молчит в леджере» почти всегда значило «просто ещё не доехало».
Пришлось объявить Telegram первичной рацией, а файловый леджер — лишь архивом.

🔧 Костыли — что мы построили, чтобы это терпеть

По каждой грабле мы дописывали подпорку. Получился целый слой middleware поверх «просто синка файлов». Само его существование — главный симптом: мы вручную дособираем распределённую систему, которой Syncthing не является.

сторожа

Watchdog-и живучести

  • syncthing_follower_watchdog.sh (5 мин)
  • peer_watch.py — жив ли пир
  • авто-nudge упавшему пиру в TG
рация-дубль

Telegram-шина вместо файлов

  • bus_send.py / bus_ping.py
  • tg_bus.py / tg_bus_read.py
  • machine_bus.py — failover-курьер
доставка

«Посылки» — форс-применение

  • deploy_check / apply / register
  • манифест PENDING-<host>
  • «синк доставил» ≠ «применено»
координация

Замки от гонок правок

  • onair.py — доска ON AIR
  • lease с TTL ~15 мин
  • прескан *.sync-conflict перед правкой
консенсус

Договорённости машин

  • consensus.py (переехал в TG)
  • inbox_robot.command
  • ACK-квитанции вручную
страховка

Бэкапы и сверка

  • git-бэкап ~/.claude (15 мин)
  • снимок + счётчики до→после
  • ручная чистка _conflict-fix-bak

≈14 скриптов + десяток правил в CLAUDE.md/памяти существуют только чтобы компенсировать поведение синка. Это не «мы плохо настроили» — это цена использования P2P-репликатора не по назначению.

🎯 Корень проблемы (5 почему)

Syncthing спроектирован как «много равных узлов, нет главного, файлы догоняют друг друга когда-нибудь». Мы просим у него три вещи, две из которых он делать не обязан:

1 · Склад180k файлов волта + медиа
умеет, но на пределе
+
2 · Конфигскиллы, память, CLAUDE.md
умеет, но нужен «главный»
+
3 · Рациясвязь, консенсус, одобрения
НЕ умеет вообще

Почему больно? → потому что нет единого хозяина (все пишут) и мы используем «когда-нибудь доедет» там, где нужна мгновенная очередь сообщений. Оба — не про Syncthing.

🧭 Альтернативы — под нашу реальную задачу

Оценка против наших нужд: near-real-time · Win+Mac · тянет 180k файлов · синкает и конфиг · ясный «единый источник правды» · простота (АК-47) · цена.

ВариантМодельReal-timeЕдиный хозяинКонфиг+бусЦенаВердикт под нас
Syncthing + тюнинг
оставить, но починить
P2P репликаторданет (все равны)частично$0 базовый шаг Убрать битую папку, .stignore на медиа/кэши, хаб = единственный писатель always-loaded. Дёшево, снимает часть боли.
Resilio Sync P2P (BitTorrent)данетчастичноfree / $ вбок Быстрее по WAN, проще UI, но тот же класс (eventual, нет главного, проприетарное). Координацию не лечит.
rclone bisync по расписаниюнетчерез облаконет$0 не для жизни Не real-time, опасен при одновременных правках, нужны --resilient/--recover. Хорош как бэкап в облако, не как живой синк.
Obsidian Sync централизованный (их сервер)дадаволт+настройки, не ~/.claude$4/мес для волта — топ E2E-шифрование, история версий, до 10 волтов, 10 ГБ. Чисто решает половину «волт». Но не синкает ~/.claude и не рация.
Облако-диск
Google Drive / Dropbox / iCloud
централизованныйпочтида (облако)да, как папкаесть у нас АК-47-путь Mac16 уже на Google Drive. Просто, один источник правды. Минус: слабые конфликты, тормоза материализации файлов, не мгновенно.
Seafile на хабе централизованный (свой сервер)дада, хаб=серверфайлы да, бус — нет$0 (self-host) склад — топ C-движок, в 2–3× быстрее Nextcloud, надёжный. Хаб всегда включён → идеальный сервер. Централизованный хозяин убивает конфликт-неоднозначность.
Nextcloud на хабе централизованныйдадафайлы да$0 тяжелее Функций море (PHP), но медленнее и сложнее в поддержке. Против АК-47.
Git (для конфига/текста) версионный, хаб=originнет (pull)даконфиг — идеально$0 конфиг — топ Уже бэкапим ~/.claude гитом! Версии, понятные конфликты, крошечный объём. Убивает receiveonly-ловушку и «тихое удаление».

Никакой один инструмент не закрывает все три работы. Поэтому — не «заменить», а «разделить».

✅ Рекомендация — разделить три работы

склад

Волт (180k файлов)

Хаб = единственный хозяин. Либо Syncthing с хаб-авторитетом + .stignore (медиа/кэши/.git вон → число файлов вниз), либо Obsidian Sync для заметок + тяжёлые медиа на Google Drive с указателями (правило у нас уже есть).

конфиг

~/.claude (скиллы/память)

Перевести на git: хаб = origin, followers делают pull. Уже бэкапится гитом — осталось сделать его основным каналом. Убирает receiveonly-ловушку, «тихое удаление» и конфликты always-loaded файлов разом.

рация

Связь / консенсус / одобрения

Telegram — единственная рация (уже почти так). Файловую _machine-bus вывести из роли шины полностью. Это выключает целый класс костылей: watchdog-пиров, failover-курьера, прескан конфликтов.

Фаза 0 — сегодня, почти бесплатно

  • Удалить битую пустую запись папки (id="") из config.xml.
  • Ужесточить существующий .stignore (он уже есть, рядом бэкап от отката d2 25 июня): исключить _originals-медиа, .git, .stversions, кэши эмбеддингов, node_modules → срезать число файлов из зоны риска 180k.
  • Вычистить 959 старых *.sync-conflict-копий (после сверки, что живые версии целы).
  • Жёсткое правило: always-loaded файлы (MEMORY.md, канон) правит только хаб. На одной машине за раз.

Фаза 1 — разнести конфиг и рацию

  • Конфиг Claude → git-канал (хаб origin, followers pull). Syncthing по конфигу выключить.
  • Telegram сделать единственной шиной; файловый леджер оставить только как архив.
  • Отключить костыли, ставшие ненужными (peer-watchdog, failover-курьер) — по одному, с проверкой.

Фаза 2 — если волт всё ещё болит

  • Поднять Seafile на всегда-включённом хабе как единый источник правды для волта. Все узлы — клиенты хаба, а не P2P-пиры. Центральный хозяин убивает неоднозначность «кто прав».
  • Или перевести заметки на Obsidian Sync ($4/мес) и не держать их в Syncthing вообще.

Результат: Syncthing (или его замена) делает одну работу — реплицирует файлы под единым хозяином. Конфиг живёт в git (версии, откат). Связь — в Telegram (мгновенно, видно людям). ~80% боли и почти весь костыль-слой отмирают.

🧒 Простыми словами

Представь, что Syncthing — это копир-мальчик, который бегает между твоими компами и делает так, чтобы у всех лежали одинаковые бумажки. Он хороший, но мы нагрузили его тремя делами сразу: таскать гору бумаг (180 тысяч!), носить твои настройки, и ещё быть рацией, чтобы компы переговаривались. Рацией он быть не умеет — вот и получается, что мы приклеили к нему кучу подпорок скотчем, чтобы он не падал.

Правильно — не выгонять мальчика, а раздать три дела трём помощникам: гору бумаг держит один главный компьютер-хаб (все берут у него), настройки возить через «git» (он помнит все версии и ничего не теряет), а переговоры вести по Telegram (быстро и видно глазами). Тогда мальчику остаётся одно простое дело — и скотч больше не нужен.

🔬 Промпт для внешнего Deep Research (независимая вторая проверка · DR26-07-07-MAC16-01)

Скопируй в ChatGPT/Gemini Deep Research, если хочешь независимо перепроверить вывод перед решением:

Роль: инженер по распределённым системам. Задача: сравнить решения для синхронизации файлов между 4 машинами (1 всегда-включённый Windows-хаб + Windows-ноут + 2 macOS) для трёх РАЗНЫХ нагрузок: (1) СКЛАД: ~180 000 преимущественно мелких текстовых файлов (Obsidian-волт) + медиа, растёт; (2) КОНФИГ: каталог настроек AI-агента (скрипты, память, ~150 файлов), критична версионность и откат, недопустимо тихое удаление; (3) КООРДИНАЦИЯ: near-real-time обмен сообщениями/консенсус/одобрения между машинами. Текущее решение — Syncthing на всё сразу; боль: конфликты always-loaded файлов, ловушка receive-only, деградация на >200k файлов, задержки при флапе P2P/VPN, использование синкаемой папки как message-bus. Сравни (2026): Syncthing (+тюнинг), Resilio Sync, rclone bisync, Obsidian Sync, Seafile, Nextcloud, git-как-канал-конфига, облачные диски (Google Drive/Dropbox/iCloud), Mutagen, Unison. Для каждого: real-time?, нужен ли центральный сервер/хозяин, поведение при одновременных правках и удалениях, потолок по числу файлов, кросс-ОС Win+Mac, простота поддержки для не-инженера, цена, риск потери данных. Дай: (а) рекомендованную АРХИТЕКТУРУ (можно разные инструменты под разные нагрузки), (б) что оставить в Syncthing, (в) поэтапный план миграции с минимальным риском, (г) конкретные настройки .stignore/тюнинга если Syncthing остаётся. Приведи источники 2026 года.

Источники

Syncthing scaling: forum · docs/tuning · issue #8602 · Resilio vs Syncthing: technologycounter · fast.io · rclone bisync: rclone.org · forum · Obsidian Sync: obsidian.md/pricing · Seafile/Nextcloud: computingforgeeks · ssdnodes

Собрано Claude (Max, ветка Mac16) с живой машины MacBook-Anton · 07.07.2026 · грабли/костыли — по факту с диска, альтернативы сверены на 2026. Не решение за тебя — карта, чтобы решить самому.