Re: [Duplicity-talk] Upgrade/rollback difficulties

[edgar . soldin]

On 03.11.2014 03:01, Russell Clemings wrote:
> Thanks. I've solved this now and am posting the details in case they could 
> help someone else.
> 
> This is a cPanel server, CentOS 5, and there are lots of warnings on the 
> cPanel forums about upgrading Python beyond 2.5 for that OS. But in the 
> course of researching that issue, I learned that I could just install 
> duplicity 0.6.21-1 from the epel repository, so I did. Now I have Python 
> 2.4.3, Duplicity 0.6.21-1, and boto 1.9b. Not the latest versions, but newer 
> than what I had. That's the good news. The bad news is when I tried to run a 
> backup, I still got the "Assertion error" problem:
> 
> File "/usr/lib/python2.4/site-packages/duplicity/collections.py", line 123, 
> in set_manifest
>     assert not self.remote_manifest_name, (self.remote_manifest_name,
> AssertionError: ('duplicity-full.20140928T050703Z.manifest.gpg', 
> 'duplicity-full.20140928T050703Z.manifest.gpg')
> 
> The only way I was able to get it to work was to delete everything from 
> /root/.cache/duplicity.

that's fine. it get's recreated from the remote in case it is missing data 
duplicity needs.
 
> I think the problem may have resulted from my initial, unsuccessful attempt 
> to upgrade Boto. My S3 bucket name was all uppercase; more recent versions of 
> Boto won't accept that, I learned. So I created a new bucket with all 
> lowercase letters. I think what happened to cause the "AssertionError" was my 
> backup script was pointing to the new bucket but the cache entries were from 
> the old backup. At least that's my theory. I can't prove it at this point.
> 
> Here's why I think that: I have a second server with cPanel and CentOS 6, and 
> I decided to upgrade its duplicity as well after getting the first one 
> working. When I did a "yum install duplicity" on the second server, it gave 
> me Python 2.6.6, Boto 2.32.1, and duplicity 0.6.22. Boto again objected to an 
> all-uppercase bucket name, so I created a new all-lowercase bucket, pointed 
> the scripts to it, and both backups and restores worked fine.
> 
> The restriction on bucket names, I gather, comes from Amazon. I don't know 
> when it began; it clearly wasn't in place when I set this up several years 
> ago. The earliest notes I have are for duplicity-0.6.06, which looks like 
> 2009-10, so it must have been in that timeframe. 
> 

some general remarks:

1. be aware that s3 charges by traffic. this makes verifying expensive.
2. after all that you should verify your older backups or live with it, if you 
can't restore them (but see 1.)
3. we had a silent corruption bug that can occure on resuming (fixed in 
0.6.23), the latest duplicity is 0.6.25. either consider upgrading from tarball 
or verify periodically to be warned when it occurs.

here's a short howto on installing duplicity from tarball (section TIPS/INSTALL 
MULTIPLE VERSIONS). 
 http://duply.net/wiki/index.php/Duply-documentation
installing it to e.g. /usr/local/ would allow you to not to interfere with your 
package manager.

..ede/duply.net