Prevent duplicity to download all manifests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Prevent duplicity to download all manifests

duplicity-talk mailing list
Whenever I want to restore some files to another machine (no local cache), it downloads ALL manifests. When I want only the latest version, I only need the last full one and following incremental ones. This could be detected based on the filenames which include the dates.
This change would speed up restore times a lot. We have a full backup every day but store 6 months of history for example.

Am I just missing some option or is there really no other way?

Btw: I found this "solution" to add a custom prefix which includes the date (again): https://serverfault.com/a/806266/347492

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: Prevent duplicity to download all manifests

duplicity-talk mailing list
On 15.10.2018 23:40, darkdragon via Duplicity-talk wrote:
> Whenever I want to restore some files to another machine (no local cache), it downloads ALL manifests. When I want only the latest version, I only need the last full one and following incremental ones. This could be detected based on the filenames which include the dates.
> This change would speed up restore times a lot. We have a full backup every day but store 6 months of history for example.
>
> Am I just missing some option or is there really no other way?

unfortunately not. you are right totally right, but as it stands it is implemented like that right now. you are welcome to provide a patch though ;)
 
> Btw: I found this "solution" to add a custom prefix which includes the date (again): https://serverfault.com/a/806266/347492

that guy creates daily independent backup chains, meaning the next day no full prefixed '${BACKUP_DATE}_' and a new one chain is started. probably not what you want.

a workaround is moving backup data (chains) on the backend into different folders effectively limiting the amount of chains the duplicity restore run sees. not elegant, but works.

and again. if you need it, you are welcome to contribute it ..ede/duply.net

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk