On Sat, 18 Mar 2023, at 23:24, Alessandro Boem wrote:
>
>> 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?
Above you said you are running `s3qladm download-metadata` and that this
failed. Could you please include the full command and full output of everything
you have done (not your summary of it)?
s3qladm does not attempt to download metadata until you have picked an object
to restore. Did you get that far? If so, which objects have you tried to
download? Do you get the error for all of them?
Similarly, fsck.s3ql should not attempt to download any objects if it is
running on the same computer on which the filesystem was most recently mounted.
Did you perhaps run it from a different system, or with a different cache
directory? Or is it giving the error at the *end* of the fsck (when attempting
to rotate metadata)?
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
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/2e697b24-7088-4a24-a73c-c0bcb3f18040%40app.fastmail.com.
