On Tuesday, June 09, 2020 12:30:24 PM Robert Nichols wrote:
> On 6/9/20 9:44 AM, [email protected] wrote:
> > In the case of rdiff-back, it wouldn't surprise me that diffs (deltas)
> > are stored as forward deltas, and, in removing old deltas, a new "base"
> > must be created before deleting the deltas. (My words probably aren't
> > exactly correct, I hope they are correct enough to explain my point.)
>
> That's not how rdiff-backup works. The diffs are _reverse_ diffs, working
> back from the current state.
Ahh, ok, thanks! (Now I know something about rdiff-back ;-)
> Any metadata or increments file with a date
> stamp older than the cutoff date can be simply deleted. I suspect that the
> problem is the time spent parsing all of the file names in the _huge_
> increments directory tree and comparing the date code.
>
> Speaking the the huge increments tree, a pet peeve of mine is that changes
> that do not affect file content cause a "zero diff" file to be generated.
> These can be changes to permissions and ownership, or even just a change
> to the hard link count. The files are typically compressed empty files,
> and are not empty themselves (there is at least a gzip header). I run an
> audit to get rid of most of these at the end of each day, after all
> clients have completed their backups. The first time I ran it, the count
> was well into the millions.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.