Clarification Requested: Archiving/Backup Copy

[micoolpaul]

Hi,

Hoping for some extra info on this note within the VBM365 helpcenter:

Data in backup copies has a different storage format as those created by backup jobs: blob files in backup copies are larger. Repacking of backed-up data is performed by either Veeam Backup for Microsoft 365 backup proxy or an auxiliary archiver appliance that Veeam Backup for Microsoft 365 can create in Microsoft Azure or Amazon EC2.

Link: https://helpcenter.veeam.com/docs/vbo36 ... ackup-copy

I understand on the surface, what is being said, but I’d like to know about the WHY behind this decision. Ultimately, Veeam must’ve had a reason as to why the files are larger. I can only assume to reduce the number of more expensive read API calls to archive storage.

It’d also be really helpful to have any insights on how this impacts storage consumption & network bandwidth for recoveries vs normal backups, such as archives are on average X-Y% larger and due to the file structure change, the recovery of items typically has an extra Z% overhead on network bandwidth.

Again, just unsure how much consolidation of files into a single blob may be happening now, detail is really light!

Any & all insights would be greatly appreciated so we know how best to approach this.

Thanks,
Michael

[HannesK]

Hello,

reduce the number of more expensive read API calls to archive storage

yes, that's it.

I'm not sure I got the other questions. Simplified example: if a source repository has 100 objects à 1MB (100MB overall), then the converted object for archive tier would still be 100MB.

With backup and restores, everything stays the same. No change here. To restore from the copy, the data first needs to be retrieved (from "archive" storage to "hot" storage). Restore from archive is more expensive because Amazon and Microsoft charge for the retrieval from archive storage.

Best regards,
Hannes

[micoolpaul]

Hi Hannes,

Thanks I wanted to make no assumptions that the 'different storage format' mentioned didn't involve any reprocessing that changed underlying file size we were working with as an example.

Thanks for your answer.