Какие возможности появились у утилиты rdiff-backup благодаря миграции на Python 3

[alex_shpak]

Возможно, стоит отметить отличие rdiff-backup от rsync: в то время как rsync каждый раз обходит всё дерево каталогов на источнике и получателе, сравнивая размеры и даты изменения каждого файла, rdiff-backup каждый раз пересчитывает sha1-суммы всех (?) файлов на источнике, сравнивая их с локально сохраненной базой данных. У обоих способов есть свои плюсы и минусы. Источник

[justhabrauser]

А зато у вас негров линчуют rsync передает только изменившиеся части файлов.
Не представляю, кому оно может помочь (разве что при бэкапах DBF-файлов), но тем не менее.

[edo1h]

при бэкапе образа виртуалки разве не помогает?

[justhabrauser]

Вот не знаю, честно говоря.
По идее должен. На практике среди себя мне не приходилось засекать время и объем.

[legolegs]

Для образов rdiff-backup ИМХО не лучшее решение. Он заточен на работу с россыпью файлов, некоторые из которых периодически частично или полностью меняются. В некотором смысле он похож на git (хотя я лично не понимаю людей, которые делают бекапы гитом).

[legolegs]

rdiff-backup каждый раз пересчитывает sha1-суммы всех (?) файлов на источнике

Это определённо не так. Как и у rsync, у rdiff-backup можно включить такое поведение, но по умолчанию сравнение идёт по метаданным. Конечно, при начальном копировании и каждый раз, когда файл меняется rdiff-backup пересчитывает и сохраняет контрольную сумму, чтобы можно было выполнить --verify-at

[legolegs]

Благодаря миграции на python 3 строго говоря rdiff-backup ничегошеньки не приобрёл. Только потерял бинарную совместимость протокола между старыми (2) и новыми (3) версиями, а поскольку собрать свежий rdiff-backup под древний линукс или вообще под termux для шестого андроида — то ещё приключение, то лично я не очень рад этой миграции.

Но, по крайней мере они поправили баг с длинными юникодными именами, который я зарепортил, так что в целом новая команда — молодцы.