My incremental job uses the same parameters as the full, and it fails on glacier/deep because duplicity tries to pull the remote manifest and can't retrieve it - here's what I run:
duplicity /mnt/backup/src boto3+s3://BUCKETNAME/FOLDERNAME --file-prefix-archive archive-$(hostna me -f)- --file-prefix-manifest manifest-$(hostname -f)- --file-prefix-signature signature-$(hostname -f)- --s3-use-deep-archive ...and here's the output: Synchronizing remote metadata to local cache... Copying signature-backup.HOSTNAME.com-duplicity-full-signatures.20200830T050003Z.sigtar.gpg to local cache. Attempt 1 failed. ClientError: An error occurred (InvalidObjectState) when calling the GetObject operation: The operation is not valid for the object's storage class It tries 4 more attempts and then fails completely. I'm still not following the logic here anyways - wouldn't it be better to store the signature files as as a standard class file, and allow the metadata sync to proceed as usual...rather than just disabling metadata sync for non-standard storage classes? The implementation seems to be inconsistent across AWS storage classes, and I can't get incrementals to work at all with glacier deep. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1875937 Title: Download of vol1 in validate_encryption_settings() fails when using S3 glacier To manage notifications about this bug go to: https://bugs.launchpad.net/duplicity/+bug/1875937/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
