Re: [Duplicity-talk] File restore extremely slow

[Nate Eldredge]

On Thu, 27 Aug 2015, Kevin Carr wrote:

> When you restore, duplicity first has to download the signature files.  It
> then locates the gzip that contains the file you want which is usually
> around 25mb and downloads it.

Does the signature file actually record which volume(s) each file is 
contained in?  I didn't think it did.  (And I just extracted a sigtar file 
and didn't see anywhere this information could be.  There appears to be 
one rdiff signature per regular file, and no further data.)

The signature files will tell you which of the incrementals contain your 
file, so that any incrementals for which the file didn't change don't have 
to be downloaded.  But you have to download everything else.  For 
instance, if your file existed when the full backup was made, you'll have 
to fetch all volumes of the full backup, together with all volumes of each 
incremental in which the file changed, up to the desired restore date.

(Note that "download" is a little of a misnomer in the OP's case; the 
backup URL is file:, so the backup data is stored locally and won't take 
much time to transfer.  The bottleneck is either reading the backups from 
disk, or (more likely) decrypting them.)

> I have had the process take an hour if I didn't have the signature files
> synced properly.
>
> On Thu, Aug 27, 2015, 4:12 PM Grant <address@hidden> wrote:
>
> > Restoring an 85kb file like this took about 30 minutes:
> >
> > # duplicity --tempdir /root --use-agent --encrypt-key=........
> > --sign-key=........ -t 7D --file-to-restore path/to/file.txt
> > file:///backups /home/user/file.txt
> >
> > Would a 1MB file take 11 or so times longer?  Is there any way to speed
> > that up?
> >
> > - Grant
> >
> > _______________________________________________
> > Duplicity-talk mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/duplicity-talk

--
Nate Eldredge
address@hidden