Déjà Dup

unnecessarily fetches manifest from remote, disaster results

Asked by Dave Cottingham

deja-dup is failing on attempting to grab a copy of the manifest from the remote server. The failure is no mystery -- I'm using S3 and transitioning everything to Glacier, so of course the remote stuff cannot be read. But I don't understand why deja-dup is trying to grab it. The local cache has the manifest.

To get more insight, I set DEJA_DUP_DEBUG=1 and slogged through the result. Everything looks fine, including the usual duplicity message "Local and Remote metadata are synchronized, no sync needed." But after checking everything and satisfying itself that everything's in order, deja-dup then mysteriously tries to retrieve the manifest. Can anybody tell me how to prevent this behavior?

Perhaps I should add that I had one full backup and two incremental backups succeed before I hit this problem.

Question information

Language:
English Edit question
Status:
Answered
For:
Déjà Dup Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Michael Terry (mterry) said : 		#1

This is more of a duplicity question than a deja-dup one. Duplicity treats the remote side as authoritive, so will prefer the remote versions of files to the local cache ones. Thus if it decides it wants a manifest file, it may try to download it...?

And it may well decide it wants a manifest file when restoring a file. Deja Dup 24.0 (in Ubuntu 12.10) will restore a test file at the end of each backup to verify it worked. Maybe that's what you're hitting.

On a side note, Deja Dup is not tested or advertised to work with Amazon Glacier. Your mileage may vary (as you see).

Revision history for this message
Dave Cottingham (dcottingham00) said : 		#2

"Deja Dup 24.0 (in Ubuntu 12.10) will restore a test file at the end of each backup to verify it worked."

I'm using deja-dup 22.0, but if it's trying to do something along these lines, it would definitely be error-prone when used with Glacier. Is this documented anywhere?

Anyhow, I guess I'll resolve my problem by going back to using duplicity directly.

Let me first make a couple comments:
1. The log file produced by DEJA_DUP_DEBUG=1 would be much improved if it gave the duplicity command lines. As it is, it leaves you guessing what deja-dup asked duplicity to do, much less why.
2. On my other machines I have so far not run into any similar trouble doing duplicity backups with Glacier.

Revision history for this message
Michael Terry (mterry) said : 		#3

Indeed, you can see the duplicity command lines if you define G_MESSAGES_DEBUG=all. I should enable that when you set DEJA_DUP_DEBUG=1 too.

Can you help with this problem?

Provide an answer of your own, or ask Dave Cottingham for more information if necessary.

To post a message you must log in.