Backup architecture for Azure retention and replication

[akraker]

I am trying to design a backup architecture for our on-prem systems that covers all my bases. I already have the B&R console installed and doing on-site backups and replication. I mainly need an off-site solution and would like to utilize Azure for this while being as cost conscious as possible. I want to have off-site backups and replication that would allow us to fail-over to a cloud environment in the event of disaster on-site. This brings up a lot of questions.
1. Do I run an instance of B&R and create a VPN between on-prem and Azure to do backup copy jobs and replication from the backup copies?
2. Do I spin up Cloud Connect in Azure with replication resources and skip the VPN?
3. Could I just utilize the direct backup to Azure blob as a repository? If I do this, maybe I can just use the "Restore to Azure" function directly from the Azure blob repository? If this is a possibility would that allow me to pay only for blob storage and then spin up a virtual environment on-demand in the event of a disaster?

I'd like to hear your suggestions around this. It seems like there are multiple options for how this could be setup.

[oleg.feoktistov]

Hi Andrew,

First, just to clarify regarding your 3rd point, you cannot backup directly to Object storage as a standalone repository. You can use it as a Capacity Tier in scope of SOBR with copy policy configured as explained here.
That being said, 3rd option looks the most concise to me. In this case, cloud-wise you will pay only for putting data to object storage, keeping it there and retrieving in the event of disaster.

Thanks,
Oleg

[akraker]

Okay. The restore to Azure as described HERE is showing the backup point being uploaded to Azure blob from an on-prem repository. Is it possible to have this work directly from the backups in the blob storage if I were to setup the scale out repository to use Azure? I am just trying to think in terms of a situation where the on-prem repository is not available and/or we want to restore to Azure without waiting for files to be uploaded.

Another though would be maybe I could have a VM built with Veeam B&R connected to the same scale out repository blob in case of total on-prem site failure and just leave it shutdown unless it is needed to spin up.

I am not all that familiar with the capabilities of blob storage so tell me if I am not making any sense.

[oleg.feoktistov]

Sure, if on-premise repositories are not available along with VBR server, you can spin up a new VBR in Azure, import backups from Azure Blob Storage and perform any restore you like. Have a look at this discussion.

[akraker]

That is exactly what I was looking for. Thank you.
Sounds like I should be able to spin up a machine in Azure and have it connected to the blob storage and just shutdown the machine until it is (hopefully never) needed for a DR situation.
It does bring up another question though. In that situation would I just use the Restore from backup option and restore the VM's to the Azure VBR server or would I use the restore to Azure option? Is the Veeam backup proxy just an instance of VBR with the proxy role installed?

[oleg.feoktistov]

In that situation would I just use the Restore from backup option and restore the VM's to the Azure VBR server...

I am not quite sure what do you mean by that. If you choose to restore directly to Azure, VM disks are converted to the VHD format and VMs become of Azure Compute type. If you want to restore back to on-premise (by choosing "Entire VM restore"), a dedicated Azure to on-premise connection would be needed.

Is the Veeam backup proxy just an instance of VBR with the proxy role installed?

It is either VBR server itself (by default) or a dedicated server hosting Veeam Data Mover Service to process backup data flow.

[akraker]

What I meant was to have a VBR instance running in Azure connected to the Azure blob. That server would also have the Hyper-V role installed and then I could potentially restore from the Azure blob repository directly to that Hyper-V server.

[oleg.feoktistov]

Got it. That's also applicable.

[akraker]

I just need to test out which option is more practical. Are either or both of those scenarios able to failback changes back to the on-prem environment?

[oleg.feoktistov]

Yes, both options are viable in this case. First looks more practical to me though if moving back to on-premise with lower RTO is required. Having VMs restored to a nested Hyper-V in Azure, to replicate back to your on-premise datacenter it would take VBR server, a dedicated VPN connection and a target hypervisor. When it comes to VMs restored directly to Azure Compute, you would need to backup them with Backup for Azure first to restore back to on-premise.
Check out more discussions on this topic here. Thanks!

[akraker]

Okay. SO I am going to test out the option of running VBR in Azure and attaching to Azure Object storage. I will have the VBR instance turned off unless failover is needed. The VBR instance will be Server 2019 with Hyper-V role so that I can restore VM's to it instead of direct to Azure Compute. Sounds like a solid setup?

One question about Azure Blob storage... I have the Scale-Out repository set to copy jobs to the scale-out repository as well right away in order to have a better RPO in Azure instead of just moving backups after they time out. How does Veeam handle these backup jobs in comparison to the local backups? I have a weekly synthetic full being created locally. Does this also happen on the Azure Blob simultaneously or is it just going to copy the full backup over to Azure after it is created locally? I'm not too sure it is practical for a full backup to be copied over every week. Is there some way that the Object storage repositories maintain their own retention copies without the need to have full backups transferred over the internet every week?

[oleg.feoktistov]

SO I am going to test out the option of running VBR in Azure and attaching to Azure Object storage. I will have the VBR instance turned off unless failover is needed. The VBR instance will be Server 2019 with Hyper-V role so that I can restore VM's to it instead of direct to Azure Compute. Sounds like a solid setup?

Sounds about right.


Well, to begin with, Object Storage has no file system. So, no backup files, just blocks and metadata. As for the logic, VBR uses block cloning method similar to ReFS/XFS and transfers only unique blocks to Capacity Tier. The blocks that have been already transferred are reused. It is all explained in this section. Cheers!

[Mikeymas]

