Skip to main content

Its getting hot … and cheap !

Welcome back after a longer break since the last blogpost.
Meanwhile I`m one of the main responsible german counterparts for Veeam Backup for Microsoft Office 365. Over the last month I saw a lot of different environments with various challenges, while there is a big transformation from on-premise repositories to object storage as well.
Today I want to share my experience with the community.
Whenever I`m involved in bigger projects, at some point in time we have a price discussion about repository costs with the customer. With the flexibility in Veeam you can choose whatever you want as a repository. There is no „vendor lock-in“ or any risk in loosing data if you want to change f.e the backup software in future.
For sure there are some pros & cons when you are choosing your object storage repository. So let me start what you need to consider and why:

Considerations

  • Size (always matters...):
    Your very first step to start your decision journey: Please use our calculator to figure out how much capacity you need for backing up your data: https://calculator.veeam.com/vbo
  • Price :
    Some vendors offer different pricings depending on the needed repository space. The price will be charged on a monthly basis and depends on the GBs you store. But there is a huge difference between vendors, country and additional costs. You will get the pricing information on the providers website. (Or check out our pricing calculator https://www.backupbros.com/2020/11/03/vbo-calculator-community-edition-v2/)
  • Additional costs:
    Whenever we are using object storage in the cloud there are a lot of ingress/egress/API-calls and a lot of providers will charge them extra. Dont be afraid! we are NOT talking about 1000 of dollars. But you also can`t neglect them. There are some vendors without additional API billing to keep it as simple and transparent for you as possible. But sometimes they can be more expensive.
    There also exists transfercosts (f.e. https://azure.microsoft.com/de-de/pricing/details/bandwidth/). If you run your VBO-environment i.e. in Microsoft Azure and you are using your object storage on AWS the transfer-costs from the VM will be charged additonally.
    When you are using Azure VM with Blob, or AWS EC2 with S3 within the same datacenter no additional transfer costs will be charged.
  • Performance:
    The performance part is not that important when we look into object storage. Our data flow (VBO) is through a local cache which should be a fast (SSD) disk. The object storage is the secondary tier and will receive the data from the local chache. So there is no need to use a „hot“ storage. You can use a cold storage with infrequent access. Archive-repositories are not supported as a primary  target.
  • Archive:
    We introduced our new archive feature for version 6 (Beta will come soon). This archive tier can be used as a secondary target for long term retention copys. Not all vendors do offer an archive storage and for sure it must be supported also from Veeam side. Please consider this in your decision.
  • Connection:
    The connection of an object storage or their providers can be ignored. If we see a bottlneck, it`s mostly the customers WAN link or the throttling when we are backing up data through the Microsoft-API.  

Its getting hot

Wasabi (www.wasabi.com) is one of my favorit object storage providers because they fulfill nearly each of my requirements with a very easy and good pricing.

DISCLAIMER: This is a private blog and this is an unpaid advertising ! I just like products with an easy to use and reliable approach … like Veeam 

Wasabi has a „flat rate“ pricing : $5.99 per TB/month . Each started TB will be charged completely.
There are NO additonal API-Call costs or any other hidden costs. 5.99$ and everything is included. You can make your pricing comparision by your own: https://wasabi.com/cloud-storage-pricing/#three-info
Start with a free trial – 1 TB space for 30 days. You can extend this trial by contacting their support if you need more time for testing.

Wasabi setup guide

Here is a short walk through how to setup:

  • Login to wasabi:
www.wasabi.com
  • Go to Buckets an klick on „create bucket“
    • Select bucket name and region
    • Click „Create bucket“
  • Go to Access Keys
    • Click „Create new access key“ (root user)
    • Download CSV or copy Access key
  • Go to Veeam Backup for Microsoft Office 365 -> Backup Infrastructure
  • Click on Object Storage Repositories and add a new repository
  • Type a name
  • Select „S3 Compatible“
  • Enter the Servicepoint adress. You can find the wasabi Servicepoints here: https://wasabi-support.zendesk.com/hc/en-us/articles/360015106031-What-are-the-service-URLs-for-Wasabi-s-different-storage-regions- (depending on location you selected when created the bucket). Enter the right date center region ! And add your access key + secret key from the downloaded CSV-File or your clipboard when we created the bucket.
    The format of the CSV is „ ,ACCESSKEY,SECRETKEY „
  • Define the folder where you want to store your backupdata. In bigger environments it make sense to create different folders for different Services (Mail, Onedrive, Sharepoint etc.) or different Jobs. When you create a seperate repository folder for each service, it is necessary to add an own caching folder !
  • Go to Backup Repositorys and create the Cache-repository:
  • Define a name and select the path where the cache folder should be placed
  • Check „Offload backup data to object storage“ and select your wasabi repository. If you want you can additional add object storage encryption by entering a password (DO NOT LOOSE IT !)
  • Select your prefered retention and click finish

    Now you are ready to point your backupjobs to the new repository and start testing your wasabi object storage!
    Enjoy you new hot object storage!

Very interesting article.  Nice to see the options for S3 with O365 backups.


Wow, very detailled and interesting article.

Thank you.


Very informative!


@bene  Good information !


Thanks for this post @bene. I would say, that especially for VBO it makes sense to go with cloud storage.

It would just be great if we could backup directly to S3/Blob storage without the local cache; something like a temporary proxy VM in AWS/Azure which does all the work. That way you could have VBO for management on-premises and keep the dataflow in the cloud.


Great post @bene, thx for sharing this.


Thanks for this post @bene. I would say, that especially for VBO it makes sense to go with cloud storage.

 

I have one single issue with that design. No 3-2-1-1-0 Rule. For a service provider, i think it is necessary to have a second copy of the vbo365 backup data. It‘s really importan to have a second copy if a disaster happens to the first copy of the customers o365 data on my backup repos. We have a responsibility to the customers data.

 

And there is no ransomware protection built in to vbo365.

If you go 100% object storage for your vbo365 data, how do you secure your backups. There are very easy deletable from the vbo365 server. And every second copy of the data on the object storage will be deleted too, because the storage policy will replicate this changes to all object storage nodes, if you have multiple data centers.

There is no versioning support, there is no object lock support yet.

My company has decided to stay on legacy disk until veeam delivers a solution to use the 3-2-1-1-0 rule with object storage backup repos for vbo365. Or some sort of an object lock feature is built in vbo365, like for vbr.

Wirh legacy disk storage, you can use VBR or Veeam Agent to create a second independent copy of the data to copy it to a tape or to a capacity with object lock activated.

 


Good point @Mildur! As long as we don't have immutability for the VBO backups, this is an advantage of disk based backup. 


I agree with @Mildur , but Veeam told me on VeeamON 2021 that by the end of this year a copy-job in VBO365 would be possible. Still no immutable solution yet...


I agree with @Mildur , but Veeam told me on VeeamON 2021 that by the end of this year a copy-job in VBO365 would be possible. Still no immutable solution yet...

Copy Jobs would be very nice so look forward to that. :smiley:


I agree with @Mildur , but Veeam told me on VeeamON 2021 that by the end of this year a copy-job in VBO365 would be possible. Still no immutable solution yet...

Yes, but no immutability. And it‘s only for cloud archiv storage.

We are using onPremise Object Storage :)


