• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue Backup manager fails to backup to S3 bucket

abanico

New Pleskian
Server operating system version
CentOS Linux 7.9.2009
Plesk version and microupdate number
Plesk Obsidian 18.0.64, update 1
Hello everybody!

I have two servers with Plesk Obsidian, and in one of them, the backup I have configured every day to S3 (actually it is Backblaze B2, but for this case, it is S3 compatible) fails when the backup is complete (i mean not incremental). Incremental backups don't give any problem, but when the full backup is done, it takes 10 to 15 hours (for a 250 GB backup) and what's worse, most of the time it fails. In the failure detail most of the time it says ‘Unable to create the remote backup: Transport error: Extension transport: ext://s3-backup/server/: no tomes available’.

On the other server the backup is smaller for now, but has never failed, and on the Backblaze side there doesn't seem to be any problems. At first I had it set to upload a single file, but then I set it to upload in volumes of 1024MB each. Even so, it still fails. This has been happening for months now, regardless of Plesk updates.

Can anyone think of what might be going on? Thanks in advance!
 
Further research showed that the error "no tomes available" is specific to backblaze storage here's the quote from the vendor's documentation:

A Backblaze Vault is comprised of 20 Storage Pods, with the data evenly spread across all 20 pods. Each Storage Pod in a given vault has the same number of drives, and the drives are all the same size.
Drives in the same drive position in each of the 20 Storage Pods are grouped together into a storage unit we call a “tome”. Each file is stored in one tome, and is spread out across the tome for reliability and availability.

I would suggest contacting the vendor's support and clarifying with them. It could be some exceeded limit of service like number of uploads or maintenance on their side. If there's evidence that Plesk involvement is required, it will be best to consider submitting a ticket with our support team as access to the server will most likely be necessary.
 
Thank you Sebahat.hadzi! I've opened a support ticket with Backblaze to clarify this, and for now I've changed the backup configuration to do it on Amazon S3 (fingers crossed!).
 
I have spoken to Backblaze. It seems that the fact that it gives error 500 when a ‘tome’ is full is expected behaviour from Backblaze, and they say that any backup software should retry the connection a few seconds later, and in that case, it would no longer give error 500 (it makes sense for the software to do several retries before giving it up!). So the ball is back in Plesk's court. Are there any plans to incorporate Backblaze support in Backup to cloud pro, as they are a quite popular cloud service?
 
Hey, @abanico. By default, the backup manager should try to reattempt the connection 3 times. What you can do is to try increasing the values by adding the following code in your panel.ini file:

[ext-s3-backup
MaxResumeAttempts = 30
MaxResumeFailures = 30
PauseBetweenAttempts = 30

Hopefully, that will sort out the issue.
 
Back
Top