Hi Dave,
I've to admit that generally would agree with "disk is cheaper than
time/cpu" as long as it is "close enough" that bandwidth doesn't play a
role.
It becomes major headache if scenario drives one to pump unnecessary xxx
GBs of data on daily basis and disaster recovery site is accessible
through 20Mbps link. (rdiff-backup does not finish within 24h).
Than the time to calculate data locally since CPU is cheap changes the
story completely and it is worth to do local calculation and discover moves.
This is what drove me towards posting this question.
Thanks,
Dawid
On 2016-02-10 1:57, Dave Kempe wrote:
*From: *"David" <dkad...@gmail.com>
Are there plans to implement fuzzy match or similar algorithms to
match
files moved/renamed files?
Tracking moves has been discussed at length in the past, and we
haven't been able to see a way past the very expensive calculation of
checksums to match files.
I think that disk is cheaper than time or cpu usage, so it hasn't been
possible to do this easily.
If you dig through the archives tracking moves has been discussed.
As for other products and rdiff-backup maintainership, its working for
me just fine. We intend to use it until we run into something that
requires fixing.
If there is a body of work that needs to be done to get it up to some
modern standard (say Python3) I'm happy to consider sponsoring it even.
thanks
Dave
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
