rsync --link-dest and --files-from lead by a "change list" from some file system audit tool (Was: Re: cut-off time for rsync ?)

Andrew Gideon c182driver1 at gideon.org
Mon Jul 13 13:53:43 UTC 2015


On Mon, 13 Jul 2015 02:19:23 +0000, Andrew Gideon wrote:

> Look at tools like inotifywait, auditd, or kfsmd to see what's easily
> available to you and what best fits your needs.
> 
> [Though I'd also be surprised if nobody has fed audit information into
> rsync before; your need doesn't seem all that unusual given ever-growing
> disk storage.]

I wanted to take this a bit further.  I've thought, on and off, about 
this for a while and I always get stuck.

I use rsync with --link-desk as a backup tool.  For various reasons, this 
is not something I want to give up.  But, esp. for some very large file 
systems, doing something that avoids the scan would be desirable.

I should also add that I mistrust time-stamp, and even time-stamp+file-
size, mechanism for detecting changes.  Checksums, on the other hand, are 
prohibitively expensive for backup of large file systems.

These both bring me to the idea of using some file system auditing 
mechanism to drive - perhaps with an --include-from or --files-from - 
what rsync moves.

Where I get stuck is that I cannot envision how I can provide rsync with 
a limited list of files to move that doesn't deny the benefit of --link-
dest: a complete snapshot of the old file system via [hard] links into a 
prior snapshot for those files that are unchanged.

Has anyone done something of this sort?  I'd thought of preceding the 
rsync with a "cp -Rl" on the destination from the old snapshot to the new 
snapshot, but I still think that this will break in the face of hard 
links (to a file not in the --files-from list) or a change to file 
attributes (ie. a chmod would effect the copy of a file in the old 
snapshot).

Thanks...

	Andrew



More information about the rsync mailing list