Hello, thanks for the sharing!
I m looking to implement VBO with Wasabit but I have a little question where do you deploy your Veeam VBO/Proxy ? 

 


Hello, thanks for the sharing!
I m looking to implement VBO with Wasabit but I have a little question where do you deploy your Veeam VBO/Proxy ? 

 

You typically will deploy them either on-premise or in a cloud space depending on your setup.


Nice topic @bene , I’ll give a try in lab for sure!

@Chris.Childerhose , @Mildur and @Nico Losschaert it’s always a great learning to read you guys :)


Dear SME’s, I have a req to deploy VBO on Azure and configure it with blob storage. 

Q: what will be the best place to have the “cache” folder location. shall i put it in the default c:\cache or make a seperate drive? 

 

If a seperate drive? what would be the capaciti of this ? I have a total maiboxes of 500 to backup. 

 

looking forward for a resolution.. 


Hi @HDsouza 

Cache size depends on the source size of data you want to backup. For Exchange Backups, the cache should be around 0.2%-1.0% of your mailbox data.

I would create a dedicated ssd disk for the cache. Technically C should work, but I don‘t like putting such data on the OS disk.

 

You can read more about it here:

https://bp.veeam.com/vbo/guide/design/sizing/objectstorage.html


Dear @Mildur Thanks for shedding some light. 

 

“0.2%-1.0% of your mailbox data” : I beleive this % is the entire backups size? 


@HDsouza 

Your welcome.

If you follow my link, the Best Practice Guide tells us, it‘s 1 percent from the source size, not backup size.

You can use Veeam‘s VBM Calculator to see how much cache is needed:

https://calculator.veeam.com

 

 

As a rule of thumb provide ~1% of the source data size as local cache for metadata for the object storage repository.


Thanks  @Mildur :bulb:


Hello, I have one query, From my on-premise Veeam backup server for O365, can I backup directly to object storage.


Hello, I have one query, From my on-premise Veeam backup server for O365, can I backup directly to object storage.

Direct to object is not supported in VBM365.  You can add OBS but not go direct to it.


Hello, I have one query, From my on-premise Veeam backup server for O365, can I backup directly to object storage.

Direct to object is not supported in VBM365.  You can add OBS but not go direct to it.

I would say it depends on the definition of direct 😅 You can backup directly to object storage, but the connection/traffic goes through the Veeam 365 backup proxy.


Hello, I have one query, From my on-premise Veeam backup server for O365, can I backup directly to object storage.

Direct to object is not supported in VBM365.  You can add OBS but not go direct to it.

I would say it depends on the definition of direct 😅 You can backup directly to object storage, but the connection/traffic goes through the Veeam 365 backup proxy.

Yes very true there but I assumed the repo was meant to be OBS itself not block for metadata. 😁


Comment