duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Backup recovery downloads all signatures


From: Romain Thouvenin
Subject: Re: [Duplicity-talk] Backup recovery downloads all signatures
Date: Wed, 4 Jul 2018 15:00:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

Thanks both for your answers.

I understand now why the whole cache was rebuilt. If optimizing this is not too complex, I think it would be great addition to duplicity.
The reason I didn't have a cache in place is that the server where the backup takes place had become unavailable, and so I was recovering from another server. I imagine this is a common case in disaster recovery.

Thanks for the tip on renaming the backup for each full backup. The command is already scripted, so it shouldn't be difficult to implement it.

Thanks for your work,
Romain


On 04/07/18 14:21, Kenneth Loafman wrote:
Hi Romain,

When duplicity starts it checks to see that it has a complete local cache of metadata.  It prepares the cache for any command that may be present.  It could be optimized by command, but it's not.  The best way to avoid this is to always leave the cache in place.  The second is to follow ede's recommendation and make each full backup in its own directory, under its own backup name.  This may require writing a script so the 'full' command is issued every three months after creating the new directory.  Be sure all the 'inc' commands use the same '--name'.

...Thanks,
...Ken


On Wed, Jul 4, 2018 at 6:39 AM <address@hidden> wrote:
On 03.07.2018 16:11, Romain Thouvenin via Duplicity-talk wrote:
> When running this command, I noticed that duplicity seems to download
> all the signatures since the first backup. Below you can see an extract
> of the output.
>
> Why is that? I had understood that one reason for doing regular full
> backups what precisely to avoid this.

nope. the reason for shorter chains is that one corrupt volume might render the whole chain useless. atleast all files that were initially or partly stored in it will fail to restore.

>Downloading all these signatures
> takes ages. Am I missing something?

well, yes. duplicity always works with a complete archive folder, regardless if it is actually needed or not. it is simply the way it was designed.

you can easily work around it though by assigning a new subfolder every 3 month as backup target. this way the resynced archive folder will hold only this time span.

i am not sure we really need the refreshed archive dir for a plain restore though. or at least if, then we could limit it to the given restore date chain.
@Ken: what do you think?

..ede/duply.net


reply via email to

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