Comment 28 for bug 1039511

I've written a patch for Duplicity that should add support for handling files in S3 that are stored on Glacier. As of now, Amazon does NOT allow uploading directly to Glacier. This should be handled through lifecycle rules you specify on your duplicity bucket. See my post above for an example on how to handle this.

What my patch does is check to see if the files required are stored on S3 or Glacier. It will then initiate a restore option for every file that is in glacier and wait for the files to finish restoring before continuing (thus, duplicity won't break, it will just be checking every 60 seconds to wait and see if the files have been moved). If your local cache is out of sync with the remote bucket, it will make sure the manifests are transferred to S3, then if you chose to do a restore option, it will make sure the required files are transferred to S3. This means it could potentially take up to 10 hours of Glacier -> S3 time, which is not ideal but at least its something.

This patch also merges parts of the _boto_multi.py and _boto_single.py code since they largely overlap. Not sure if there was a reason to keep the two separate.

Tests I plan to run:
1. Clear my local cache and try to do a restore from a point in time that is being stored in Glacier (Done and tested: PASSED)
2. Do a restore from a point in time that is not in Glacier (Done and tested: PASSED)
3. Do a backup using multi-upload processing (Will do tonight)
4. Do a backup using normal upload processing (Will try tomorrow night)

I see there's also a branch on launchpad that adds Glacier as a backend. My approach is adding compatibility with the current S3 backend instead of making a new one, you could "mimic" a Glacier backend by using lifecycle rules in S3 to immediately transfer to Glacier.