rsync и копирование DBF-файлов

А я стесняюсь спросить - как приёмник будет узнавать, какие части изменились, если всё, что у него есть - удалённый файл и локальный файл? Дельту он из астрала получит?

Конечно будет целиком. Откуда оно знает что изменилось? Бинарный файл он на то и есть бинарный...

Возможно я не совсем точно описал ситуацию, расшаренная папка с источника (win2k8) монтируется приемником (CentOS) в /mnt/1c-src, папка назначения /mnt/1c-dst так же расположена на приемнике. В ней уже лежит копия нужных для синхронизации файлов.

Т.е. я ожидаю от rsync'а отработки ~5-10 мегабайт изменившихся частей, а не копирования 3.2 Гб DBF-ок на основании их даты изменения.

Синхронизация выполняется командой

rsync -azv --stats /mnt/1c-src/modul/ /mnt/1c-dst/modul/
rsync -azv --stats /mnt/1c-src/User/ /mnt/1c-dst/User/
rsync -azv --stats /mnt/1c-src/usrdef/ /mnt/1c-dst/usrdef/

Маны читать нынче немодно?

-W, --whole-file With this option rsync’s delta-transfer algorithm is not used and the whole file is sent as-is instead. The transfer may be faster if this option is used when the bandwidth between the source and destination machines is higher than the bandwidth to disk (especially when the «disk» is actually a networked filesystem). This is the default when both the source and destination are specified as local paths, but only if no batch-writing option is in effect.

Т.е. для моего случая rsync не подходит вообще ?

Если так, не могли бы подсказать альтернативы, которыми можно реализовать задуманное.

А я стесняюсь спросить - как приёмник будет узнавать, какие части изменились, если всё, что у него есть - удалённый файл и локальный файл? Дельту он из астрала получит?

Учиться никогда не поздно:

In delta encoded transmission over a network where only a single copy of the file is available at each end of the communication channel, special error control codes are used to detect which parts of the file have changed since its previous version. For example, rsync uses a rolling checksum algorithm based on Mark Adler's adler-32 checksum.

DALDON

Конечно будет целиком. Откуда оно знает что изменилось? Бинарный файл он на то и есть бинарный...

TheRaven

Если так, не могли бы подсказать альтернативы

Извините, конечно что вмешиваюсь, но ник этого пользователя какбы намекает на его понимане данного вопроса. http://dic.academic.ru/dic.nsf/ogegova/50774

Ещё раз: всё, что умеет делать удалённая часть - отдавать куски файла. Каким образом локальная часть узнает изменившиеся куски? Правильно, путём чтения всего удалённого файла. Если ТС хочет оптимизации - пусть поднимает на удалённой части rsync-сервер, тогда и будет «rolling checksum algorithm based on Mark Adler's adler-32 checksum».

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

Так что я бы на вашем месте попробовал бы поднять на Win2K8 порт rsync - например DeltaCopy - и забирать файлы прямо с сервера, без всяких cifs

Ещё раз: всё, что умеет делать удалённая часть - отдавать куски файла. Каким образом локальная часть узнает изменившиеся куски? Правильно, путём чтения всего удалённого файла.

Логика это прекрасно, но она, к сожалению, не всегда может заменить знания.

For remote transfers, a modern rsync uses ssh for its communications

Подключаясь к хосту rsync получает remote shell и, естественно, rolling checksum рассчитывается в remote shell или на «удалённой части», в вашей терминологии, передавая «локальной части» только значения checksum, а ни как не содержимое всего удалённого файла.

Если ТС хочет оптимизации - пусть поднимает на удалённой части rsync-сервер, тогда и будет «rolling checksum algorithm based on Mark Adler's adler-32 checksum».

Если ТС хочет проблем с безопасностью, то конечно пусть поднимает на удалённой части rsync-сервер, не поддерживающий ни авторизацию ни шифрование.

Подключаясь к хосту rsync получает remote shell и, естественно, rolling checksum рассчитывается в remote shell или на «удалённой части»

Эге, какой-такой «remote shell»? ТС монтирует удаленный каталог локально, а после удивляется что файло целиком тащится.

Неискоренима у людей вера в волшебные программы читающие мысли :)

Эге, какой-такой «remote shell»? ТС монтирует удаленный каталог локально, а после удивляется что файло целиком тащится.

Этот пост был адресован вовсе не ТСу, которому я ответил ранее.

Неискоренимо у людей желание тред-нечитать-сразу-отвечать.

Если ТС хочет проблем с безопасностью, то конечно пусть поднимает на удалённой части rsync-сервер, не поддерживающий ни авторизацию ни шифрование.

[CentOS | rsync  сервер на 127.0.0.1| sshd]
  |
  ^
  |
[Win2k8|putty with ssh key|port forwading|rsync client]

Не ?

Ну и Кэп намекает что у ТС , с его mount.cifs, как бы уже проблемы с безопасностью

При копировании локальных директорий ( а она локальная для rsync, поскольку подмонтирована) rsync ведет себя как обычний cp. Пруф:

-W, --whole-file
              With this option rsync's delta-transfer algorithm  is  not  used
              and  the  whole file is sent as-is instead.  The transfer may be
              faster if this option is used when  the  bandwidth  between  the
              source  and destination machines is higher than the bandwidth to
              disk  (especially  when  the  "disk"  is  actually  a  networked
              filesystem).   This is the default when both the source and des-
              tination are specified as local paths, but  only  if  no  batch-
              writing option is in effect.

Домо аригато, бокуа бака десу ^_^«»

Понял свою ошибку, будем менять архитектуру. Спасибо за уделенное время.

Это конечно хорошо, что ты слушаешь тролей, что тебе предлагают считать контрольные суммы от файла, точнее делить я так понимаю файл на некие чанки, высчитывать их суммы, что-то куда-то искать дельту по этим алгоритмам... Но! Тут возникает вопрос процессорного времени потраченного на всё это дело, а так-же на время в целом потраченного на это - пока оно тебе там всё подсчитает. - Лично я предпочту нормальное, человеческое копирование целого файла базы данных, чем потом случайно так остаться у разбитого корыта, из-за того что какой-то чанк, где-то там, что-то там, 100 лет назад... - В общем моё ИМХО, то на то и выйдет. Лучше уж на виндах сделай теневое копирование тома, и копируй себе спокойно каждый день файл с базой данных, а пользователи смогут спокойно при этом работать с базой. - Ты будешь использовать надёжные технологии, и простые как табурет, чем доверяться программным алгоритмам высчитывания контрольных сумм, и чесать репу «А чё бекап кривой...». - Чем проще, тем оно лучше.

Тем более база 4гб. - это тьфу, даже на 100 мегабитной сетке. Места тоже немного занимает, 10 бекапов всего 40 гигабайт. - Зато спать будешь спокойно. Ну или можешь делать простое копирование каждый день, а раз в неделю забирать тупо целый файл. - Но надо-ли из батона хлеба делать троллейбус?

На 100Мбитной - тьфу, но если вы прочтете первый пост, то узнаете, что у меня 4 Мбита. Полное копирование занимает ~5 часов.

По сабжу - спасибо berrywizard за наводку на верные мысли, все замечательно завелось с использованием rsyncd на удаленной стороне, накатывание суточных изменений занимает несколько минут.

Ок! Сори, не обратил внимание на канал. Хорошо, что завелось.