[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: backup solution



> Давайте разговаривать по существу. Я указал на два глючка. По ним у вас
> есть возражения?
По вашей логике, раз у лошади нет горбов, значит, лошадь - недоделанный 
верблюд. При чем здесь глюки? То, что есть, работает надежно. То, чего нету, 
не нужно разработчикам. Мне тоже не нужно, понадобится - буду думать, как 
добавить или искать другое решение.

> На тему сложности - если у Вас на обеих системах есть по GNU tar-у и
> есть где держать snapshoot файл на машине-источнике, то комбинация из
> (1)tar на машине-источнике (с выводом архива в stdout),
> (2)ssh, и (3)tar, читающего архив со stdin локально тоже позволит
> слить изменения на машину-приемник (и читать каждый файл в дереве-источнике

И что же, вы будете каждый раз передавать все содержимое? А канал до сервера с 
бэкапами в 64 килобит вас не смущает? Интернет-канал в любой момент 
может "упасть", после чего потребуется _продолжить_ синхронизацию, а не 
начинать сначала - как вы обработаете эту ситуацию вашим способом?

> просто не придется). Это сложнее чем rsync, который (при наличии файла
> на обеих машинах) разобьёт его на куски, там и там посчитает хэши,
> передаст куски с несовпадающими хэшами с машины-источника на
> машину-приемник, соберет файл?

Для того и сделано, что место на диске ограничено и канал не резиновый. При 
наличии неограниченного места и неограниченного канала появляются 
изобретатели "сферического коня в вакууме". В вашем случае можно просто 
подмонтировать sshfs на сервер с бэкапами и делать полную копию нужных 
данных. В принципе, вы это и делаете, но не сказать, что самым простым и 
прозрачным способом. Но это скорее дело вкуса.

> Если у нас есть маломеняющийся здоровенный файл, который надо
> синхронизировать по каналу с платным трафиком - я безусловно за rsync,
> но я полагаю его навороченным транспортом и не более.

На суть дела это не влияет, назовите транспортом, назовите навороченным, но 
для меня это необходимость. Файл может быть один, файлов может быть много, не 
в этом дело. 


> Как человек, который довольно долго интересовался задачей отбора файлов
> для инкрементального backup-а я не могу понять почему от метода со
> snaphoot-файлом народ бегает. Он простой. Я готов отстаивать эту точку
> зрения.

Решение задачи начинается с формулировки условия. А вы как раз условием и не 
поинтересовались. Мало кто имеет абсолютно неограниченные ресурсы и может 
работать с удаленной машиной как с локальной и притом не экономить дисковое 
пространство.



Reply to: