Re: [Duplicity-talk] Slow file restore

[Kenneth Loafman]

address@hidden wrote:
> Background:
> 
> Probably not the best configuration... but my latest set of backups is
> on a remote Windows server (not my choice) as a full backup followed by
> weeks of incrementals.  The Windows server can't handle the normal
> filenames use by duplicity, so the --short-filenames option is needed.
> The Windows directory is mounted using samba.  Oh yes: running Debian/
> lenny with duplicity 0.4.11 on a AMD dual core / nVidia MB.
> 
> I just had the "opportunity" to restore a file from this backup set.
> This was done as:
> 
>   duplicity --file-to-restore --short-filenames file:///directory/path 
> path/name/restore.this.file
> 
> This absolutely crawled - on screen it appeared as though the system was
> resolving each and every file in creation until, it is hoped, it reached
> the named file.  After hours of waiting (there's 20GB of backup data in
> this directory), I killed the restore operation as I could get this old
> file from an old tar in a few minutes.
> 
> Is there a more efficient way to invoke duplicity in this situation?
> In comparison, the backup speed (same server, same connection) is fantastic!
> Thanks Ken, for all your great work!

No, its just slow for this kind of process.  The underlying file
structure is still tar, so there's no central directory.  It has to go
through the entire full backup to find the file, then through all the
incrementals to update the file.  Given that you were remote, a full
restore could probably be done in just a bit more time than a single
file restore.

...Ken

signature.asc
Description: OpenPGP digital signature