Download of vol1 in validate_encryption_settings() fails when using S3 glacier

Bug #1875937 reported by Alexander Hofstätter on 2020-04-29
18
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Duplicity
Low
Unassigned
duplicity (Ubuntu)
Low
Unassigned

Bug Description

Duplicity version: 0.8.12.1612
ubuntu 20.04 LTS
python 3.8.2

When i try to restart a backup which goes to S3 (via boto3) (use of: --s3-use-deep-archive or --s3-use-glacier) it fails:

Last full backup date: Wed Apr 29 17:45:32 2020
RESTART: Volumes 2 to 2 failed to upload before termination.
         Restarting backup at volume 2.
Attempt 1 failed. ClientError: An error occurred (InvalidObjectState) when calling the GetObject operation: The operation is not valid for the object's storage class
Attempt 2 failed. ClientError: An error occurred (InvalidObjectState) when calling the GetObject operation: The operation is not valid for the object's storage class

This is because a file stored in glacier cannot be downloaded. I dont know if this known?

To solve this: either skip validate_encryption_settings() when using any of this storage backends or introduce an option to skip the download manually (e.g. --skip-download-on-restart)

I fixed it for me with manully skipping the validate_encryption_settings() function.

description: updated

Update: Actually, all actions which require read access to the destination are not possible when the objects have a glacier-like storage classe are not possible ...

no longer affects: ubuntu

When using boto3, glacier restore is not supported yet. You'll need to download the backup to a local drive and restore from there.

Changed in duplicity:
status: New → Triaged
importance: Undecided → Low

Yes, this is clear as per design of the glacier storage backend. However, the problem ist not the restore action, the problem is that when duplicity wants to restart a backup (because e.g. the upload failed recently) it wants to download the latest archive to verify the use of the same keys.

This is not possible with glacier and therefore if the upload of a backup to glacier fails the backup can never be continued.

Changed in duplicity:
milestone: none → 0.8.14
status: Triaged → Fix Committed
Changed in duplicity (Ubuntu):
status: New → Fix Committed
importance: Undecided → Low
Changed in duplicity:
status: Fix Committed → Fix Released
Jack (jack-234521) wrote :

This is not fixed in 8.14 - glacier and glacier deep mode save the signature files in glacier/deep storage class, and --s3-use-ia stores BOTH the manifest and signature files in the IA storage class.

It seems to be working as it should. When you do the incremental are you specifying the storage class or using IA? We check to see if --s3-use-deep-archive or --s3-use-glacier is used and don't run validate_encryption_settings() if either is set.

Jack (jack-234521) wrote :

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.

Jack (jack-234521) wrote :

Sorry - mixed my words - as you can see it's failing on an attempt to retreive the remote *signatures* file, not the manifest file. The manifest is stored in standard class; the signatures file is stored in DEEP_ARCHIVE class.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers