Нужна прога для синхронизации файлов / папок по сети
если в 4-гиговом файле изменился 1 байтФайл, надеюсь, текстовый?
svn или любая другая система контроля версий.
Мне не нужны все версии папки. Хранить надо только несколько последних, иначе никакого места не хватит. А насколько мне известно, с удалением старых ревизий у SVN проблемы.
Также хотелось бы, чтобы все происходило автоматически, но тут конечно можно просто заюзать cron.
Ну и плюс svn гадит в файловую систему, чего я не люблю.
Также хотелось бы, чтобы все происходило автоматически, но тут конечно можно просто заюзать cron.
Ну и плюс svn гадит в файловую систему, чего я не люблю.
Я когда-то тоже составил список требований к сетевой репликации, да вот беда - ни единого решения не нашлось
> Я когда-то тоже составил список требований к сетевой репликации
"Read my mind, do what I want?"
---
"В произведении должна быть ясная, определённая мысль.
Вы должны знать, для чего пишете, иначе если пойдёте по этой
живописной дороге без определённой цели, то вы заблудитесь..."
"Read my mind, do what I want?"
---
"В произведении должна быть ясная, определённая мысль.
Вы должны знать, для чего пишете, иначе если пойдёте по этой
живописной дороге без определённой цели, то вы заблудитесь..."
Я когда-то тоже составил список требований к сетевой репликацииЕсли ты был бы математик, ты бы проверил свои требования на непротиворечивость и замкнутость
Нагуглил только Unison, но он не работает с юникодными именами файлов.Уверен?
CHANGES FROM VERSION 2.33.-4
...
* Experimental Unicode-aware case insensitive mode. It is activated
when the preference "unicode" is set to true and Unison is in
case-insensitive mode.
В общем, я иногда страдаю графоманством. Оформив пожелания письменно проще от них отказаться. В общем, погляди на список требований и признай, что они все осуществимы и непротиворечивы
Рассмотрим современные сетевые файловые системы. Все они больше частью созданы для хранения готовых файлов, а не тех, что находятся в процессе написания. И это вполне объяснимо, доля этих файлов в локальной файловой системе слишком мала. Один человек не может сравниться с тысячами, которые создают и создавали другие файлы. Готового продукта (не в смысле пригодного к продаже, а в смысле спродуцированного людьми и сравнительно завершённого) на моём компьютере накапливается много, а моих личных файлов - мало, тем более что как программист я работаю с множеством текстовых файлов. Но и для большинства видов деятельности кроме видео, фото, аудио монтажа характерно то же распределение файлов.
А это значит, что долгое время задача создания специальных сетевых файловых систем для рабочих документов была если и не неактуальной, то как минимум неприоритетной. Сейчас различные файловые системы, в том числе и сетевые, растут как грибы после дождя, в них воплощаются всё новые и новые идеи, для них находятся специфичные области примения. Я решил, что стоит выделить ещё одну область примения сетевых файловых систем, и сформулировал основные требования и ожидаемые свойства такой системы.
Сразу решим, что для такого дела как рабочие документы, надёжность и функциональность важнее производительности и занимаемого на диске места. Рассмотрим область применния и накладываемые ею ограничения.
1. Количество пользователей - либо небольшая группа с высоким уровнем доверия, либо вовсе один человек. Это значит что клиентов будет немного и ресурсов хватит для того, чтобы каждый клиент знал об остальных достаточно для непосредственной синхронизации файлов.
2. Мы желаем хранить все файлы в одном месте и в одной файловой системе, а это значит, что зависимость от сервера недопустима. Сервер может стать недоступным, а работать с файлами нам по-прежнему хочется. Выходит что подходящей архитектурой будет являться одноранговая сеть, которую тем не менее не стоит путать с p2p сетью. Существующие решения с выделенным сервером дают лишь только возможность синхронизироваться время от времени, причём делать это приходось вручную, что я полагаю не самам удобным вариантом. Задача файловой системы - самой оргнизовывать общение по сети, и делать это прозрачно для пользователя.
3. Где могут храниться соотвествующие данные, какие хосты в какой роли могут выступать в интернете?
Рассмотрим случай одного человека, тесно общающегося с информационными технологиями. У него есть ноутбук, который он берёт с собой в дорогу, стационарный компьютер, с которым он предпочитает работать дома, возможно есть файловый сервер (свой, или просто арендует пространство приспособленный в том числе и для хранения документации, сервер, смотрящий в интернет, с которым удобно синхронизироваться в любой точке земного шара.
Если мы имеем в виду небольшую группу людей, то у них будет практически та же картина, помноженная на количество человек, за вычетом тех серверов, которыми они пользуются сообща.
А это значит, что система должна поддерживать облако хостов с разнородной связью между ними, по возможности оптимизируя маршруты обмена сообщениями, с обязтальной поддержкой бродкастов. Посокольку не во всех современных системах (серия ОС Windows от Microsoft) реализованы шейперы трафика, да и в любом случае системе маршуртизации полезно будет учитывать априорные знания о пропускной способности каналов, то нужно давать возможность устанавливать ограничения на максимальную потребляемую пропускную способность. Желательно так же уметь задавать диапазон используемых портов с тем, чтобы их можно было учитывать при составлении правил маршрутизации для роутера.
Мы пренебрежём иными видами стоимости трафика, кроме времени. Система, нацеленная на эффективность (а я уже утверждал, что таковая не является целью должна иметь возможность производиь маршрутизацию, учитывающую разные аспекты стоимости соединения: время задержки, скорость передачи, условная стоимость маршрута (с коммерческой точки зрения gprs канал дороже оптоволокна различные квоты трафика. Маршрутизацию можно построить на модульном уровне, оставив возможность добавления этой необязательной и трудной в исполнении задачи.
Кроме того, как видно, часть сообщений может проходить через недоверительные сети, а значит необходима поддержка своего прокола для криптобезопасной передачи данных. Более того, часто возникает ситуация, когда доступ по общедоступным протоколам перекрывается политикой безопасности организация, оставляя возможность соединения через ssh или web-proxy, что добавляет требование поддержки подобных способов передачи данных. Коротко их можно охарактеризовать так: умение соединяться через любую форточку в системе безопасности. А для этого хорошо бы иметь свой стек пользовательских протоколов, разумеется по модульному принципу, чтобы можно было задавать в одну строчку адрес соединения через цепочку туннелей разной природы.
4. Рассмотрим физическое размещение хранимой информации. Прежде всего следует разделить множество хранимой информации - на метаинформацию файловой системы и собственно файлы. Это разделение полезно потому что первый класс ифнормации важнее для функционирования сети и занимает меньше места. Так же можно различать собственные файлы, и файлы созданные прочими людьми в группе. Хосты также имеет смысл разделять в зависимости от того, кто работает за компьютером. Получаем, что для нормальной работы хост должен хранить все метаданные владельца (иначе станет невозможно осуществлять синхронизацию). Желательно так же хранить все файлы владельца и метаданные группы.
Учитывая количественное превосходство хостов в сети перед людьми в группе и распределённый характер сети, возможно хранить файлы с заметной избыточностью, причём она возможно будет меньше чем количество компов в сети (то есть не везде будут лежать полные копии). Очевидно что избыточность должна настраиваться в целом для сети (размазывать файлы по хостам нужно равномерно, чтобы не было такого, что один файл представлен на каждом хосте, а другой файл нигде не хранится) и отдельно для хостов с учётом внеочередной загрузки тех файлов, непосредственно с которыми ведёт работу пользователеь. Я бы назвал это кешированием файлов. Полезно будет дать возможность пользователю настраивать политику кеширования.
Для нормальной работы файловой системы необходимы механизмы синхронизации, блокировки и всех прочих благ локальной файловой системы, к которым уже привык пользователь. Их будет не слишком трудно написать, учитывая то, что на не придётся бороться с пользователями, которые могли бы использовать особенности протокола для создания коллизий, поскольку доступ к файлу на запись есть только у его владельца, и он в отсутсвии шизофринических наклонностей лоялен по отношению к себе.
Общая картинка представляется такой: в синхронном режиме осуществляется д
Рассмотрим современные сетевые файловые системы. Все они больше частью созданы для хранения готовых файлов, а не тех, что находятся в процессе написания. И это вполне объяснимо, доля этих файлов в локальной файловой системе слишком мала. Один человек не может сравниться с тысячами, которые создают и создавали другие файлы. Готового продукта (не в смысле пригодного к продаже, а в смысле спродуцированного людьми и сравнительно завершённого) на моём компьютере накапливается много, а моих личных файлов - мало, тем более что как программист я работаю с множеством текстовых файлов. Но и для большинства видов деятельности кроме видео, фото, аудио монтажа характерно то же распределение файлов.
А это значит, что долгое время задача создания специальных сетевых файловых систем для рабочих документов была если и не неактуальной, то как минимум неприоритетной. Сейчас различные файловые системы, в том числе и сетевые, растут как грибы после дождя, в них воплощаются всё новые и новые идеи, для них находятся специфичные области примения. Я решил, что стоит выделить ещё одну область примения сетевых файловых систем, и сформулировал основные требования и ожидаемые свойства такой системы.
Сразу решим, что для такого дела как рабочие документы, надёжность и функциональность важнее производительности и занимаемого на диске места. Рассмотрим область применния и накладываемые ею ограничения.
1. Количество пользователей - либо небольшая группа с высоким уровнем доверия, либо вовсе один человек. Это значит что клиентов будет немного и ресурсов хватит для того, чтобы каждый клиент знал об остальных достаточно для непосредственной синхронизации файлов.
2. Мы желаем хранить все файлы в одном месте и в одной файловой системе, а это значит, что зависимость от сервера недопустима. Сервер может стать недоступным, а работать с файлами нам по-прежнему хочется. Выходит что подходящей архитектурой будет являться одноранговая сеть, которую тем не менее не стоит путать с p2p сетью. Существующие решения с выделенным сервером дают лишь только возможность синхронизироваться время от времени, причём делать это приходось вручную, что я полагаю не самам удобным вариантом. Задача файловой системы - самой оргнизовывать общение по сети, и делать это прозрачно для пользователя.
3. Где могут храниться соотвествующие данные, какие хосты в какой роли могут выступать в интернете?
Рассмотрим случай одного человека, тесно общающегося с информационными технологиями. У него есть ноутбук, который он берёт с собой в дорогу, стационарный компьютер, с которым он предпочитает работать дома, возможно есть файловый сервер (свой, или просто арендует пространство приспособленный в том числе и для хранения документации, сервер, смотрящий в интернет, с которым удобно синхронизироваться в любой точке земного шара.
Если мы имеем в виду небольшую группу людей, то у них будет практически та же картина, помноженная на количество человек, за вычетом тех серверов, которыми они пользуются сообща.
А это значит, что система должна поддерживать облако хостов с разнородной связью между ними, по возможности оптимизируя маршруты обмена сообщениями, с обязтальной поддержкой бродкастов. Посокольку не во всех современных системах (серия ОС Windows от Microsoft) реализованы шейперы трафика, да и в любом случае системе маршуртизации полезно будет учитывать априорные знания о пропускной способности каналов, то нужно давать возможность устанавливать ограничения на максимальную потребляемую пропускную способность. Желательно так же уметь задавать диапазон используемых портов с тем, чтобы их можно было учитывать при составлении правил маршрутизации для роутера.
Мы пренебрежём иными видами стоимости трафика, кроме времени. Система, нацеленная на эффективность (а я уже утверждал, что таковая не является целью должна иметь возможность производиь маршрутизацию, учитывающую разные аспекты стоимости соединения: время задержки, скорость передачи, условная стоимость маршрута (с коммерческой точки зрения gprs канал дороже оптоволокна различные квоты трафика. Маршрутизацию можно построить на модульном уровне, оставив возможность добавления этой необязательной и трудной в исполнении задачи.
Кроме того, как видно, часть сообщений может проходить через недоверительные сети, а значит необходима поддержка своего прокола для криптобезопасной передачи данных. Более того, часто возникает ситуация, когда доступ по общедоступным протоколам перекрывается политикой безопасности организация, оставляя возможность соединения через ssh или web-proxy, что добавляет требование поддержки подобных способов передачи данных. Коротко их можно охарактеризовать так: умение соединяться через любую форточку в системе безопасности. А для этого хорошо бы иметь свой стек пользовательских протоколов, разумеется по модульному принципу, чтобы можно было задавать в одну строчку адрес соединения через цепочку туннелей разной природы.
4. Рассмотрим физическое размещение хранимой информации. Прежде всего следует разделить множество хранимой информации - на метаинформацию файловой системы и собственно файлы. Это разделение полезно потому что первый класс ифнормации важнее для функционирования сети и занимает меньше места. Так же можно различать собственные файлы, и файлы созданные прочими людьми в группе. Хосты также имеет смысл разделять в зависимости от того, кто работает за компьютером. Получаем, что для нормальной работы хост должен хранить все метаданные владельца (иначе станет невозможно осуществлять синхронизацию). Желательно так же хранить все файлы владельца и метаданные группы.
Учитывая количественное превосходство хостов в сети перед людьми в группе и распределённый характер сети, возможно хранить файлы с заметной избыточностью, причём она возможно будет меньше чем количество компов в сети (то есть не везде будут лежать полные копии). Очевидно что избыточность должна настраиваться в целом для сети (размазывать файлы по хостам нужно равномерно, чтобы не было такого, что один файл представлен на каждом хосте, а другой файл нигде не хранится) и отдельно для хостов с учётом внеочередной загрузки тех файлов, непосредственно с которыми ведёт работу пользователеь. Я бы назвал это кешированием файлов. Полезно будет дать возможность пользователю настраивать политику кеширования.
Для нормальной работы файловой системы необходимы механизмы синхронизации, блокировки и всех прочих благ локальной файловой системы, к которым уже привык пользователь. Их будет не слишком трудно написать, учитывая то, что на не придётся бороться с пользователями, которые могли бы использовать особенности протокола для создания коллизий, поскольку доступ к файлу на запись есть только у его владельца, и он в отсутсвии шизофринических наклонностей лоялен по отношению к себе.
Общая картинка представляется такой: в синхронном режиме осуществляется д
бля
Почему никто rsync не предложил?
может из-за
Также было бы неплохо иметь возможность откатиться до состояния в прошлом.?
Ну сливать старый бекап в отдельное место можно перед созданием текущего.
Можно заморачиваться со скриптами с использованием rsync
А можно купить готовое средство: Symantec BackupExec с опцией DLO
А можно купить готовое средство: Symantec BackupExec с опцией DLO
Плохое сравнение rsync+shell+cron дадут систему, которая будет вести себя именно так, как ты хочешь и ты будешь в этом уверен. А готовый велосипед делает только то, что вложили в него разработчики и одним им известным способом.
Мы желаем хранить все файлы в одном месте и в одной файловой системе, а это значит, что зависимость от сервера недопустима. Сервер может стать недоступным, а работать с файлами нам по-прежнему хочется.Я один вижу тут противоречие?
Если сервер будет находиться на твоём компьютере - то с этого компьютера ты всегда сможешь работать с файлами (если не отформатируешь винчестер); а другие компьютеры тебя и не волнуют.
ЗЫ: Так чем там тебя git не устроил?
rsync+shell+cronне все будут заморачиваться
С чем там заморачиваться? С прочтением man rsync?
А с изучением твоего велосипеда заморачиваться не надо? Или считается, что если там гуи, то можно изучить методом тыка? Как правило в таких велосипедах это не так - приходится экспериментировать а как он себя поведёт если я вот ту галочку поставлю. Поэтому по времени на его изучение уйдёт не меньше, чем на чтение man rsync.
А с изучением твоего велосипеда заморачиваться не надо? Или считается, что если там гуи, то можно изучить методом тыка? Как правило в таких велосипедах это не так - приходится экспериментировать а как он себя поведёт если я вот ту галочку поставлю. Поэтому по времени на его изучение уйдёт не меньше, чем на чтение man rsync.
> С чем там заморачиваться?
С алгоритмом синхронизации.
Давай, ты попробуешь это сделать, а потом уже поговорим.
---
"Истина всегда конкретна."
С алгоритмом синхронизации.
Давай, ты попробуешь это сделать, а потом уже поговорим.
---
"Истина всегда конкретна."
Я делал уже это для своих нужд и ты скрипт видел. Единственное, чего не хватает - это бекапа старой версии, но в моём скорипте удаление информации по случайности откатить нельзя только если удаление было в момент бэкапа (а у меня это в 5 утра, когда я точно сплю). А по случаю поломки диска потеря данных исключена благодаря предварительной проверке перед бекапом.
не у всех задача именно такая как у тебя
Я один вижу тут противоречие?Если сервер будет находиться на твоём компьютере - то с этого компьютера ты всегда сможешь работать с файлами (если не отформатируешь винчестер); а другие компьютеры тебя и не волнуют.я имел в виду неприемлимость архитектуры с центральным сервером, вроде гугльдоков. Упал инет - и прощай инфа. Подняли великий российский файервол - и прощая инфа.
Именно поэтому софта с заранее заданными свойствами на все случаи жизни не хватит. А небольшой скриптик при желании любой может написать - не надо для этого быть великим программистом - нужно просто изложить какого поведения от программы ты хочешь.
бля вот ты еблан
есть готовое решение для потребностей топикстартера
отсюда не следует, что я не знаю что:
достал, дятел тупоголовый
есть готовое решение для потребностей топикстартера
отсюда не следует, что я не знаю что:
софта с заранее заданными свойствами на все случаи жизни не хватит.
достал, дятел тупоголовый
я имел в виду неприемлимость архитектуры с центральным серверомА если центральный сервер - свой?
он тоже может оказаться недоступен или винты разом грохнутся (что конечно менее вероятно, чем падение коннекта до гугла). А так всё получается отказоустойчиво, более того - не всегда получается самому поднять сервер (то бишь выделить комп 24/7 в инет смотрящий)
Оставить комментарий
tima56
Имеется несколько ноутов и стационарных компов, соединенных сеткой.Необходимо, чтобы изменения в помеченных для синхронизации папках на одном из компов через некоторое время распространялись и на другие.
Также было бы неплохо иметь возможность откатиться до состояния в прошлом. При этом информацию о старых версиях файлов есть смысл хранить только на одном из компов.
Чего хотелось бы:
- Работа под win/*nix.
- Корректная работа с юникодными именами файлов.
- Пожирание траффика в разумных пределах - если в 4-гиговом файле изменился 1 байт, то пересылать весь файл не надо.
Нагуглил только Unison, но он не работает с юникодными именами файлов.