duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Upgrade/rollback difficulties


From: Russell Clemings
Subject: Re: [Duplicity-talk] Upgrade/rollback difficulties
Date: Sun, 2 Nov 2014 18:01:04 -0800

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.

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. 

rac

On Sat, Nov 1, 2014 at 8:36 AM, Martin Pool <address@hidden> wrote:
The original error is due to the new code using the Python ternary syntax 'a if b else c', which was added in Python 2.5. So you need to upgrade to 2.5 or later.

On Wed Oct 29 2014 at 4:52:30 PM Russell Clemings <address@hidden> wrote:
I've been using duplicity-0.6.08b (Python 2.4.3, boto-1.9b, GnuPG 1.4.5) successfully for quite some time, but decided it was time to upgrade. (Famous last words.)

I installed duplicity-0.6.25 and boto-2.1.1 and after resolving some new dependencies, I got the following when I tried to run a backup:

---------------------------------------------

address@hidden [/path/to/scripts/s3backup]# ./backup.sh
Import of duplicity.backends.cloudfilesbackend Failed: the scheme cf+http already has a backend associated with it
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1239, in ?
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1232, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1118, in main
    action = "">
  File "/usr/lib/python2.4/site-packages/duplicity/commandline.py", line 1062, in ProcessCommandLine
    backup, local_pathname = set_backend(args[0], args[1])
  File "/usr/lib/python2.4/site-packages/duplicity/commandline.py", line 955, in set_backend
    globals.backend = backend.get_backend(bend)
  File "/usr/lib/python2.4/site-packages/duplicity/backend.py", line 163, in get_backend
    return _backends[pu.scheme](pu)
  File "/usr/lib/python2.4/site-packages/duplicity/backends/_boto_single.py", line 163, in __init__
    self.resetConnection()
  File "/usr/lib/python2.4/site-packages/duplicity/backends/_boto_single.py", line 185, in resetConnection
    self.conn = get_connection(self.scheme, self.parsed_url, self.storage_uri)
  File "/usr/lib/python2.4/site-packages/duplicity/backends/_boto_single.py", line 38, in get_connection
    from boto.s3.connection import S3Connection
  File "/usr/lib/python2.4/site-packages/boto-2.1.1-py2.4.egg/boto/s3/connection.py", line 292
    delimiter = '?' if '?' not in auth_path else '&'
                     ^
SyntaxError: invalid syntax

---------------------------------------------

So I cleaned out all of the new duplicity and boto files and reinstalled the old versions.

It started up just fine but then quit as follows:

---------------------------------------------

address@hidden [/path/to/scripts/s3backup]# ./backup.sh
Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20141025T050704Z.sigtar to local cache.
Copying duplicity-full.20140928T050703Z.manifest to local cache.
Copying duplicity-full.20141025T050704Z.manifest to local cache.
Copying duplicity-inc.20140928T050703Z.to.20140929T040702Z.manifest to local cache.

(and so on ... snipped a long list of files)

Copying duplicity-inc.20141027T040702Z.to.20141028T040704Z.manifest to local cache.
Copying duplicity-new-signatures.20141025T050704Z.to.20141026T040703Z.sigtar to local cache.
Copying duplicity-new-signatures.20141026T040703Z.to.20141027T040702Z.sigtar to local cache.
Copying duplicity-new-signatures.20141027T040702Z.to.20141028T040704Z.sigtar to local cache.
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1239, in ?
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1232, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1137, in main
    globals.archive_dir).set_values()
  File "/usr/lib/python2.4/site-packages/duplicity/collections.py", line 679, in set_values
    (backup_chains, self.orphaned_backup_sets,
  File "/usr/lib/python2.4/site-packages/duplicity/collections.py", line 804, in get_backup_chains
    map(add_to_sets, filename_list)
  File "/usr/lib/python2.4/site-packages/duplicity/collections.py", line 794, in add_to_sets
    if set.add_filename(filename):
  File "/usr/lib/python2.4/site-packages/duplicity/collections.py", line 89, in add_filename
    self.set_manifest(filename)
  File "/usr/lib/python2.4/site-packages/duplicity/collections.py", line 117, in set_manifest
    assert not self.remote_manifest_name, (self.remote_manifest_name,
AssertionError: ('duplicity-full.20140928T050703Z.manifest.gpg', 'duplicity-full.20140928T050703Z.manifest.gpg')

---------------------------------------------

I'd appreciate some guidance on resolving the second error so that I can get my backups going again.

After that, I may try the upgrade again, so any advice on the first error would be useful as well.

rac


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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]