On 11/10/2015 12:16 PM, Warren Young wrote:
Well, be fair, rsync can also miss files if files are changing while the backup occurs. Once rsync has passed through a given section of the tree, it will not see any subsequent changes.
I think you miss my meaning. Consider this sequence of events:
* "find" begins and processes dirA and then dirB
* another application writes files in dirA
* "find" completes
* a new timestamp file is written
Now, the new file in dirA wasn't seen by find during this run, and it
won't be seen on the next run either. That's what I mean by missed.
Not temporarily missed, but permanently. That file won't ever be backed
up in this very naïve process.
There's no benefit to the process, either. rsync can efficiently
examine and synchronize filesystems without using find. And while it
may miss files that are written while it's running, it *will* get them
on the next run, unlike using "find".
If you need guaranteed-complete filesystem-level snapshots, you need to be using something at the kernel level that can atomically collect the set of modified blocks/files, rather than something that crawls the tree in user space.
Generally, I agree with you. In fact:
https://bitbucket.org/gordonmessmer/dragonsdawn-snapshot
https://github.com/rsnapshot/rsnapshot/pull/44
Doing block-level differentials is nice, if you're using ZFS. But not
everyone wants to run ZFS on Linux. I do think that backing up
snapshots is important, though.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
