Re: Reverting backup location to a previous state

And because it was such a nice FAQ, I made a pull request out of it:
https://github.com/rdiff-backup/rdiff-backup/pull/435

KR, Eric

On 26/07/2020 06:56, EricZolf wrote:
> Hi,
> 
> what Daryl + Frank wrote _but_
> 
> On 26/07/2020 06:27, Frank Crawford wrote:
>> Any help would be appreciated! Using the delete script to delete
>> all the directories that should have been excluded would take me a
>> very long time.
> 
> I'm surprised by this statement: regression takes a very long time, I
> wouldn't swear that deleting the files is faster, but that would be my
> expectation.
> 
> Just to have a little bit of fact, I tried both actions on two copies of
> the same repo (the restoretest3 repo we use in our tests):
> 
> $ time .../rdiff-backup-regress.sh -f /tmp/restoretest3.reg
> [...]
> real	0m0.368s
> user	0m0.299s
> sys	0m0.064s
> 
> $ time rdiff-backup-delete /tmp/restoretest3.del/nochange
> [...]
> real	0m0.042s
> user	0m0.033s
> sys	0m0.009s
> 
> It's of course impossible to generalize from such a small test but
> logically it makes sense that deleting takes ~10x less time:
> 
> - deletion applies only to the unwanted files and their ancestors, and
> implies only finding and deleting impacted files.
> - regression requires finding all the files of the last generation, and
> recreating them from the current one, via delta generation, and then
> deleting the current generation (the mirror). This means calculating,
> writing and deleting files.
> 
> As said, I can't tell for your specific setup but given that you have
> only one generation of the unwanted files, I guess that deletion will be
> also much faster than regression, unless you have good reasons to
> believe otherwise.
> 
> KR, Eric
>