Duplicity exits with error on first run.

[Trym Hansen <trym@…>]

Zentyal 2.0.3.

Duplicity exits with an error the first time you run it on a fresh install:

Output: --- NcFTP version is 3.2.2 Synchronizing remote metadata to local cache... Copying duplicity-full-signatures.20110213T153011Z.sigtar to local cache. Traceback (most recent call last):

File "/usr/bin/duplicity", line 1257, in <module>

with_tempdir(main)

File "/usr/bin/duplicity", line 1250, in with_tempdir

fn()

File "/usr/bin/duplicity", line 1151, in main

sync_archive()

File "/usr/bin/duplicity", line 965, in sync_archive

copy_to_local(fn)

File "/usr/bin/duplicity", line 925, in copy_to_local

size=sys.maxint)

File "/usr/lib/python2.6/dist-packages/duplicity/gpg.py", line 331, in GzipWriteFile?

new_block = block_iter.next(min(128*1024, bytes_to_go))

File "/usr/bin/duplicity", line 903, in next

(self.fileobj.name, sys.exc_info()),

AttributeError?: FileobjHooked? instance has no attribute 'name' --- If you run it again, it runs normally.

Also, the next run after upgrading system shows: --- NcFTP version is 3.2.2 Local and Remote metadata are synchronized, no sync needed. Last full backup date: Sat Mar 5 11:09:39 2011 Invalid data - SHA1 hash mismatch: Calculated hash: b402dcd2294d7161839847baabe4ba93c2f43da6 Manifest hash: 1ac54a7b15694c8c98e37f15400e2a8c35eb7218 --- Again, next run works normally.

How to reproduce:

o Install Zentyal, 32- or 64-bit. o Run duplicity restore from a shell.

[jamor@…]

In order to reproduce it:

• what was the duplicity command you used?
• you were using the FTP method?

Thanks

[Trym Hansen <trym@…>]

Replying to jamor@…:

In order to reproduce it:

• what was the duplicity command you used?
• you were using the FTP method?

Thanks

Yes. This command to be exact:

duplicity restore --file-to-restore var/lib/ebox/extra-backup-data/confbackup.tar  ftp://user:password@backupserver confbackup.tar --no-encryption --force

::Trym

[anonymous]

Sorry but I need a bit more of clarification. When you say 'on first run' you mean the first run after having at least one backup made?

[Trym Hansen <trym@…>]

Replying to anonymous:

Sorry but I need a bit more of clarification. When you say 'on first run' you mean the first run after having at least one backup made?

No, I mean the first time you run duplicity after having freshly installed 2.0.3.

So...

o Install Zentyal o Install the backup and network modules. o run duplicity restore.

It exits the first time, works the next.

::Trym

[jamor@…]

Ok, I get it. You have already a duplicity-made backup by hand in your ftp server and now you want to manage it using Zentyal. (Please, correct me if I am wrong) This is a scenario that we don't have tested and we couldn't support because is strictly a duplicity issue not related with Zentyal. Why don't you make a backup using Zentyal and then test wethet you can recover it?.

[anonymous]

No, you don't get it.

This *is* a backup made by Zentyal.

Imagine this:

Your server makes a backup, successfully.

One day, it crashes and won't boot.

You install a new server and try to recover your files from the backup.

You get the error.

Unless you know it will work on the next run, it's time to panic.

(This is no big deal for me, I know it will work on the next run. Just trying to help.)

[jamor@…]

Ok, it seems that FINALLY I am getting it..

I will try to reproduce the situation this week.

Thanks for the report, is very helpful for us.

[jamor@…]

I tried to reproduce it in two machines without getting the error. I had tested both encrypted and unencrypted backups.

You say that you run it after a upgrade. maybe you had different duplicity versions in the two runs. You know if the upgrade included a new duplicity version?.

This could be know grepping /var/log/dpkg. log for 'duplicity'

[Trym Hansen <trym@…>]

I've recently deleted a lot of the old backup sets, as I've basically had to rebuild everything due to a mysql error, and you are right, I cannot any longer reproduce the error, although it consistently used to appear. I've also stopped using incremental backups to minimize the risk of backup corruption. (I perform backups and install and restore virtual and physical machines daily as part of testing the how-to I've made.)

I *could* run a test where I install 2.0.2 without upgrading, perform a backup, update, and create more backups using the existing configuration, I have a feeling that would reintroduce the error. I can't justify spending the time however.

What is worrying about this is that an 'upgrade' may have invalidated previous backups without warning. (The error doesn't worry me as much as the inconsistent "manifest hash" warnings.)

Personally I've deleted all old backup sets and manually made brand new ones for all servers I maintain, I guess that's the wisest thing to do for anybody who configured backup a long time ago.

I guess this topic can be closed as resolved, but if I were you I'd do further tests combining old and new backups with old and new versions of duplicity (especially when a new version appends an incremental backup to one made by an older version). This may come back to bite you.

::Trym

[anonymous]

Trym,

your feedback is very appreciated. I will talk with the team to setup better compability tests for the backup.

Cheers,

Javier