Andrew
On Wednesday, 10 December 2014, <
address@hidden> wrote:
Andrew,
if possible update to 0.6.25 to make sure this is not something fixed in between.
to simply workaround it. just start a new chain into a new remote target folder and duplicity will have nothing to sync anymore.
..ede/duply.net
On 10.12.2014 14:03, Andrew Langhorn wrote:
> From what I can see, it has unencrypted *.manifest and *.sigtar.gz files in
> two of the directories under ~/.cache/duplicity, but nothing in the
> remaining two; here's a Gist of the tree:
> https://gist.github.com/ajlanghorn/1f3c38e362a5d72990af
>
> We're running 0.6.18, which does appear to be a few behind given that the
> current is 0.6.25. Nothing else, that we're aware of, was deleted with the
> ~/.cache directory, but at this stage, I suppose it's difficult to tell
> either way.
>
> Thanks Ken!
>
>
>
> On 10 December 2014 at 12:55, Kenneth Loafman <address@hidden> wrote:
>
>> Duplicity needs the *.manifest and *.sigtar.gz files to be unencrypted in
>> the local cache. When syncing the remote to the local, the key is needed
>> in order to decrypt those files back into the cache. When you look in the
>> cache you should see only those kinds of files.
>>
>> It sounds like collection-status may be wrong about the sync of the data.
>> What version of duplicity are you running? What else was deleted along
>> with the .cache? Maybe it was something that supplied the password to gpg
>> (has nothing to do with private key).
>>
>> ...Ken
>>
>>
>> On Wed, Dec 10, 2014 at 6:10 AM, Andrew Langhorn <
>> address@hidden> wrote:
>>
>>> Hi,
>>>
>>> Recently, the contents of the ~/.cache directory of the user which some
>>> Duplicity jobs run under were removed. Since then, Duplicity backup jobs
>>> have failed to run because the GnuPG passphrase is now required. We don't
>>> store the private key on this machine, as we only need it to encrypt with
>>> the public key - decryption (if required) takes place elsewhere.
>>>
>>> From running 'collection-status', there appear to be some
>>> orphaned/incomplete backups on the remote, which I think is a new thing -
>>> these don't appear to have been there from before we lost `~/.cache`.
>>> 'collection-status' reckons that the local cache has been fully synced from
>>> the remote metadata.
>>>
>>> I don't want to pass the private key in to Duplicity to get this working,
>>> but I don't know how to get over this hurdle.
>>>
>>> Help?!
>>>
>>> Thanks! :)
>>>
_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk