9.5 Update 4 and Microsoft Azure Blob Storage

[veremin]

a) technically would already be possible to do a restore/IR of a VM directly to azure with "full speed", bypassing slower internet links (so that the data would be directly written/read from azure to azure)

As long as you use Azure proxy in this scenario, traffic should stay isolated to Azure. Thanks!

[thomas321]

Hi guys,

just to recap:

Our current understanding is that Veeam will be able to move backups/restore points to blob once a certain retention time is hit.

Examples:
a) 60 restore points should be kept on local NAS, archive is enabled for everything older 30 days
This means up to 30 days/restore points will not be replicated off-site?!
This is critical in case of a site disaster scenario as the recent restore points are not off-site

b) 60 restore points should be kept on local NAS, archive is enabled for everything older 1 day
This means up to 1 days/restore points will not be replicated off-site?!
This will allow quick replication to off-site but will make common restores very slow and expensive
as we would have only 1 restore point on-site?!

Is this correct?

Thanks!

[Gostev]

Replicating backups off-site is a totally separate process that is handled by Backup Copy jobs in Veeam. Backup Copy jobs will continue to operate normally whether or not you enable archiving of older backups to an object storage, creating and maintaining the required number of backups off-site.

[MikePettit]

Hi Thomas,

Yes, you can move backups to the blob after a certain retention has hit with scale out repositories. However, based on your examples and concerns, I think you want to use copy jobs.

a) Yes, if you setup a scale out repository that has a 30 day retention, and you had 60 restore points, it would move 30 days to the blob and keep 30 days onsite. As you mentioned, this would not be good if there was a disaster and you counted on these backups for restoration, as they'd be 30 days old at best.

b) This is where it gets interesting. The only backups that can be moved via scale out repository are any backups that come before the last full backup. Meaning that if you wanted to have the data moved every day, you will need to do full backups every day. In essence, the previous backup chain must be closed by another full backup in order for it to move. There must always be a full backup onsite. So that presents two problems for this scenario. One, you have to do full backups every day. Two, you would only have one backup copy onsite.

Based on your concerns, I think you want to use copy jobs. That will backup the data locally and then copy the data to the cloud, leaving a current set locally and an almost-current set in the cloud. You could probably mix in the archiving piece to keep older backup sets, but your primary goal seems to need copy jobs.

Therein lies the problem that we face today, we cannot target azure blob with copy jobs. We can target azure VMs with data disks, a much more expensive option, which is what I'm doing right now. Or you can setup a Service Provider storage and have the copy job target that. There are some decent options there.

Gostov has given us hope that copy jobs will eventually be able to send data to azure blob and perhaps other archive tiers. But hopefully it's not too late.

[alesovodvojce]

In near future will Veeam announce Azure for SOBR (Scale-out Backup repositories).
This way to have infinite backup storage and use Azure as a capacity tier. More details somewhere here on forums.

There are several best practices to build Veeam backup system onprem right.
For instance not to join VBR server to Active directory and to choose different passwords from other servers on the network. So even if the domain get compromised, the backups still should remain safe.

We have hybrid AD scenario (onpremise + Azure AD) and thinking about backups to coud-Azure.
Should we use the same Azure environment for backups or create new, isolated one?
And any other best practices?

Best, Petr

[PTide]

Hi,

Should we use the same Azure environment for backups or create new, isolated one?

Personally I would go with an isolated one. From my point of view the fact that the other AD is on Azure does not make a big difference in case it got compromised.

Regarding other best practices, please use our forum search engine, here are some examples:

veeam-tools-for-microsoft-azure-f36/off ... 48905.html
vmware-vsphere-f24/best-practice-for-se ... 44351.html

Thanks!

[alesovodvojce]

I did search prior asking, but cannot find any coherent source of recommendation. Still see it missing. Thanks @PTide for the other point.

[networkup]

any estimates on a release date yet please?

[Gostev]

We've shipped the first release candidate build for internal and private beta use by our systems engineers a few days ago, which means the RTM build should be out in the next few weeks.

[crackocain]

Hi

What kind of blob storage is supported?

-Block Blobs
-Azure Data Lake Storage
-Managed Disks
-Files

https://azure.microsoft.com/en-us/prici ... s/storage/

[Gostev]

This > Azure Blob Storage

[crackocain]

Hi Anton

Thank you for your response. I'm enter the pricing link and Blob options came out. It's confusing

Block Blobs(0.002$) is enough? Or we must buy the Files? (0.06$)

Thank you.

[veremin]

