Hi guys,

After successfuly backing up several times one of my TKL VMs has been failing to backup for the past week. In the log i see:

Deleting local /var/cache/duplicity/<some random characters>/duplicity-full-signatures.<timestamp>.sigtar.gz (not authoritative at backend)

and then the error:

os.unlink(del_name) 
OSError: [Errno 2] No such file or directory: '/var/cache/duplicity/<some random characters>/duplicity-full-signatures.<timestamp>.sigtar.gz'

I've had a look in that directory and the equivalent .sigtar.gpg file exists but not the .sigar.gz. Any suggestions on how to fix this? Can I create an empty file with the missing files filename or delete the .sigar.gpg file?

Cheers,

Andy

Forum: 
Jeremy Davis's picture

And from a cusory google it seems it may be related to a bug that Liraz (TKL core dev) lodged against Duplicity (TKLBAM backend) sometime ago. Note though that this bug is marked as a duplicate of this other bug, which is marked as 'fix released' as of version 0.6.08b-0ubuntu2.1 (the version currently available in Lucid - the basis of all v11.x TKL appliances). Although it may be possible if you have an older version of TKL this bug still exists in your appliance?

Probably the safest way to resolve this issue would be to install a fresh clean TKL v11.3 VM (of the same appliance) and run a restore from your backup (hopefully it's not missing too much data). I'd definately double and triple check everything and make sure it all works and that there is nothing missing prior to destroying the old VM.

Otherwise you could try just removing the duplicity cache, although I don't know what other side effects this may have and I can't test ATM. To do that, rename the existing cache and create a new cache folder:

mv /var/cache/duplicitiy/ /var/cache/duplicity.old
mkdir /var/cache/duplicity

and then run a fresh manual backup:

tklbam-backup

But be warned I can't guarantee the results of this, and it is possible that it may break your system (although you chould be able to return it to its current state by moving the cache folder back). Ideally it would be a good idea to snapshot (or similar) the VM prior to doing anything too much!

I did try a quick search on Google and the forums before posting and didnt find anything. 

Your suggestion worked. I created a snapshot, removed the contents of /var/cache/duplicity and then ran a backup. The backup was successfula and everything seems to be ok.

Thanks for the help.

Jeremy Davis's picture

But TBH I'm not sure why this has occurred. It sounds like my original workaround still works though... So until we have a better solution (and understanding of why this happens in the first place) I suggest you try that.

Add new comment