Amazon S3 with Object lock

erlicthemad

I have been testing and was looking at trying to use the Amazon S3 settings with the BackBlaze buckets. I can get the Buckets to appear to work, but if I turn on 'Object Lock', the storage destination will fail. Reporting a write error. I suspect that XOA is trying to do something or clean up by deleting objects that the Object lock prohibits.

The purpose of the Object Lock is to ensure that once backed up all files/items are read-only and cannot be modified after written. To prevent malware from trying to delete or encrypt the backups.

Is this just a thing to have to accept from XOA, or is there some kind of a fix coming to allow for Object Lock to be used safely?

olivierlambert

Question for @florent

florent

@erlicthemad in theory object lock is honored by the backup process.
Can you post the full error log ?

erlicthemad

This is the message that appeared in the logs when Object lock was enabled. After changing the Object lock on the B2 bucket back to 0 the error resolved. In Backblaze once Object lock is enabled it cannot be disabled.

remote.test
{
"id": "395eab46-2f98-4581-b8da-1444f40da06a"
}
{
"message": "Cannot read properties of undefined (reading 'httpStatusCode')",
"name": "TypeError",
"stack": "TypeError: Cannot read properties of undefined (reading 'httpStatusCode')
at S3Handler._sync (/opt/xo/xo-builds/xen-orchestra-202404121746/@xen-orchestra/fs/src/s3.js:462:27)"
}

As a quick test, I turned the Object lock to 2 days and ran the connectivity test.

This is the error message that came back with a 2-day object lock.

Error

    {
      "name": "InvalidRequest",
      "$fault": "client",
      "$metadata": {
        "httpStatusCode": 400,
        "requestId": "4d2e36629f72e33e",
        "extendedRequestId": "aNKplp2YaZs40bWLzODM5kTl4N05hXWT/",
        "attempts": 1,
        "totalRetryDelay": 0
      },
      "Code": "InvalidRequest",
      "message": "Missing required header for this request: Content-MD5"
    }

Test step
    write

If I change the Object lock back to 0 days and rerun the connectivity test I get the following result. "The remote appears to work correctly"

florent

@erlicthemad we are doing some check atthe connection to the remote to detect Object Lock, since enabling Content-md5 is only mandatory then. And computing it means keeping a lot of more data in memory (code here https://github.com/vatesfr/xen-orchestra/blob/master/%40xen-orchestra/fs/src/s3.js#L452 )

let me look into the dock if we can detect it also for backblaze

edit : can you try to disable the remote, enable content lock and reenable the remote ?
have you got any message like 'Object lock is not available or not configured, don't add the content MD5 header' or 's3 user doesnt have enough privilege to check for Object Lock, enable content MD5 header' in your logs ?

erlicthemad

@florent I updated to build 16498 and followed your suggestion. Now it is showing that the connection is running and successful. I have a 2-day object lock enabled. In BackBlaze B2 Buckets once object lock is enabled you cannot disable it. You can change the days to lock to 0 but that will only affect new files. Existing files will be locked based on the Object lock settings applied when the file was saved.

It appears that this is resolved. I will try to run a few backups to my BackBlaze buckets to see if it runs.