Re: [Duplicity-talk] Upgrade/rollback difficulties

[Russell Clemings]

That worked great on the second (python 2.6) server, thanks.

On the first (python 2.4.3) server I get:

  File "/usr/local/src/duplicity-0.6.23/duplicity/progress.py", line 128

    class ProgressTracker():

SyntaxError: invalid syntax

I see a bug report (but no details) that suggests duplicity-0.6.23 won't work with python 2.4: 

https://bugs.launchpad.net/duplicity/+bug/1264847

The README still says "Python v2.4 or later."

Suggestions?

This is what works for me:

duplicity 0.6.21

Python 2.4.3

boto.Version '1.9b'

This gives me the error noted above:

duplicity 0.6.23

Python 2.4.3

boto.Version '2.0'

rac

On Mon, Nov 3, 2014 at 12:29 AM, <address@hidden> wrote:

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

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

--

===============================================
Russell Clemings

<address@hidden>
===============================================