Block Blobs(0.002$) is enough?

Enough. Thanks!

[gummett]

Please note that 'ARCHIVE' class block blobs can't be written to or read from, only HOT and COLD.
From https://azure.microsoft.com/en-us/prici ... age/blobs/: "For blobs in Archive, the only valid operations are GetBlobProperties, GetBlobMetadata, ListBlobs, SetBlobTier, and DeleteBlob. Setting the tier from Archive to Hot or Cool typically takes up to 15 hours to complete"

[crackocain]

Hi Ed

We are evaluating Cool type blob. Availability and latency restrictions. Archive Blob maybe use tiering.

Thank you.

[veremin]

As mentioned, Cool as well as Hot access tier should work without any issues, while Archive one will not be support in the initial release. Thanks!

[crackocain]

Thank you Vladimir.

I'm assumed at start Archieve Tier is enough but it was not good fit. If it isn't supported good to know.

Cool blob 0.016$/gb per month is affordable price for my customers.

[veremin]

Correct, Cool tier will be the cheapest option for storing the data (besides Archive, of course), but the cost for data retrieval and removal will be a bit higher for this access tier. Thanks!

[Gostev]

I would like to re-emphasize what Vladimir said.

One important thing to keep in mind with public cloud object storage is transaction costs to actually put your data there. Most people only look at actual storage costs, so API costs always come as a nasty surprise along with the first bill. While of course, API costs are negligible for data archiving use cases, such as offloading GFS backups to the cloud and keeping them there for a few years - they may hurt when we're talking about just a few months, easily doubling your bill. And I am not even talking about performing restores yet.

The good news is not all cloud object storage providers charge you for API. The bad news is that both Microsoft and Amazon do.

[martimartin12]

data repositories feature for Azure block blob storage will be avaliable on Veeam 10 ? or also its supported with Veeam 9.5 ?
Veeam 10 have already released ? or when it will be ?

[wishr]

Hi Martin,

Welcome to Veeam Community Forums and thanks for posting.

Support for Azure Blob Storage as scale-out backup repository Capacity Tier will be released as a part of Veeam B&R 9.5 Update 4 that is planned to be GA soon. Please stay tuned for updates.

I've moved your post to an existing Azure Blob Storage discussion thread - please take a quick look.

Thanks

[djecak]

Maybe this is a stupid question, but how to restore a VM from Azure Blob Storage?

[anthonyspiteri79]

Hey there Ermin.

Once you have data tiered into Azure Blob via the Capacity Tier extent you can perform all normal Veeam restore operations against that VM. We don't treat it any differently. If the data blocks resides in the Capacity Tier we will pull them down for the restore and in addition to that we have a feature that will look at the local backup files for similar blocks and if found, pull them from the local extents instead of the Capacity Tier.

[djecak]

Thanks Anthony.
So, basically, I have to move it again from capacity to performance tier, in order to be able to restore it. Correct?

[anthonyspiteri79]

Negative, that is done automatically. We track which blocks are where and pull them as required.

[djecak]

Excellent!
So, what happens if I lose original Veeam backup server? Can I still restore that data from object storage by deploying new Veeam server and adding that same blob storage as backup repository?
I assume backup metadata should be sitting in that blob storage as well.
Thanks!

[anthonyspiteri79]

That's correct. We keep a copy of the metadata in the Object Storage for this very reason. The only thing to consider there is that you only have backup data that is outside of the operational restore window policy you set. ie. If you set it to 7 days you will only be able to resync metatdata locally from the Capacity Tier older than that.

[garypigott]

The only thing to consider there is that you only have backup data that is outside of the operational restore window policy you set. ie. If you set it to 7 days you will only be able to resync metatdata locally from the Capacity Tier older than that.

So that means this isn't a traditional off-site backup per-se. If you want to be able to recover your most recent backup after a site loss, you still need an off-site repository or a Cloud Connect copy. This is really just a method of parking old, low-value data to cheap cloud disk.

[anthonyspiteri79]

Exactly right Gary.

It's about moving data off to what is essentially cheaper storage while retaining full repo functionality...extending the SOBR to be truly scaleable. There is only 1 copy of the backup data at any one time.

Cloud Connect Backup is still the best way to satisfy the 3-2-1 rule of backup and get a copy offsite for archival purposes.

[Gostev]

So that means this isn't a traditional off-site backup per-se. If you want to be able to recover your most recent backup after a site loss, you still need an off-site repository or a Cloud Connect copy. This is really just a method of parking old, low-value data to cheap cloud disk.

NB: Well said.