Cloud Connect storage versus Regular Cloud storage

[mbmn]

I am having trouble understanding the difference between the more expensive per TB Cloud Connect services and something like Azure Cool Tier storage service

My intent is to have an onpremise physical server running Veeam that would have onprem NFS volumes mounted and provide a VTL interface to the cloud. I would then backup data on the NFS volumes to the cloud via the Veeam VTL.

I am going to be adding 30TB of data every month and the data will have an infinite retention in the cloud and the cloud will be the sole backup location of this data. I'd like to use the Azure cool tier at $0.01 per GB or $10.24 per TB. Can my onprem physical Veam server just interface with Azure cool tier directly?
When I look at "Cloud Connect " enabled services the price per TB is much higher. The cheapest seems to be $45 per TB. What is the difference with the "Cloud Connect" storage services versus Cool Tier?

Do I need to run a VM in Azure to interface with my onprem physical Veeam server?

[Steve-nIP]

Veeam 10 comes with a ton of enhancements with regards to S3 Storage integration and copy jobs, but one can already today send "old" backups to S3 using a Scale-out repository. I guess the biggest difference is, you've got no-one to help you if problems arise. I'm sure others can chime in with their experience.

[mbmn]

I need to wait for Veeam 10 to be able to use Azure cool tier storage directly via Veam Backup/Replication sw?

There is not support for Azure cool tier? Only cloud connect branded storage? Functionally there is no difference? I thought that with Cloud Connect there was different functionality. Does either plain Azure Cool Tier or CloudConnect require an additional VM in the cloud to partner with my onprem veem physical?

[soncscy]

Hey mbmn,

No, there already is Azure Blob Storage via Capacity Tier. What Steve meant was advancements in the current method, as only "old" backups can be offloaded. My way of explaining it to my clients is that because Veeam has transforming backups (forever forward incremental namely), where the contents of the Full backup changes, only "inactive" backups which are guaranteed not to change will be sent up to Azure/S3. I read that there is a change to this in v10 to make it more immediate.

But right now, if you have the licensing, you can make a Scale Out Repository, add your Azure Blob Storage as Capacity tier (not sure on the different Azure tiers, but This says Cool is A-okay so I think you're fine.

[mbmn]

Thanks that helps. So I'll have a physical linux server onprem, running Veeam backup/replication. It will be acting as an nfs client to mount our NFS volumes where the source data is that needs to be backedup to Azure blob capacity.

Veeam will read the data from the nfs mounted on the veeam server and write only full backups to Azure blob. Will that work? Any issues I should be concerned about?

I keep hearing people say you need a place to "land the data" before it goes to the cloud. But in my above scenario it doesn't appear necessary when doing all straight fulls. If you tell me I really need an intermediary 'landing storage" between the source nfs and the destination azure blob...i would just mount another NFS volume to the veeam server for this...but it seems inefficient to have Veeam pull data off of source NFS, push it to landing storage NFS, only to immediately move it to azure blob and all onprem copies deleted. The only place the backup should exist is in Azure blob once the backup is done

[Gostev]

The only place the backup should exist is in Azure blob once the backup is done

That would represent the fatal data protection design flaw though, as the 3-2-1 rule of backups requires at least two copies of backups residing on a different media.

Not to mention that keeping a few most recent restore points on-prem is the only way to ensure fast operational restores and meet required RTOs.

[mbmn]

Hi Gostev - I understand the point you are making, but I don't believe it is applicable in our case. We endlessly receive lossless source audio files from providers that we immediately encode into lower bitrate media files for distribution. To store all of these files as the lossless input is basically a couple dozen petabytes. Historically we have only had to restore data from this lossless archive once in 7 years. Due to the lowest cost/GB we have stored this accumulating lossless archive on LTO tape..., but now going forward we are putting it in the cloud. We simply can't afford the scale of storing this multi-petabyte lossless cataloge in the cloud AND locally on disk. It has to get off our disk to and into the cloud quickly, but we expect to be able to restore that data (if we should need to, but probably won't for years) from the cloud with the backup of it in the cloud being all the input we need with whatever local/transient copy long deleted once the backup was done and initially stored in the cloud.

We would use the source lossless media to re-encode the lower bitrate media if we lost the lower bitrate media which is itself on redundany tier 1 hardware.

I just want to fully confirm. Yes, we do have to backup the NFS source lossless data to a second onprem landing storage location that will also be NFS for the duration of the Veeam backup, but after that is done Veeam can copy it to the cloud (Azure cool tier) and we can delete the local copies of the data and immediately proceed with the next backup rinsing and repeating the same process over and over?
Thanks

[Gostev]

No, you cannot delete local copies of the data, as this will break things and the job will start failing. All data management operations must be performed by the scale-out repository itself.

It sounds like your scenario is best addressed by doing VTL to object storage (so, same approach as you had with tapes).

[mbmn]

So with VTL to object storage I use my onprem VBR that has a Cloud VTL configured and points to Azure Cool Blob via S3 protocol? When the backup job runs it reads the source music NFS mounts and copies it into the VTL which physically resides in Azure blob cool tier? The VTL avoids the intermediary "landing storage" and local copy of all the data backups?

[Gostev]

Yep.