Error mirroring full backups to backblaze b2

pedro_udifar

Hello forum!

I recently begun mirroring my full backups to backblaze and I've been getting the error "maximum size allowed is (your minPartSize for the chunk)"

This error was supposed to be fixed, earlier this year, but I'm still getting it.
Actually PR #9396 might only fix direct backups and not mirror backups...
I'm running xo built last week. Object lock is set to 0 at backblaze for the time being, but I plan to turn it whenr this problem is over.

This may be caused because I'm mirroring from a local nfs remote (not encripted) to backcblaze remote (encripted) ? Maybe this scenario wasn't tested.

Anyway, everytime I run the mirror job the larger VMs would fail and all VMs would show warnings about issues checking XVA:

I've just bumped minPartSize to 100 000 000 (following the recomendation from Backblaze and hope that the maximum size allowed error goes away, though the warnings will still be there.

Thank you,
Pedro

poddingue

Thanks for the detailed write-up, Pedro.
I'm not a backup expert, far from it. but you might be right that https://github.com/vatesfr/xen-orchestra/pull/9396 only fixed the size estimation for direct full backups, not the mirror path.
Your error is the same as the maximum size allowed one, just twelve bytes over 209715200000. Before this turns into a GitHub issue, it would help to know whether it reproduces on a fresh mirror job and whether bumping minPartSize actually cleared it, so we can be sure it's the mirror code and not the B2 remote settings.
The object storage docs list Backblaze B2 as supported (https://docs.xen-orchestra.com/xo5/object-storage-support#supported-storage-providers) but don't say much about part-size tuning.
If it's awkward to test in isolation, a mention to @Team-XO-Backend is probably the quickest route, since they own the backup job code.
The XVA checksum warnings in your second screenshot look like a separate non-blocking clean VM directory step rather than the cause.
I hope that points somewhere useful!

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(backups): size estimation of full backups #9396

florent

@poddingue said:

Thanks for the detailed write-up, Pedro.
I'm not a backup expert, far from it. but you might be right that https://github.com/vatesfr/xen-orchestra/pull/9396 only fixed the size estimation for direct full backups, not the mirror path.
Your error is the same as the maximum size allowed one, just twelve bytes over 209715200000. Before this turns into a GitHub issue, it would help to know whether it reproduces on a fresh mirror job and whether bumping minPartSize actually cleared it, so we can be sure it's the mirror code and not the B2 remote settings.
The object storage docs list Backblaze B2 as supported (https://docs.xen-orchestra.com/xo5/object-storage-support#supported-storage-providers) but don't say much about part-size tuning.
If it's awkward to test in isolation, a mention to @Team-XO-Backend is probably the quickest route, since they own the backup job code.
The XVA checksum warnings in your second screenshot look like a separate non-blocking clean VM directory step rather than the cause.
I hope that points somewhere useful!

nice catch
and the mirror path is easier to fix . Thaks @pedro_udifar and @poddingue we will fix it asap

will it be possible to test a potential fix @pedro_udifar , since it's often specific to a provider ( and need huge VM to work )?

florent

now that I am in front of the source code , it is already getting the real size, so it should compute the right size

are the source or destination encrypted ?

florent

@pedro_udifar we have found a clue , if the destination is encrypted and the source is not

can you test this branch ? https://github.com/vatesfr/xen-orchestra/pull/10061
if you are using a xoa, we can deploy the fix if you open a support tunnel

fbeauchamp opened this pull request in vatesfr/xen-orchestra

open fix(fs): compute the output stream precisely when encrypted #10061

pedro_udifar

Hello Poddingue and Florent,

I started duplicating "default" minPartSize but the larger VMs we're still failing to mirror. After that, I found that Bacblaze has a recommended chunk size of minPartSize=100000000 and, with this setting, all my VMs completed without that specific error.
(My largest VM compressed backup is about 450 GB)

https://www.backblaze.com/docs/cloud-storage-large-files
In my case, the recommendPartSize returned was 100000000.

Since I was also getting the other warnings "Issue checking XVA" and "XVA might be broken", most o f the times I would wipe de backblaze bucket and start with a new job no XO (so that I could be sure it was not about the retention settings of this mirror job).

Replication source is on a local NFS Ztsd compressed, not encripted.
Replication destinations is Backblaze with encription. Object lock is turned off (XO can delete and change the files without restrictions)

I'm still getting the XVA warnings and my next step was to run a test turning encription on, on the local 1st tier nfs remote.

The sizes reported locally and on backblaze have very different sizes, which I guess is to be expected on this scenario.

Local:

Backblaze:

In my planned backup pipeline, I am planning to turn on object lock on backblaze, making sure it's aligned with mirror retention settings on XO thoug I'm not sure this will work nice with metadata json files. What do you guys think?

I'll gladly test the fix when it's ready. Is already commited?

Thank you for your help,
Pedro

florent

@pedro_udifar object lock works quite well with xo
it is automatically detected if the s3 user has enough privilege to see if object lock is enabled

the main point is that it won't create "cache.json.gz" files since theses files must be updated, so the backup listing is a little slower

note that XO retention should be at least 1 more than object lock . At worst you will have error , saying that XO coudn't delete an old backup

The fix is on a separated branch : fix_s3_nonencrypted_to_encrypted_xva ( PR : https://github.com/vatesfr/xen-orchestra/pull/10061 )

fbeauchamp opened this pull request in vatesfr/xen-orchestra