The highest speed and efficiency is to only observe time and size as
then just a stat-call is needed.
But in more complex situations you have to take also the checksum,
inode-number, etc into account.
In previous posts there were many ideas to cope with this. As rsync is
state-less regarding the filesystem,
it needs to be extended by a DB to hold the previous state of the
observed filesystem.
The DB can provide quickly files on many aspects, eg find a file by
checksum or other characteristic
that is not possible to ask from a standard filesystem without doing a
full scan first.
The worse case problem by tackling renamed files and directories is when
they are not only moved
or renamed, but when they are also changed in contents.
You probably noticed Henri's reply, he pointed to link-backup:
This URL has a links to Link-Backup and LSync :
http://connect.homeunix.com/lbackup/about#alternatives_to_lbackup
The LSync project has integrated with Link-Backup if you are
interested.
otherwise just jump directly to the Link-Backup project.
It is a big python script, but not easy to integrate in my current setup.
Nico
Jamie Lokier schreef:
N.J. van der Horn (Nico) wrote:
Hmmm, right, IF and only IF you notice the rename at the source on
time, you can do so at destination. But in practise, I see its
getting more and more impossible to keep up with the growing number
of hosts. Just keeping a DB with characteristics like checksum
seems to be not the ultimate solution, but at least in our case it
would help a lot, as the biggest disaster is just massive renaming,
or at top level. Like you state, when the renamed file(s) is/are
also modified, it is getting very hard to identify it/them again.
Basing on inode-number is not usable for all OS'es as far as i look
at the problem.
True, inode number is not usable for all filesystems on unix either.
But it works well enough for most of them.
Without trusting inode numbers from run to run, what can you do?
Reading the content of all files to calculate the checksums before
starting will take a very long time in many cases.
-- Jamie
--
Behandeld door / Handled by: N.J. van der Horn (Nico)
---
ICT Support Vanderhorn IT-works, www.vanderhorn.nl,
Kamer van Koophandel / Chambre of Commerce 24228233,
Voorstraat 55, 3135 HW Vlaardingen, The Netherlands,
Tel +31 10 2486060, Fax +31 10 2486061
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
