Skip to main content
  • EN

Inspired by @Geoff Burke‘s post about immutability for Kasten with Wasabi, I decided to post the same for Veeam Backup & Replication. If you want to check out Geoff’s post, then follow this link:

What/who is Wasabi?

Probably Wasabi doesn’t need to be introduced. But if you can only think about the paste you get with Sushi, then you should check out their cloud object storage. Besides AWS and Microsoft, Wasabi is one of the Vendors, who often gets recommended for usage with Veeam Backup. The reason for that is their really competitive pricing, combined with great functionality/quality and low complexity.

How to create an immutable bucket

After registering an account with Wasabi, the creation of an immutable bucket isn’t complicated at all.

Just make sure that you select the right region for your location, and also enable bucket versioning and object locking.

Afterwards you need to create an access key. For testing purposes you can use the root account key, but for production you should create a dedicated user with limited permissions. I’ll write a separate post about this in the next time.

Add Wasabi to Veeam

Next you need to add the newly created bucket as a S3 compatible object storage repository.

 

Depending on the region you have selected, you will have to use a specific service point/URL. Visit this site to find out the corresponding URL: https://wasabi-support.zendesk.com/hc/en-us/articles/360015106031-What-are-the-service-URLs-for-Wasabi-s-different-storage-regions-

Select your bucket and create a new folder, specific to your Veeam repository. I would always suggest to limit the object storage consumption. This way a misconfiguration doesn’t create excessive costs.

And, most importantly, don’t forget to configure the immutable time interval in days.

Next steps

For now, we can only copy existing backups to an object storage with scale-out repository and the capacity tier. So your finaly step will be, to create the scale-out repository and define how you want to upload/copy your backups to Wasabi.

In v12 this may change, as it’s planned to implement direct backup to object storage.

Hidden secret in v12

If you add an object-storage in v12, you might see a small change in the dialog. 😉

 

Great post.  I use Wasabi and have it configured on my homelab in a SOBR.  Really great for just my small things I test and my upload to Wasabi is almost a full 1GB speed which is nice.  😎

I have seen new the new dialog as I am using v12 Beta2 for testing. 😁

Great article @regnor! I love that Wasabi is a first class citizen now in v12, nice to see something other than the hyperscalers being name dropped!

 

Appreciate you collating the support materials too for endpoint names etc, gonna be using Wasabi for my M365 backup (I don’t like the idea of backing up M365 to Azure personally), so I’ll be using this to speed through gathering that detail!

Hey @drews they are talking about you!

Great post.  I use Wasabi and have it configured on my homelab in a SOBR.  Really great for just my small things I test and my upload to Wasabi is almost a full 1GB speed which is nice.  😎

I have seen new the new dialog as I am using v12 Beta2 for testing. 😁

Their performance so far has been really more than ok. During a restore to Azure I’ve seen ~2Gbit/s in parallel.

@MicoolPaul In v12 you don’t event need to enter the URLs as they’re hardcoded; only the region needs to be entered. Storing the backups at a different provider makes sense; not only because of the different infrastructure but also the seperation of access/control.

Great post.  I use Wasabi and have it configured on my homelab in a SOBR.  Really great for just my small things I test and my upload to Wasabi is almost a full 1GB speed which is nice.  😎

I have seen new the new dialog as I am using v12 Beta2 for testing. 😁

Their performance so far has been really more than ok. During a restore to Azure I’ve seen ~2Gbit/s in parallel.

@MicoolPaul In v12 you don’t event need to enter the URLs as they’re hardcoded; only the region needs to be entered. Storing the backups at a different provider makes sense; not only because of the different infrastructure but also the seperation of access/control.

Wow 2GB very nice! 👍

Brilliant post @regnor Really simple and straightforward to implement. 

Very interesting and detailled post. Thank you @regnor 

Thank you @regnor for the kind words regarding your experience with Wasabi.
We’re stoked to make the short list of named parters in VBR v12!
If anyone is currently using the Wasabi free trial as part of an evaluation and needs more than 30 days, please send an email over to support@wasabi.com, tell them I sent you, and we’ll get you an extension!

Thank you @regnor for the kind words regarding your experience with Wasabi.
We’re stoked to make the short list of named parters in VBR v12!
If anyone is currently using the Wasabi free trial as part of an evaluation and needs more than 30 days, please send an email over to support@wasabi.com, tell them I sent you, and we’ll get you an extension!

Thank you!

Thank you @regnor for the kind words regarding your experience with Wasabi.
We’re stoked to make the short list of named parters in VBR v12!
If anyone is currently using the Wasabi free trial as part of an evaluation and needs more than 30 days, please send an email over to support@wasabi.com, tell them I sent you, and we’ll get you an extension!

That's great, thanks @drews! 👏 Especially if you're working with immutability for the first time, more than 30 days can be necessary or useful.

Hi all, I just wonder if it’s possible to make veeam configuration backup immutable by sending it to Wasabi Bucket with immutability.

