https://opennet.me/openforum/vsluhforumID3/133326.html После полутора лет разработки опубликован релиз Rsync 3.3.0, утилиты для синхронизации файлов и резервного копирования, позволяющей минимизировать трафик за счёт инкрементального копирования изменений. В качестве транспорта могут быть использованы ssh, rsh или собственный протокол rsync. Поддерживается организация работы анонимных rsync-серверов, оптимально подходящих для обеспечения синхронизации зеркал...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60941<br> https://opennet.me/openforum/vsluhforumID3/133326.html#59 Fri, 17 May 2024 06:29:17 GMT &gt; на уровне bittorrent sync 1.3.109 есть чё?<br>&gt; synthning - бажная шляпа. rsync не кроссплатформенный <br><br>дык в чем проблема ?? платишь за resilio sync и пользуешь в свое удовольствие. btsync аккурат в resilio переименовали.<br> https://opennet.me/openforum/vsluhforumID3/133326.html#58 Thu, 18 Apr 2024 13:31:10 GMT а если я не переименовывал, а создал новый каталог (или два, три) и скопировал туда файлы? <br> https://opennet.me/openforum/vsluhforumID3/133326.html#57 Thu, 11 Apr 2024 12:32:59 GMT использую синхфинг уж десяток лет - умвр :) мож у тебя руки не тем концом не туда вставлены ??<br> https://opennet.me/openforum/vsluhforumID3/133326.html#56 Mon, 08 Apr 2024 04:35:51 GMT &gt; Если не использовать btrfs/zfs (у которых есть свои средства для снимков <br>&gt; и синхронизации), опция --fuzzy работала достаточно хорошо, по крайней мере, <br>&gt; в моих случаях. По ссылке она упоминается.<br>&gt; Если эту проблему решать в общем случае, надо залезать на уровень кода файловых систем<br><br>Она не решается в хорошем виде в общем случае. В CoW видите ли трекинг изменений часть логики работы ФС, оно делается в фоне, всегда.<br><br>В случае обычной ФС этого знания просто изначально нет. И вам придется явно угробить ресурсы на его отстраивание и трекинг. Это привносит свой уровень сложности и потребления ресурсов. При том что результат как правило все же хуже чем вон там. Да, дифференциальный btrfs send и точнее, и меньше ресурсов. Что хотите то и делайте с этим фактом. Rsync же скорее для всякой синхры зеркал годится, и даже там грабель - можно огрести от души. Ибо стандартно трекинга отличий нет, полная версия ресурсоемка что капец, а эмпирика - весьма компромиссное решение.<br><br>&gt; (и там есть варианты) или даже н https://opennet.me/openforum/vsluhforumID3/133326.html#55 Mon, 08 Apr 2024 02:56:00 GMT &gt; Учитывая, что бизнес, сделавший ставку на питон, рано или поздно задаёт себе <br>&gt; вопрос типа "а чё у нас всё так тормозит?" или "а чё нам так много за хостинг<br>&gt; приходится отваливать?"<br><br>Еще раньше они начинают задаваться вопросом "почему все разваливается и постоянно надо переписывать и майнтайнить".<br> https://opennet.me/openforum/vsluhforumID3/133326.html#54 Sun, 07 Apr 2024 23:23:46 GMT Пользовался когда-то сборкой для винды. Работало без проблем, но медленно. Теперь пользуюсь robocopy.<br> https://opennet.me/openforum/vsluhforumID3/133326.html#53 Sun, 07 Apr 2024 22:40:30 GMT &gt;экономия канала тут может вообще не оправдаться<br><br>Речь идет совсем не об экономии трафика. Время!<br>Поясню:<br>На небольшом сервачке каждую ночь AIDE проверяет неизменность объектов ФС (файлы, линки, директории) одновременно по следующим признакам: permissions, link, user, group, size, mtime, acl, md5<br>Вот вчерашний лог проверки:<br>Number of entries: 20891<br>End timestamp: 2024-04-07 02:12:06 +0300 (run time: 0m 5s)<br><br>5 (пять!) секунд на 20 тысяч объектов ФС. Суммарный объем этих файлов - 2,8 Гбайт. Если качать их по 100 Мбит линку, то это займет &gt; 280 сек. Даже на скромной виртуалке считать хэши быстрее полной повторной закачки ~ в 50 раз.<br> https://opennet.me/openforum/vsluhforumID3/133326.html#52 Sun, 07 Apr 2024 19:58:12 GMT &gt;&gt;Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши <br>&gt; Сферический конь в вакууме.<br><br>Вот потому у них и многое, а нас не очень, что они к подробностям внимательны, а не отмахиваются.<br> https://opennet.me/openforum/vsluhforumID3/133326.html#51 Sun, 07 Apr 2024 18:17:58 GMT &gt; Абсолютно не требуется. Всего-то надо проверить size, mtime и хэш вложенных файлов <br>&gt; (на случай если в переименованном каталоге изменились какие-то файлы) и качать только измененные.<br><br>Так это ни разу не всего-то, считать хеши всех подряд (ведь мы не знаем, что и куда было перемещено) файлов и держать даже сами хеши (всех-всех файлов в синхронизируемом каталоге и его подкаталогах) в памяти удовольствие совсем не бесплатное и экономия канала тут может вообще не оправдаться. Если какая-то редко нужная функциональность ухудшит жизнь тем кому она не нужна &#8212; нехорошо получится всё же.<br><br>Лезть на уровень ФС можно чтобы получить информацию о том что такой-то inode был отлинкован от одного каталога и прилинкован к другому (или что вообще тупо каталог был переименован), при этом данные самого файла не менялись. У rsync между запусками не хранится информация об обрабатывавшихся inode, поэтому ему неоткуда об этом узнать. Патч detect-renamed в каких-то ситуациях проблему решает, но не во всех и в комментарии