Скил file-sync-config — предполётный чеклист для двустороннего синка
Как Datarim предотвращает конфликты синхронизации и проблемы с платформой при настройке Syncthing, rclone или любого двустороннего файлового синка — с обязательной инвентаризацией, деревом решений для git-репозиториев и переиспользуемым шаблоном игнор-паттернов.
Двусторонний файловый синк между несколькими машинами выглядит просто — до тех пор, пока не встретится вложенный git-репозиторий, виртуальное окружение Python, собранное под другую архитектуру, или локальная SQLite-база, которой незачем попадать на другой хост. Скил file-sync-config предоставляет обязательный предполётный чеклист для любой установки двустороннего синка — до того, как передвинется первый байт.
Скил применяется при настройке папок Syncthing, rclone bisync, общих папок Dropbox и iCloud, периодических заданий rsync и любых кастомных слоёв синхронизации. Для односторонних резервных копий и передачи артефактов CI он явно не предназначен — там модель рисков другая.
Причина появления скила
Скил создан после конкретного сбоя. Первоначальный .stignore для Syncthing содержал 28 паттернов и не покрывал .venv, __pycache__, target/, *.db и не исключал вложенные git-репозитории. Результат за одну неделю: один реализованный конфликт синка в продакшн-файле CLAUDE.md, более 60 конфликтных файлов в хранилище, 14 git-репозиториев с разными ветками, синхронизированных как обычные рабочие деревья, и риск кросс-платформенных бинарников от виртуальных окружений Python, собранных под macOS и скопированных на Linux-хост. После расширения списка паттернов с 28 до 66 количество синхронизируемых файлов сократилось с 40 361 до 2 206 — на 95%.
Предполётная инвентаризация
Перед включением синка скил требует запустить find по пяти классам проблемных файлов на хосте-источнике: артефакты сборки и каталоги зависимостей (node_modules, .venv, target, .next и другие), вложенные git-репозитории, локальные файлы баз данных (*.db, *.sqlite), скомпилированные бинарники (*.so, *.dylib, *.dll), а также мусор IDE и ОС. Каждый обнаруженный класс должен быть добавлен в игнор-паттерны до первого запуска синка.
Дерево решений для git-репозиториев
Для каждой директории .git/ внутри корня синка скил задаёт один вопрос: есть ли на втором узле живые правки, агенты или продакшн-рантайм в этом репозитории? Если да — весь путь к репозиторию исключается из синка, а второй узел получает обновления через cron-задание git pull. Если нет — рабочее дерево можно синхронизировать, но сама директория .git/ всё равно исключается, чтобы каждый узел хранил собственную историю коммитов.
По умолчанию ответ считается «да». Любой второй узел рано или поздно становится активным — появляется новый агент, приходит скрипт деплоя, кто-то вносит правку вручную. Избыточная защита обходится дешевле, чем восстановление.
Чеклист комплаенса
Скил включает девятипунктный чеклист для инфраструктурных задач: предполётная инвентаризация выполнена; все обнаруженные классы есть в игнор-паттернах; каждая вложенная git-директория либо исключена, либо задокументирована как зеркало «только для чтения»; кросс-платформенные бинарники исключены при синке между разными ОС; файлы баз данных исключены; применены настройки блокировки; сохранена резервная копия конфигурации; задокументирован runbook; проведён смок-тест в обе стороны.
Скил также предоставляет переиспользуемый шаблон .stignore для Syncthing, шпаргалку по синтаксису паттернов для Syncthing, rclone и rsync, и описание workflow для обновления исключённых git-репозиториев на втором узле через cron-скрипт или self-hosted runner CI/CD.
Подробнее о пайплайне Datarim — в посте что такое Datarim, а о завершении цикла разработки — в посте о скиле finishing-a-development-branch.