In fact, I configured a new Wasabi repo with immutability configured. I select this repository for Veeam backup Config but files seems not to be immutable as I can delete them 🤔

Thanks for your answer

Configuration backups cannot be immutable - as far as I know...

Configuration backups cannot be immutable - as far as I know...

Yes, I agree with this while they can go to Object storage now, I don’t believe immutability applies.

I just targeted for fun my wasabi object locked repo it accepts it.

 

 

I just targeted for fun my wasabi object locked repo it accepts it.

You can, but it’s not immutable :)

I just targeted for fun my wasabi object locked repo it accepts it.

You can, but it’s not immutable :)

Thanks @Mildur 

I have looked for an official statement, but did not find any...

Should I back up directly to Wasabi or back up local and copy over?   I am backing up a Hyper V Server with over a Terabyte.

Thank you @regnor for sharing and great post

Should I back up directly to Wasabi or back up local and copy over?   I am backing up a Hyper V Server with over a Terabyte.

I would always keep as many copies as possible. I have dealt with a lot of situations when something did not work as expected and the extra copy saved the day. If finances allow I would have local and offsite. 

For a more literate explanation of keeping extra copies look no further than here https://www.veeam.com/blog/321-backup-rule.html where the @Rick Vanover 

and here @Nico Losschaert 

 

Should I back up directly to Wasabi or back up local and copy over?   I am backing up a Hyper V Server with over a Terabyte.

Good advice from @Nico Losschaert and @Geoff Burke  → My point of view on back up directly to or do a copy is to consider your restore options. If it is 1TB of backups, direct to the object storage is likely fine. If we are talking 1 PB, I’d be weary of having to egress that much when you need it.

 

So, for now, I’m recommending copies to object storage. Exception would be edge, endpoints or other information that would give me more specifics @Mudslide03 → And that’s a cool name → Watch out for a shout out on the recap. Heads up @safiya 

Should I back up directly to Wasabi or back up local and copy over?   I am backing up a Hyper V Server with over a Terabyte.

I would always keep as many copies as possible. I have dealt with a lot of situations when something did not work as expected and the extra copy saved the day. If finances allow I would have local and offsite. 

For a more literate explanation of keeping extra copies look no further than here https://www.veeam.com/blog/321-backup-rule.html where the @Rick Vanover 

and here @Nico Losschaert 

 

Thanks Geoff.   I am following the 3-2-1 rule.   This is an additional backup so I can have one on Immutable storage.   My concern was it taking several days to run the backup directly to Wasabi which affects my other backups.

Should I back up directly to Wasabi or back up local and copy over?   I am backing up a Hyper V Server with over a Terabyte.

Good advice from @Nico Losschaert and @Geoff Burke  → My point of view on back up directly to or do a copy is to consider your restore options. If it is 1TB of backups, direct to the object storage is likely fine. If we are talking 1 PB, I’d be weary of having to egress that much when you need it.

 

So, for now, I’m recommending copies to object storage. Exception would be edge, endpoints or other information that would give me more specifics @Mudslide03 → And that’s a cool name → Watch out for a shout out on the recap. Heads up @safiya 

Thanks Rick.    Wasabi is just for my Immutable storage backup so hopefully I will only be egressing it twice a year for a restore test and never need it otherwise.   Mudslide03 is my online persona since 2003 based on my favorite cocktail, Thanks!

If would only do direct backups if bandwidth and therefore the backup window doesn't become a problem. In all other cases go with Backup Copy or capacity tier as those are much more flexible for offloading backups.

Should I back up directly to Wasabi or back up local and copy over?   I am backing up a Hyper V Server with over a Terabyte.

I would always keep as many copies as possible. I have dealt with a lot of situations when something did not work as expected and the extra copy saved the day. If finances allow I would have local and offsite. 

For a more literate explanation of keeping extra copies look no further than here https://www.veeam.com/blog/321-backup-rule.html where the @Rick Vanover 

and here @Nico Losschaert 

 

Thx @Geoff Burke for mentioning my ever first post that made the recap 🤣

@Mudslide03 : strong advice, always - always - always apply the  3-2-1-1-0 rule as described in my post and also what @Rick Vanover recommend. There is also another post of @MicoolPaul : Veeam B&R v12 - Backup Direct to Object Storage! | Veeam Community Resource Hub.

There were also a lot of comments, also from me.

My recommendation : always try to create a primary backup as fast as possible, so the production is being minimal impacted. So this has to be done locally!!! Afterwards you can create as many copies as you want to where you want. The source hypervisor is not impacted anymore, only the primary repository, network towards the secondary repository. Next you that you have always 2 backups if one should fail. Try to accomplish this always and make no exception. I have see too many issues by not applying the golden backup rule. That’s why I always explain this to my customers that this the thing we always start with. @Rick Vanover finds this also very important, and I agree with him, this has be on top of the backup design 😃

Comment


Terms & Conditions