Comments 82
вспоминается как N лет назад нихронизацию поднимали на базах Fidonet стека, с помощью «левонета организации»…
ignoreDelete is an advanced folder setting that affects the handling of incoming index updates. When set, incoming updates with the delete flag set are ignored.
docker run -d --name syncthing -v /var/syncthing:/var/syncthing -p 8384:8384 -p 22000:22000 --restart=always
— под нагрузкой начинает потреблять большое количество ресурсов (иногда на столько большое что allwiner h3 1Gb просто не откроет интерфейс настройки);
— вылит клиента и возвращение через неделю, в такой сети, приводит к дублированию файлов (он их помечает как конфликтные). Решается в ручную удалением дублей, но все хосты сети перекачают по трафику.
Пришлось отказаться в пользу схемы клиент-сервер (хотя очень жаль).
Так, что до сих пор не исправлено
1.19.2
Сервер на debian, клиенты на винде и android
Если сменить регистр папки то вся папака со всем содержимым исчезает со всех девайсов. Архивные копии на серере и андроиде сработали правильно, на винде архивирования не было в этот момент. Так что актуально в 2022
Можно еще посмотреть на https://www.cis.upenn.edu/~bcpierce/unison/
Он конечно не умеет синхронизировать всех со всеми, а только мастер и много слейвов. Но обычно хоть одна точка с хорошим быстрым интернетом для мастера есть. По идее ресурсов unison должен потреблять меньше. Пусть unison и не прямая альтернатива syncthing, но как вариант.
Второй вариант будет работать только тогда, когда пользователь залогинился через ssh или авторизировался в локальной системе.
Раньше пытался использовать их для синхронизации рабочего окружения на десктопе, сервере и ноутбуке. Было очень удобно: не нужно вообще ни о чём задумываться — всё синхронизируется само в автомате. Но со временем стали появляться проблемы, и в итоге пришлось от этих программ отказаться после пары случае рассинхронизации.
Одна из фундаментальных проблем — отсутствие полноценных средств слежения за изменениями в файлах и директориях в ОС и ФС. Механизм inotify очень плохо масштабируется: с его помощью нельзя следить рекурсивно за всеми директориями, за каждой директорией нужно сделить отдельно, но дескрипторов-то у нас не бесконечное количество. В Windows дела обстоят лучше — там средство слежения рекурсивное, но возможен приход события до вступления изменения в силу. И в обоих случаях есть ещё один подводный камень: переполнение очереди событий, восставление после которого будет очень болезненным.
Syncthing тоже отжирает кучу памяти, но при добавлении папки в игнор, перестает ее индексировать и работает вобщем-то нормально.
Сейчас как раз использую SyncThing на трех машинах.
Начинал всё это синкать с помощью BTSync, почти сразу попал на полный рассинхрон на всех трех устройствах (винда, линукс и андроид). И каждый клиент показывал разную информацию.
Тогда (года два назад) я решил попробовать Syncthing, и никакого рассинхрона до сих пор не было. Были пару раз какие-то дубли-конфликты, но решалось быстро ручной проверкой.
Вот мой случай:
Folder "F:\.BTSync"
Contains:
Folders 22481
Files 387593
Files size 137 GBПравда, из этого количества нужно ещё выкинуть игнорируемые директории — останется примерно 15к папок и 200к файлов, что все равно дофига для синхронизации.
для синхронизации каталога с мелкими файлами (заметки, логи, версии этого в git) — 33 тысячи файлов, 1.3 гб — полет нормальный. постоянно несколько нод онлайн, максимально — до 5 нод поднимал.
в другом месте на двух windows машинах синхронизация данных — около 180 гб, используется версионирование, переодически слышу отзывы о пропадании корректной версии, или наоборот, о невозможности откатиться на нужную, часто вижу конфликты по синхронизации, и там более нескольких сотен таких ошибок — разбирать часто нет времени/желания. отказываться ещё не хочу, но проблемы признаю.
На днях добавил к тем windows-нодам свой linux сервер — чтобы организовать версионирование силами btrfs, при синхронизации сотни ошибок по поводу длины имени файла (ntfs vs btrfs )) ) — но с моей точки зрения, если это будет работать, то резервные копии уже не так и нужны.
Всем программам динамической синхронизации, то есть такой, которая происходит в реальном времени, нужно держать в памяти все метаданные к файлам. Хотя бы потому что система inotify ненадёжна по определению. Потому любые такие программы будут есть много памяти на множестве мелких файлов пока не придумали надёжный вид inotify. Это не беда программ синхронизации, это особенность современных ОС.
Иначе говоря, вы либо терпите этот недостаток, либо делаете rsync раз в полчаса. Ругаться, жаловаться и порицать не имеет смысла: это не та проблема, которую можно решить.
Это не беда программ синхронизации, это особенность современных ОС.…
Почему же? В той же Mac OS проблемы с переполнением очереди событий, насколько я понимаю, нет. FSEvents — вполне эффективная штука, судя по её описанию.
Ругаться, жаловаться и порицать не имеет смысла: это не та проблема, которую можно решить.
Ругаться, жаловаться и порицать как раз имеет смысл. Если программа синхронизации использует ненадёжный источник данных, работает в условиях сетеового соединени я низкого качества, и при этом не способна восстановиться после ошибки, то это недоработка программы.
Кстати, интересно, почему до сих пор нет решений на базе виртуальных файловых систем? Берём FUSE/Dokan, проксифицируем обращения к ФС и имеем полный контроль за всеми изменениями, правда, ценой небольшого падения производительности из-за накладных расходов.
Посмотрите на https://github.com/systemd/casync/
Заточен под работу именно с папками. Правда только под Linux.
А можно настроить запуск какой-нибудь команды по окончанию синхронизации?
Например, раздача софта или обновлений баз данных: сейчас для этого по крону запускается скрипт, который сперва через rsync выкачивает содержимое папки, потом запускает команду распаковки/установки. Чтобы 200+ серверов выкачивающих гигабайты данных не положили сеть и раздающий сервер, приходится разбрасывать время старта.
Syncthing мог бы распараллелить и снизить нагрузку, но как узнать, что точно все файлы и папки загрузились, и можно запускать программу установки?
docs.syncthing.net/dev/rest.html
и в нем можно подписаться на какие-то события и прочитать состояние ноды
aria2 is a lightweight multi-protocol & multi-source command-line download utility. It supports HTTP/HTTPS, FTP, SFTP, BitTorrent and Metalink. aria2 can be manipulated via built-in JSON-RPC and XML-RPC interfaces.
По-моему, это только всё усложнит.
Syncthing удобен тем, что расшарил папочку, и клиенты её выкачивают, а если папочка большая и клиентов много, то они качают и друг от друга, а не только с раздающего сервера.
Не хватает только хука syncCompleted.sh, который бы выполнялся после завершения синхронизации.
Но исходники открытые, можно и подкостылить для себя, наверное, или зацепиться за event-ы ItemFinished или FolderCompletion, как предлагает Tsvetik.
Очень нравится стабильность и скорость и не ломать головы насчет NAT на слабом канале по сравнению с другими способами перекачки файлов.
Работает более года уже.
Главное настроить исключения нормально. С последними билдами отпала необходимость выставлять время синхронизации. Ставим «Watch for Changes» и на всякий случай «Full Rescan Interval» в час или часы.
Инкрементальный бэкап сильно упрощает жизнь, а если с сжатием так вообще сказка.
На одном из серверов БД сделано так. Сервер делает бэкапы в папку на самом сервере. Полные, инкрементальные, транзакций. После этого «синком» улетает на сервер бекапов. Контроль версий не используется из за того что в названии бэкапа имеется timestamp.
А вообще сильно индивидуально. Зависит от объема, нагрузки, etc.
Описанное выше это слабонагруженный сервер и ему такие вольности простительны.
Печалит, что .stignore не передается между нодами и необходимо придумывать велосипеды с #include
И идея в том была, чтобы через SyncThing синхронизировать папку с необходымым набором скриптов (cmd/powershell — не суть), пара из которых запланирована была бы шедуллером на запуск по событию и условно раз в день в час Ч. Проблема доставить их и поддерживать актуальными при эпизодической связи, это и хотелось бы решить через ST.
Где-то с 2011 года начал использовать в своих делах BTSync, как только они начали его монетизировать перешёл на Syncthing и так же продолжил использовать для бизнеса. В синхро-работе 7 машин (2 всегда включены). Есть свой релей, и тот же для глобального обнаружения, так как почти все пользователи за NAT.
Посмотрел сейчас в работе: 97 553 объекта, всего 74,4 ГБ. Работает не захлёбывается. Скорости синхронизации выставляем на 5-10Мбит. Кое-что синхронизируем с поддержкой пяти последних версий файлов, что-то ежедневно в архив убираем, что-то раз в месяц.
Вот как-то так и живём. Syncthing крутая штука.
Но это не всё, что нам помогает. Есть у нас пару nextcloud. Для дела и второй для личного. Ну так повелось, два разных.
Hidden text
Но это не всё, что нам помогает.
Есть у нас пару nextcloud. Очень крутая и нужна вещь для дела. Без него тоже никак.
Так повелось, два разных. Для дела и второй для личного.
Настраиваем Syncthing. Синяя изолента в мелком бизнесе и дома