rdiff-backup-users
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]