Re: backup solution
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
Reply to: