duplicity-team team mailing list archive

[Brandon Anderson <Brandon753.ba@xxxxxxxxx>]

> restoring from remote usually assumes you have no local copy. so why would you
> expect a local manifest to be usable with remote volumes?

I agree that restoring from remote would assume the local manifest is unavailable requiring access to the remote copy, but I was referring to the ability to do incremental backups without having to pull the remote manifest from glacier or keep it stored in S3. If you are doing an incremental backup from a source wouldn't a reasonable assumption be that a local manifest file could be used? Currently duplicity tries to pull the remote manifest in order to do a incremental backup and because of how AWS glacier works it hangs, which is why I have the conditional store the manifest in standard S3 storage, but ideally all files would be stored in glacier and a local manifest could be used for incremental backups. 

> >Also while looking at this code it does not seem there is any command
> checking for exclusive storage options. If I where to enter in duplicity with
> the options '--s3-use-ia --s3-use-rrs --s3-use-onezone-ia' it looks like it
> would happily take all the options without throwing an error and store
> everything on Reduced Redundancy since that is the first option checked in the
> if statement. I have not looked super deep into this so maybe its checked for
> elsewhere but it stood out when I made the changes I did.
> 
> yeah. saw that as well. generally, as these options are excluding each other
> they should go into one switch. preferably like --s3-storage-class=glacier
> using the string that is used by the API as well. if you'd like o tackle that
> youre welcome. keep backward compatibility though. meaning the other
> parameters setting the new var.

Yea if I get some free time I will push a patch for that.
-- 
https://code.launchpad.net/~brandon753-ba/duplicity/aws-glacier/+merge/364306
Your team duplicity-team is subscribed to branch lp:duplicity.