with Stonefly Smart Cloud connect you can backup to Azure and restore from Azure directly without download, upload from azure. your RTO is just the time to restore from azure to azure. It is similar to your on-prem storage for backup and restores. I think this is the solution you are looking for.
https://stonefly.com/smart-cloud-gateway
https://stonefly.com/resources/technical-videos

[soncscy]

with Stonefly Smart Cloud connect you can backup to Azure and restore from Azure directly without download, upload from azure. your RTO is just the time to restore from azure to azure. It is similar to your on-prem storage for backup and restores. I think this is the solution you are looking for.
https://stonefly.com/smart-cloud-gateway
https://stonefly.com/resources/technical-videos

This entire site gives me really bad voodoo vibes

Why add a 3rd party product to do what the product I'm paying for already does? Stonefly's site is filled with non-sense buzzwords and their white papers are locked behind spam-walls (first one I could access, subsequent access required a phone number. Just to read a darn whitepaper on how they actually do anything they claim to). The videos being narrated by some speech synth also doesn't give me warm fuzzies...

I don't see the benefit of Stonefly at at all here except to line someone's pocket, and frankly posts like the above reads as really spammy.

https://stonefly.com/veeam-cloud-backup-replication

Can anyone from Veeam comment, is Stonefly __really__ a Veeam Partner? Looking on Veeam Ready, I don't see Stonefly anywhere.

[akraker]

Seems spammy to me too soncscy

Back to my thread. I thought I saw somewhere that Veeam does not support use of lifecycle management rules in Azure. Is this only true of Cool to Archive rules or can I also not do hot to cool lifecycles? I am not sure I need to do this yet, just curious if I can or not.
Also, Veeam will delete data from the blob in accordance with my retention settings in the backup job right?

[Mikeymas]

They are Technolgy alliance partner and Veeam cloud Service provider.serach in the directory
https://www.veeam.com/wp-how-to-deploy- ... azure.html
Their focus is Veeam Backup and DR (spinup) is Azure and AWS
This seems to be a solution to this problem. just a suggestion

[soncscy]

Given that you cannot even seem to correct the red squiggles in your browser, I think I'll continue to wait for a Veeam employee to respond Also, your link is to a whitepaper, it doesn't address why Stonefly isn't on VeeamReady.

@Andrew, from what I know, life cycling is not allowed 100%, regardless of the tiering you do. From what I've read on the Capacity Tier structure, it makes sense -- the app looks to expect certain files to be in a certain place, and shuffling that around without the app knowing seems like a recipe for trouble.

For retention, from experience, it's tied to the source job retention. I've seen it with clients where the blocks get cleaned up during other offload jobs and they slowly phase out. Keep in mind that this is about "blocks", not backup files. A backup file might be reused due to how incremental backups work, so it's blocks that get cleaned out.

[akraker]

soncscy,
Thanks. Why does it seem like block/blob storage works better than a normal repository? No weekly "virtual full backup" processing, no merging incrementals, no error checking and defragmenting, etc. It just seems much simpler to manage without any downside. Is there a downside to object based storage repositories?

[soncscy]

Hey, you're welcome

Capacity Tier took a bit for me and my team to get until we really understood what "extension of performance tier" meant. Capacity tier is meant to bolster performance tier, not to replace it. The operations you can do on performance tier you cannot do in capacity tier (the API costs would be insane), BUT!, the end result of performance tier saving space and doing the operations is immediately reflected in capacity tier. It's kind of brilliance for me, to be honest. Instead of trying to fight with full files, they just took the BitTorrent approach with blocks. Blocks are malleable, repeatable/resusable, and most importantly, independent. If a block isn't needed, it's discarded. For me that is some seriously cool tech.

The downside I've seen with my clients is that you have to be hands-off -- capacity tier can be fragile in the same sense that if you were to edit a backup file with a hex editor, you can really cause some damage. Veeam seems to think that people read documentation and are patient enough to not muck about on their buckets, but this is not the case, and I've already had a lot of long conversations with clients who could not keep their hands off the offloaded data.

There's an element of trust you need to have that the app works as expected, and I think that's one of the main catches.

For me, what helped it click was that Capacity Tier isn't a Secondary Backup, it's an extension of existing backups and repositories. Clients who want GFS in an immutable space? Send it to AWS with immutability. Clients who want a copy on Azure/AWS in case ransomware hits locally? Copy Mode with immutability (for amazon anyways)

The downside to Capacity Tier for me is that you need to offload it (expected, unavoidable), and that it's highly dependent on the existing structure. I'd love to see some additional resilience for "super blocks" from Veeam (i.e., heavily referenced blocks), but I think the current offering is strong.

Understand it as a last resort, not your primary backup, and you're golden. If you want to just copy the full files to S3 without worry, don't bother with capacity tier, just use any storage gateway app and rsync.

[akraker]

Funny. I went to create my VBR VM in Azure and there is no VM's available to be provisioned in any size in Azure North Central where by blob storage is.

When I am able to create a VM should I attach my blob storage directly to the VM or just add a VBR object based repository the same way I did on the on-prem instance?

[oleg.feoktistov]

From what I know, life cycling is not allowed 100%, regardless of the tiering you do. From what I've read on the Capacity Tier structure, it makes sense -- the app looks to expect certain files to be in a certain place, and shuffling that around without the app knowing seems like a recipe for trouble.

@soncscy, 100% correct.

@akraker, you need to attach it as an object storage repository through VBR console, as you normally do.
Thanks!