On 25.08.2021 10:26, zga9uhnq4g--- via Duplicity-talk wrote:
Okay, I tried re-encrypting the 2020-12-12 files and copying them back to OneDrive, but
when I ran "duplicity verify --time 2020-12-12 ..." I got
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Aug 11 02:01:44 2021
Invalid data - SHA1 hash mismatch for file:
duplicity-full.20201212T204209Z.vol1.difftar.gpg
Calculated hash: bcac07d8b88aeff2b928090c35db072fe1444f47
Manifest hash: 0529e8d2384b24dec4d771f50dacca7d585188f8
So must have done something wrong. The command I used to reencrypt was
gpg2 --symmetric --cipher-algo AES256 $file
Do I need to give more or different option to gpg?
no, the re-encryption seems to have enabled duplicity to decrypt the files now.
the error comes from duplicity now as it correctly sees that the volumes were
modified after their first creation. it's possible that adding
'--ignore-errors' will not fail on the error but that should only be a last
resort, as it'll silently ignore other errors too, that might theoretically
there. nope, just tested, fails still.
just did some local tests and it looks like the hash is saved in the manifest
file under
"
Volume 1:
StartingPath ...
EndingPath ...
Hash SHA1 df901ba65335d73e6e9724c4fc9ed79adda4dfac
"
it should contain 0529e8d2384b24dec4d771f50dacca7d585188f8 now, replace it with
0529e8d2384b24dec4d771f50dacca7d585188f8, encrypt the new manifest and that
should get rid of the failed checksum in duplicity. you may need to do this for
all volumes obviously. 'sha1sum' can help you.
if that does not work instantly it might be because duplicity caches manifests
from remote. delete the archive dir cache for the repo to force duplicity to
become aware of the change. easiest is to provide a '--name foobar', then you
will find the folder under .cache/duplicity/foobar . delete it after you did
changes to your test repo and run duplicity only after and it will be recreated.
for your tests you may just place the files in a folder locally and run "duplicity
verify file:///absolute/local/folder". you can leave out time if you just place the
first full (and later incrementals) there as duplicity will test the one chain it should
find.
to make it maybe even more easier/complicated you may try working with the unencrypted
files by putting them in a folder and run duplicity like "duplicity
collection-status --no-encryption --no-compression file:///absolute/local/folder" .
that might probably fail though due to the checksums from above not being modified too.
good luck ..ede/duply.net
_______________________________________________
Duplicity-talk mailing list
Duplicity-talk@nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk