[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reverting backup location to a previous state
From: |
EricZolf |
Subject: |
Re: Reverting backup location to a previous state |
Date: |
Sun, 26 Jul 2020 06:56:34 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
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