On Thu, 16 Mar 2023, at 14:50, Alessandro Boem wrote:
> Hi Nikolaus,
>
>
> Il giorno giovedì 16 marzo 2023 alle 12:49:56 UTC+1 Nikolaus Rath ha scritto:
>> __
>> Hi Alessandro,
>>
>>
>> On Wed, 15 Mar 2023, at 14:57, Alessandro Boem wrote:
>>> We're trying to recover the consistency of the db from a machine power
>>> outage.
>>> I know that the project is no longer developed, but we're looking for an
>>> extra docs/help trying to recover the data.
>>>
>>> Reading and following the available documentation, we have already tried
>>> these:
>>> fsck.s3ql s3c://r1-it.storage.cloud.it/bdrive --authfile=/etc/s3ql.authinfo
>>> --cachedir=/var/cache/s3ql/bdrive/
>>> s3ql_verify --authfile=/etc/s3ql.authinfo
>>> --cachedir=/var/cache/s3ql/bdrive/ s3c://r1-it.storage.cloud.it/bdrive
>>> s3qladm upgrade s3c://r1-it.storage.cloud.it/bdrive
>>> --authfile=/etc/s3ql.authinfo --cachedir=/var/cache/s3ql/bdrive/
>>> We always receive these message:
>>> ERROR: File system revision needs upgrade (or backend data is corrupted)
>>> We have a backup of the db file and we restored it without success (we
>>> still receive the previous error)
>>
>> Can you provide a bit more information? How exactly did you restore the
>> metadata backup (full command and output)? Which backups did you try?
>>
> First I ran all the cited three command in that order and all of them return
> the error.
> I did not restore the metadata from backend but I've tried to restore the
> file with .db extension in /var/cache/s3ql/bdrive from machine last backup
> before crash (backup was performed at same day of the crash at midnigh, the
> machine power outage was at 09:30)
The error message refers to what is stored in the cloud. It's quite possible
that nothing at all is wrong with the files in /var/cache/s3ql.
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
>
>
>>
>> Is it possible that you accidentally upgraded from an old S3QL version (so
>> your data isn't corrupted at all, and you just have to upgrade through some
>> not-quite-as-old S3QL version)?
>>
> We 're using s3ql version 3.3.2 on an Ubuntu 20.04 server release
That's what you're using now, right? Which version did you use before the crash?
> I also tried to upgrade to a later version the package (4.0.0) compiling and
> installing it with setup.py, then I ran
> s3qladm upgrade s3c://r1-it.storage.cloud.it/bdrive
> --authfile=/etc/s3ql.authinfo --cachedir=/var/cache/s3ql/bdrive/
> again with 4.0.0 release but it return the same error: ERROR: File system
> revision needs upgrade (or backend data is corrupted)
Of course. What I said is that you may need an *older* release (if you
accidentally upgraded, that is).
>>
>>> Taking a look at the backed data we can see that all the metadata copy have
>>> the same datetime:
>>
>>
>> The metadata backups may be created either by copying or by moving
>> operations: https://github.com/s3ql/s3ql/blob/master/src/s3ql/metadata.py
>>
>> It is possible that your backend uses copy, and sets the modification date
>> to the date of the copy (rather than the modification date of the source).
>> Is that possible? Are the *contents* of the backups identical as well?
> I checked with a HEX editor the metadata copy on the backend and they are
> different.
> Can I use a backup copy of metadata to restore file system coherence?
Yes, that is what 's3qladm download-metadata' is intended for.
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/3905b2cf-6f82-4a7c-9a6b-73f870174123%40app.fastmail.com.
