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
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
|