On Mon, Aug 13, 2007 at 11:01:04AM +0400, Pechnikov Alexey wrote: > Чем более сложное решение мы выбираем, тем выше вероятность сбоя в нем и > возможна ситуация, что такое решение делает не то, что мы от него ждем. > Простое решение дает максимальную надежность, зато приходится думать о том, > как правильно его применить. > > > Кроме того судя по тому же man-у на изменения владельцев и прав доступа > > он реагировать не заточен. > > Отслеживать изменения прав можно разнообразными способами. Снимайте регулярно > список файлов с их правами (утилит для этого хватает, в рассылке эта тема > обсуждалась), в любой момент можно будет восстановить.
Давайте разговаривать по существу. Я указал на два глючка. По ним у вас есть возражения? На тему сложности - если у Вас на обеих системах есть по GNU tar-у и есть где держать snapshoot файл на машине-источнике, то комбинация из (1)tar на машине-источнике (с выводом архива в stdout), (2)ssh, и (3)tar, читающего архив со stdin локально тоже позволит слить изменения на машину-приемник (и читать каждый файл в дереве-источнике просто не придется). Это сложнее чем rsync, который (при наличии файла на обеих машинах) разобьёт его на куски, там и там посчитает хэши, передаст куски с несовпадающими хэшами с машины-источника на машину-приемник, соберет файл? Если у нас есть маломеняющийся здоровенный файл, который надо синхронизировать по каналу с платным трафиком - я безусловно за rsync, но я полагаю его навороченным транспортом и не более. Как человек, который довольно долго интересовался задачей отбора файлов для инкрементального backup-а я не могу понять почему от метода со snaphoot-файлом народ бегает. Он простой. Я готов отстаивать эту точку зрения. WBR Dmitri Ivanov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]