Estimating Azure Blob write operations

[dtwiley]

Is there any way of estimating write operations if we know how much data transfer we estimate?

For Cool storage with regular daily copy jobs from on-premise, we're seeing a higher cost against write operations than storage itself. Obviously for high its the other way around.

What I'd like to do is work out which will be the best policy based on data transfer but I don't know how data transfer equates to write operations. I'd have thought we could calculate this but its not clear how.

What we're up against is cloud backup providers which just provide a per GB cost, so when we quote Veeam with Azure Blob, its very difficult to estimate costs other than using stored data which isn't always the biggest cost.

I guess i'm asking what block size Veeam use for Azure Repos, would that give me what i want or is it not that simple?

[dtwiley]

Or does it inherit the block size from the job settings storage optimisation for the original backup job its copying?

[tyler.jurgens]

The block size for the job is inherited from the original backup job, unfortunately.

I have a feature request posted here: post504078.html#p504078 for that setting to be configurable on backup copy jobs and capacity/archive tier.

[mr_jjjj]

I'm also wondering this - what is the recommended (or default) block size when using blob storage as a backup repository (so not a backup copy but a straight backup job)?

[ericschott_OF]

For any estimate need to say a bit more about what your doing. ie primary backups, are you using immutability? What is your schedule for retention, GFS ?

Are you using active fulls?
what type of blob storage?
does the data compress?

Azure Cool does charge more for put requests, and it charges a minimum storage duration, so for primary backups (or initial destination for a copy job), it may not be the best choice....the devil is in the details I ask about above...

[mr_jjjj]

The most typical scenario is forever incremental (which is the default when using blob storage) stored to Azure Cool Tier, without immutability but with data compression (again, default settings for backup to blob storage). I'm not sure what the retention schedule has to do with number of write operations, but say

I've had cases where the write operations cost as much if not more than the actual storage and I'm guessing it's from having an incorrect block size setup.

[ericschott_OF]

Without immutability, put operations are primarily adding data to the blob storage. The scheduling matters as it affects the amount of data, (as does the overall data size, compression ration, etc).

Again as an initial landing area for a primary job, performance tier sobr or copy job, I'm not sure cool is the best choice given the likely turn over in retention and minimum durations of cool tier. The details matter to know.

[m.novelli]

I have many customers exporting backups to Azure, after years of knowledge I've moved all of them to Hot Storage, is cheaper than Cool Storage and you don't have to worry about writes (stupid cloud providers...)

Marco