On Tue, Aug 14, 2007 at 12:41:29PM +0400, Pechnikov Alexey wrote: > > Давайте разговаривать по существу. Я указал на два глючка. По ним у вас > > есть возражения? > По вашей логике, раз у лошади нет горбов, значит, лошадь - недоделанный > верблюд. При чем здесь глюки? То, что есть, работает надежно. То, чего нету, > не нужно разработчикам. Мне тоже не нужно, понадобится - буду думать, как > добавить или искать другое решение.
В конце своего письма вы упрекаете иеня в том, что я не поинтересовался постановкой задачи. И ведь вы правы - надо было, поскольку про канал с платным трафиком (как вариант просто медленный канал) я в треде слов не помню. А вы как-то догадались... > > > На тему сложности - если у Вас на обеих системах есть по GNU tar-у и > > есть где держать snapshoot файл на машине-источнике, то комбинация из > > (1)tar на машине-источнике (с выводом архива в stdout), > > (2)ssh, и (3)tar, читающего архив со stdin локально тоже позволит > > слить изменения на машину-приемник (и читать каждый файл в дереве-источнике > > И что же, вы будете каждый раз передавать все содержимое? А канал до сервера > с > бэкапами в 64 килобит вас не смущает? Интернет-канал в любой момент > может "упасть", после чего потребуется _продолжить_ синхронизацию, а не > начинать сначала - как вы обработаете эту ситуацию вашим способом? > > > просто не придется). Это сложнее чем rsync, который (при наличии файла > > на обеих машинах) разобьёт его на куски, там и там посчитает хэши, > > передаст куски с несовпадающими хэшами с машины-источника на > > машину-приемник, соберет файл? > > Для того и сделано, что место на диске ограничено и канал не резиновый. При > наличии неограниченного места и неограниченного канала появляются > изобретатели "сферического коня в вакууме". В вашем случае можно просто > подмонтировать sshfs на сервер с бэкапами и делать полную копию нужных > данных. В принципе, вы это и делаете, но не сказать, что самым простым и > прозрачным способом. Но это скорее дело вкуса. Я использую netcat+tar когда мне нужно перелить кучу мелких файлов по локалке (с машины на машину). Оказывается много быстрее, чем samba. Попробуйте, если не верите (gzip или bzip2 естественно не используются). В приведенном мной примере я просто заменил netcat на ssh. Насчет полной копии - опять же мы с вами друг друга не поняли. Я предполагал на машине-источнике вызывать tar с опцией --listed-incremental. tar на машине-приемнике запускать в общем-то необязательно :) Насчет "упадет канал" кстати вопрос интересный. Понятно, что архив придется лить по новой, но вот останется ли в нормальном состоянии snapshoot-file я не знаю... По идее запортиться не должен. > > > Если у нас есть маломеняющийся здоровенный файл, который надо > > синхронизировать по каналу с платным трафиком - я безусловно за rsync, > > но я полагаю его навороченным транспортом и не более. > > На суть дела это не влияет, назовите транспортом, назовите навороченным, но > для меня это необходимость. Файл может быть один, файлов может быть много, не > в этом дело. > > > > Как человек, который довольно долго интересовался задачей отбора файлов > > для инкрементального backup-а я не могу понять почему от метода со > > snaphoot-файлом народ бегает. Он простой. Я готов отстаивать эту точку > > зрения. > > Решение задачи начинается с формулировки условия. А вы как раз условием и не > поинтересовались. Мало кто имеет абсолютно неограниченные ресурсы и может > работать с удаленной машиной как с локальной и притом не экономить дисковое > пространство. > WBR Dmitri Ivanov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
