On Tuesday, June 09, 2020 12:30:24 PM Robert Nichols wrote: > On 6/9/20 9:44 AM, rhkra...@gmail.com 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.
