Comment 10 for bug 1875937

TLDR;

Simply temporarily restore the signature files from glacier to s3. Once the restore is complete, configure your backup to use the legacy "boto+s3://" and run the incremental backup.

-=-=-=-=-=-

To clarify the issue reported here (recently), there seems to be an edge case where during the last incremental backup the `duplicity-new-signatures.20220720T121233Z.to.20220724T120838Z.sigtar.gz` signature file was not saved to local cache.

However, the signature file is saved to S3 with the glacier storage class.

On the next incremental backup, it of course fails when duplicity attempts to save the signatures file to local cache, but cannot access the glacier file.

For myself, incremental backups performed on/after July 24, 2022 did not save a local copy of the signature file.

I can confirm that my backup was configured with "s3://" and "--s3-use-deep-archive". Thus, my hypothesis is that edge case here is due to performing a one-time successful incremental backup being after the user updated duplicity with s3:// default to boto3, and for whatever reason the signature file was not saved to the local cache (as you mentioned Boto3 does not support glacier yet).

To leave a breadcrumb trail to solve the issue for others, temporarily restore the signature files from glacier to s3. Once the restore is complete, configure your backup to use the legacy "boto+s3://", you will also need to configure "--s3-region-name" and "--s3-endpoint-url" and run the incremental backup.

It will download the signature files to cache, and also successfully save any new signature files from the incremental backup to the local cache. (Just fixed my glacier backups, and can confirm v0.8.23 is working as it should with glacier).