Il giorno sabato 18 marzo 2023 alle 11:39:29 UTC+1 Nikolaus Rath ha scritto:
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
On Fri, 17 Mar 2023, at 11:31, Alessandro Boem wrote:
Il giorno venerdì 17 marzo 2023 alle 12:05:03 UTC+1 Nikolaus Rath ha
scritto:
On Fri, 17 Mar 2023, at 09:42, Alessandro Boem wrote:
File system was created with version 3.3.2 and that's the version in use at
the time of crash.
[...]
Ok nice. I ran s3qladm download-metadata s3c://r1-it.storage.cloud.it/bdrive
--authfile=/etc/s3ql.authinfo --cachedir=/var/cache/s3ql/bdrive/
but I got the same error: ERROR: File system revision needs upgrade (or
backend data is corrupted)
If you really did not change S3QL versions, then this sounds as if the
s3ql_passphrase object in the cloud has somehow been corrupted.
I have no idea how this could possibly happen (since S3QL never writes to
it after mkfs), nor how it could be related to a local system crash.
Maybe check if there's a backup of this object somewhere? Otherwise you can
use 's3qladm recover-key' to restore this object from your offline copy of
the master key (which you hopefully created at mkfs time).
This object contains the master key, so without it you can't decrypt any of
the other objects.
When I create the filesystem I specified the --plain option. Shoud I find
an s3ql_passphrase in the backend if I used that option? I can't see any
file with that name on the backend...
In that case there should be no such object. Also, in that case you should
never see the above warning, because that gets generated if this object
exists but cannot be read.
Might be interesting to dump the communication with the backend to find out
what the backend is returning when S3QL asks for this object. It should be
a 404 response, which in turn should tell S3QL that the filesystem is not
encrypted.
You could force this behavior by replacing 'backend.fetch('s3ql_passphrase')'
with 'raise NoSuchObject('s3ql_passphrase')' in
https://github.com/s3ql/s3ql/blob/master/src/s3ql/common.py#L265 (but
that's not really a solution).
I've changed the line to raise the NoSuchObject instead to fetch the
passphrase but it return the same error.
Running fsck it doesn't raise the exception at line 283 but the one at line
325 of common.py
So the backend seem to gave the correct response 404 requesting a correctly
missing s3ql_passphrase, but s3ql_metadata is unreadable.
Do I have to try the others copy of s3ql_metadata?
Best,
-Nikolaus
--
You received this message because you are subscribed to the Google Groups
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/s3ql/d4cceb3a-e72f-4d75-81d5-80d3ad019d05n%40googlegroups.com.
